Mailing list test, please ignore
Mailing list test, please ignore. -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
test
Is it me or this list is misconfigured ? --srrk; ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: test
Why would it be misconfigured? On Sat, Feb 6, 2010 at 8:11 PM, strk s...@keybit.net wrote: Is it me or this list is misconfigured ? --srrk; ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Fatal DMA error problem with netbook and BCM4312 - Test 3
On 28/12/09 04:49, Larry Finger wrote: Hi, In the latest Broadcom driver, I found code that sets the timeout field of the SSB configuration for some BCM4311 and all BCM4312 devices. Please test this patch following a cold boot. Sadly it does not work. Tested with the mainline kernel. The DMA errors persist. Andy ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Fatal DMA error problem with netbook and BCM4312 - Test 3
On 12/28/2009 09:52 AM, Andrew Benton wrote: Sadly it does not work. Tested with the mainline kernel. The DMA errors persist. Shucks!!! I was hoping for a late Christmas present. Unfortunately, more coal in my stocking. As usual, thanks for testing. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Fatal DMA error problem with netbook and BCM4312 - Test 3
On Monday 28 December 2009 05:49:14 Larry Finger wrote: + tmp = ~(SSB_IMCFGLO_SERTO | SSB_IMCFGLO_REQTO_SHIFT); This does not make any sense. Did you mean: + tmp = ~(SSB_IMCFGLO_SERTO | SSB_IMCFGLO_REQTO); + tmp |= 3; So you set SER-timeout to 3 and REQ-timeout to 0. Is that what we want? REQ=zero smells fishy to me, but if the broadcom code also does this, I'm OK with it. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Fatal DMA error problem with netbook and BCM4312 - Test 3
On 12/28/2009 12:33 PM, Michael Buesch wrote: On Monday 28 December 2009 05:49:14 Larry Finger wrote: +tmp = ~(SSB_IMCFGLO_SERTO | SSB_IMCFGLO_REQTO_SHIFT); This does not make any sense. Did you mean: + tmp = ~(SSB_IMCFGLO_SERTO | SSB_IMCFGLO_REQTO); +tmp |= 3; So you set SER-timeout to 3 and REQ-timeout to 0. Is that what we want? REQ=zero smells fishy to me, but if the broadcom code also does this, I'm OK with it. I did get that wrong. The Broadcom code does the equivalent of tmp = tmp ~0x77 | 3 which is what my code ended up doing by accident, but REQ is set to zero. Are these values discussed anywhere in the open? I have not found anything regarding the SSB configuration. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Fatal DMA error problem with netbook and BCM4312 - Test 3
On Monday 28 December 2009 20:09:05 Larry Finger wrote: I did get that wrong. The Broadcom code does the equivalent of tmp = tmp ~0x77 | 3 Ok, so you need my version of the masking. which is what my code ended up doing by accident, but REQ is set to zero. Yeah, OK to me. It's a workaround after all... Are these values discussed anywhere in the open? I have not found anything regarding the SSB configuration. Well, there's no real docs on these, but I'm pretty sure they are related to the posting of messages on the SSB bus. These values are timeouts for the communication on the bus. So yeah, I think in _theory_ it can cause DMA (and other) trouble. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Fatal DMA error problem with netbook and BCM4312 - Test 3
Hi,
In the latest Broadcom driver, I found code that sets the timeout field of the
SSB configuration for some BCM4311 and all BCM4312 devices. Please test this
patch following a cold boot.
Thanks,
Larry
Index: wireless-testing/drivers/ssb/driver_pcicore.c
===
--- wireless-testing.orig/drivers/ssb/driver_pcicore.c
+++ wireless-testing/drivers/ssb/driver_pcicore.c
@@ -621,6 +621,14 @@ int ssb_pcicore_dev_irqvecs_enable(struc
tmp |= 0x40;
ssb_pcie_write(pc, 0x100, tmp);
}
+ if (bus-chip_id == 0x4312 ||
+ (bus-chip_id == 0x4311 bus-chip_rev == 2)) {
+ tmp = ssb_read32(pdev, SSB_IMCFGLO);
+ tmp = ~(SSB_IMCFGLO_SERTO | SSB_IMCFGLO_REQTO_SHIFT);
+ tmp |= 3;
+ ssb_write32(pdev, SSB_IMCFGLO, tmp);
+ ssb_commit_settings(bus);
+ }
}
pc-setup_done = 1;
out:
Index: wireless-testing/drivers/ssb/driver_chipcommon_pmu.c
===
--- wireless-testing.orig/drivers/ssb/driver_chipcommon_pmu.c
+++ wireless-testing/drivers/ssb/driver_chipcommon_pmu.c
@@ -424,9 +424,9 @@ static void ssb_pmu_resources_init(struc
switch (bus-chip_id) {
case 0x4312:
/* We keep the default settings:
-* min_msk = 0xCBB
* max_msk = 0x7
*/
+ min_msk = 0xCBB;
break;
case 0x4325:
/* Power OTP down later. */
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Fatal DMA error problem with netbook and BCM4312 - Test 2
Hi,
I placed a number of test prints in my system trying to find where a
DMA data error might occur. In doing so, I found that 3 slots in the
DMA header cache cross a page boundary. Such a situation is allowed on
my system, but it might be forbidden on Atom processors. Please try
this really ugly hack to see if it makes any difference.
Thanks,
Larry
Index: wireless-testing/drivers/net/wireless/b43/dma.h
===
--- wireless-testing.orig/drivers/net/wireless/b43/dma.h
+++ wireless-testing/drivers/net/wireless/b43/dma.h
@@ -160,7 +160,7 @@ struct b43_dmadesc_generic {
#define B43_DMA0_RX_FRAMEOFFSET30
/* DMA engine tuning knobs */
-#define B43_TXRING_SLOTS 256
+#define B43_TXRING_SLOTS 74
#define B43_RXRING_SLOTS 64
#define B43_DMA0_RX_BUFFERSIZE IEEE80211_MAX_FRAME_LEN
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Fatal DMA error problem with netbook and BCM4312 - Test 2
On Monday 21 December 2009 22:31:10 Larry Finger wrote: Hi, I placed a number of test prints in my system trying to find where a DMA data error might occur. In doing so, I found that 3 slots in the DMA header cache cross a page boundary. Such a situation is allowed on my system, but it might be forbidden on Atom processors. Please try this really ugly hack to see if it makes any difference. First thing is that the DMA buffers are allowed to cross any boundary (and the header is just a buffer). The boundary requirements only apply to the memory holding the descriptors. Second thing is: How does the patch prevent a boundary crossing? -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Fatal DMA error problem with netbook and BCM4312 - Test 2
On 12/21/2009 03:47 PM, Michael Buesch wrote: On Monday 21 December 2009 22:31:10 Larry Finger wrote: Hi, I placed a number of test prints in my system trying to find where a DMA data error might occur. In doing so, I found that 3 slots in the DMA header cache cross a page boundary. Such a situation is allowed on my system, but it might be forbidden on Atom processors. Please try this really ugly hack to see if it makes any difference. First thing is that the DMA buffers are allowed to cross any boundary (and the header is just a buffer). The boundary requirements only apply to the memory holding the descriptors. That is what we will test for the Atom. I know it doesn't matter for my CPU, but ... Second thing is: How does the patch prevent a boundary crossing? The number of slots is reduced to the point that the header cache fits in one page, just as the RX header cache does. As I said, this is really ugly. If this fixes the problem, then a more elegant fix will be needed. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Fatal DMA error problem with netbook and BCM4312 - Test 2
On Monday 21 December 2009 23:02:39 Larry Finger wrote: On 12/21/2009 03:47 PM, Michael Buesch wrote: On Monday 21 December 2009 22:31:10 Larry Finger wrote: Hi, I placed a number of test prints in my system trying to find where a DMA data error might occur. In doing so, I found that 3 slots in the DMA header cache cross a page boundary. Such a situation is allowed on my system, but it might be forbidden on Atom processors. Please try this really ugly hack to see if it makes any difference. First thing is that the DMA buffers are allowed to cross any boundary (and the header is just a buffer). The boundary requirements only apply to the memory holding the descriptors. That is what we will test for the Atom. I know it doesn't matter for my CPU, but ... I'm pretty sure the broadcom DMA engine is not _that_ braindead. (It is pretty weird, but not _that_ weird). It would effectively mean that we'd have to bouncebuffer _every_ TX packet. Second thing is: How does the patch prevent a boundary crossing? The number of slots is reduced to the point that the header cache fits in one page, just as the RX header cache does. As I said, this is really ugly. If this fixes the problem, then a more elegant fix will be needed. But the allocation is not required to be aligned to the page start. The first header might start at offset 4000 of a page, so you cross the page border after the first few headers. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Fatal DMA error problem with netbook and BCM4312 - Test 2
Larry Finger wrote: Hi, I placed a number of test prints in my system trying to find where a DMA data error might occur. In doing so, I found that 3 slots in the DMA header cache cross a page boundary. Such a situation is allowed on my system, but it might be forbidden on Atom processors. Please try this really ugly hack to see if it makes any difference. I confirm that the DMA error is still present with this patch. - William Thanks, Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Fatal DMA error problem with netbook and BCM4312 - Test 2
On 12/21/2009 04:11 PM, Michael Buesch wrote: On Monday 21 December 2009 23:02:39 Larry Finger wrote: On 12/21/2009 03:47 PM, Michael Buesch wrote: On Monday 21 December 2009 22:31:10 Larry Finger wrote: Hi, I placed a number of test prints in my system trying to find where a DMA data error might occur. In doing so, I found that 3 slots in the DMA header cache cross a page boundary. Such a situation is allowed on my system, but it might be forbidden on Atom processors. Please try this really ugly hack to see if it makes any difference. First thing is that the DMA buffers are allowed to cross any boundary (and the header is just a buffer). The boundary requirements only apply to the memory holding the descriptors. That is what we will test for the Atom. I know it doesn't matter for my CPU, but ... I'm pretty sure the broadcom DMA engine is not _that_ braindead. (It is pretty weird, but not _that_ weird). It would effectively mean that we'd have to bouncebuffer _every_ TX packet. I'm not that worried about the Broadcom implementation as I am about the support chips on the Netbooks. Second thing is: How does the patch prevent a boundary crossing? The number of slots is reduced to the point that the header cache fits in one page, just as the RX header cache does. As I said, this is really ugly. If this fixes the problem, then a more elegant fix will be needed. But the allocation is not required to be aligned to the page start. The first header might start at offset 4000 of a page, so you cross the page border after the first few headers. Here, it was slot 74 that crossed the page boundary. At 110 bytes per every 2 slots, that works out to 4070 bytes for 0 - 73. From that, I infer that the cache starts on a page boundary. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Fatal DMA error problem with netbook and BCM4312 - Test 2
On 12/21/2009 04:18 PM, William Bourque wrote: Larry Finger wrote: Hi, I placed a number of test prints in my system trying to find where a DMA data error might occur. In doing so, I found that 3 slots in the DMA header cache cross a page boundary. Such a situation is allowed on my system, but it might be forbidden on Atom processors. Please try this really ugly hack to see if it makes any difference. I confirm that the DMA error is still present with this patch. Thanks for testing. The results are as Michael expected, and as I feared. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Fatal DMA error problem with netbook and BCM4312 - Test 2
On Monday 21 December 2009 23:20:06 Larry Finger wrote: Here, it was slot 74 that crossed the page boundary. At 110 bytes per every 2 slots, that works out to 4070 bytes for 0 - 73. From that, I infer that the cache starts on a page boundary. Yeah well. For you. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Fatal DMA error problem with netbook and BCM4312 - Test 2
On Mon, 21 Dec 2009 17:18:01 -0500 William Bourque william.bour...@polymtl.ca wrote: Larry Finger wrote: Hi, I placed a number of test prints in my system trying to find where a DMA data error might occur. In doing so, I found that 3 slots in the DMA header cache cross a page boundary. Such a situation is allowed on my system, but it might be forbidden on Atom processors. Please try this really ugly hack to see if it makes any difference. I confirm that the DMA error is still present with this patch. Ditto. Chris ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Fatal DMA error problem with netbook and BCM4312 - another test
Hi, If possible, please test this patch starting from a cold boot. It is a variation of something we tried earlier, but enough different to try it. Thanks, Larry In exploring the cause of DMA errors for BCM4312 devices on Atom processors, other drivers that work write to PCI configuration register 0x40. The code fragment below was found in the open-code portion of the Broadcom hybrid wl driver. It is also used in the ipw2100 and ath9k drivers. In the latter case, it had been removed and later restored to prevent fatal interrupt errors. Signed-off-by: Larry Finger larry.fin...@lwfinger.net --- Index: wireless-testing/drivers/net/wireless/b43/main.c === --- wireless-testing.orig/drivers/net/wireless/b43/main.c +++ wireless-testing/drivers/net/wireless/b43/main.c @@ -4292,6 +4292,15 @@ static int b43_wireless_core_init(struct setup_struct_wldev_for_init(dev); phy-ops-prepare_structs(dev); + /* We disable the RETRY_TIMEOUT register (0x41) to keep +* PCI Tx retries from interfering with C3 CPU state +* This code fragment found in the Broadcom hybrid wl driver +*/ + pci_read_config_dword(bus-host_pci, 0x40, tmp); + if ((tmp 0xff00) != 0) + pci_write_config_dword(bus-host_pci, 0x40, tmp + ~(0xff00)); + /* Enable IRQ routing to this device. */ ssb_pcicore_dev_irqvecs_enable(bus-pcicore, dev-dev); ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Fatal DMA error problem with netbook and BCM4312 - another test
On Sat, 19 Dec 2009 10:43:29 -0600 Larry Finger larry.fin...@lwfinger.net wrote: Hi, If possible, please test this patch starting from a cold boot. It is a variation of something we tried earlier, but enough different to try it. Thanks, Larry I applied this to 2.6.32.2 and it didn't help with the DMA errors I am afraid. Chris ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Fatal DMA error problem with netbook and BCM4312 - another test
On 19/12/09 19:55, Chris Vine wrote: On Sat, 19 Dec 2009 10:43:29 -0600 Larry Fingerlarry.fin...@lwfinger.net wrote: Hi, If possible, please test this patch starting from a cold boot. It is a variation of something we tried earlier, but enough different to try it. Thanks, Larry I applied this to 2.6.32.2 and it didn't help with the DMA errors I am afraid. Chris Same here, the patch didn't prevent the DMA errors, however, I did notice that it only reported the error once, it didn't keep trying to reload the firmware. Andy ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Fatal DMA error problem with netbook and BCM4312 - another test
On 12/19/2009 05:11 PM, Andrew Benton wrote: On 19/12/09 19:55, Chris Vine wrote: I applied this to 2.6.32.2 and it didn't help with the DMA errors I am afraid. Chris Same here, the patch didn't prevent the DMA errors, however, I did notice that it only reported the error once, it didn't keep trying to reload the firmware. The change that bails out after one fatal DMA error is a separate one. As there is no chance of recovering, we decided not to spam the logs. Thanks for testing. I had little expectation, but this one may be needed in conjunction with something else. Back to the grindstone. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Fatal DMA error problem with netbook and BCM4312 - another test
Larry Finger wrote: Hi, If possible, please test this patch starting from a cold boot. It is a variation of something we tried earlier, but enough different to try it. Thanks, Larry A little late but I just tested and I have the same bug. However, unlike Andrew, the error keep repeating as before... - William ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Fatal DMA error problem with netbook and BCM4312 - another test
On 12/19/2009 10:15 PM, William Bourque wrote: Larry Finger wrote: Hi, If possible, please test this patch starting from a cold boot. It is a variation of something we tried earlier, but enough different to try it. Thanks, Larry A little late but I just tested and I have the same bug. However, unlike Andrew, the error keep repeating as before... He is using wireless-testing or a recent mainline kernel. That is where the change I described is installed. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Test message, please ignore.
I suspect that this will trigger a response from a spambot. reset ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
b43 and sprom modification success on a test card.
Well, I have a different card to modify as I prepare to familiarize myself with the process so that when the bcm4321 chipset (0x4328 / 0x4329) is supported I will have great success. I found a miniPCI card from a china made bcm4306 based card with the 0x4320 ID that was not recognized as an Apple Airport card. It look like it would be recognized by the b43 module based on source examination so I figured I'd use a PCI to miniPCI adapter and see if I can make the changes without bricking the card. iwpriv doesn't seem to like the b43 module recognized card and wouldn't allow me to perform any read/write functions and it was hinted that this method is for the older bcm43xx module. I located the ssb_sprom file for the card in question by identification of lspci and copied out the ssb_sprom file to the Desktop as original_sprom for easy identification (and so I know which was the unmodified). Time for step one: I modified the firmware with the ID's I want using the ssb-sprom application. On to step two: As suggested by Asheesh, I copied the modified firmware file onto the ssb_sprom file in the original location and at first I couldn't tell and wasn't sure if anything happened so I rmmod b43; modprobe b43 and copied the ssb_sprom file back to the desktop as new_original_sprom and then did ssb-sprom -i Desktop/ new_original_sprom -P and my new ID's were displayed so it was time to test this so I started trying the card in various computers and was elated with the success of things. Results now in Mac OS X on a BW G3, a PowerPC Dual G5 Xserve and an generic Intel x86 PC sporting a Core 2 Quad is that the card is natively recognized and supported. http://acm.pastebin.com/f517a0a8 http://daleenterprise.com/download/airportclone.png Now I have question regarding the process I performed. Was the disabling and enabling of b43 required??? Is this the correct procedure for modification of the subsys ID's??? -- Dale PGP.sig Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
b43 and sprom modification success on a test card. [correction]
Well, I have a different card to modify as I prepare to familiarize myself with the process so that when the bcm4321 chipset (0x4328 / 0x4329) is supported I will have great success. I found a miniPCI card from a china made bcm4306 based card with the 0x4320 ID that was not recognized as an Apple Airport card. It look like it would be recognized by the b43 module based on source examination so I figured I'd use a PCI to miniPCI adapter and see if I can make the changes without bricking the card. iwpriv doesn't seem to like the b43 module recognized card and wouldn't allow me to perform any read/write functions and it was hinted that this method is for the older bcm43xx module. I located the ssb_sprom file for the card in question by identification of lspci and copied out the ssb_sprom file to the Desktop as original_sprom for easy identification (and so I know which was the unmodified). Time for step one: I modified the firmware with the ID's I want using the ssb-sprom application. On to step two: As suggested by Asheesh, I copied the modified firmware file onto the ssb_sprom file in the original location and at first I couldn't tell and wasn't sure if anything happened so I rmmod b43; modprobe b43 and copied the ssb_sprom file back to the desktop as new_original_sprom and then did ssb-sprom -i Desktop/ new_original_sprom -P and my new ID's were displayed so it was time to test this so I started trying the card in various computers and was elated with the success of things. Results now in Mac OS X on a BW G3, a PowerPC Dual G5 Xserve and an generic Intel x86 PC sporting a Core 2 Quad is that the card is natively recognized and supported. http://acm.pastebin.com/f5175a0a8 http://daleenterprise.com/download/airportclone.png Now I have question regarding the process I performed. Was the disabling and enabling of b43 required??? Is this the correct procedure for modification of the subsys ID's??? -- Dale PGP.sig Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 and sprom modification success on a test card. [correction] [THANK YOU]
I started looking at the Apple ID list again and it appears that 0x0453 was incorrect for this card type since it was the ID for the miniPCIe card and not the miniPCI card I was using so I thought I'd give it another shot and change the ID again. I modified my ID's in a new file and copied it over to ssb_sprom. I took a look at dmesg and I saw that ssb writing to the card so without further action I rebooted into OSX and the ID's were now correct for the specific card type. I tested the card in Mac OS X 10.4.0, 10.4.8, 10.4.11, 10.5.0, 10.5.2 and 10.5.3 and the card was properly identified. While the process has now become much simpler, I think it's extremely dangerous if it doesn't perform some kind of verification on the data that is being copied before it actually performs the firmware update. I wish to thank Asheesh for his time in helping me get acclimated to ubuntu-hardy and also the authors of b43 and ssb for simplifying the sprom writing process and look forward to when the new cards like the LinkSYS WMP300n and Buffalo Technology WLI-PCI-G300N are supported so that the ID's can be corrected thus allowing the use of inexpensive third-party cards without sacrificing functionality in other OS's. Since this has turned out to be such a simple process, waiting for the support of newer cards is a worthwhile wait provide that effort is being applied. I really wanna help, the cause is worthwhile. What task can I perform? (no task to menial) On Jun 09, 2008, at 04:46 AM, Dale Walsh wrote: Well, I have a different card to modify as I prepare to familiarize myself with the process so that when the bcm4321 chipset (0x4328 / 0x4329) is supported I will have great success. I found a miniPCI card from a china made bcm4306 based card with the 0x4320 ID that was not recognized as an Apple Airport card. It look like it would be recognized by the b43 module based on source examination so I figured I'd use a PCI to miniPCI adapter and see if I can make the changes without bricking the card. iwpriv doesn't seem to like the b43 module recognized card and wouldn't allow me to perform any read/write functions and it was hinted that this method is for the older bcm43xx module. I located the ssb_sprom file for the card in question by identification of lspci and copied out the ssb_sprom file to the Desktop as original_sprom for easy identification (and so I know which was the unmodified). Time for step one: I modified the firmware with the ID's I want using the ssb-sprom application. On to step two: As suggested by Asheesh, I copied the modified firmware file onto the ssb_sprom file in the original location and at first I couldn't tell and wasn't sure if anything happened so I rmmod b43; modprobe b43 and copied the ssb_sprom file back to the desktop as new_original_sprom and then did ssb-sprom -i Desktop/ new_original_sprom -P and my new ID's were displayed so it was time to test this so I started trying the card in various computers and was elated with the success of things. Results now in Mac OS X on a BW G3, a PowerPC Dual G5 Xserve and an generic Intel x86 PC sporting a Core 2 Quad is that the card is natively recognized and supported. http://acm.pastebin.com/f5175a0a8 http://daleenterprise.com/download/airportclone.png Now I have question regarding the process I performed. Was the disabling and enabling of b43 required??? Is this the correct procedure for modification of the subsys ID's??? -- Dale ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev -- Dale -- Dale PGP.sig Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 and sprom modification success on a test card. [correction] [THANK YOU]
On Monday 09 June 2008 12:03:35 Dale Walsh wrote: While the process has now become much simpler, I think it's extremely dangerous if it doesn't perform some kind of verification on the data that is being copied before it actually performs the firmware update. It performs an 8bit CRC check. So you can't write any random data to it. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 4311: trouble with Fedora 8 Test 3
On 10/10/07, John W. Linville [EMAIL PROTECTED] wrote: On Wed, Oct 10, 2007 at 12:08:08PM -0400, sean darcy wrote: Nothing at all about the 4311 card in dmesg. Made sure NetworkManager was working. Restarted it. I can see the icon. No connection. If I connect the wire it starts up the wired connection. Please post the output of this command: cat /sys/bus/ssb/devices/ssb0\:0/uevent cat /sys/bus/ssb/devices/ssb0\:0/uevent PHYSDEVBUS=ssb MODALIAS=ssb:v4243id0812rev0D I suspect that your device's core is too new to be supported. OK, break my heart. I actually thought that since it had the intel 965 chipset, that it would have intel wlan, but I shoulda checked... In the meantime, if I can supply any info, just let me know. sean ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
4311: trouble with Fedora 8 Test 3
Compaq Presario C714NR, Intel GM965 uname -r 2.6.23-0.224.rc9.git6.fc8 lspci 01:00.0 Network controller: Broadcom Corporation BCM94311MCG wlan mini-PCI (rev 02) Installed b43-fwcutter and followed the instructions at http://linuxwireless.org/en/users/Drivers/b43#devicefirmware Got http://downloads.openwrt.org/sources/broadcom-wl-4.80.53.0.tar.bz2 untarred that file and ran b43-fwcutter -w /lib/firmare broadcom-wl-4.80.53.0/kmod/wl_apsta.o that seemed to work, and populated /lib/firmware/b43/ with a bunch of *.fw files. Then rmmod b43; modprobe -vv b43. No errors. Nothing in syslog. modprobe also loaded cfg80211 and mac80211. Shouldn't I have seen the firmware being loaded in dmesg, or syslog? Nothing at all about the 4311 card in dmesg. Made sure NetworkManager was working. Restarted it. I can see the icon. No connection. If I connect the wire it starts up the wired connection. dmesg does show this error: ssb: rev 6000 WARNING: at drivers/ssb/main.c:889 ssb_tmslow_reject_bitmask() (Not tainted) Call Trace: [88118878] :ssb:ssb_tmslow_reject_bitmask+0x76/0x7f [88119062] :ssb:ssb_device_is_enabled+0xf/0x39 [8811b232] :ssb:ssb_pcicore_init+0x19/0x4a [881185e2] :ssb:ssb_attach_queued_buses+0x83/0x25e [88119ce8] :ssb:ssb_pci_get_invariants+0x0/0x2ba [88118be8] :ssb:ssb_bus_register+0x144/0x196 [88118cea] :ssb:ssb_bus_pcibus_register+0x2a/0x4b [8811a5a9] :ssb:ssb_pcihost_probe+0x6f/0x9e [81137d8d] pci_device_probe+0xd0/0x137 [811a1033] driver_probe_device+0xff/0x17c [811a11f8] __driver_attach+0x90/0xcc [811a1168] __driver_attach+0x0/0xcc [811a1168] __driver_attach+0x0/0xcc [811a03ca] bus_for_each_dev+0x43/0x6e [811a0742] bus_add_driver+0x7b/0x19d [81137f6f] __pci_register_driver+0x68/0x9a [880e9045] :ssb:ssb_modinit+0x45/0x5d [8105d8b3] sys_init_module+0x15d5/0x173a [8100bbfe] system_call+0x7e/0x83 ssb: Sonics Silicon Backplane found on PCI device :01:00.0 I also rmmod b43, and modprobe'd b43legacy. No help. Any help appreciated. sean ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 4311: trouble with Fedora 8 Test 3
On Wed, Oct 10, 2007 at 12:08:08PM -0400, sean darcy wrote: Nothing at all about the 4311 card in dmesg. Made sure NetworkManager was working. Restarted it. I can see the icon. No connection. If I connect the wire it starts up the wired connection. Please post the output of this command: cat /sys/bus/ssb/devices/ssb0\:0/uevent I suspect that your device's core is too new to be supported. dmesg does show this error: ssb: rev 6000 WARNING: at drivers/ssb/main.c:889 ssb_tmslow_reject_bitmask() (Not tainted) Technically a warning, not an error. :-) John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 4311: trouble with Fedora 8 Test 3
sean darcy wrote: Compaq Presario C714NR, Intel GM965 uname -r 2.6.23-0.224.rc9.git6.fc8 lspci 01:00.0 Network controller: Broadcom Corporation BCM94311MCG wlan mini-PCI (rev 02) As John Linville suggested, rev 02 of the 4311's are not supported. At the moment, the reverse engineers need to take apart the latest Broadcom driver and write the specifications for this device. Until they find the time, this device will not work with either b43 or bcm43xx. Sorry, Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Test framework
I was wondering whether there exists a test framework/there is a need for automated tests, which could be run by everyone, without the knowledge what is exactly going on in bcm43xx development. What kind of test would be of any interest to you? Functional/performance blackbox tests? Coverage tests? -- at ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
speed test (4318)
With this card: LinkSys Wireless-G WPC54GS (ver.2)) Chip ID 0x4318, rev 0x2 Number of cores: 4 bcm43xx: Core 0: ID 0x800, rev 0xd, vendor 0x4243, enabled bcm43xx: Core 1: ID 0x812, rev 0x9, vendor 0x4243, disabled bcm43xx: Core 2: ID 0x804, rev 0xc, vendor 0x4243, enabled bcm43xx: Core 3: ID 0x80d, rev 0x7, vendor 0x4243, enabled I'm getting these speeds: -- 2.6.20 patched with 2.6.20.combined -- RATE SPEED 11 Mb/s 621 Kb/s 18 Mb/s 620 Kb/s 24 Mb/s 608 Kb/s 36 Mb/s 534 Kb/s 54 Mb/s 572 Kb/s -- 2.6.20 patched with 2.6.20.combined and with the `the real fix for bcm4311 and bcm4312' (Feb 7) -- RATE SPEED 11 Mb/s 524 Kb/s 18 Mb/s 578 Kb/s 24 Mb/s 616 Kb/s 36 Mb/s 619 Kb/s 54 Mb/s 607 Kb/s The router is a LinkSys WRT54G(L) (no other cards connecting). The speed estimates come from wget downloading kernel source, averaged over 3 tries. With the earlier patch (the `really good news' patch, Feb 6), the card continued to work, but it slowed to a crawl. Hope this is helpful. Thanks for all the good work, Jim ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: speed test (4318)
Jim McCloskey wrote: With this card: LinkSys Wireless-G WPC54GS (ver.2)) Chip ID 0x4318, rev 0x2 Number of cores: 4 bcm43xx: Core 0: ID 0x800, rev 0xd, vendor 0x4243, enabled bcm43xx: Core 1: ID 0x812, rev 0x9, vendor 0x4243, disabled bcm43xx: Core 2: ID 0x804, rev 0xc, vendor 0x4243, enabled bcm43xx: Core 3: ID 0x80d, rev 0x7, vendor 0x4243, enabled I'm getting these speeds: -- 2.6.20 patched with 2.6.20.combined -- RATE SPEED 11 Mb/s 621 Kb/s 18 Mb/s 620 Kb/s 24 Mb/s 608 Kb/s 36 Mb/s 534 Kb/s 54 Mb/s 572 Kb/s -- 2.6.20 patched with 2.6.20.combined and with the `the real fix for bcm4311 and bcm4312' (Feb 7) -- RATE SPEED 11 Mb/s 524 Kb/s 18 Mb/s 578 Kb/s 24 Mb/s 616 Kb/s 36 Mb/s 619 Kb/s 54 Mb/s 607 Kb/s The router is a LinkSys WRT54G(L) (no other cards connecting). The speed estimates come from wget downloading kernel source, averaged over 3 tries. With the earlier patch (the `really good news' patch, Feb 6), the card continued to work, but it slowed to a crawl. Hope this is helpful. Thanks for all the good work, You are very welcome. I'm just happy to finally start to crack these problems after so long. Just as a point of reference, I think wget yields KBs (kilo-bytes/sec). My iperf numbers are in Kbs (kilo-bits/sec). Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[TEST] Does this help 1GB memory problem?
The patch below implements a quick-and-dirty approach to solving the problem of
DMA with more than 1 GB memory. Unfortunately, I don't have the hardware to test
it. The patch is intended for the wireless-2.6 tree. It will not work with
2.6.18-rcX. Please report your results, and the log messages.
Thanks,
Larry
Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_dma.c
===
--- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_dma.c
+++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_dma.c
@@ -215,15 +215,36 @@ void free_descriptor_buffer(struct bcm43
static int alloc_ringmemory(struct bcm43xx_dmaring *ring)
{
struct device *dev = (ring-bcm-pci_dev-dev);
+ int i, j;
+ struct {
+ dma_addr_t dmabase;
+ void *descbase;
+ } dma_trial[10];
- ring-descbase = dma_alloc_coherent(dev, BCM43xx_DMA_RINGMEMSIZE,
+ for (i=0; i10; i++) {
+ ring-descbase = dma_alloc_coherent(dev,
BCM43xx_DMA_RINGMEMSIZE,
(ring-dmabase), GFP_KERNEL);
- if (!ring-descbase) {
- printk(KERN_ERR PFX DMA ringmemory allocation failed\n);
- return -ENOMEM;
+ if (!ring-descbase) {
+ printk(KERN_ERR PFX DMA ringmemory allocation
failed\n);
+ return -ENOMEM;
+ }
+ if (ring-dmabase + BCM43xx_DMA_RINGMEMSIZE 0x3fff)
+ goto low_mem_ok;
+ dma_trial[i].descbase = ring-descbase;
+ dma_trial[i].dmabase = ring-dmabase;
+ printk(KERN_INFO PFX Trial %d: dmabase = 0x%.8x\n, i+1,
ring-dmabase);
}
+ printk(KERN_INFO PFX Unable to get DMA memory below 1 GB boundary.\n);
+
+low_mem_ok:
memset(ring-descbase, 0, BCM43xx_DMA_RINGMEMSIZE);
+ if (i != 0) {
+ for (j=0; ji; j++)/* get rid of any trials that failed */
+ dma_free_coherent(dev, BCM43xx_DMA_RINGMEMSIZE,
+ dma_trial[j].descbase,
dma_trial[j].dmabase);
+ }
+
return 0;
}
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [TEST] Does this help 1GB memory problem?
On Tuesday 19 September 2006 18:40, Larry Finger wrote:
The patch below implements a quick-and-dirty approach to solving the problem
of
DMA with more than 1 GB memory. Unfortunately, I don't have the hardware to
test
it. The patch is intended for the wireless-2.6 tree. It will not work with
2.6.18-rcX. Please report your results, and the log messages.
Q: Does this help 1GB memory problem?
A: No ;)
Please lookup old SVN archives, where I implemented such a
dirty workaround like this.
1) We also need to have descriptor buffers under 1G
2) I think it's clear to you, that this is based on pure
luck, as retrying 10 times can easily fail as well
as only trying once.
If you want 1G, get a device which supports this.
Thanks,
Larry
Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_dma.c
===
--- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_dma.c
+++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_dma.c
@@ -215,15 +215,36 @@ void free_descriptor_buffer(struct bcm43
static int alloc_ringmemory(struct bcm43xx_dmaring *ring)
{
struct device *dev = (ring-bcm-pci_dev-dev);
+ int i, j;
+ struct {
+ dma_addr_t dmabase;
+ void *descbase;
+ } dma_trial[10];
- ring-descbase = dma_alloc_coherent(dev, BCM43xx_DMA_RINGMEMSIZE,
+ for (i=0; i10; i++) {
+ ring-descbase = dma_alloc_coherent(dev,
BCM43xx_DMA_RINGMEMSIZE,
(ring-dmabase), GFP_KERNEL);
- if (!ring-descbase) {
- printk(KERN_ERR PFX DMA ringmemory allocation failed\n);
- return -ENOMEM;
+ if (!ring-descbase) {
+ printk(KERN_ERR PFX DMA ringmemory allocation
failed\n);
+ return -ENOMEM;
+ }
+ if (ring-dmabase + BCM43xx_DMA_RINGMEMSIZE 0x3fff)
+ goto low_mem_ok;
+ dma_trial[i].descbase = ring-descbase;
+ dma_trial[i].dmabase = ring-dmabase;
+ printk(KERN_INFO PFX Trial %d: dmabase = 0x%.8x\n, i+1,
ring-dmabase);
}
+ printk(KERN_INFO PFX Unable to get DMA memory below 1 GB boundary.\n);
+
+low_mem_ok:
memset(ring-descbase, 0, BCM43xx_DMA_RINGMEMSIZE);
+ if (i != 0) {
+ for (j=0; ji; j++)/* get rid of any trials that failed */
+ dma_free_coherent(dev, BCM43xx_DMA_RINGMEMSIZE,
+ dma_trial[j].descbase,
dma_trial[j].dmabase);
+ }
+
return 0;
}
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [TEST] Does this help 1GB memory problem?
Am Dienstag 19 September 2006 18:50 schrieb Michael Buesch: If you want 1G, get a device which supports this. I am not affected by this issue but as mentioned earlier: could you fall back to non-dma mode? If not, you should fail completely instead of trying to run a setup that is know to not work correctly. HS ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [TEST] Does this help 1GB memory problem?
Michael Buesch wrote: On Tuesday 19 September 2006 18:40, Larry Finger wrote: Q: Does this help 1GB memory problem? A: No ;) Please lookup old SVN archives, where I implemented such a dirty workaround like this. 1) We also need to have descriptor buffers under 1G 2) I think it's clear to you, that this is based on pure luck, as retrying 10 times can easily fail as well as only trying once. If you want 1G, get a device which supports this. Sorry that I didn't see your workaround in the SVN archives. I found what Linville did for the b44 chip. In your estimation, should it be possible to implement a test for 30-bit hardware and more than 1 GB memory early enough to switch the interface to pio mode? Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [TEST] Does this help 1GB memory problem?
On Tue, 2006-09-19 at 12:45 -0500, Larry Finger wrote: Michael Buesch wrote: On Tuesday 19 September 2006 18:40, Larry Finger wrote: Q: Does this help 1GB memory problem? A: No ;) Please lookup old SVN archives, where I implemented such a dirty workaround like this. 1) We also need to have descriptor buffers under 1G 2) I think it's clear to you, that this is based on pure luck, as retrying 10 times can easily fail as well as only trying once. If you want 1G, get a device which supports this. Sorry that I didn't see your workaround in the SVN archives. I found what Linville did for the b44 chip. In your estimation, should it be possible to implement a test for 30-bit hardware and more than 1 GB memory early enough to switch the interface to pio mode? Larry Must admit the patch seemed like a stretch, but tried it anyway, as predicted, the same exception still exists. OK, I have'nt been hacking the kernel for many years now but how does the Win XP driver then work with ndiswrapper. Surely it should be failing with a similar problem on the same hardware? From dmesg I see the following, this tells me there are both DMA and DMA32 available? On node 0 totalpages: 514181 DMA zone: 2384 pages, LIFO batch:0 DMA32 zone: 511797 pages, LIFO batch:31 I am assuming DMA is 16 bit, so is there no way to force the kernel to only return a DMA allocation 2^30. In other words from the DMA zone and not the DMA32 zone? ~Z~ ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [TEST] Does this help 1GB memory problem?
On Tue, 2006-09-19 at 18:50 +0200, Michael Buesch wrote: If you want 1G, get a device which supports this. This is really not an option. First and foremost reason is that I like many others use a notebook with built in hardware. So the option to simply replace the hardware is unrealistic at best. Secondly even newer hardware like the Acer Ferrari 5000, Asus Lamborghini and many more now supports memory way above 1GB. The Acer for instance supports upto 4GB RAM. Saying that there simply is no way to get a working driver for that kind of hardware will only cause people to rethink moving to linux and sticky with what works Win XP / Vista. Now I'm no Win fan by any chance and I have been a long supporter, user and hacker of linux since the days when the network drivers were still embeded inside the kernel, back in '94. We've come along way since then and I simply can't believe that there is absolutely no way of working around this problem. BTW. The Acer Ferrari 5000 still uses a Broadcom chipset for it's wireless hadrware. ~Z~ ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [TEST] Does this help 1GB memory problem?
Zahir Toufie wrote: Must admit the patch seemed like a stretch, but tried it anyway, as predicted, the same exception still exists. OK, I have'nt been hacking the kernel for many years now but how does the Win XP driver then work with ndiswrapper. Surely it should be failing with a similar problem on the same hardware? From what I understand, there is a long-standing bug in the DMA memory allocation routine. The net effect is that it either makes the full 4 GB (32 bit) range available, or it limits one to a 16 Mb (24 bit) limit. A problem is that for large systems, all memory in the lower 16 MB is probably used before the bcm43xx driver tries to get its allocation. This faulty allocation scheme is maintained to keep heritage devices from breaking. Windows probably has implemented the allocation scheme correctly. I'm not sure how ndiswrapper gets around the problem. What I would like to do is find where the distinction is made between 32- and 24-bit DMA and prepare a mod that an individual user could apply to make their interface work. It should be safe to assume that any system with 2 GB of memory probably doesn't have any such heritage equipment! In any case, this patch would _NEVER_ make it into the stable tree. So far, I have not found and/or understood this part of the code. Any pointers as to where to look would be appreciated. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [TEST] Does this help 1GB memory problem?
On Tuesday 19 September 2006 20:55, Zahir Toufie wrote: On Tue, 2006-09-19 at 18:50 +0200, Michael Buesch wrote: If you want 1G, get a device which supports this. This is really not an option. First and foremost reason is that I like many others use a notebook with built in hardware. So the option to simply replace the hardware is unrealistic at best. Secondly even newer hardware like the Acer Ferrari 5000, Asus Lamborghini and many more now supports memory way above 1GB. The Acer for instance supports upto 4GB RAM. Saying that there simply is no way to get a working driver for that kind of hardware will only cause people to rethink moving to linux and sticky with what works Win XP / Vista. Now I'm no Win fan by any chance and I have been a long supporter, user and hacker of linux since the days when the network drivers were still embeded inside the kernel, back in '94. We've come along way since then and I simply can't believe that there is absolutely no way of working around this problem. Oh, come one. If you are a long supporter, user and hacker, you can surely come up with a good solution that a) works and b) is not a damn ugly hack This is the same issue as with PCI-E hardware. _Lots_ of people request it, but nobody is going to implement and test it. Well, I can't do it for you, as I don't have the hardware. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] Fix for bcm43xx_mac_suspend timeouts - please test
Michael,
In trying various things in mac_suspend, I accidentally messed up the test for IRQ ready so that the
code returned immediately. The bottom line was that nothing went wrong. There were no crashes and no
hangs. On that basis, I changed the code as shown in the following patch. This code has been running
for two days on my system. Numerous MAC suspend failed messages have been logged, but the
interface has not failed. I will continue testing.
Larry
index 1cd47c5..a7ae1a9 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_main.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_main.c
@@ -2307,24 +2147,22 @@ void bcm43xx_mac_enable(struct bcm43xx_p
bcm43xx_power_saving_ctl_bits(bcm, -1, -1);
}
-/* http://bcm-specs.sipsolutions.net/SuspendMAC */
+/* http://bcm-specs.sipsolutions.net/SuspendMAC calls for the code to delay as
long as 10 ms for
+ the interface to set the BCM43xx_IRQ_READY bit in
BCM43xx_MMIO_GEN_IRQ_REASON. To date, only
+ Rev 2 of the BCM4306 has needed any delay before setting the ready bit, and
this revision
+ seems to work OK without a delay, even when the ready bit is not set.
Therefore, the delay loop
+ has been removed. */
+
void bcm43xx_mac_suspend(struct bcm43xx_private *bcm)
{
- int i;
- u32 tmp;
-
bcm43xx_power_saving_ctl_bits(bcm, -1, 1);
bcm43xx_write32(bcm, BCM43xx_MMIO_STATUS_BITFIELD,
bcm43xx_read32(bcm, BCM43xx_MMIO_STATUS_BITFIELD)
~BCM43xx_SBF_MAC_ENABLED);
bcm43xx_read32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON); /* dummy read */
- for (i = 10; i; i--) {
- tmp = bcm43xx_read32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON);
- if (tmp BCM43xx_IRQ_READY)
- return;
- udelay(10);
- }
- printkl(KERN_ERR PFX MAC suspend failed\n);
+ if (!(bcm43xx_read32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON)
BCM43xx_IRQ_READY))
+ printkl(KERN_ERR PFX MAC suspend failed\n);
+ return;
}
void bcm43xx_set_iwmode(struct bcm43xx_private *bcm,
=
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] Fix for bcm43xx_mac_suspend timeouts - please test
On Sunday 02 July 2006 17:45, you wrote:
Michael,
In trying various things in mac_suspend, I accidentally messed up the test
for IRQ ready so that the
code returned immediately. The bottom line was that nothing went wrong. There
were no crashes and no
hangs. On that basis, I changed the code as shown in the following patch.
This code has been running
for two days on my system. Numerous MAC suspend failed messages have been
logged, but the
interface has not failed. I will continue testing.
This patch is not going upstream, as it is broken.
What are you trying to do here?
If the READY bit will be there the first time IT WON'T LOOP ANYWAY.
PLEASE stop messing with the mac_suspend, and apply my original patch.
Damnit!
We _must_ synchronize with the device here. Fullstop.
index 1cd47c5..a7ae1a9 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_main.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_main.c
@@ -2307,24 +2147,22 @@ void bcm43xx_mac_enable(struct bcm43xx_p
bcm43xx_power_saving_ctl_bits(bcm, -1, -1);
}
-/* http://bcm-specs.sipsolutions.net/SuspendMAC */
+/* http://bcm-specs.sipsolutions.net/SuspendMAC calls for the code to delay
as long as 10 ms for
+ the interface to set the BCM43xx_IRQ_READY bit in
BCM43xx_MMIO_GEN_IRQ_REASON. To date, only
+ Rev 2 of the BCM4306 has needed any delay before setting the ready bit,
and this revision
+ seems to work OK without a delay, even when the ready bit is not set.
Therefore, the delay loop
+ has been removed. */
+
void bcm43xx_mac_suspend(struct bcm43xx_private *bcm)
{
- int i;
- u32 tmp;
-
bcm43xx_power_saving_ctl_bits(bcm, -1, 1);
bcm43xx_write32(bcm, BCM43xx_MMIO_STATUS_BITFIELD,
bcm43xx_read32(bcm, BCM43xx_MMIO_STATUS_BITFIELD)
~BCM43xx_SBF_MAC_ENABLED);
bcm43xx_read32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON); /* dummy read */
- for (i = 10; i; i--) {
- tmp = bcm43xx_read32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON);
- if (tmp BCM43xx_IRQ_READY)
- return;
- udelay(10);
- }
- printkl(KERN_ERR PFX MAC suspend failed\n);
+ if (!(bcm43xx_read32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON)
BCM43xx_IRQ_READY))
+ printkl(KERN_ERR PFX MAC suspend failed\n);
+ return;
}
void bcm43xx_set_iwmode(struct bcm43xx_private *bcm,
=
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [Bcm43xx-dev] Test report.
On Sat, 2005-12-31 at 02:37 +, David Woodhouse wrote: At that point I can use dhclient successfully and Legacy IP works. Hm, almost. If I leave a ping running, I see an occasional TX timeout, followed by a reset -- and then I have to manually set the ESSID again before it'll work any more. I also see it complain 'bcm43xx: ieee80211_rx() failed' every minute, when it receives a IEEE80211_STYPE_NULLFUNC frame which iee80211_rx() silently drops. bcm43xx driver 0.0.1 bcm43xx: Chip ID 0x4306, rev 0x2 bcm43xx: Number of cores: 6 bcm43xx: Core 0: ID 0x800, rev 0x2, vendor 0x4243, enabled bcm43xx: Core 1: ID 0x812, rev 0x4, vendor 0x4243, enabled bcm43xx: Core 2: ID 0x80d, rev 0x1, vendor 0x4243, enabled bcm43xx: Core 3: ID 0x807, rev 0x1, vendor 0x4243, disabled bcm43xx: Core 4: ID 0x804, rev 0x7, vendor 0x4243, enabled bcm43xx: Core 5: ID 0x812, rev 0x4, vendor 0x4243, disabled bcm43xx: Ignoring additional 802.11 core. bcm43xx: Detected PHY: Version: 1, Type 2, Revision 1 bcm43xx: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2) bcm43xx: Radio turned off bcm43xx: Radio turned off bcm43xx: InitVals written bcm43xx: Radio turned on bcm43xx: Chip initialized bcm43xx: DMA initialized bcm43xx: 80211 cores initialized bcm43xx: TODO: Incomplete code in keymac_write() at drivers/net/wireless/bcm43xx/bcm43xx_main.c:1343 bcm43xx: TODO: Incomplete code in keymac_write() at drivers/net/wireless/bcm43xx/bcm43xx_main.c:1343 bcm43xx: TODO: Incomplete code in keymac_write() at drivers/net/wireless/bcm43xx/bcm43xx_main.c:1343 bcm43xx: TODO: Incomplete code in keymac_write() at drivers/net/wireless/bcm43xx/bcm43xx_main.c:1343 bcm43xx: TODO: Incomplete code in keymac_write() at drivers/net/wireless/bcm43xx/bcm43xx_main.c:1343 bcm43xx: TODO: Incomplete code in keymac_write() at drivers/net/wireless/bcm43xx/bcm43xx_main.c:1343 bcm43xx: TODO: Incomplete code in keymac_write() at drivers/net/wireless/bcm43xx/bcm43xx_main.c:1343 bcm43xx: TODO: Incomplete code in keymac_write() at drivers/net/wireless/bcm43xx/bcm43xx_main.c:1343 bcm43xx: TODO: Incomplete code in keymac_write() at drivers/net/wireless/bcm43xx/bcm43xx_main.c:1343 bcm43xx: TODO: Incomplete code in keymac_write() at drivers/net/wireless/bcm43xx/bcm43xx_main.c:1343 bcm43xx: TODO: Incomplete code in keymac_write() at drivers/net/wireless/bcm43xx/bcm43xx_main.c:1343 bcm43xx: TODO: Incomplete code in keymac_write() at drivers/net/wireless/bcm43xx/bcm43xx_main.c:1343 bcm43xx: TODO: Incomplete code in keymac_write() at drivers/net/wireless/bcm43xx/bcm43xx_main.c:1343 bcm43xx: TODO: Incomplete code in keymac_write() at drivers/net/wireless/bcm43xx/bcm43xx_main.c:1343 bcm43xx: TODO: Incomplete code in keymac_write() at drivers/net/wireless/bcm43xx/bcm43xx_main.c:1343 bcm43xx: TODO: Incomplete code in keymac_write() at drivers/net/wireless/bcm43xx/bcm43xx_main.c:1343 keys cleared eth2: no IPv6 routers present SoftMAC: net/ieee80211/softmac/ieee80211softmac_assoc.c:149:ieee80211softmac_assoc_work() SoftMAC: Associate: Network not known, trying to initiate scan: SoftMAC: Start scanning with channel: 1 SoftMAC: Scanning 13 channels ok. SoftMAC: Scanning finished SoftMAC: net/ieee80211/softmac/ieee80211softmac_assoc.c:149:ieee80211softmac_assoc_work() SoftMAC: Associate: Network not known, trying to initiate scan: SoftMAC: Start scanning with channel: 1 SoftMAC: Scanning 13 channels ok. SoftMAC: Scanning finished SoftMAC: net/ieee80211/softmac/ieee80211softmac_assoc.c:149:ieee80211softmac_assoc_work() SoftMAC: Associate: Network not known, trying to initiate scan: SoftMAC: Start scanning with channel: 1 SoftMAC: Scanning 13 channels ok. SoftMAC: Scanning finished SoftMAC: net/ieee80211/softmac/ieee80211softmac_assoc.c:149:ieee80211softmac_assoc_work() SoftMAC: Unable to find network after scan! bcm43xx: set security called bcm43xx:.active_key = 0 bcm43xx:.level = 1 bcm43xx:.enabled = 1 bcm43xx:.encrypt = 1 bcm43xx: TODO: Incomplete code in keymac_write() at drivers/net/wireless/bcm43xx/bcm43xx_main.c:1343 SoftMAC: net/ieee80211/softmac/ieee80211softmac_assoc.c:149:ieee80211softmac_assoc_work() SoftMAC: Associate: Network not known, trying to initiate scan: SoftMAC: Start scanning with channel: 1 SoftMAC: Scanning 13 channels ok. SoftMAC: Scanning finished SoftMAC: net/ieee80211/softmac/ieee80211softmac_assoc.c:149:ieee80211softmac_assoc_work() SoftMAC: Associate: Network not known, trying to initiate scan: SoftMAC: Start scanning with channel: 1 SoftMAC: Scanning 13 channels ok. SoftMAC: Scanning finished SoftMAC: net/ieee80211/softmac/ieee80211softmac_assoc.c:149:ieee80211softmac_assoc_work() SoftMAC: Associate: Network not known, trying to initiate scan: SoftMAC: Start scanning with channel: 1 SoftMAC: Scanning 13 channels ok. SoftMAC: Scanning finished SoftMAC: net/ieee80211/softmac/ieee80211softmac_assoc.c:149:ieee80211softmac_assoc_work() SoftMAC: Unable to find network after scan! SoftMAC:
[Bcm43xx-dev] Test report.
I've just tried the current (20051230) snapshot on the 2.6.15-rc7-git4 (Fedora Rawhide) kernel on a PowerBook. I also used the patch from http://marc.theaimsgroup.com/?l=linux-netdevm=113591302004639w=2 The resulting kernel package (which also installs on FC4 with --nodeps) is at http://david.woodhou.se/kernel-2.6.14-1.1805_FC5.bcm43xx.ppc.rpm Firmware as follows: filename : AppleAirPort2 version : 3.90.34.0.p11 (400.17) MD5 : ca0f34df2f0bfb8b5cfd83b5848d2bf5 Although the output of 'iwlist scan' looks correct, it doesn't manage to connect with ESSID set to 'any'. I have to explicitly set the ESSID for it to connect. I'm using WEP. At that point I can use dhclient successfully and Legacy IP works. IPv6, on the other hand, does not. It looks like a multicast problem -- it doesn't see the router advertisements which are sent to the multicast MAC address 33:33:00:00:00:01 -- even when I use tcpdump in promiscuous mode. If I ping the link-local address of other machines on the network, or manually configure IPv6 address and routes, then it almost works for _outgoing_ connections -- as long as the machine it's talking to is automatically inferring its MAC address from the packet which initiates the connection. To communicate with anything further afield than the local network, I have to keep pinging the router so that it doesn't forget my MAC address -- since I never see its neighbour solicitations. Suspend and resume led to a machine check... bcm43xx: Resuming... PCI: Enabling device 0001:10:12.0 ( - 0002) bcm43xx: InitVals written bcm43xx: Radio turned on Machine check in kernel mode. Caused by (from SRR1=214b030): Transfer error ack signal Vector: 200 (Machine Check) at [c1807be0] pc: f216f3e0: bcm43xx_phy_read+0x50/0xa0 [bcm43xx] lr: f216f584: bcm43xx_phy_set_antenna_diversity+0xb4/0x320 [bcm43xx] -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
