Return-path: Received: from fg-out-1718.google.com ([72.14.220.155]:26481 "EHLO fg-out-1718.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754828AbYBMHma (ORCPT ); Wed, 13 Feb 2008 02:42:30 -0500 Received: by fg-out-1718.google.com with SMTP id e21so4313853fga.17 for ; Tue, 12 Feb 2008 23:42:28 -0800 (PST) Message-ID: <47B29F63.6050605@gmail.com> (sfid-20080213_074235_969268_87635A99) Date: Wed, 13 Feb 2008 08:42:27 +0100 From: drago01 MIME-Version: 1.0 To: Tomas Winkler CC: Dan Williams , linux-wireless , "Zhu, Yi" , "Cahill, Ben M" , ipw3945-devel Subject: Re: [ipw3945-devel] iwl3945 rfkill regression References: <1ba2fa240801261411x7bb437c9s31aea593537afeba@mail.gmail.com> In-Reply-To: <1ba2fa240801261411x7bb437c9s31aea593537afeba@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sender: linux-wireless-owner@vger.kernel.org List-ID: Tomas Winkler wrote: > On Jan 26, 2008 9:00 PM, drago01 wrote: > >> On Jan 22, 2008 9:24 PM, drago01 wrote: >> >>> On Jan 22, 2008 9:21 PM, Winkler, Tomas wrote: >>> >>>> >>>>> -----Original Message----- >>>>> From: drago01 [mailto:drago01@gmail.com] >>>>> Sent: Tuesday, January 22, 2008 10:12 PM >>>>> To: Winkler, Tomas >>>>> >>>>> Cc: ipw3945-devel; Cahill, Ben M; Zhu, Yi; linux-wireless >>>>> Subject: Re: [ipw3945-devel] iwl3945 rfkill regression >>>>> >>>>> On Jan 22, 2008 9:07 PM, Winkler, Tomas >>>>> >>>> wrote: >>>> >>>>>> I believe it's delaying uCode load to mac_start - still need to be >>>>>> polished. >>>>>> >>>>> ok, thx for the quick reply. >>>>> If you have any potential fixes I would be happy to test them ;) >>>>> >>>> Can you get me the sequence it is happening? RF kill switch is off >>>> before you power up the laptop or after, during association or in >>>> unassociated state..etc >>>> Thanks >>>> >>> I boot with rf kill off = device on >>> acciotate using NM >>> kill the card by pressing the rfkill (ie. setting it to on) >>> card is dead (like described in my first mail), until I relaod the module >>> the rfkill switch does not have any effect at this time. >>> >>> >> OK, I investigated a bit and it seems to be the "disable interrupt >> when device goes down" is the problem. >> In my case NetworkManager detected the rfkill and brought the device >> down, which caused the interrupt to be disabled. Now after pressing >> the rfkill again nothing happend. But if I bring the device back up >> the interrupt is enabled again and rfkill and the card is back to >> live. >> So in short disabling the interrupt in mac_stop breaks the hw rfkill >> while the interface is down. >> >> > > Thanks for investigating this, still didn't have to time to dig into it. > > ping?