Re: HP Compaq nx6325 - new users experience
On Thu, 2007-04-12 at 19:22 +0200, Philipp E. Letschert wrote: > Warning: Driver for device eth1 has been compiled with version 22 > of Wireless Extension, while this program supports up to version 20. > Some things may be broken... That's fine, we just cycled to version 22 in the kernel and userspace doesn't even support that yet afaik ;) johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list [EMAIL PROTECTED] https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] bcm43xx-mac80211: Fix machine checks on PPC with rev 1 PHYs
John W. Linville wrote: > On Wed, Apr 11, 2007 at 11:08:53AM -0500, Larry Finger wrote: >> On PPC architecture with phy->rev == 1, machine checks occur during >> initialization of the "Extended G PHY registers". This problem was >> also seen on bcm43xx-softmac, and was fixed by conditionally skipping >> over certain reads/writes of these registers. The same solution has been >> applied here with testing by David Woodhouse. Note: These modifications >> are not found in the specifications, but are needed for PPC. > > I added this patch to the Fedora rawhide kernels, but our Fedora QA > lead reports that he still has this crash: > > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233011 > > I had diagnosed this to be the same crash as this patch was supposed > to address. Was I in error? > > He also reports that the problem still occurs on my FC7 test kernels, > which are very close to the current rawhide kernels but with the most > recent round of wireless-dev updates added. I suspect the machine check is from the same kind of problem; however, the soft lockup is different. It is always possible that it changes the behavior. There is also the different program flow in mac80211. I just put in the ones that failed in softmac. Your tester needs to get a copy of David's hack that prints out the address of the offending register. That is the only way to tell what is happening. Once we know the address, then it will be a matter of getting printk's into the code to tell which one is failing. Larry ___ Bcm43xx-dev mailing list [EMAIL PROTECTED] https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] bcm43xx-mac80211: Fix machine checks on PPC with rev 1 PHYs
On Thu, 2007-04-12 at 20:09 -0400, John W. Linville wrote: > I added this patch to the Fedora rawhide kernels, but our Fedora QA > lead reports that he still has this crash: > > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233011 > > I had diagnosed this to be the same crash as this patch was supposed > to address. Was I in error? I also observed the machine check with the current mb branch this morning, although I didn't have a chance to capture it, so I wanted to reported it later when I would have the details. I was testing the patch on a G4 PowerMac. I also have a G3 PowerMac where I tested older versions, and I intend to test the current code on it as well. > Any thoughts? Apparently more changes are needed. I don't think the latest patch needs to be reverted. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list [EMAIL PROTECTED] https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: HP Compaq nx6325 - new users experience
Philipp, I can give you a little further info about the LED and the switch. The switch controls the radio, but it doesn't actually control the LED. The status is reported through a single bit that is read-only from the processor. In addition, the switch doesn't cause an interrupt. What happens is that the bcm43xx driver runs a periodic thread that is scheduled every one second. Among other things, it compares the hardware bit with a saved setting. If the bit changes, the appropriate message is logged and the LED control bits are changed. That is why there is a delay from the time the switch is pressed until the light changes state. The radio, however is turned off immediately. Your description matches exactly what is programmed. I am currently working on a patch to turn off the LED when the driver is unloaded either by rmmod or by rebooting. So far it isn't working. Larry ___ Bcm43xx-dev mailing list [EMAIL PROTECTED] https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] bcm43xx-mac80211: Fix machine checks on PPC with rev 1 PHYs
On Wed, Apr 11, 2007 at 11:08:53AM -0500, Larry Finger wrote: > On PPC architecture with phy->rev == 1, machine checks occur during > initialization of the "Extended G PHY registers". This problem was > also seen on bcm43xx-softmac, and was fixed by conditionally skipping > over certain reads/writes of these registers. The same solution has been > applied here with testing by David Woodhouse. Note: These modifications > are not found in the specifications, but are needed for PPC. I added this patch to the Fedora rawhide kernels, but our Fedora QA lead reports that he still has this crash: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233011 I had diagnosed this to be the same crash as this patch was supposed to address. Was I in error? He also reports that the problem still occurs on my FC7 test kernels, which are very close to the current rawhide kernels but with the most recent round of wireless-dev updates added. http://people.redhat.com/linville/kernels/fc7/ Any thoughts? John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list [EMAIL PROTECTED] https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: HP Compaq nx6325 - new users experience
Larry Finger schrieb am Do, 12.04.2007 (13:08:31 -0500): > Philipp E. Letschert wrote: > >LED functionality: > > > >after `ifconfig eth1 up' the LED turns on, and using the WLAN keyboard > >switch turns the LED on and off. But this has no impact on the driver, > >WLAN seems to work, even with LED turned off. > > > >Using ndiswrapper, the LED turns on right after loading the module and > >the keyboard switch turns LED on and off and additionally > >enables/disables the device. > > In bcm43xx, the LED will never turn on until after the interface is brought > up. That is deliberate. Are there any messages about "Radio hardware status > changed" in the dmesg output? My laptop with a 4311 has a switch on the > front lip, not on the keyboard, the LED changes with the switch and the > radio is disabled by the hardware. If yours behaves differently, we should > change it, but if the hardware status changes do not propagate, I'm not > sure what we can do. > > >With both drivers, when rebooting the laptop with LED switched on, it > >stays on, even when no driver is loaded and no device is available. So I > >manually unload the driver during shutdown, so the LED goes off before > >rebooting. > > That is a manifestation of the same problem. > > >Device corruption: > > > >this has been mentioned on the list before, and was also observed here: > >When using 2.6.20 unpatched kernel and rebooting the laptop with bcm43xx > >loaded and interface up, the device gets somehow corrupted. > >After rebooting it was impossible to get the device working again. > >Neither with bcm43xx nor ndiswrapper, power off didnt help either. The > >only solution I found was to select 'Restore Defaults'->'Save' in the > >laptops BIOS, and the device did work again. (The laptop BIOS version is > >F.06) > > > >However this issue has been resolved using 2.6.21-rc6 with combined > >patch applied. > > No PCIe device works on an unpatched 2.6.20 kernel. You need 2.6.20.4 or > later. The reason is that PCIe interrupts are not passed on, which > obviously confuses your BIOS, and jams up interrupts on the appropriate IRQ > line. I'm surprised that turning off the power didn't get it reset. I finally found out what my "corruption bug" was about: In kernel 2.6.20.4 the LED didn't work, when pressing the switch (btw. it is not directly on the keyboard, but a separate switch right above, with an integrated LED) and there were no "Radio hardware status changed" messages. So I assumed the switch doesnt work at all. But that was wrong, I silently disabled the device (with the LED still on) and it stayed disabled, even when turning power off. All I should have done, was to press the switch once more (even with LED already on), instead of resetting the BIOS. Finding this kept me busy for a few hours... In patched 2.6.21-rc6 LED works fine, and the "Radio hardware status changed" messages show up. Again I was wrong in thinking the switch doesnt turn off the device properly. It just doesnt switch off immediately. After pressing and the LED is off, you still have a result from "iwlist scan" for a some seconds, before the device is finally disabled - bad tester I am. I try to describe the LEDs behaviour: 1. Initial boot, hardware enabled, LED is off, no module loaded 2. modprobe bcm43xx, ifconfig ethx up 3. LED is on, Device is working 4. Reboot 5. Hardware enabled, LED is on, no module loaded 6. modprobe bcm43xx 7. LED goes off 8. ifconfig ethx up 9. LED goes on, device is working 10. pressing WLAN switch 11. LED goes off, device is not working 12. Power off, Boot 13. Hardware disabled, LED is off, no module loaded 14. modprobe bcm43xx, ifconfig ethx up 15. LED doesn't turn on, hardware still disabled, device not working 16. pressing WLAN switch 17. LED goes on, device is working This is all ok and I dont know if other devices are the same, but I could imagine a different behaviour: - loading the module initially disables the hardware, never mind if it was enabled or disabled before - doing ifconfig ethx up enables hardware (and LED) or pressing WLAN switch enables hardware and does ifconfig ethx up - doing ifconfig ethx down disables hardware or pressing WLAN switch disables hardware and does ifconfig ethx down - doing a reboot disables the hardware and turns the LED off. > >Rate settings: > > > >setting a rate with iwconfig seems to have no effect, its always 1M > >(with ndiswrapper its always 54M). But this could be a result of > >unsupported wireless extensions? > > > >Warning: Driver for device eth1 has been compiled with version 22 > >of Wireless Extension, while this program supports up to version 20. > >Some things may be broken... > > No - The VERSION message is just a standard one. With 2.6.21-rc6, the rate > is initialized at 24M. If it has been downgraded to 1M, it must be a > consequence of the strength of your signal. What are the signal strengths, > etc. shown by iwconfig? Ah, I had no AP associated, so
Finally working! :)
Thank you all very much. For the first time my BCM4311 based card actually works. It is a little unstable by that might be the access point. I am testing it on my universities heavily loaded network. The range is not as good as in windows but this is just amazing. I have listed my machines rough spec. Thank you all for your work. Compaq Presario V3019US BCM4311 AMD64 with SMP linux-2.6.20.6 with patch udev-104-r12 (My earlier udev had a fw loading bug) -- http://www.coe.neu.edu/~efoss/ http://evanfoss.googlepages.com/ ___ Bcm43xx-dev mailing list [EMAIL PROTECTED] https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: BCM43xx_LOCALE_USA_CANADA_ANZ correct? -- Re: Please pull 'upstream-fixes' branch of wireless-2.6
On Thu, Apr 12, 2007 at 09:52:17AM -0500, Larry Finger wrote: > John W. Linville wrote: > >BCM43xx_LOCALE_USA_CANADA_ANZ a correct grouping? > Those categories were copied from the data in the SPROM on the BCM43xx > chips, which are obviously out of date. That said, it is likely that the > code will do the right thing in Australia and New Zealand as most of the > cards have a 0 in the locale field of the SPROM, which falls through to the > default case of the switch. Cool, thanks... -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list [EMAIL PROTECTED] https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: HP Compaq nx6325 - new users experience
Philipp E. Letschert wrote: > Hi all, > > > HP Compaq nx6325 laptop was already on the list for a few times, so I > would like to add my experiences: > > Im using kernel 2.6.21-rc6 with combined_2.6.21-rc6.patch applied. > > lspci -vn reports: > 30:00.0 0280: 14e4:4312 (rev 01) > > dmesg after modprobe bcm43xx and ifconfig eth1 up: > bcm43xx driver > ACPI: PCI Interrupt :30:00.0[A] -> GSI 18 (level, low) -> IRQ 20 > PCI: Setting latency timer of device :30:00.0 to 64 > bcm43xx: Chip ID 0x4311, rev 0x1 > bcm43xx: Number of cores: 4 > bcm43xx: Core 0: ID 0x800, rev 0x11, vendor 0x4243 > bcm43xx: Core 1: ID 0x812, rev 0xa, vendor 0x4243 > bcm43xx: Core 2: ID 0x817, rev 0x3, vendor 0x4243 > bcm43xx: Core 3: ID 0x820, rev 0x1, vendor 0x4243 > bcm43xx: PHY connected > bcm43xx: Detected PHY: Analog: 4, Type 2, Revision 8 > bcm43xx: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2) > bcm43xx: Radio turned off > bcm43xx: Radio turned off > bcm43xx: PHY connected > bcm43xx: Microcode rev 0x118, pl 0x17 (2004-05-06 21:34:00) > bcm43xx: Radio turned on > bcm43xx: Radio enabled by hardware > bcm43xx: Chip initialized > bcm43xx: 32-bit DMA initialized > bcm43xx: Keys cleared > bcm43xx: Selected 802.11 core (phytype 2) > > First question: > Shouldnt the driver report Chip ID 0x4312 as lspci does? No. The PCI id is different from the chip ID. Actually the programming of the device is mostly dependent on PHY and radio parameters. > Second: How important is the firmware version? Im using 3.70.22.0, as > recommended by Larry, but was also able to load 3.100.65.1, so I don't > know if this has an impact on the driver. It shouldn't matter. > btw, if it helps for development of 4.x support, the latest HP driver > for the nx6325 is located at > http://ftp.hp.com/pub/softpaq/sp34001-34500/sp34152.exe with firmware > version 4.100.15.5. > > > LED functionality: > > after `ifconfig eth1 up' the LED turns on, and using the WLAN keyboard > switch turns the LED on and off. But this has no impact on the driver, > WLAN seems to work, even with LED turned off. > > Using ndiswrapper, the LED turns on right after loading the module and > the keyboard switch turns LED on and off and additionally > enables/disables the device. In bcm43xx, the LED will never turn on until after the interface is brought up. That is deliberate. Are there any messages about "Radio hardware status changed" in the dmesg output? My laptop with a 4311 has a switch on the front lip, not on the keyboard, the LED changes with the switch and the radio is disabled by the hardware. If yours behaves differently, we should change it, but if the hardware status changes do not propagate, I'm not sure what we can do. > With both drivers, when rebooting the laptop with LED switched on, it > stays on, even when no driver is loaded and no device is available. So I > manually unload the driver during shutdown, so the LED goes off before > rebooting. That is a manifestation of the same problem. > Device corruption: > > this has been mentioned on the list before, and was also observed here: > When using 2.6.20 unpatched kernel and rebooting the laptop with bcm43xx > loaded and interface up, the device gets somehow corrupted. > After rebooting it was impossible to get the device working again. > Neither with bcm43xx nor ndiswrapper, power off didnt help either. The > only solution I found was to select 'Restore Defaults'->'Save' in the > laptops BIOS, and the device did work again. (The laptop BIOS version is > F.06) > > However this issue has been resolved using 2.6.21-rc6 with combined > patch applied. No PCIe device works on an unpatched 2.6.20 kernel. You need 2.6.20.4 or later. The reason is that PCIe interrupts are not passed on, which obviously confuses your BIOS, and jams up interrupts on the appropriate IRQ line. I'm surprised that turning off the power didn't get it reset. > Rate settings: > > setting a rate with iwconfig seems to have no effect, its always 1M > (with ndiswrapper its always 54M). But this could be a result of > unsupported wireless extensions? > > Warning: Driver for device eth1 has been compiled with version 22 > of Wireless Extension, while this program supports up to version 20. > Some things may be broken... No - The VERSION message is just a standard one. With 2.6.21-rc6, the rate is initialized at 24M. If it has been downgraded to 1M, it must be a consequence of the strength of your signal. What are the signal strengths, etc. shown by iwconfig? Larry ___ Bcm43xx-dev mailing list [EMAIL PROTECTED] https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
HP Compaq nx6325 - new users experience
Hi all, HP Compaq nx6325 laptop was already on the list for a few times, so I would like to add my experiences: Im using kernel 2.6.21-rc6 with combined_2.6.21-rc6.patch applied. lspci -vn reports: 30:00.0 0280: 14e4:4312 (rev 01) dmesg after modprobe bcm43xx and ifconfig eth1 up: bcm43xx driver ACPI: PCI Interrupt :30:00.0[A] -> GSI 18 (level, low) -> IRQ 20 PCI: Setting latency timer of device :30:00.0 to 64 bcm43xx: Chip ID 0x4311, rev 0x1 bcm43xx: Number of cores: 4 bcm43xx: Core 0: ID 0x800, rev 0x11, vendor 0x4243 bcm43xx: Core 1: ID 0x812, rev 0xa, vendor 0x4243 bcm43xx: Core 2: ID 0x817, rev 0x3, vendor 0x4243 bcm43xx: Core 3: ID 0x820, rev 0x1, vendor 0x4243 bcm43xx: PHY connected bcm43xx: Detected PHY: Analog: 4, Type 2, Revision 8 bcm43xx: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2) bcm43xx: Radio turned off bcm43xx: Radio turned off bcm43xx: PHY connected bcm43xx: Microcode rev 0x118, pl 0x17 (2004-05-06 21:34:00) bcm43xx: Radio turned on bcm43xx: Radio enabled by hardware bcm43xx: Chip initialized bcm43xx: 32-bit DMA initialized bcm43xx: Keys cleared bcm43xx: Selected 802.11 core (phytype 2) First question: Shouldnt the driver report Chip ID 0x4312 as lspci does? Second: How important is the firmware version? Im using 3.70.22.0, as recommended by Larry, but was also able to load 3.100.65.1, so I don't know if this has an impact on the driver. btw, if it helps for development of 4.x support, the latest HP driver for the nx6325 is located at http://ftp.hp.com/pub/softpaq/sp34001-34500/sp34152.exe with firmware version 4.100.15.5. LED functionality: after `ifconfig eth1 up' the LED turns on, and using the WLAN keyboard switch turns the LED on and off. But this has no impact on the driver, WLAN seems to work, even with LED turned off. Using ndiswrapper, the LED turns on right after loading the module and the keyboard switch turns LED on and off and additionally enables/disables the device. With both drivers, when rebooting the laptop with LED switched on, it stays on, even when no driver is loaded and no device is available. So I manually unload the driver during shutdown, so the LED goes off before rebooting. Device corruption: this has been mentioned on the list before, and was also observed here: When using 2.6.20 unpatched kernel and rebooting the laptop with bcm43xx loaded and interface up, the device gets somehow corrupted. After rebooting it was impossible to get the device working again. Neither with bcm43xx nor ndiswrapper, power off didnt help either. The only solution I found was to select 'Restore Defaults'->'Save' in the laptops BIOS, and the device did work again. (The laptop BIOS version is F.06) However this issue has been resolved using 2.6.21-rc6 with combined patch applied. Rate settings: setting a rate with iwconfig seems to have no effect, its always 1M (with ndiswrapper its always 54M). But this could be a result of unsupported wireless extensions? Warning: Driver for device eth1 has been compiled with version 22 of Wireless Extension, while this program supports up to version 20. Some things may be broken... As I'm a new user, thats all I can report for the moment, I have no experience in stabilty, performance, encryption settings for the bcm43xx driver yet. Regards, Philipp ___ Bcm43xx-dev mailing list [EMAIL PROTECTED] https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: BCM43xx_LOCALE_USA_CANADA_ANZ correct? -- Re: Please pull 'upstream-fixes' branch of wireless-2.6
John W. Linville wrote:
> BCM43xx_LOCALE_USA_CANADA_ANZ a correct grouping?
John,
Those categories were copied from the data in the SPROM on the BCM43xx chips,
which are obviously
out of date. That said, it is likely that the code will do the right thing in
Australia and New
Zealand as most of the cards have a 0 in the locale field of the SPROM, which
falls through to the
default case of the switch.
Larry
> John
>
>>
>> Hi John,
>>
>> Apols for unsolicted email but I was looking through your patch and this
>> caught my eye:
>>> +/* set the maximum channel based on locale set in sprom or witle locale
>>> option */
>>> + switch (bcm->sprom.locale) {
>>> + case BCM43xx_LOCALE_THAILAND:
>>> + case BCM43xx_LOCALE_ISRAEL:
>>> + case BCM43xx_LOCALE_JORDAN:
>>> + case BCM43xx_LOCALE_USA_CANADA_ANZ:
>>> + case BCM43xx_LOCALE_USA_LOW:
>>> + max_bg_channel = 11;
>>> + break;
>>> + case BCM43xx_LOCALE_JAPAN:
>>> + case BCM43xx_LOCALE_JAPAN_HIGH:
>>> + max_bg_channel = 14;
>>> + break;
>>> + default:
>>> + max_bg_channel = 13;
>>> + }
>>> +
>>>
>> Specifically BCM43xx_LOCALE_USA_CANADA_ANZ. A/NZ is certainly not the
>> same as USA/Canada - in Australia we get 13 channels not 11 of US/Canada.
>>
>> I'm sure this is because I don't know your driver but just in case you
>> do need to split out an ANZ definition I thought I'd shout up.
>>
>> Steve
>
> - End forwarded message -
>
___
Bcm43xx-dev mailing list
[EMAIL PROTECTED]
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
BCM43xx_LOCALE_USA_CANADA_ANZ correct? -- Re: Please pull 'upstream-fixes' branch of wireless-2.6
BCM43xx_LOCALE_USA_CANADA_ANZ a correct grouping?
John
- Forwarded message from "stevie.glass" <[EMAIL PROTECTED]> -
> DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed;
> d=gmail.com; s=beta;
>
> h=domainkey-signature:received:received:message-id:date:from:reply-to:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
>
> b=b/L4/k3Vj3gsfNabz0EfEE6pG2gAFJyPx+52Mcx3IuMfpM7cFY2sv/jbixkmWSJQcARwPoiHFNmv8mC4k8cwgpd/pxeHDznfl+sRmG0EH2Od3cSc9wFXkvZE2CyLJwUj88acjE3W8JODmYDO8ha7p0fA0ySae3ExOQyzuSZ+xZA=
> DomainKey-Signature: a=rsa-sha1; c=nofws;
> d=gmail.com; s=beta;
>
> h=received:message-id:date:from:reply-to:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
>
> b=c13rHvw5Z5QAZnP6CrA3+XeeF4D8Zdi7GRjiZK3vAoqYZ78O8yNQ6bkAzpi1pKGhbffVx3bGd44Ok057V3PWVhsMjncGr5jMKiiAEQJRpDpKIB++oimQXCPHjGCxUQwesBr2V/yvL06CcBZKsupeD7hHAvo2CeVCLWCuSmcwiGM=
> Date: Wed, 11 Apr 2007 08:16:59 +1000
> From: "stevie.glass" <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> User-Agent: Icedove 1.5.0.10 (X11/20070329)
> To: "John W. Linville" <[EMAIL PROTECTED]>
> Subject: Re: Please pull 'upstream-fixes' branch of wireless-2.6
> In-Reply-To: <[EMAIL PROTECTED]>
> X-Spam-Status: No, score=-2.6 required=3.0 tests=AWL,BAYES_00,SPF_HELO_PASS,
> SPF_PASS autolearn=unavailable version=3.1.8-gr0
> X-Spam-Checker-Version: SpamAssassin 3.1.8-gr0 (2007-02-13) on
> ra.tuxdriver.com
>
> Hi John,
>
> Apols for unsolicted email but I was looking through your patch and this
> caught my eye:
> > +/* set the maximum channel based on locale set in sprom or witle locale
> > option */
> > + switch (bcm->sprom.locale) {
> > + case BCM43xx_LOCALE_THAILAND:
> > + case BCM43xx_LOCALE_ISRAEL:
> > + case BCM43xx_LOCALE_JORDAN:
> > + case BCM43xx_LOCALE_USA_CANADA_ANZ:
> > + case BCM43xx_LOCALE_USA_LOW:
> > + max_bg_channel = 11;
> > + break;
> > + case BCM43xx_LOCALE_JAPAN:
> > + case BCM43xx_LOCALE_JAPAN_HIGH:
> > + max_bg_channel = 14;
> > + break;
> > + default:
> > + max_bg_channel = 13;
> > + }
> > +
> >
> Specifically BCM43xx_LOCALE_USA_CANADA_ANZ. A/NZ is certainly not the
> same as USA/Canada - in Australia we get 13 channels not 11 of US/Canada.
>
> I'm sure this is because I don't know your driver but just in case you
> do need to split out an ANZ definition I thought I'd shout up.
>
> Steve
- End forwarded message -
--
John W. Linville
[EMAIL PROTECTED]
___
Bcm43xx-dev mailing list
[EMAIL PROTECTED]
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
