Re: b43legacy-phy3: Radio hardware status changed to XXX
On Sat, Feb 06, 2010 at 06:54:44PM -0600, Larry Finger wrote: You can get the wireless-compat sources for kernel 2.6.26 and build that. Othersise, go to kernel.org and get the full sources. I opted for an upgrade first (debian lenny to debian squeeze). So I'm now at kernel version 2.6.32 and the problem is somehow different (still related to kill switch). The messages in this case are more clear (on ifconfig wlan0 ): b43legacy ssb0:0: firmware: requesting b3legacy/ucode2.fw b43legacy ssb0:0: firmware: requesting b3legacy/pcm4.fw b43legacy ssb0:0: firmware: requesting b3legacy/b0g0initvals2.fw b43legacy-phy0: Loading firmware version 0x127, patch level 14 (2005-04-18 02:36:27) b43legacy-phy0: Radio hardware status changed to DISABLED b43legacy-phy0: Radio turned on by software b43legacy-phy0: The hardware RF-kill button still turns the radio physically off. Press th ebutton to turn it on. Same suggestions applies ? Or was some load-time option added in 2.6.32 ? --strk; () Free GIS Flash consultant/developer /\ http://foo.keybit.net/~strk/services.html ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43legacy-phy3: Radio hardware status changed to XXX
2010/2/7 strk s...@keybit.net: On Sat, Feb 06, 2010 at 06:54:44PM -0600, Larry Finger wrote: You can get the wireless-compat sources for kernel 2.6.26 and build that. Othersise, go to kernel.org and get the full sources. I opted for an upgrade first (debian lenny to debian squeeze). So I'm now at kernel version 2.6.32 and the problem is somehow different (still related to kill switch). The messages in this case are more clear (on ifconfig wlan0 ): b43legacy ssb0:0: firmware: requesting b3legacy/ucode2.fw b43legacy ssb0:0: firmware: requesting b3legacy/pcm4.fw b43legacy ssb0:0: firmware: requesting b3legacy/b0g0initvals2.fw b43legacy-phy0: Loading firmware version 0x127, patch level 14 (2005-04-18 02:36:27) b43legacy-phy0: Radio hardware status changed to DISABLED b43legacy-phy0: Radio turned on by software b43legacy-phy0: The hardware RF-kill button still turns the radio physically off. Press th ebutton to turn it on. I'm not sure... if radio is turned off physically (by hardware) can compiling without RFKILL help at all? AFAIU rfkill is just for disabling radio by software... -- Rafał ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43legacy-phy3: Radio hardware status changed to XXX
On Sunday 07 February 2010 13:48:59 Rafał Miłecki wrote: 2010/2/7 strk s...@keybit.net: On Sat, Feb 06, 2010 at 06:54:44PM -0600, Larry Finger wrote: You can get the wireless-compat sources for kernel 2.6.26 and build that. Othersise, go to kernel.org and get the full sources. I opted for an upgrade first (debian lenny to debian squeeze). So I'm now at kernel version 2.6.32 and the problem is somehow different (still related to kill switch). The messages in this case are more clear (on ifconfig wlan0 ): b43legacy ssb0:0: firmware: requesting b3legacy/ucode2.fw b43legacy ssb0:0: firmware: requesting b3legacy/pcm4.fw b43legacy ssb0:0: firmware: requesting b3legacy/b0g0initvals2.fw b43legacy-phy0: Loading firmware version 0x127, patch level 14 (2005-04-18 02:36:27) b43legacy-phy0: Radio hardware status changed to DISABLED b43legacy-phy0: Radio turned on by software b43legacy-phy0: The hardware RF-kill button still turns the radio physically off. Press th ebutton to turn it on. I'm not sure... if radio is turned off physically (by hardware) can compiling without RFKILL help at all? AFAIU rfkill is just for disabling radio by software... rfkill is a hardware lock in the case of broadcom. Software can only read the state. (There may be laptops with broadcom cards where rfkill can be changed by software. But that's done by other means (BIOS) and the broadcom hardware doesn't know about it.) -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43legacy-phy3: Radio hardware status changed to XXX
2010/2/7 Michael Buesch m...@bu3sch.de: On Sunday 07 February 2010 13:48:59 Rafał Miłecki wrote: 2010/2/7 strk s...@keybit.net: On Sat, Feb 06, 2010 at 06:54:44PM -0600, Larry Finger wrote: You can get the wireless-compat sources for kernel 2.6.26 and build that. Othersise, go to kernel.org and get the full sources. I opted for an upgrade first (debian lenny to debian squeeze). So I'm now at kernel version 2.6.32 and the problem is somehow different (still related to kill switch). The messages in this case are more clear (on ifconfig wlan0 ): b43legacy ssb0:0: firmware: requesting b3legacy/ucode2.fw b43legacy ssb0:0: firmware: requesting b3legacy/pcm4.fw b43legacy ssb0:0: firmware: requesting b3legacy/b0g0initvals2.fw b43legacy-phy0: Loading firmware version 0x127, patch level 14 (2005-04-18 02:36:27) b43legacy-phy0: Radio hardware status changed to DISABLED b43legacy-phy0: Radio turned on by software b43legacy-phy0: The hardware RF-kill button still turns the radio physically off. Press th ebutton to turn it on. I'm not sure... if radio is turned off physically (by hardware) can compiling without RFKILL help at all? AFAIU rfkill is just for disabling radio by software... rfkill is a hardware lock in the case of broadcom. Software can only read the state. (There may be laptops with broadcom cards where rfkill can be changed by software. But that's done by other means (BIOS) and the broadcom hardware doesn't know about it.) So pressing something like Fn+FX can eventually be handled by BIOS and can cause hardware (physical) enabling radio? In such a case Broadcom hardware doesn't know about this (wow, that's weird), and so b43 driver doesn't know as well? As the result b43 doesn't try to run wireless. If we compile without rfkill we won't check for radio status, and we will just try to use radio, that may be enabled at some point by BIOS. Is my understand correct? Thanks for explaining Michael :) -- Rafał ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43legacy-phy3: Radio hardware status changed to XXX
On Sunday 07 February 2010 14:18:43 Rafał Miłecki wrote: So pressing something like Fn+FX can eventually be handled by BIOS and can cause hardware (physical) enabling radio? Yeah, could be the case. It could also be handled by another kernel driver (wmi). In no case will the wireless driver be able to modify the state. In such a case Broadcom hardware doesn't know about this (wow, that's weird), and so b43 driver doesn't know as well? As the result b43 doesn't try to run wireless. Well, the only thing the driver can do is _observing_ that the radio is killed. If we compile without rfkill we won't check for radio status, and we will just try to use radio, that may be enabled at some point by BIOS. Yeah. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43legacy-phy3: Radio hardware status changed to XXX
W dniu 7 lutego 2010 14:22 użytkownik Michael Buesch m...@bu3sch.de napisał: On Sunday 07 February 2010 14:18:43 Rafał Miłecki wrote: So pressing something like Fn+FX can eventually be handled by BIOS and can cause hardware (physical) enabling radio? Yeah, could be the case. It could also be handled by another kernel driver (wmi). In no case will the wireless driver be able to modify the state. In such a case Broadcom hardware doesn't know about this (wow, that's weird), and so b43 driver doesn't know as well? As the result b43 doesn't try to run wireless. Well, the only thing the driver can do is _observing_ that the radio is killed. Hm, AFAIR my old Acer Aspire 5024 was using acer-wmi module to manage (turn off) rfkill. I was using this with b43 driver so somehow in my case b43 (and hardware?) did know state of radio state... But you wrote: But that's done by other means (BIOS) and the broadcom hardware doesn't know about it so finally... when we are able to know rfkill status and when we are not? Is this like following? 1) If BIOS handles rfkill we don't know status of radio and radio doesn't know as well 2) If something like WMI handles rfkill, we know status of radio ? -- Rafał ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43legacy-phy3: Radio hardware status changed to XXX
On Sun, Feb 07, 2010 at 02:05:09PM +0100, Michael Buesch wrote: rfkill is a hardware lock in the case of broadcom. Software can only read the state. (There may be laptops with broadcom cards where rfkill can be changed by software. But that's done by other means (BIOS) and the broadcom hardware doesn't know about it.) Uhm, but still I'm pretty sure there's no physical switch on this laptop (L5800C). Also, if there was one, surely I wasn't turning it on and off continuosly to justify those notices coming down to b43legacy. Note that bcm43xx used to work fine. --strk; () Free GIS Flash consultant/developer /\ http://foo.keybit.net/~strk/services.html ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43legacy-phy3: Radio hardware status changed to XXX
On Sunday 07 February 2010 15:09:05 Rafał Miłecki wrote: W dniu 7 lutego 2010 14:22 użytkownik Michael Buesch m...@bu3sch.de napisał: On Sunday 07 February 2010 14:18:43 Rafał Miłecki wrote: So pressing something like Fn+FX can eventually be handled by BIOS and can cause hardware (physical) enabling radio? Yeah, could be the case. It could also be handled by another kernel driver (wmi). In no case will the wireless driver be able to modify the state. In such a case Broadcom hardware doesn't know about this (wow, that's weird), and so b43 driver doesn't know as well? As the result b43 doesn't try to run wireless. Well, the only thing the driver can do is _observing_ that the radio is killed. Hm, AFAIR my old Acer Aspire 5024 was using acer-wmi module to manage (turn off) rfkill. I was using this with b43 driver so somehow in my case b43 (and hardware?) did know state of radio state... But you wrote: But that's done by other means (BIOS) and the broadcom hardware doesn't know about it so finally... when we are able to know rfkill status and when we are not? Is this like following? 1) If BIOS handles rfkill we don't know status of radio and radio doesn't know as well 2) If something like WMI handles rfkill, we know status of radio ? We always know about the status of the radio (rfkill). We just can't modify it from within the broadcom device. The rfkill signal is a physical signal that goes into the broadcom radio. If that signal is turned to kill by the BIOS, there's nothing the broadcom chip can do about it. It will just show the state of that physical line to the driver via a bit in a register or via IRQ. So if rfkill can be switched by software, that is totally unrelated to b43. It's done by completely unrelated hardware registers that are not on the broadcom device or by other means (BIOS calls, etc...). -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43legacy-phy3: Radio hardware status changed to XXX
On Sunday 07 February 2010 15:30:18 strk wrote: On Sun, Feb 07, 2010 at 02:05:09PM +0100, Michael Buesch wrote: rfkill is a hardware lock in the case of broadcom. Software can only read the state. (There may be laptops with broadcom cards where rfkill can be changed by software. But that's done by other means (BIOS) and the broadcom hardware doesn't know about it.) Uhm, but still I'm pretty sure there's no physical switch on this laptop (L5800C). Also, if there was one, surely I wasn't turning it on and off continuosly to justify those notices coming down to b43legacy. Note that bcm43xx used to work fine. I'm not talking about possible bugs in the software. I'm just explaining how the hardware works, because I think there's some confusion here. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43legacy-phy3: Radio hardware status changed to XXX
On Sun, Feb 07, 2010 at 03:37:36PM +0100, Michael Buesch wrote: On Sunday 07 February 2010 15:30:18 strk wrote: On Sun, Feb 07, 2010 at 02:05:09PM +0100, Michael Buesch wrote: rfkill is a hardware lock in the case of broadcom. Software can only read the state. (There may be laptops with broadcom cards where rfkill can be changed by software. But that's done by other means (BIOS) and the broadcom hardware doesn't know about it.) Uhm, but still I'm pretty sure there's no physical switch on this laptop (L5800C). Also, if there was one, surely I wasn't turning it on and off continuosly to justify those notices coming down to b43legacy. Note that bcm43xx used to work fine. I'm not talking about possible bugs in the software. I'm just explaining how the hardware works, because I think there's some confusion here. Ok, so supposedly here the situation can be on of these: 1) b43legacy driver is wrong while reading kill switch state 2) something (software) is toggling kill switch Would case 1 be fixed by having b43legacy NOT check the state ? --strk; () Free GIS Flash consultant/developer /\ http://foo.keybit.net/~strk/services.html ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43legacy-phy3: Radio hardware status changed to XXX
On Sunday 07 February 2010 15:44:01 strk wrote: On Sun, Feb 07, 2010 at 03:37:36PM +0100, Michael Buesch wrote: On Sunday 07 February 2010 15:30:18 strk wrote: On Sun, Feb 07, 2010 at 02:05:09PM +0100, Michael Buesch wrote: rfkill is a hardware lock in the case of broadcom. Software can only read the state. (There may be laptops with broadcom cards where rfkill can be changed by software. But that's done by other means (BIOS) and the broadcom hardware doesn't know about it.) Uhm, but still I'm pretty sure there's no physical switch on this laptop (L5800C). Also, if there was one, surely I wasn't turning it on and off continuosly to justify those notices coming down to b43legacy. Note that bcm43xx used to work fine. I'm not talking about possible bugs in the software. I'm just explaining how the hardware works, because I think there's some confusion here. Ok, so supposedly here the situation can be on of these: 1) b43legacy driver is wrong while reading kill switch state 2) something (software) is toggling kill switch Would case 1 be fixed by having b43legacy NOT check the state ? Well, it would not be a fix, but it would possibly be a workaround for it. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43legacy-phy3: Radio hardware status changed to XXX
On Sun, Feb 07, 2010 at 03:48:07PM +0100, Michael Buesch wrote: On Sunday 07 February 2010 15:44:01 strk wrote: Ok, so supposedly here the situation can be on of these: 1) b43legacy driver is wrong while reading kill switch state 2) something (software) is toggling kill switch Would case 1 be fixed by having b43legacy NOT check the state ? Well, it would not be a fix, but it would possibly be a workaround for it. If it *does* work as a workaround it'd be a good reason to add a load-time option to the driver (allow workaround to bogus behaviours). I'll let you know if it does work. --strk; () Free GIS Flash consultant/developer /\ http://foo.keybit.net/~strk/services.html ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43legacy-phy3: Radio hardware status changed to XXX
On Sunday 07 February 2010 15:59:53 strk wrote: On Sun, Feb 07, 2010 at 03:48:07PM +0100, Michael Buesch wrote: On Sunday 07 February 2010 15:44:01 strk wrote: Ok, so supposedly here the situation can be on of these: 1) b43legacy driver is wrong while reading kill switch state 2) something (software) is toggling kill switch Would case 1 be fixed by having b43legacy NOT check the state ? Well, it would not be a fix, but it would possibly be a workaround for it. If it *does* work as a workaround it'd be a good reason to add a load-time option to the driver (allow workaround to bogus behaviours). I'll let you know if it does work. We are not going to add module options to workaround bugs. We fix the bug instead. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43legacy-phy3: Radio hardware status changed to XXX
2010/2/7 Michael Buesch m...@bu3sch.de: On Sunday 07 February 2010 15:59:53 strk wrote: On Sun, Feb 07, 2010 at 03:48:07PM +0100, Michael Buesch wrote: On Sunday 07 February 2010 15:44:01 strk wrote: Ok, so supposedly here the situation can be on of these: 1) b43legacy driver is wrong while reading kill switch state 2) something (software) is toggling kill switch Would case 1 be fixed by having b43legacy NOT check the state ? Well, it would not be a fix, but it would possibly be a workaround for it. If it *does* work as a workaround it'd be a good reason to add a load-time option to the driver (allow workaround to bogus behaviours). I'll let you know if it does work. We are not going to add module options to workaround bugs. We fix the bug instead. ++ Please test first if it actually changes anything. -- Rafał ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43legacy-phy3: Radio hardware status changed to XXX
On Sun, Feb 07, 2010 at 04:27:02PM +0100, RafaÅ? MiÅ?ecki wrote: 2010/2/7 Michael Buesch m...@bu3sch.de: On Sunday 07 February 2010 15:59:53 strk wrote: On Sun, Feb 07, 2010 at 03:48:07PM +0100, Michael Buesch wrote: On Sunday 07 February 2010 15:44:01 strk wrote: Ok, so supposedly here the situation can be on of these:  1) b43legacy driver is wrong while reading kill switch state  2) something (software) is toggling kill switch Would case 1 be fixed by having b43legacy NOT check the state ? Well, it would not be a fix, but it would possibly be a workaround for it. If it *does* work as a workaround it'd be a good reason to add a load-time option to the driver (allow workaround to bogus behaviours). I'll let you know if it does work. We are not going to add module options to workaround bugs. We fix the bug instead. ++ Please test first if it actually changes anything. Aaargh, my laptop's screen just died. It'll probaby take some time before I go on with this task (luckly the *wired* nic still works). --strk; () Free GIS Flash consultant/developer /\ http://foo.keybit.net/~strk/services.html ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43legacy-phy3: Radio hardware status changed to XXX
On 02/07/2010 05:57 AM, strk wrote: On Sat, Feb 06, 2010 at 06:54:44PM -0600, Larry Finger wrote: You can get the wireless-compat sources for kernel 2.6.26 and build that. Othersise, go to kernel.org and get the full sources. I opted for an upgrade first (debian lenny to debian squeeze). So I'm now at kernel version 2.6.32 and the problem is somehow different (still related to kill switch). The messages in this case are more clear (on ifconfig wlan0 ): b43legacy ssb0:0: firmware: requesting b3legacy/ucode2.fw b43legacy ssb0:0: firmware: requesting b3legacy/pcm4.fw b43legacy ssb0:0: firmware: requesting b3legacy/b0g0initvals2.fw b43legacy-phy0: Loading firmware version 0x127, patch level 14 (2005-04-18 02:36:27) b43legacy-phy0: Radio hardware status changed to DISABLED b43legacy-phy0: Radio turned on by software b43legacy-phy0: The hardware RF-kill button still turns the radio physically off. Press th ebutton to turn it on. Same suggestions applies ? Or was some load-time option added in 2.6.32 ? There is no load-time option to ignore RFKILL, and as you have read, there never will be. I assume that your laptop has a mini-PCI BCM4303 card. Neither of my two devices uses that format, nor do either of mine implement the RF silent input, which is on pin 13, according to http://www.interfacebus.com/MiniPCI_Pinout_124Pin.html You did not see any logged rfkill messages with bcm43xx as it did not examine this input. The hardware must have honored that input and suppressed the radio whenever it was set. If you generate a system with the RFKILL subsystem disabled, all that will happen is that the messages will go away, and your radio will be silently disabled on an intermittent basis. You need to discover why that input is being generated? There could be a failure in the motherboard circuits that generate the signal. There could be a bug in the software that processes whatever WMI info that your system generates. WMI (Windows Management Interface) code handles the functions of the top row of your keyboard that are generated by a fn+FX key. One alternative would be to alter the MB or the card so that the RF silent input cannot be changed. BTW, I have no idea if it is a high or a low here that kills the radio. I suspect that the radio will be on if the pin is floating, but that is a guess. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
