Hi,
RFKILL used to work fine on 2.6.37 for me but I have a regression on .38.
wifi works fine generally, but after cycling RFKILL I have to reload the
various modules before it works again.
I can turn the machine on with wireless (+bluetooth) enabled and if I
hit the rfkill switch (Fn+F2 on my machine) both wifi and bt turn off as
they should.
If I turn it back on again however, both of the lights turn on briefly
but then the wifi one goes out and bt follows shortly thereafter. The
only way I can find to get wifi back is to reboot or:
[root@jimmy ~]# rmmod btusb
[root@jimmy ~]# rmmod bluetooth
[root@jimmy ~]# rmmod dell_laptop
[root@jimmy ~]# rmmod iwlagn
[root@jimmy ~]# rmmod iwlcore
[root@jimmy ~]# rmmod mac80211
[root@jimmy ~]# rmmod cfg80211
[root@jimmy ~]# rmmod rfkill
[root@jimmy ~]# lsmod | grep rfk
<press button to enable>
[root@jimmy ~]# modprobe iwlagn
The dmesg is below (it's short enough to just paste in-line). What
appears to happen is that when re-enabling it, it will automatically
re-kill it again.
On and working -> Turn off:
iwlagn 0000:0b:00.0: RF_KILL bit toggled to disable radio.
iwlagn 0000:0b:00.0: Not sending command - RF KILL
iwlagn 0000:0b:00.0: Error sending REPLY_QOS_PARAM: enqueue_hcmd failed: -5
iwlagn 0000:0b:00.0: Not sending command - RF KILL
iwlagn 0000:0b:00.0: Error sending REPLY_RXON: enqueue_hcmd failed: -5
iwlagn 0000:0b:00.0: Error setting new RXON (-5)
iwlagn 0000:0b:00.0: Not sending command - RF KILL
iwlagn 0000:0b:00.0: Error sending REPLY_RXON_ASSOC: enqueue_hcmd failed: -5
wlan0: deauthenticating from 00:24:01:c5:4a:16 by local choice (reason=3)
iwlagn 0000:0b:00.0: Not sending command - RF KILL
iwlagn 0000:0b:00.0: Error sending REPLY_REMOVE_STA: enqueue_hcmd failed: -5
iwlagn 0000:0b:00.0: Error removing station 00:24:01:c5:4a:16
iwlagn 0000:0b:00.0: Not sending command - RF KILL
iwlagn 0000:0b:00.0: Error sending REPLY_RXON_ASSOC: enqueue_hcmd failed: -5
iwlagn 0000:0b:00.0: Not sending command - RF KILL
iwlagn 0000:0b:00.0: Error sending REPLY_RXON: enqueue_hcmd failed: -5
iwlagn 0000:0b:00.0: Error setting new RXON (-5)
cfg80211: Calling CRDA to update world regulatory domain
iwlagn 0000:0b:00.0: Not sending command - RF KILL
iwlagn 0000:0b:00.0: Error sending REPLY_RXON: enqueue_hcmd failed: -5
iwlagn 0000:0b:00.0: Error setting new RXON (-5)
iwlagn 0000:0b:00.0: Failing on timeout while stopping DMA channel 1
[0xa5a5a5a2]
iwlagn 0000:0b:00.0: Failing on timeout while stopping DMA channel 3
[0xa5a5a5a2]
iwlagn 0000:0b:00.0: Failing on timeout while stopping DMA channel 4
[0xa5a5a5a2]
iwlagn 0000:0b:00.0: Failing on timeout while stopping DMA channel 6
[0xa5a5a5a2]
cfg80211: World regulatory domain updated:
cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain,
max_eirp)
cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
cfg80211: Calling CRDA for country: GB
cfg80211: Regulatory domain changed to country: GB
cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain,
max_eirp)
cfg80211: (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm)
cfg80211: (5250000 KHz - 5330000 KHz @ 40000 KHz), (N/A, 2000 mBm)
cfg80211: (5490000 KHz - 5710000 KHz @ 40000 KHz), (N/A, 2700 mBm)
usb 4-2: USB disconnect, address 3
Turn back on:
iwlagn 0000:0b:00.0: RF_KILL bit toggled to enable radio.
usb 4-2: new full speed USB device using uhci_hcd and address 4
usb 4-2: New USB device found, idVendor=413c, idProduct=8126
usb 4-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 4-2: Product: BCM2045
usb 4-2: Manufacturer: Broadcom Corp
ADDRCONF(NETDEV_UP): wlan0: link is not ready
iwlagn 0000:0b:00.0: RF_KILL bit toggled to disable radio.
<------------Problem here?
iwlagn 0000:0b:00.0: Not sending command - RF KILL
iwlagn 0000:0b:00.0: Error sending REPLY_RXON: enqueue_hcmd failed: -5
iwlagn 0000:0b:00.0: Error setting new RXON (-5)
iwlagn 0000:0b:00.0: Failing on timeout while stopping DMA channel 1
[0xa5a5a5a2]
iwlagn 0000:0b:00.0: Failing on timeout while stopping DMA channel 3
[0xa5a5a5a2]
iwlagn 0000:0b:00.0: Failing on timeout while stopping DMA channel 4
[0xa5a5a5a2]
iwlagn 0000:0b:00.0: Failing on timeout while stopping DMA channel 6
[0xa5a5a5a2]
usb 4-2: USB disconnect, address 4
FWIW, I already mentioned this problem here:
https://www.mageia.org/pipermail/mageia-dev/20110421/004124.html
Another user using the same kernel with the same hardware cannot
reproduce, so not quite sure what's causing the issue.
iwlagn : Intel Corporation|PRO/Wireless 4965 AG or AGN [Kedron]
Network Connection [NETWORK_OTHER] (vendor:8086 device:4229 subv:8086
subd:1101) (rev: 61)
I've been looking through the various commits that could come into play
(although I am sure there are others):
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.38.y.git;a=commitdiff;h=3dd823e6b86407aed1a025041d8f1df77e43a9c8
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.38.y.git;a=commitdiff;h=554d1d027b19265c4aa3f718b3126d2b86e09a08
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.38.y.git;a=commitdiff;h=6cd0b1cb872b3bf9fc5de4536404206ab74bafdd
What is odd about the 3dd8 commit is that there is code that says:
if (test_bit(STATUS_INT_ENABLED, &priv->status))
iwl_enable_interrupts(priv);
I presume test_bit returns "true" if the bit is set? If so, then the
call, is a little strange as iwl_enable_interrupts sets the bit again.
So it's only enabled if it's already set? Perhaps test_bit returns 0
when it's already set?
172 static inline void iwl_enable_interrupts(struct iwl_priv *priv)
173 {
174 IWL_DEBUG_ISR(priv, "Enabling interrupts\n");
175 set_bit(STATUS_INT_ENABLED, &priv->status);
176 iwl_write32(priv, CSR_INT_MASK, priv->inta_mask);
177 }
But I'm no kernel hacker, so all this could be rubbish.
Cheers in advance for any 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/]
On Tue, Apr 26, 2011 at 03:00:38PM +0100, Colin Guthrie wrote:
> RFKILL used to work fine on 2.6.37 for me but I have a regression on .38.
[snip]
> iwlagn 0000:0b:00.0: RF_KILL bit toggled to enable radio.
> usb 4-2: new full speed USB device using uhci_hcd and address 4
> usb 4-2: New USB device found, idVendor=413c, idProduct=8126
> usb 4-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
> usb 4-2: Product: BCM2045
> usb 4-2: Manufacturer: Broadcom Corp
> ADDRCONF(NETDEV_UP): wlan0: link is not ready
> iwlagn 0000:0b:00.0: RF_KILL bit toggled to disable radio.
> <------------Problem here?
That mean device see rf switch in state to disable radio.
> I've been looking through the various commits that could come into play
> (although I am sure there are others):
>
> http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.38.y.git;a=commitdiff;h=3dd823e6b86407aed1a025041d8f1df77e43a9c8
>
> http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.38.y.git;a=commitdiff;h=554d1d027b19265c4aa3f718b3126d2b86e09a08
You may want to revert these commits and see if that helps.
> http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.38.y.git;a=commitdiff;h=6cd0b1cb872b3bf9fc5de4536404206ab74bafdd
>
> What is odd about the 3dd8 commit is that there is code that says:
>
> if (test_bit(STATUS_INT_ENABLED, &priv->status))
> iwl_enable_interrupts(priv);
>
> I presume test_bit returns "true" if the bit is set? If so, then the
> call, is a little strange as iwl_enable_interrupts sets the bit again.
>
> So it's only enabled if it's already set? Perhaps test_bit returns 0
> when it's already set?
Sometimes function iwl_enable_interrupts() is called unconditionally
without STATUS_INT_ENABLED check. This part is generally ok.
If reverting 2 above commit will not help, you may wish to blacklist
all *wmi* and/or *acpi* modules. This problems looks more like platform
problem than rfkill core or iwlagn. If that will not help, bisection
will be needed to solve the issue.
Stanislaw
'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/]
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 | [email protected]
On Tue, May 10, 2011 at 11:36 AM, Colin Guthrie <[email protected]> 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
Hi Colin,
[Matthew, everybody from the platform list, please see
http://mid.gmane.org/[email protected] 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
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/]
'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 <[email protected]> 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/]
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/[email protected] 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/]
'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 <[email protected]> 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/]
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 <[email protected]> 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 <[email protected]> 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.
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 <[email protected]> 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
[email protected] might be all we have. Be ready.