Re: b43legacy-phy3: Radio hardware status changed to XXX
On Sun, Feb 07, 2010 at 05:45:30PM +0100, strk wrote: > On Sun, Feb 07, 2010 at 04:27:02PM +0100, RafaÅ? MiÅ?ecki wrote: > > 2010/2/7 Michael Buesch : > > > > > > We are not going to add module options to workaround bugs. We fix the bug > > > instead. > > > > ++ > > > > Please test first if it actually changes anything. Alright guys, I'm back up to speed with my laptop and in the process of rebuilding the module with RFKILL switch support disabled at compile time. Meanwhile (it's an old laptop) I've found a report of someone else having the same problem with the same laptop who "fixed" it by doing exactly that (disable the RFKILL compile-time): http://ubuntuforums.org/showthread.php?t=1368106 Report is of less then two months ago, maybe you may be interested in tracking that forum.. --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
Larry Finger wrote: > 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. The BIOS is rarely if ever involved in any of this. As was already explained, the rfkill signal is an electrical input to the wifi hardware, and the b43 driver can only ever read the state of this input. Who drives the signal depends on the unique system design. (Think mainboard.) In laptops there is always at least one "embedded controller" AKA EC which handles some or all of keyboard, GPIO signals, LEDs, Fn keys, lid switch, power switch, special function keys, fan control, battery charging and various other bits and pieces of the system. Bytecode within the ACPI tables in the BIOS may be executed by the kernel in order to discover e.g. Fn+key combination presses or lid switch, but the BIOS does not have anything to do with changing the electrical signal going out from the EC - that is done either by the EC firmware (in response to some keypress, which will also be reported via ACPI so the OS can update some status display) or as ordered by the operating system (in response to some keypress reported by the EC via ACPI). There is no standardization at all for these signals and this behavior. If you can find the schematics for your laptop that would help. //Peter ___ 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
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 : > > 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
2010/2/7 Michael Buesch : > 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 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
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: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: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: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 Sunday 07 February 2010 15:09:05 Rafał Miłecki wrote: > W dniu 7 lutego 2010 14:22 użytkownik Michael Buesch 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:04:22 Rafał Miłecki wrote: > Would it be good idea to add kernel-module-parameter hack like > "ignore_rfkill"? No. If b43 detects the radio as disabled, it _really_ _is_ physically turned off. There's no way around that except by enabling the radio physically. -- 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 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
W dniu 7 lutego 2010 14:22 użytkownik Michael Buesch 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
W dniu 7 lutego 2010 14:22 użytkownik Michael Buesch 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. > >> 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. Would it be good idea to add kernel-module-parameter hack like "ignore_rfkill"? -- 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
2010/2/7 Michael Buesch : > On Sunday 07 February 2010 13:48:59 Rafał Miłecki wrote: >> 2010/2/7 strk : >> > 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 13:48:59 Rafał Miłecki wrote: > 2010/2/7 strk : > > 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 strk : > 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 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
On 02/06/2010 06:49 PM, strk wrote: > On Sat, Feb 06, 2010 at 06:29:03PM -0600, Larry Finger wrote: >> On 02/06/2010 06:22 PM, strk wrote: >>> On Sat, Feb 06, 2010 at 06:20:15PM -0600, Larry Finger wrote: >>> You could probably avoid the problems by disabling the RFKILL and RFKILL_INPUT options. >>> >>> How do I do that ? Runtime ? Compile-time ? >> >> It needs to be compile time to elimionate that section of b43legacy. > > Thanks. Is there a repository from which I can get *only* > bcm43xx sources and compile against kernel headers ? > I've seen this done with debian module-assistant tool... 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. Larry ___ 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 Sat, Feb 06, 2010 at 06:29:03PM -0600, Larry Finger wrote: > On 02/06/2010 06:22 PM, strk wrote: > > On Sat, Feb 06, 2010 at 06:20:15PM -0600, Larry Finger wrote: > > > >> You could probably avoid the problems by disabling the RFKILL and > >> RFKILL_INPUT > >> options. > > > > How do I do that ? Runtime ? Compile-time ? > > It needs to be compile time to elimionate that section of b43legacy. Thanks. Is there a repository from which I can get *only* bcm43xx sources and compile against kernel headers ? I've seen this done with debian module-assistant tool... --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/06/2010 06:22 PM, strk wrote: > On Sat, Feb 06, 2010 at 06:20:15PM -0600, Larry Finger wrote: > >> You could probably avoid the problems by disabling the RFKILL and >> RFKILL_INPUT >> options. > > How do I do that ? Runtime ? Compile-time ? It needs to be compile time to elimionate that section of b43legacy. Larry ___ 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 Sat, Feb 06, 2010 at 06:20:15PM -0600, Larry Finger wrote: > You could probably avoid the problems by disabling the RFKILL and RFKILL_INPUT > options. How do I do that ? Runtime ? Compile-time ? --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/06/2010 03:14 PM, strk wrote: > On Sat, Feb 06, 2010 at 02:43:36PM -0600, Larry Finger wrote: > >> After bcm43xx was split into b43 and b43legacy, both were upgraded to take >> account of the computers "radio kill switch". Changes in the hardware switch >> input are causing the "Radio hardware ENABLED/DISABLED" messages. >> >> How does the ASUS implement that switch? Some laptops have a slide switch >> with >> an on/off position, while others have a push button with software keeping >> track >> of the state. > > I can see no slide switch, nor sign on any key suggesting > to have that purpose. It seems my problem was already reported here: > > https://lists.berlios.de/pipermail/bcm43xx-dev/2008-November/004843.html > > ... but the thread has no happy end (I add the author of that post in Cc). > > Jorge, have you figured it out lately ? You could probably avoid the problems by disabling the RFKILL and RFKILL_INPUT options. Larry ___ 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
[ sorry for repost, Jorge wasn't in recipient list ] On Sat, Feb 06, 2010 at 10:14:12PM +0100, strk wrote: > On Sat, Feb 06, 2010 at 02:43:36PM -0600, Larry Finger wrote: > > How does the ASUS implement that switch? Some laptops have a slide switch > > with > > an on/off position, while others have a push button with software keeping > > track > > of the state. > > I can see no slide switch, nor sign on any key suggesting > to have that purpose. It seems my problem was already reported here: > > https://lists.berlios.de/pipermail/bcm43xx-dev/2008-November/004843.html > > ... but the thread has no happy end (I add the author of that post in Cc). > > Jorge, have you figured it out lately ? --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 Sat, Feb 06, 2010 at 02:43:36PM -0600, Larry Finger wrote: > After bcm43xx was split into b43 and b43legacy, both were upgraded to take > account of the computers "radio kill switch". Changes in the hardware switch > input are causing the "Radio hardware ENABLED/DISABLED" messages. > > How does the ASUS implement that switch? Some laptops have a slide switch with > an on/off position, while others have a push button with software keeping > track > of the state. I can see no slide switch, nor sign on any key suggesting to have that purpose. It seems my problem was already reported here: https://lists.berlios.de/pipermail/bcm43xx-dev/2008-November/004843.html ... but the thread has no happy end (I add the author of that post in Cc). Jorge, have you figured it out lately ? -- () 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/06/2010 01:08 PM, strk wrote: > Hi everybody, > my excuses in advance for asking something which was likely > asked a lot more in the past. > > I just switched to usin b43legacy from bmcxxx (from linux 2.6.18 > to linux 2.6.26) and am having some problems with the wireless > card. In particular I continually get disable-enable messages: > > Feb 6 20:01:21 xtops kernel: [ 4910.000194] b43legacy-phy3: Radio hardware > status changed to ENABLED > Feb 6 20:01:46 xtops kernel: [ 4935.000441] __ratelimit: 3 messages > suppressed > Feb 6 20:01:46 xtops kernel: [ 4935.000458] b43legacy-phy3: Radio hardware > status changed to DISABLED > > Sometimes this results in a disconnection. -- snip -- > > Any hint on how to further debug or fix ? > Thanks in advance. After bcm43xx was split into b43 and b43legacy, both were upgraded to take account of the computers "radio kill switch". Changes in the hardware switch input are causing the "Radio hardware ENABLED/DISABLED" messages. How does the ASUS implement that switch? Some laptops have a slide switch with an on/off position, while others have a push button with software keeping track of the state. Larry PS: Your address bcm43xx-...@berios.de is wrong. You should use just bcm43xx-...@lists.berlios.de. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
