The problem is well known and is due to Broadcom's SPROM miscoding for most, if not all, PCI versions of the BCM4306 and at least one PCI version of the BCM4318. The difficulty is with Bluetooth coexistence, thus we cannot apply the "fix" to _ALL_ cards without testing a representative of each card group. The problem slipped through the bcm43xx team because none of us had the necessary hardware.
The patches for all _KNOWN_ devices with this problem have been accepted into the mainline kernel (2.6.27-rc4), sent to Ubuntu, and merged by them into the code base for both Hardy and Intrepid. I would expect the fix to be in the next kernel version. As I'm not affiliated with Ubuntu, I have no idea when that might be.
The specific cards that are addressed by the patches are as follows (the numbers in parentheses are the vendor, device, subvendor and subvendor codes that show up in the first two lines of the 'lspci -nnv' output for the wireless interface.):
I have been treating the cases individually during the process of card identification, but there is a workaround. To use it, you need to obtain the SPROM utility from the bcm43xx tools at http://linuxwireless.org/en/users/Drivers/b43#relatedtools. To use this tool, you will need packages containing git, make, gcc, and glibc. The specific fix is to clear bit 1 of the low-order board flags. In most of the boards listed above, the current contents are 0x000D, which must be changed to 0x000C. When fixed, the kernel does this dynamically when starting, but a permanent change is equally effective. Caution must be taken to observe the current contents before changing them! If you blindly write 0x000C into the board flags, you may kill your card!
If you have a card with this problem _AND_ numbers different from the above list, I would like to know about it so that future kernels will be fixed.
The problem is well known and is due to Broadcom's SPROM miscoding for most, if not all, PCI versions of the BCM4306 and at least one PCI version of the BCM4318. The difficulty is with Bluetooth coexistence, thus we cannot apply the "fix" to _ALL_ cards without testing a representative of each card group. The problem slipped through the bcm43xx team because none of us had the necessary hardware.
The patches for all _KNOWN_ devices with this problem have been accepted into the mainline kernel (2.6.27-rc4), sent to Ubuntu, and merged by them into the code base for both Hardy and Intrepid. I would expect the fix to be in the next kernel version. As I'm not affiliated with Ubuntu, I have no idea when that might be.
The specific cards that are addressed by the patches are as follows (the numbers in parentheses are the vendor, device, subvendor and subvendor codes that show up in the first two lines of the 'lspci -nnv' output for the wireless interface.):
ASUS WL-138G V2 (4314, 4318, 1043, 100F)
DELL DW1350 (4314, 4320, 1028, 0003)
LINKSYS (4314, 4320, 1737, 0013)
LINKSYS (4314, 4320, 1737, 0014)
LINKSYS (4314, 4320, 1737, 0015)
I have been treating the cases individually during the process of card identification, but there is a workaround. To use it, you need to obtain the SPROM utility from the bcm43xx tools at http:// linuxwireless. org/en/ users/Drivers/ b43#relatedtool s. To use this tool, you will need packages containing git, make, gcc, and glibc. The specific fix is to clear bit 1 of the low-order board flags. In most of the boards listed above, the current contents are 0x000D, which must be changed to 0x000C. When fixed, the kernel does this dynamically when starting, but a permanent change is equally effective. Caution must be taken to observe the current contents before changing them! If you blindly write 0x000C into the board flags, you may kill your card!
If you have a card with this problem _AND_ numbers different from the above list, I would like to know about it so that future kernels will be fixed.
I hope this answers your questions.
Larry