Re: [PATCH RFC] ssb: Generic SPROM override for devices without SPROM
At least on my Acer One D250 dmidecode provides a mainboard UUID. Sebastian Stupid me, I had a closer look at the UUID and they are using one scheme supported by uuidgen where the last 6 bytes are the MAC address *of eth0* ___ 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: [PATCH RFC] ssb: Generic SPROM override for devices without SPROM
On Tuesday 24 November 2009 09:51:37 Oncaphillis wrote: On 11/20/2009 12:12 PM, Michael Buesch wrote: This patch adds a generic mechanism for overriding the SPROM mechanism on devices without SPROM hardware. There currently is a major problem with this: It tries to deduce a MAC address from various hardware parameters. But currently it will result in the same MAC address for machines of the same type. Does somebody have an idea of some device-instance specific serial number or something similar that could be hashed into the MAC? What version is this patch against ? I tries rc7,rc8 and 2.6.31.6. But it doesn't work for me. wireless testing -- 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
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
DMA errors with BCM4312 - an update
This E-mail is to summarize what I have learned to date. The pm_qos change does nothing useful. It may have helped a little, but the side effects are far worse than the benefits. Most systems work better with b43 when warm booted after Broadcom's wl driver was loaded. The conclusion is that wl is making some change in the setup that b43 is not. (3) Based on the above, I have done MMIO and PCI-E configuration tracing for the two drivers and found some real differences. After seeing these, I did more RE work, and found some setup for the PCI-E core that was missed earlier. I am still working on the changes. What I have completed is found at http://bcm-v4.sipsolutions.net/PCI-E#PCI-E_Setup I doubt that most of these new routines will affect the problem interfaces as they apply only to PCI-E core revisions 7 and 8. My BCM4312 has rev 9. I do not know what versions are giving the trouble. With SSB_DEBUG enabled, it will be in a log line as follows: ssb: Core 3 found: PCI-E (cc 0x820, rev 0x09, vendor 0x4243) If you are seeing the DMA error, please supply the above info. The PCI-E Miscellaneous Configuration routine that is not yet finished does run on my system and is the source of the tracing differences. If the problem cards has a revision newer than 9, I will probably need an MMIO trace for your device. 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
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: DMA errors with BCM4312 - an update
On Tue, 24 Nov 2009 13:06:43 -0600 Larry Finger larry.fin...@lwfinger.net wrote: This E-mail is to summarize what I have learned to date. The pm_qos change does nothing useful. It may have helped a little, but the side effects are far worse than the benefits. Most systems work better with b43 when warm booted after Broadcom's wl driver was loaded. The conclusion is that wl is making some change in the setup that b43 is not. (3) Based on the above, I have done MMIO and PCI-E configuration tracing for the two drivers and found some real differences. After seeing these, I did more RE work, and found some setup for the PCI-E core that was missed earlier. I am still working on the changes. What I have completed is found at http://bcm-v4.sipsolutions.net/PCI-E#PCI-E_Setup I doubt that most of these new routines will affect the problem interfaces as they apply only to PCI-E core revisions 7 and 8. My BCM4312 has rev 9. I do not know what versions are giving the trouble. With SSB_DEBUG enabled, it will be in a log line as follows: ssb: Core 3 found: PCI-E (cc 0x820, rev 0x09, vendor 0x4243) If you are seeing the DMA error, please supply the above info. The PCI-E Miscellaneous Configuration routine that is not yet finished does run on my system and is the source of the tracing differences. If the problem cards has a revision newer than 9, I will probably need an MMIO trace for your device. This is mine, the same revision as yours, but which demonstrates the DMA errors: ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x16, vendor 0x4243) ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x0F, vendor 0x4243) ssb: Core 2 found: PCMCIA (cc 0x80D, rev 0x0A, vendor 0x4243) ssb: Core 3 found: PCI-E (cc 0x820, rev 0x09, vendor 0x4243) ssb: Found rev 1 PMU (capabilities 0x02A62F01) ssb: SPROM revision 8 detected. ssb: Sonics Silicon Backplane found on PCI device :03:00.0 Chris ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: DMA errors with BCM4312 - an update
On Tuesday 24 November 2009 22:15:52 Chris Vine wrote: On Tue, 24 Nov 2009 13:06:43 -0600 Larry Finger larry.fin...@lwfinger.net wrote: This E-mail is to summarize what I have learned to date. The pm_qos change does nothing useful. It may have helped a little, but the side effects are far worse than the benefits. Most systems work better with b43 when warm booted after Broadcom's wl driver was loaded. The conclusion is that wl is making some change in the setup that b43 is not. (3) Based on the above, I have done MMIO and PCI-E configuration tracing for the two drivers and found some real differences. After seeing these, I did more RE work, and found some setup for the PCI-E core that was missed earlier. I am still working on the changes. What I have completed is found at http://bcm-v4.sipsolutions.net/PCI-E#PCI-E_Setup I doubt that most of these new routines will affect the problem interfaces as they apply only to PCI-E core revisions 7 and 8. My BCM4312 has rev 9. I do not know what versions are giving the trouble. With SSB_DEBUG enabled, it will be in a log line as follows: ssb: Core 3 found: PCI-E (cc 0x820, rev 0x09, vendor 0x4243) If you are seeing the DMA error, please supply the above info. The PCI-E Miscellaneous Configuration routine that is not yet finished does run on my system and is the source of the tracing differences. If the problem cards has a revision newer than 9, I will probably need an MMIO trace for your device. This is mine, the same revision as yours, but which demonstrates the DMA errors: ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x16, vendor 0x4243) ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x0F, vendor 0x4243) ssb: Core 2 found: PCMCIA (cc 0x80D, rev 0x0A, vendor 0x4243) ssb: Core 3 found: PCI-E (cc 0x820, rev 0x09, vendor 0x4243) ssb: Found rev 1 PMU (capabilities 0x02A62F01) Larry, do you also have the same PMU? -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: DMA errors with BCM4312 - an update
Larry Finger wrote: This E-mail is to summarize what I have learned to date. The pm_qos change does nothing useful. It may have helped a little, but the side effects are far worse than the benefits. Most systems work better with b43 when warm booted after Broadcom's wl driver was loaded. The conclusion is that wl is making some change in the setup that b43 is not. (3) Based on the above, I have done MMIO and PCI-E configuration tracing for the two drivers and found some real differences. After seeing these, I did more RE work, and found some setup for the PCI-E core that was missed earlier. I am still working on the changes. What I have completed is found at http://bcm-v4.sipsolutions.net/PCI-E#PCI-E_Setup I doubt that most of these new routines will affect the problem interfaces as they apply only to PCI-E core revisions 7 and 8. My BCM4312 has rev 9. I do not know what versions are giving the trouble. With SSB_DEBUG enabled, it will be in a log line as follows: ssb: Core 3 found: PCI-E (cc 0x820, rev 0x09, vendor 0x4243) If you are seeing the DMA error, please supply the above info. The PCI-E Miscellaneous Configuration routine that is not yet finished does run on my system and is the source of the tracing differences. If the problem cards has a revision newer than 9, I will probably need an MMIO trace for your device. Larry Here is mine. r...@mini ~ # dmesg | grep ssb [ 138.450389] ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x16, vendor 0x4243) [ 138.450420] ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x0F, vendor 0x4243) [ 138.450447] ssb: Core 2 found: PCMCIA (cc 0x80D, rev 0x0A, vendor 0x4243) [ 138.450473] ssb: Core 3 found: PCI-E (cc 0x820, rev 0x09, vendor 0x4243) [ 138.490310] ssb: Found rev 1 PMU (capabilities 0x02A62F01) [ 138.499585] ssb: SPROM revision 8 detected. [ 138.533626] ssb: Sonics Silicon Backplane found on PCI device :01:00.0 Just a note, I am testing it right now and you were right, the card does work if warm booted after having used wl driver. Seems like some initialization stuff is done differently, as the led turn active (blue ) even before loading any driver for the card. - 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 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: DMA errors with BCM4312 - an update
On 24/11/09 19:06, Larry Finger wrote: know what versions are giving the trouble. With SSB_DEBUG enabled, it will be in a log line as follows: ssb: Core 3 found: PCI-E (cc 0x820, rev 0x09, vendor 0x4243) If you are seeing the DMA error, please supply the above info. I have been seeing the DMA errors (if I enable the ACPI processor module) andy:~$ dmesg | grep ssb ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x16, vendor 0x4243) ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x0F, vendor 0x4243) ssb: Core 2 found: PCMCIA (cc 0x80D, rev 0x0A, vendor 0x4243) ssb: Core 3 found: PCI-E (cc 0x820, rev 0x09, vendor 0x4243) ssb: Found rev 1 PMU (capabilities 0x02A62F01) ssb: SPROM revision 8 detected. ssb: Sonics Silicon Backplane found on PCI device :03:00.0 b43 ssb0:0: firmware: requesting b43/ucode15.fw b43 ssb0:0: firmware: requesting b43/lp0initvals15.fw b43 ssb0:0: firmware: requesting b43/lp0bsinitvals15.fw andy:~$ ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: DMA errors with BCM4312 - an update
On 11/24/2009 03:20 PM, Michael Buesch wrote: On Tuesday 24 November 2009 22:15:52 Chris Vine wrote: On Tue, 24 Nov 2009 13:06:43 -0600 Larry Finger larry.fin...@lwfinger.net wrote: This E-mail is to summarize what I have learned to date. The pm_qos change does nothing useful. It may have helped a little, but the side effects are far worse than the benefits. Most systems work better with b43 when warm booted after Broadcom's wl driver was loaded. The conclusion is that wl is making some change in the setup that b43 is not. (3) Based on the above, I have done MMIO and PCI-E configuration tracing for the two drivers and found some real differences. After seeing these, I did more RE work, and found some setup for the PCI-E core that was missed earlier. I am still working on the changes. What I have completed is found at http://bcm-v4.sipsolutions.net/PCI-E#PCI-E_Setup I doubt that most of these new routines will affect the problem interfaces as they apply only to PCI-E core revisions 7 and 8. My BCM4312 has rev 9. I do not know what versions are giving the trouble. With SSB_DEBUG enabled, it will be in a log line as follows: ssb: Core 3 found: PCI-E (cc 0x820, rev 0x09, vendor 0x4243) If you are seeing the DMA error, please supply the above info. The PCI-E Miscellaneous Configuration routine that is not yet finished does run on my system and is the source of the tracing differences. If the problem cards has a revision newer than 9, I will probably need an MMIO trace for your device. This is mine, the same revision as yours, but which demonstrates the DMA errors: ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x16, vendor 0x4243) ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x0F, vendor 0x4243) ssb: Core 2 found: PCMCIA (cc 0x80D, rev 0x0A, vendor 0x4243) ssb: Core 3 found: PCI-E (cc 0x820, rev 0x09, vendor 0x4243) ssb: Found rev 1 PMU (capabilities 0x02A62F01) Larry, do you also have the same PMU? ssb: Found rev 1 PMU (capabilities 0x02A62F01) Yes - seems to be identical. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
