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
Re: Fatal DMA error problem with netbook and BCM4312
On Mon, 23 Nov 2009 22:58:36 -0500 William Bourque william.bour...@polymtl.ca wrote: Larry Finger wrote: One last check. I would appreciate receiving answers to the following questions. These questions apply to anyone else with this problem. Does the pm_qos patch help your fatal DMA error problem, particularly when booted from power-off? If you warm-boot after loading the wl driver, does the patch make any difference? Larry Hi I run a test case scenario on my notebook to figure out the QOS patch effect on the card reliability. I would say that the results are not very conclusive, but it seems the patch helped slightly, but not very time. To explain the methodology, I ran 4 series of test (Cold boot and warm boot, on battery and pluged in) between a patched and unpatched wireless-testing kernel. The time in the sheet is the time between the first line of the load of the firmware (b43 ssb0:0: firmware: requesting b43/ucode15.fw) to the first DMA error (b43-phy0 ERROR: Fatal DMA error: ) Three time, the card crashed but not DMA error were printed in the log. In that case, the line about the interface failing (b43-phy0 debug: Wireless interface stopped) were used instead. The time is taken accordingly to kernel timestamp printed by dmesg. Note that this test was design to make the card fails quickly. As soon as the card was up, the full kernel tree was transfert over a wireless LAN, as it has been observed before that fast rate transfert were good at crashing DMA. (I tried ping -f 172.16.0.1 before but the card was still alive after 5 minutes). Technically the following command was run : ifup wlan0 scp -r /usr/src/linux 172.16.0.1:~/ The result seems to show that the patch has no effect on warm-booted system but it seems to make the card slightly more reliable on cold-booted system, with an average time before crashing of 24.07 (patched cold boot) vs 22.98 (unpatched coldboot). William, Out of interest (I am not a b43 developer), was the warm boot a warm boot from a kernel with the proprietary wl driver installed, and if so does the wl driver work for you? 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
Chris Vine wrote: On Mon, 23 Nov 2009 22:58:36 -0500 William Bourque william.bour...@polymtl.ca wrote: Larry Finger wrote: One last check. I would appreciate receiving answers to the following questions. These questions apply to anyone else with this problem. Does the pm_qos patch help your fatal DMA error problem, particularly when booted from power-off? If you warm-boot after loading the wl driver, does the patch make any difference? Larry Hi I run a test case scenario on my notebook to figure out the QOS patch effect on the card reliability. I would say that the results are not very conclusive, but it seems the patch helped slightly, but not very time. To explain the methodology, I ran 4 series of test (Cold boot and warm boot, on battery and pluged in) between a patched and unpatched wireless-testing kernel. The time in the sheet is the time between the first line of the load of the firmware (b43 ssb0:0: firmware: requesting b43/ucode15.fw) to the first DMA error (b43-phy0 ERROR: Fatal DMA error: ) Three time, the card crashed but not DMA error were printed in the log. In that case, the line about the interface failing (b43-phy0 debug: Wireless interface stopped) were used instead. The time is taken accordingly to kernel timestamp printed by dmesg. Note that this test was design to make the card fails quickly. As soon as the card was up, the full kernel tree was transfert over a wireless LAN, as it has been observed before that fast rate transfert were good at crashing DMA. (I tried ping -f 172.16.0.1 before but the card was still alive after 5 minutes). Technically the following command was run : ifup wlan0 scp -r /usr/src/linux 172.16.0.1:~/ The result seems to show that the patch has no effect on warm-booted system but it seems to make the card slightly more reliable on cold-booted system, with an average time before crashing of 24.07 (patched cold boot) vs 22.98 (unpatched coldboot). William, Out of interest (I am not a b43 developer), was the warm boot a warm boot from a kernel with the proprietary wl driver installed, and if so does the wl driver work for you? I was using the B43 (GPL) driver but with the proprietary firmware extracted from Broadcom crap with bfwcutter. The proprietary driver provided by Broadcom (what you refer as wl?) fails to even detect the card. They clearly hate their customers. - 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
On Tue, 24 Nov 2009 10:50:13 -0500 William Bourque william.bour...@polymtl.ca wrote: [snip] I was using the B43 (GPL) driver but with the proprietary firmware extracted from Broadcom crap with bfwcutter. The proprietary driver provided by Broadcom (what you refer as wl?) fails to even detect the card. They clearly hate their customers. I should be very surprised if it doesn't detect your card provided you are using the right driver (and if you haven't compiled and installed a driver called wl.ko then so far as the proprietary driver is concerned you aren't). If you want to take this further, you probably want to go to http://www.broadcom.com/support/802.11/linux_sta.php , install the 32-bit or 64-bit driver according to your system, get the wl.ko driver working and then try warm booting from that and seeing if the b43 driver then works for you - it should. (You will need to copy wl.ko somewhere into your working module directory by hand - it doesn't really matter where - and after doing so run depmod -ae.) Note that this won't compile on 2.6.32-rc* without patching one of the files in the broadcom package, so it would probably be best to install it in a 2.6 31 (or earlier) kernel and warm boot from that. 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
Chris Vine wrote: On Tue, 24 Nov 2009 10:50:13 -0500 William Bourque william.bour...@polymtl.ca wrote: [snip] I was using the B43 (GPL) driver but with the proprietary firmware extracted from Broadcom crap with bfwcutter. The proprietary driver provided by Broadcom (what you refer as wl?) fails to even detect the card. They clearly hate their customers. I should be very surprised if it doesn't detect your card provided you are using the right driver (and if you haven't compiled and installed a driver called wl.ko then so far as the proprietary driver is concerned you aren't). I did tried before, it succesfully built, it was loading (modprobe) correctly but no new interface was registered by it. However, I might have done something wrong, I will try it again to make sure it wasn't a PEBKAC problem. If you want to take this further, you probably want to go to http://www.broadcom.com/support/802.11/linux_sta.php , install the 32-bit or 64-bit driver according to your system, get the wl.ko driver working and then try warm booting from that and seeing if the b43 driver then works for you - it should. (You will need to copy wl.ko somewhere into your working module directory by hand - it doesn't really matter where - and after doing so run depmod -ae.) Note that this won't compile on 2.6.32-rc* without patching one of the files in the broadcom package, so it would probably be best to install it in a 2.6 31 (or earlier) kernel and warm boot from that. Right. Do you have a link to this patch? I would rather avoid downgrading my kernel. - 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
On 11/24/2009 10:58 AM, William Bourque wrote: I did tried before, it succesfully built, it was loading (modprobe) correctly but no new interface was registered by it. However, I might have done something wrong, I will try it again to make sure it wasn't a PEBKAC problem. Are you certain that neither b43 nor ssb were loaded at the time? If ssb is in memory, it will own the PCI device. Right. Do you have a link to this patch? I would rather avoid downgrading my kernel. I just downloaded a fresh copy of the wl driver. It compiled cleanly. The only patch I applied is the following: Index: hybrid-wl/Makefile === --- hybrid-wl.orig/Makefile +++ hybrid-wl/Makefile @@ -34,3 +34,5 @@ clean: install: install -D -m 755 wl.ko /lib/modules/`uname -r`/kernel/drivers/net/wireless/wl.ko + depmod -a + With it, the dependencies are properly setup. Note, the install line above is improperly wrapped, but you get the idea. 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
Chris Vine wrote: On Tue, 24 Nov 2009 10:50:13 -0500 William Bourque william.bour...@polymtl.ca wrote: [snip] I was using the B43 (GPL) driver but with the proprietary firmware extracted from Broadcom crap with bfwcutter. The proprietary driver provided by Broadcom (what you refer as wl?) fails to even detect the card. They clearly hate their customers. I should be very surprised if it doesn't detect your card provided you are using the right driver (and if you haven't compiled and installed a driver called wl.ko then so far as the proprietary driver is concerned you aren't). If you want to take this further, you probably want to go to http://www.broadcom.com/support/802.11/linux_sta.php , install the 32-bit or 64-bit driver according to your system, get the wl.ko driver working and then try warm booting from that and seeing if the b43 driver then works for you - it should. (You will need to copy wl.ko somewhere into your working module directory by hand - it doesn't really matter where - and after doing so run depmod -ae.) Note that this won't compile on 2.6.32-rc* without patching one of the files in the broadcom package, so it would probably be best to install it in a 2.6 31 (or earlier) kernel and warm boot from that. So, I compiled the Broadcom proprietary driver (wl) against an old 2.6.32-rc5 that I still had. The compilation went fine so I guess I don't need the patch after all : r...@mini hybrid-broadcom # make KBUILD_NOPEDANTIC=1 make -C /lib/modules/`uname -r`/build M=`pwd` make[1]: Entering directory `/usr/src/linux-2.6.32-rc5-homemade' Building modules, stage 2. MODPOST 1 modules WARNING: modpost: missing MODULE_LICENSE() in /usr/local/hybrid-broadcom/wl.o see include/linux/module.h for more information make[1]: Leaving directory `/usr/src/linux-2.6.32-rc5-homemade' ..the module is copied at the right place and depmoded : r...@mini hybrid-broadcom # cp wl.ko /lib/modules/2.6.32-rc5-homemade/kernel/drivers/net/wireless/ r...@mini hybrid-broadcom # depmod -ae WARNING: -e needs -E or -F r...@mini hybrid-broadcom # **The system is rebooted here** r...@mini ~ # uname -a Linux mini 2.6.32-rc5-homemade #1 SMP PREEMPT Fri Nov 13 04:15:41 EST 2009 i686 GNU/Linux All others b43 drivers are blacklisted and does not load at boot : r...@mini ~ # lsmod Module Size Used by ipv6 225039 18 wmi 4083 0 i2c_i8017106 0 sky2 39059 0 evdev 6653 14 (Yes, very few modules, I like my kernel free of useless stuff). Now we load wl (depmod and everything was done, the build went correctly, I will probably output if needed) : r...@mini ~ # modprobe wl Lsmod shown the drivers is not in use : r...@mini ~ # lsmod Module Size Used by wl 1262065 0 ipv6 225039 18 wmi 4083 0 i2c_i8017106 0 sky2 39059 0 evdev 6653 14 Not much in dmesg either : r...@mini ~ # dmesg | tail -5 [ 94.693445] sky2 eth0: Link is up at 100 Mbps, full duplex, flow control rx [ 94.693849] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 105.540193] eth0: no IPv6 routers present [ 447.078683] wl: module license 'unspecified' taints kernel. [ 447.078691] Disabling lock debugging due to kernel taint As you can see, it does not : r...@mini ~ # ifconfig -a eth0 Link encap:Ethernet HWaddr 00:24:81:5d:10:65 inet addr:142.133.110.63 Bcast:142.133.111.255 Mask:255.255.254.0 inet6 addr: fe80::224:81ff:fe5d:1065/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1670 errors:0 dropped:0 overruns:0 frame:0 TX packets:263 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:222383 (217.1 KiB) TX bytes:37989 (37.0 KiB) Interrupt:17 loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:511 errors:0 dropped:0 overruns:0 frame:0 TX packets:511 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:96730 (94.4 KiB) TX bytes:96730 (94.4 KiB) Conclusion : The Broadcom proprietary driver (wl) FAILS to detect the card. Feel free to point me any errors I could have made... I could try with the 2.6.32-rc* patch if you'd like but the compilation went fine (no error no warning). - 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
On 11/24/2009 11:54 AM, William Bourque wrote: Chris Vine wrote: On Tue, 24 Nov 2009 10:50:13 -0500 William Bourque william.bour...@polymtl.ca wrote: [snip] I was using the B43 (GPL) driver but with the proprietary firmware extracted from Broadcom crap with bfwcutter. The proprietary driver provided by Broadcom (what you refer as wl?) fails to even detect the card. They clearly hate their customers. I should be very surprised if it doesn't detect your card provided you are using the right driver (and if you haven't compiled and installed a driver called wl.ko then so far as the proprietary driver is concerned you aren't). If you want to take this further, you probably want to go to http://www.broadcom.com/support/802.11/linux_sta.php , install the 32-bit or 64-bit driver according to your system, get the wl.ko driver working and then try warm booting from that and seeing if the b43 driver then works for you - it should. (You will need to copy wl.ko somewhere into your working module directory by hand - it doesn't really matter where - and after doing so run depmod -ae.) Note that this won't compile on 2.6.32-rc* without patching one of the files in the broadcom package, so it would probably be best to install it in a 2.6 31 (or earlier) kernel and warm boot from that. So, I compiled the Broadcom proprietary driver (wl) against an old 2.6.32-rc5 that I still had. The compilation went fine so I guess I don't need the patch after all : r...@mini hybrid-broadcom # make KBUILD_NOPEDANTIC=1 make -C /lib/modules/`uname -r`/build M=`pwd` make[1]: Entering directory `/usr/src/linux-2.6.32-rc5-homemade' Building modules, stage 2. MODPOST 1 modules WARNING: modpost: missing MODULE_LICENSE() in /usr/local/hybrid-broadcom/wl.o see include/linux/module.h for more information make[1]: Leaving directory `/usr/src/linux-2.6.32-rc5-homemade' ..the module is copied at the right place and depmoded : r...@mini hybrid-broadcom # cp wl.ko /lib/modules/2.6.32-rc5-homemade/kernel/drivers/net/wireless/ r...@mini hybrid-broadcom # depmod -ae WARNING: -e needs -E or -F r...@mini hybrid-broadcom # **The system is rebooted here** r...@mini ~ # uname -a Linux mini 2.6.32-rc5-homemade #1 SMP PREEMPT Fri Nov 13 04:15:41 EST 2009 i686 GNU/Linux All others b43 drivers are blacklisted and does not load at boot : r...@mini ~ # lsmod Module Size Used by ipv6 225039 18 wmi 4083 0 i2c_i8017106 0 sky2 39059 0 evdev 6653 14 (Yes, very few modules, I like my kernel free of useless stuff). Now we load wl (depmod and everything was done, the build went correctly, I will probably output if needed) : r...@mini ~ # modprobe wl Lsmod shown the drivers is not in use : r...@mini ~ # lsmod Module Size Used by wl 1262065 0 ipv6 225039 18 wmi 4083 0 i2c_i8017106 0 sky2 39059 0 evdev 6653 14 Not much in dmesg either : r...@mini ~ # dmesg | tail -5 [ 94.693445] sky2 eth0: Link is up at 100 Mbps, full duplex, flow control rx [ 94.693849] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 105.540193] eth0: no IPv6 routers present [ 447.078683] wl: module license 'unspecified' taints kernel. [ 447.078691] Disabling lock debugging due to kernel taint As you can see, it does not : r...@mini ~ # ifconfig -a eth0 Link encap:Ethernet HWaddr 00:24:81:5d:10:65 inet addr:142.133.110.63 Bcast:142.133.111.255 Mask:255.255.254.0 inet6 addr: fe80::224:81ff:fe5d:1065/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1670 errors:0 dropped:0 overruns:0 frame:0 TX packets:263 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:222383 (217.1 KiB) TX bytes:37989 (37.0 KiB) Interrupt:17 loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:511 errors:0 dropped:0 overruns:0 frame:0 TX packets:511 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:96730 (94.4 KiB) TX bytes:96730 (94.4 KiB) Conclusion : The Broadcom proprietary driver (wl) FAILS to detect the card. Feel free to point me any errors I could have made... I could try with the 2.6.32-rc* patch if you'd like but the compilation went fine (no error no warning). The wl driver needs lib80211 as a module. Check your .config for CONFIG_LIB80211. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de
Re: Fatal DMA error problem with netbook and BCM4312
Larry Finger wrote: On 11/24/2009 11:54 AM, William Bourque wrote: Chris Vine wrote: On Tue, 24 Nov 2009 10:50:13 -0500 William Bourque william.bour...@polymtl.ca wrote: [snip] I was using the B43 (GPL) driver but with the proprietary firmware extracted from Broadcom crap with bfwcutter. The proprietary driver provided by Broadcom (what you refer as wl?) fails to even detect the card. They clearly hate their customers. I should be very surprised if it doesn't detect your card provided you are using the right driver (and if you haven't compiled and installed a driver called wl.ko then so far as the proprietary driver is concerned you aren't). If you want to take this further, you probably want to go to http://www.broadcom.com/support/802.11/linux_sta.php , install the 32-bit or 64-bit driver according to your system, get the wl.ko driver working and then try warm booting from that and seeing if the b43 driver then works for you - it should. (You will need to copy wl.ko somewhere into your working module directory by hand - it doesn't really matter where - and after doing so run depmod -ae.) Note that this won't compile on 2.6.32-rc* without patching one of the files in the broadcom package, so it would probably be best to install it in a 2.6 31 (or earlier) kernel and warm boot from that. So, I compiled the Broadcom proprietary driver (wl) against an old 2.6.32-rc5 that I still had. The compilation went fine so I guess I don't need the patch after all : r...@mini hybrid-broadcom # make KBUILD_NOPEDANTIC=1 make -C /lib/modules/`uname -r`/build M=`pwd` make[1]: Entering directory `/usr/src/linux-2.6.32-rc5-homemade' Building modules, stage 2. MODPOST 1 modules WARNING: modpost: missing MODULE_LICENSE() in /usr/local/hybrid-broadcom/wl.o see include/linux/module.h for more information make[1]: Leaving directory `/usr/src/linux-2.6.32-rc5-homemade' ..the module is copied at the right place and depmoded : r...@mini hybrid-broadcom # cp wl.ko /lib/modules/2.6.32-rc5-homemade/kernel/drivers/net/wireless/ r...@mini hybrid-broadcom # depmod -ae WARNING: -e needs -E or -F r...@mini hybrid-broadcom # **The system is rebooted here** r...@mini ~ # uname -a Linux mini 2.6.32-rc5-homemade #1 SMP PREEMPT Fri Nov 13 04:15:41 EST 2009 i686 GNU/Linux All others b43 drivers are blacklisted and does not load at boot : r...@mini ~ # lsmod Module Size Used by ipv6 225039 18 wmi 4083 0 i2c_i8017106 0 sky2 39059 0 evdev 6653 14 (Yes, very few modules, I like my kernel free of useless stuff). Now we load wl (depmod and everything was done, the build went correctly, I will probably output if needed) : r...@mini ~ # modprobe wl Lsmod shown the drivers is not in use : r...@mini ~ # lsmod Module Size Used by wl 1262065 0 ipv6 225039 18 wmi 4083 0 i2c_i8017106 0 sky2 39059 0 evdev 6653 14 Not much in dmesg either : r...@mini ~ # dmesg | tail -5 [ 94.693445] sky2 eth0: Link is up at 100 Mbps, full duplex, flow control rx [ 94.693849] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 105.540193] eth0: no IPv6 routers present [ 447.078683] wl: module license 'unspecified' taints kernel. [ 447.078691] Disabling lock debugging due to kernel taint As you can see, it does not : r...@mini ~ # ifconfig -a eth0 Link encap:Ethernet HWaddr 00:24:81:5d:10:65 inet addr:142.133.110.63 Bcast:142.133.111.255 Mask:255.255.254.0 inet6 addr: fe80::224:81ff:fe5d:1065/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1670 errors:0 dropped:0 overruns:0 frame:0 TX packets:263 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:222383 (217.1 KiB) TX bytes:37989 (37.0 KiB) Interrupt:17 loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:511 errors:0 dropped:0 overruns:0 frame:0 TX packets:511 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:96730 (94.4 KiB) TX bytes:96730 (94.4 KiB) Conclusion : The Broadcom proprietary driver (wl) FAILS to detect the card. Feel free to point me any errors I could have made... I could try with the 2.6.32-rc* patch if you'd like but the compilation went fine (no error no warning). The wl driver needs lib80211 as a module. Check your .config for CONFIG_LIB80211. Larry lib80211 was _included_ in the kernel already but I recompiled to make it a module, just to make sure it was not the
Re: Fatal DMA error problem with netbook and BCM4312
Nothing changed... Again, the Broadcom driver is helpless. Also note all of this was made after a _warm_ boot. Do you want me to try everything from a cold boot? Just an update, cold booting didn't help. - 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
Well well... While looking to activate SSB_DEBUG, I found out that SSB was _included_ in my old 2.6.32-rc5 kernel. I recompiled with SSB as module and the Broadcom wl driver seems to claim the card correctly... look like ssb was claiming the PCI device from it. I don't remember I played in the SSB config so I suspect another included config make the SSB to be included (instead of modularized) as well. Still, I feel very dumb about that, I should have checked. Sorry for the time lost. - 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
On 11/24/2009 01:35 PM, William Bourque wrote: Well well... While looking to activate SSB_DEBUG, I found out that SSB was _included_ in my old 2.6.32-rc5 kernel. I recompiled with SSB as module and the Broadcom wl driver seems to claim the card correctly... look like ssb was claiming the PCI device from it. I don't remember I played in the SSB config so I suspect another included config make the SSB to be included (instead of modularized) as well. Still, I feel very dumb about that, I should have checked. Sorry for the time lost. One of the disadvantages of building everything into the kernel. You can never unload it! ___ 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
On Tue, 24 Nov 2009 11:43:32 -0600 Larry Finger larry.fin...@lwfinger.net wrote: On 11/24/2009 10:58 AM, William Bourque wrote: I did tried before, it succesfully built, it was loading (modprobe) correctly but no new interface was registered by it. However, I might have done something wrong, I will try it again to make sure it wasn't a PEBKAC problem. Are you certain that neither b43 nor ssb were loaded at the time? If ssb is in memory, it will own the PCI device. Right. Do you have a link to this patch? I would rather avoid downgrading my kernel. I just downloaded a fresh copy of the wl driver. It compiled cleanly. The only patch I applied is the following: Index: hybrid-wl/Makefile === --- hybrid-wl.orig/Makefile +++ hybrid-wl/Makefile @@ -34,3 +34,5 @@ clean: install: install -D -m 755 wl.ko /lib/modules/`uname -r`/kernel/drivers/net/wireless/wl.ko + depmod -a + With it, the dependencies are properly setup. Note, the install line above is improperly wrapped, but you get the idea. For the record, and in case someone else needs it, I had to apply this one: one glue file didn't include sched.h as it should have done (presumably one of the other included headers happened to include it in kernel = 2.6.31 but not after). I don't know why it isn't necessary in your cases. Chris --- src/wl/sys/wl_linux.c.orig 2009-11-21 10:07:59.0 + +++ src/wl/sys/wl_linux.c 2009-11-21 10:08:32.0 + @@ -38,6 +38,7 @@ #include linux/ethtool.h #include linux/completion.h #include linux/pci_ids.h +#include linux/sched.h #define WLC_MAXBSSCFG 1 #if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 29) ___ 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
On 24/11/09 20:25, Chris Vine wrote: For the record, and in case someone else needs it, I had to apply this one: one glue file didn't include sched.h as it should have done (presumably one of the other included headers happened to include it in kernel= 2.6.31 but not after). I don't know why it isn't necessary in your cases. Chris --- src/wl/sys/wl_linux.c.orig2009-11-21 10:07:59.0 + +++ src/wl/sys/wl_linux.c 2009-11-21 10:08:32.0 + @@ -38,6 +38,7 @@ #includelinux/ethtool.h #includelinux/completion.h #includelinux/pci_ids.h +#includelinux/sched.h #define WLC_MAXBSSCFG 1 #if LINUX_VERSION_CODE= KERNEL_VERSION(2, 6, 29) The Broadcom driver compiles fine for me if I run this sed before I run make:- sed -i '/types.h/a#include linux/sched.h' src/wl/sys/wl_linux.c It achieves the same result as your patch. 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
On 24/11/09 18:05, Larry Finger wrote: The wl driver needs lib80211 as a module. Check your .config for CONFIG_LIB80211. Larry The wl driver works well for me with a monolithic kernel. The only module I have is wl andy:~$ lsmod Module Size Used by wl 1262348 0 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
On Sun, 2009-11-22 at 19:52 -0600, Larry Finger wrote: We know that the wl driver does something to the interface that persists across a warm boot - we just do not know what. It does not appear to be done in any of the MMIO traffic - at least I have not seen it in the mmio-trace output. If anyone has a KVM setup using PCI passthrough, it is possible to trace PCI configuration traffic? I'm pretty sure even the binary driver has to go through drivers/pci/access.c, maybe you can just insert logging into that code? johannes signature.asc 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: Fatal DMA error problem with netbook and BCM4312
Larry Finger wrote: One last check. I would appreciate receiving answers to the following questions. These questions apply to anyone else with this problem. Does the pm_qos patch help your fatal DMA error problem, particularly when booted from power-off? If you warm-boot after loading the wl driver, does the patch make any difference? Larry Hi I run a test case scenario on my notebook to figure out the QOS patch effect on the card reliability. I would say that the results are not very conclusive, but it seems the patch helped slightly, but not very time. To explain the methodology, I ran 4 series of test (Cold boot and warm boot, on battery and pluged in) between a patched and unpatched wireless-testing kernel. The time in the sheet is the time between the first line of the load of the firmware (b43 ssb0:0: firmware: requesting b43/ucode15.fw) to the first DMA error (b43-phy0 ERROR: Fatal DMA error: ) Three time, the card crashed but not DMA error were printed in the log. In that case, the line about the interface failing (b43-phy0 debug: Wireless interface stopped) were used instead. The time is taken accordingly to kernel timestamp printed by dmesg. Note that this test was design to make the card fails quickly. As soon as the card was up, the full kernel tree was transfert over a wireless LAN, as it has been observed before that fast rate transfert were good at crashing DMA. (I tried ping -f 172.16.0.1 before but the card was still alive after 5 minutes). Technically the following command was run : ifup wlan0 scp -r /usr/src/linux 172.16.0.1:~/ The result seems to show that the patch has no effect on warm-booted system but it seems to make the card slightly more reliable on cold-booted system, with an average time before crashing of 24.07 (patched cold boot) vs 22.98 (unpatched coldboot). - William Command issued : ifup wlan0 scp -r /usr/src/linux 172.16.0.1:~/ Count start line : b43 ssb0:0: firmware: requesting b43/ucode15.fw Count end line : b43-phy0 ERROR: Fatal DMA error: Alternate end line: b43-phy0 debug: Wireless interface stopped QOS PATH Warm boot on Battery: 1-14.030134 2-14.050803 3-14.012732 Cold boot on Battery : 1-16.981828 2-*29.269881 3-*25.666901 Warm boot Plugged in : 1-13.992476 2-14.000156 3-14.047689 4-14.010163 Cold boot Plugged in : 1-16.454922 2-16.005255 3-30.873647 4-33.235585 ** NO QOS PATCH: Warm boot on Battery: 1-14.010197 2-14.043525 3-14.040962 Cold boot on Battery : 1-22.858424 2-24.253975 3-15.584923 Warm boot Plugged in : 1-13.994969 2-14.022592 3-14.000205 Cold boot Plugged in : 1-19.990719 2-*24.234147 3-29.321423 4-24.582662 ___ 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
On Sat, 21 Nov 2009 00:15:12 + Chris Vine ch...@cvine.freeserve.co.uk wrote: WARM BOOT FROM KERNEL WITH WL MODULE INSTALLED The patched kernel makes no change on a warm boot in the sense that if I warm boot after initialising the wireless device with the wl module then the b43 module appears to work correctly, both with and without the patch applied. On the same stress test as mentioned above, I have not been able to induce the DMA errors nor kernel warnings. It resolutely refuses to do anything except work correctly. This is just to say that I have carried out further stress tests today after warm booting to an unpatched linux-2.6.32-rc8 kernel with the b43 driver (on the assumption that unpatched is the least favourable case for the driver). This is a warm reboot from a 2.6.31.6 kernel which had the wl driver installed. I have created an extended period of high speed traffic on my wireless lan and I cannot induce any errors at all with the b43 driver on a warm reboot. This makes me wonder whether the patch is just (partially) masking the problem rather than actually dealing with it. Chris PS The wl driver was compiled from hybrid-portsrc-x86_32-v5.10.91.9.3.tar.gz available at http://www.broadcom.com/support/802.11/linux_sta.php . (Note for anyone want to try this with a warm boot from 2.6.32, that this driver will not compile with 2.6.32 without patching the headers of one of the blob glue files as one of them fails to include linux/sched.h.) ___ 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
On 11/22/2009 01:03 PM, Chris Vine wrote: On Sat, 21 Nov 2009 00:15:12 + Chris Vine ch...@cvine.freeserve.co.uk wrote: WARM BOOT FROM KERNEL WITH WL MODULE INSTALLED The patched kernel makes no change on a warm boot in the sense that if I warm boot after initialising the wireless device with the wl module then the b43 module appears to work correctly, both with and without the patch applied. On the same stress test as mentioned above, I have not been able to induce the DMA errors nor kernel warnings. It resolutely refuses to do anything except work correctly. This is just to say that I have carried out further stress tests today after warm booting to an unpatched linux-2.6.32-rc8 kernel with the b43 driver (on the assumption that unpatched is the least favourable case for the driver). This is a warm reboot from a 2.6.31.6 kernel which had the wl driver installed. I have created an extended period of high speed traffic on my wireless lan and I cannot induce any errors at all with the b43 driver on a warm reboot. This makes me wonder whether the patch is just (partially) masking the problem rather than actually dealing with it. We know that the wl driver does something to the interface that persists across a warm boot - we just do not know what. It does not appear to be done in any of the MMIO traffic - at least I have not seen it in the mmio-trace output. If anyone has a KVM setup using PCI passthrough, it is possible to trace PCI configuration traffic? Have you tried running your system with the patch entitled [PATCH] b43: Rewrite DMA Tx status handling sanity checks? It cleared up some of the problems that I was seeing with the open-source firmware. Larry ___ 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
One last check. I would appreciate receiving answers to the following questions. These questions apply to anyone else with this problem. Does the pm_qos patch help your fatal DMA error problem, particularly when booted from power-off? If you warm-boot after loading the wl driver, does the patch make any difference? 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
Larry Finger wrote: One last check. I would appreciate receiving answers to the following questions. These questions apply to anyone else with this problem. Does the pm_qos patch help your fatal DMA error problem, particularly when booted from power-off? If you warm-boot after loading the wl driver, does the patch make any difference? I would say yes right now to both, but I'm afraid it could be coincidence. I don't want to send you on a wrong path, I will perform and document several tests on each case today and I will get back to you with a definitive answer supported by documented test case. - 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
On Fri, 20 Nov 2009 06:43:05 -0600 Larry Finger larry.fin...@lwfinger.net wrote: One last check. I would appreciate receiving answers to the following questions. These questions apply to anyone else with this problem. Does the pm_qos patch help your fatal DMA error problem, particularly when booted from power-off? If you warm-boot after loading the wl driver, does the patch make any difference? What's the date/time of the last patch you posted for this and what kernel does it apply to? Chris ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
