Re: [Regression] Problem with rfkill on 2.6.38

Re: [Regression] Problem with rfkill on 2.6.38

[Johannes Berg]

Hi Colin,

[Matthew, everybody from the platform list, please see
http://mid.gmane.org/ip6j66$o5f$1@dough.gmane.org for the full email
thread]

Sorry, took me a while to get back to your email.

> wifi works fine generally, but after cycling RFKILL I have to reload the
> various modules before it works again.


> [root@jimmy ~]# rmmod dell_laptop

I'm pretty sure this one's at fault, see below.

> Turn back on:
> 
> iwlagn 0000:0b:00.0: RF_KILL bit toggled to enable radio.

See, iwlwifi just reports this from the hw.

> usb 4-2: new full speed USB device using uhci_hcd and address 4

And your BT USB device shows up on the bus too. But then:

> iwlagn 0000:0b:00.0: RF_KILL bit toggled to disable radio.

> usb 4-2: USB disconnect, address 4

iwlwifi reports that it was killed, and your BT USB device disappears.

> I've been looking through the various commits that could come into play
> (although I am sure there are others):

All the commits you listed are related to iwlwifi only. However, we can
see that both wifi and BT are killed again. Therefore, iwlwifi can't be
at fault (its rfkill line is basically a GPIO input, it can't cause BT
to drop from the bus).

The consequence is that the fault must be with dell_laptop, the BIOS is
the only thing that can be causing both to be rf-killed. (I'd also
suspect rfkill, but it has no changes since 2.6.37)

johannes

Re: [Regression] Problem with rfkill on 2.6.38

[Colin Guthrie]

Hiya,


No worries about the late reply... was running around for the last
couple weeks at various events so haven't had a chance to test any other
suggestions yet anyway.

'Twas brillig, and Johannes Berg at 09/05/11 09:36 did gyre and gimble:
>> > [root@jimmy ~]# rmmod dell_laptop
> I'm pretty sure this one's at fault, see below.

Looking at the only commit available for this module on this cycle I see:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.38.y.git;a=commit;h=a3d77411e8b2ad661958c1fbee65beb476ec6d70

dell-laptop: Toggle the unsupported hardware killswitch

It is found on Dell Inspiron 1018 that the firmware reports that the
hardware killswitch is not supported. This makes the rfkill key not
functional.

This patch forces the driver to toggle the firmware rfkill status in the
case that the hardware killswitch is indicated as unsupported by the
firmware.





This looks pretty suspicious to me (from the description) and sounds
like this could be an unintended consequence of the changes here.

I'll see if reverting this one fixes the issue. Thanks for the insights!

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

Re: [Regression] Problem with rfkill on 2.6.38

[Colin Guthrie]

Hi all,

'Twas brillig, and Johannes Berg at 09/05/11 09:36 did gyre and gimble:
> [Matthew, everybody from the platform list, please see
> http://mid.gmane.org/ip6j66$o5f$1@dough.gmane.org for the full email
> thread]
> 
> Sorry, took me a while to get back to your email.
> 
>> wifi works fine generally, but after cycling RFKILL I have to reload the
>> various modules before it works again.
> 
> 
>> [root@jimmy ~]# rmmod dell_laptop
> 
> I'm pretty sure this one's at fault, see below.

Just a quick (non-compile) followup from my last email... blacklisting
the dell-laptop module works around the issue, so I think the commit
previously mentioned is indeed the culprit (as it's the only recent
commit and does fiddle with the rfkill stuff).

Not sure what the best track forward is, but it's certainly a
regression, so should probably be fixed or reverted until a more
complete fix is found.

Cheers

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

Re: [Regression] Problem with rfkill on 2.6.38

[Matthew Garrett]

On Mon, May 09, 2011 at 06:09:27PM +0100, Colin Guthrie wrote:

> Just a quick (non-compile) followup from my last email... blacklisting
> the dell-laptop module works around the issue, so I think the commit
> previously mentioned is indeed the culprit (as it's the only recent
> commit and does fiddle with the rfkill stuff).
> 
> Not sure what the best track forward is, but it's certainly a
> regression, so should probably be fixed or reverted until a more
> complete fix is found.

If you can confirm that with a build then I'll do that.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [Regression] Problem with rfkill on 2.6.38

[Colin Guthrie]

'Twas brillig, and Matthew Garrett at 09/05/11 18:11 did gyre and gimble:
> On Mon, May 09, 2011 at 06:09:27PM +0100, Colin Guthrie wrote:
> 
>> Just a quick (non-compile) followup from my last email... blacklisting
>> the dell-laptop module works around the issue, so I think the commit
>> previously mentioned is indeed the culprit (as it's the only recent
>> commit and does fiddle with the rfkill stuff).
>>
>> Not sure what the best track forward is, but it's certainly a
>> regression, so should probably be fixed or reverted until a more
>> complete fix is found.
> 
> If you can confirm that with a build then I'll do that.

ACK. Reverting that commit and unblacklisting the dell_laptop module
restores the previous, working functionality. I've flipped rfkill a few
times and it's always worked fine.

Many thanks.

Col


-- 

Colin Guthrie
mageia(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Regression] Problem with rfkill on 2.6.38

[Keng-Yü Lin]

On Tue, May 10, 2011 at 11:36 AM, Colin Guthrie <mageia-D409yXkIzt2rnn0nCzrM/w@public.gmane.org> wrote:
> 'Twas brillig, and Matthew Garrett at 09/05/11 18:11 did gyre and gimble:
>> On Mon, May 09, 2011 at 06:09:27PM +0100, Colin Guthrie wrote:
>>
>>> Just a quick (non-compile) followup from my last email... blacklisting
>>> the dell-laptop module works around the issue, so I think the commit
>>> previously mentioned is indeed the culprit (as it's the only recent
>>> commit and does fiddle with the rfkill stuff).
>>>
>>> Not sure what the best track forward is, but it's certainly a
>>> regression, so should probably be fixed or reverted until a more
>>> complete fix is found.
>>
>> If you can confirm that with a build then I'll do that.
>
> ACK. Reverting that commit and unblacklisting the dell_laptop module
> restores the previous, working functionality. I've flipped rfkill a few
> times and it's always worked fine.
>

May I have the model of your Dell laptop?

dell_latop has a debugfs node in /sys/kernel/debug/dell_latop/rfkill,
can you attach the logs at both the moment when the radio devices are
enabled and disabled? the output of the command `rfkill list` at both
moments will helpful too.

In my experience that different models of Dell laptop may have
different reaction/behaviour on the rfkill handling. Reverting the
patch may make your laptop working, but can cause others non-working.

It should make sense and be appreciated that you attach more debug
information for investigation on the bug.

  Thanks,
-kengyu
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Regression] Problem with rfkill on 2.6.38

[Colin Guthrie]

'Twas brillig, and Keng-Yü Lin at 10/05/11 15:48 did gyre and gimble:
> On Tue, May 10, 2011 at 11:36 AM, Colin Guthrie <mageia-D409yXkIzt1YnqJbiw7iEA@public.gmane.orge> wrote:
>> 'Twas brillig, and Matthew Garrett at 09/05/11 18:11 did gyre and gimble:
>>> On Mon, May 09, 2011 at 06:09:27PM +0100, Colin Guthrie wrote:
>>>
>>>> Just a quick (non-compile) followup from my last email... blacklisting
>>>> the dell-laptop module works around the issue, so I think the commit
>>>> previously mentioned is indeed the culprit (as it's the only recent
>>>> commit and does fiddle with the rfkill stuff).
>>>>
>>>> Not sure what the best track forward is, but it's certainly a
>>>> regression, so should probably be fixed or reverted until a more
>>>> complete fix is found.
>>>
>>> If you can confirm that with a build then I'll do that.
>>
>> ACK. Reverting that commit and unblacklisting the dell_laptop module
>> restores the previous, working functionality. I've flipped rfkill a few
>> times and it's always worked fine.
>>
> 
> May I have the model of your Dell laptop?

Absolutely! I have a Inspiron 6400 MM061. The WIFI PCI card is an after
market addition (upgrade from bg only to agn), but I suspect that
particular detail is unimportant.

> dell_latop has a debugfs node in /sys/kernel/debug/dell_latop/rfkill,
> can you attach the logs at both the moment when the radio devices are
> enabled and disabled? the output of the command `rfkill list` at both
> moments will helpful too.

OK, do you want this on the previous kernel (with the problem commit in
it) or the one when I've reverted it?

Here is the info from the reverted kernel (as I'm running it now!):

Wifi+BT starts enabled.


status: 0x1030C
Bit 0 : Hardware switch supported:   0
Bit 1 : Wifi locator supported:      0
Bit 2 : Wifi is supported:           1
Bit 3 : Bluetooth is supported:      1
Bit 4 : WWAN is supported:           0
Bit 5 : Wireless keyboard supported: 0
Bit 8 : Wifi is installed:           1
Bit 9 : Bluetooth is installed:      1
Bit 10: WWAN is installed:           0
Bit 16: Hardware switch is on:       1
Bit 17: Wifi is blocked:             0
Bit 18: Bluetooth is blocked:        0
Bit 19: WWAN is blocked:             0

hwswitch_state: 0x3
Bit 0 : Wifi controlled by switch:      1
Bit 1 : Bluetooth controlled by switch: 1
Bit 2 : WWAN controlled by switch:      0
Bit 7 : Wireless switch config locked:  0
Bit 8 : Wifi locator enabled:           0
Bit 15: Wifi locator setting locked:    0


$ rfkill list
0: dell-wifi: Wireless LAN
  Soft blocked: no
  Hard blocked: no
1: dell-bluetooth: Bluetooth
  Soft blocked: no
  Hard blocked: no
3: phy0: Wireless LAN
  Soft blocked: no
  Hard blocked: no
8: hci0: Bluetooth
  Soft blocked: no
  Hard blocked: no




<PRESS SWITCH TO DISABLE>


status: 0x6030C
Bit 0 : Hardware switch supported:   0
Bit 1 : Wifi locator supported:      0
Bit 2 : Wifi is supported:           1
Bit 3 : Bluetooth is supported:      1
Bit 4 : WWAN is supported:           0
Bit 5 : Wireless keyboard supported: 0
Bit 8 : Wifi is installed:           1
Bit 9 : Bluetooth is installed:      1
Bit 10: WWAN is installed:           0
Bit 16: Hardware switch is on:       0
Bit 17: Wifi is blocked:             1
Bit 18: Bluetooth is blocked:        1
Bit 19: WWAN is blocked:             0

hwswitch_state: 0x3
Bit 0 : Wifi controlled by switch:      1
Bit 1 : Bluetooth controlled by switch: 1
Bit 2 : WWAN controlled by switch:      0
Bit 7 : Wireless switch config locked:  0
Bit 8 : Wifi locator enabled:           0
Bit 15: Wifi locator setting locked:    0


$ rfkill list
0: dell-wifi: Wireless LAN
  Soft blocked: yes
  Hard blocked: yes
1: dell-bluetooth: Bluetooth
  Soft blocked: yes
  Hard blocked: yes
3: phy0: Wireless LAN
  Soft blocked: no
  Hard blocked: yes


> In my experience that different models of Dell laptop may have
> different reaction/behaviour on the rfkill handling. Reverting the
> patch may make your laptop working, but can cause others non-working.

Yes I suspect so, but as this is still a regression in behaviour, it
should still be reverted by policy I believe (not that it shouldn't be
fixed properly of course!)

> It should make sense and be appreciated that you attach more debug
> information for investigation on the bug.

Sure, I fully appreciate the need for this. Please feel free to ask me
for any other additional details and/or testing etc.

All the best.

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Regression] Problem with rfkill on 2.6.38

[Colin Guthrie]

'Twas brillig, and Keng-Yü Lin at 10/05/11 15:48 did gyre and gimble:
> On Tue, May 10, 2011 at 11:36 AM, Colin Guthrie <mageia@colin.guthr.ie> wrote:
>> 'Twas brillig, and Matthew Garrett at 09/05/11 18:11 did gyre and gimble:
>>> On Mon, May 09, 2011 at 06:09:27PM +0100, Colin Guthrie wrote:
>>>
>>>> Just a quick (non-compile) followup from my last email... blacklisting
>>>> the dell-laptop module works around the issue, so I think the commit
>>>> previously mentioned is indeed the culprit (as it's the only recent
>>>> commit and does fiddle with the rfkill stuff).
>>>>
>>>> Not sure what the best track forward is, but it's certainly a
>>>> regression, so should probably be fixed or reverted until a more
>>>> complete fix is found.
>>>
>>> If you can confirm that with a build then I'll do that.
>>
>> ACK. Reverting that commit and unblacklisting the dell_laptop module
>> restores the previous, working functionality. I've flipped rfkill a few
>> times and it's always worked fine.

Just wondering if there was any progress on this. I ACKed a regression
but it was not reverted.... I thought the standard practice was to
revert until a fuller fix was found.

I appreciate some other users will not get their fix but I was still
under the impression that this was the policy?

I don't see any relevant changes in the 2.6.39 kernel:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.39.y.git;a=history;f=drivers/platform/x86/dell-laptop.c;h=de301aa8e5c3799620ff5a06372b5e1942c2dab2;hb=HEAD

nor in Linus' 2.6 tree (which I presume is actually for 3.0 these days?):
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=history;f=drivers/platform/x86/dell-laptop.c;h=d3841de6a8cf199ec08b24bd85f50a0af0490d37;hb=HEAD


> May I have the model of your Dell laptop?
snip....

I supplied all this info before here:
http://thread.gmane.org/gmane.linux.kernel.wireless.general/68758

Anything else I can do to move this forward?

Col



-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

Re: [Regression] Problem with rfkill on 2.6.38

[Keng-Yü Lin]

Sorry for the late reply.

After looking into this a bit I agree with you the patch should be reverted.

On Fri, Jun 24, 2011 at 6:54 PM, Colin Guthrie <gmane@colin.guthr.ie> wrote:
> 'Twas brillig, and Keng-Yü Lin at 10/05/11 15:48 did gyre and gimble:
>> On Tue, May 10, 2011 at 11:36 AM, Colin Guthrie <mageia@colin.guthr.ie> wrote:
>>> 'Twas brillig, and Matthew Garrett at 09/05/11 18:11 did gyre and gimble:
>>>> On Mon, May 09, 2011 at 06:09:27PM +0100, Colin Guthrie wrote:
>>>>
>>>>> Just a quick (non-compile) followup from my last email... blacklisting
>>>>> the dell-laptop module works around the issue, so I think the commit
>>>>> previously mentioned is indeed the culprit (as it's the only recent
>>>>> commit and does fiddle with the rfkill stuff).
>>>>>
>>>>> Not sure what the best track forward is, but it's certainly a
>>>>> regression, so should probably be fixed or reverted until a more
>>>>> complete fix is found.
>>>>
>>>> If you can confirm that with a build then I'll do that.
>>>
>>> ACK. Reverting that commit and unblacklisting the dell_laptop module
>>> restores the previous, working functionality. I've flipped rfkill a few
>>> times and it's always worked fine.
>
> Just wondering if there was any progress on this. I ACKed a regression
> but it was not reverted.... I thought the standard practice was to
> revert until a fuller fix was found.
>
> I appreciate some other users will not get their fix but I was still
> under the impression that this was the policy?
>
> I don't see any relevant changes in the 2.6.39 kernel:
>
> http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.39.y.git;a=history;f=drivers/platform/x86/dell-laptop.c;h=de301aa8e5c3799620ff5a06372b5e1942c2dab2;hb=HEAD
>
> nor in Linus' 2.6 tree (which I presume is actually for 3.0 these days?):
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=history;f=drivers/platform/x86/dell-laptop.c;h=d3841de6a8cf199ec08b24bd85f50a0af0490d37;hb=HEAD
>
>
>> May I have the model of your Dell laptop?
> snip....
>
> I supplied all this info before here:
> http://thread.gmane.org/gmane.linux.kernel.wireless.general/68758
>
> Anything else I can do to move this forward?
>

I am happy to form the revert patch if necessary.

Re: [Regression] Problem with rfkill on 2.6.38

[John W. Linville]

On Fri, Jun 24, 2011 at 08:29:33PM +0800, Keng-Yü Lin wrote:
> Sorry for the late reply.
> 
> After looking into this a bit I agree with you the patch should be reverted.
> 
> On Fri, Jun 24, 2011 at 6:54 PM, Colin Guthrie <gmane@colin.guthr.ie> wrote:

> > I supplied all this info before here:
> > http://thread.gmane.org/gmane.linux.kernel.wireless.general/68758
> >
> > Anything else I can do to move this forward?
> >
> 
> I am happy to form the revert patch if necessary.

Please do so -- I'm sure Matthew would appreciate it. :-)

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.