Re: b43 fatal DMA errors
On Sun, 15 Nov 2009 15:42:25 -0800 (PST) Linus Torvalds torva...@linux-foundation.org wrote: On Sun, 25 Oct 2009, Chris Vine wrote: And Chris, just out of interest - does FORCE_PIO work for you too? Yes. So I've been trying to debug this, but no real luck. The Broadcom official driver seems to _load_ for me, but I can't seem to get it to work or do anythign interesting. I didn't spend any real time on it, though. You need to blacklist (and unload) the ssb module as well as the b43 module to use the proprietary driver. This tripped me up to begin with. You also need to amend Kconfig in net/wireless by hand in order to compile the lib80211 WEP/TKIP/CCMP encryption modules (make config/menuconfig/xconfig will not offer this as an option). But PIO mode continues to work fine. So how about this kind of fallback patch that just says if we see fatal DMA errors that we don't understand, fall back to PIO. Makes sense to me, and makes the driver work for me without any special hacks. On using PIO, I have found that it works with WEP encryption but runs into difficulties with WPA. Chris PS I am not a b43 developer. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 fatal DMA errors
2009/10/28 Linus Torvalds torva...@linux-foundation.org: On Sun, 25 Oct 2009, Gábor Stefanik wrote: Also, is there any reference to a failed channel switch in the log? I've been debugging this some more, and it looks like there are more issues at play than just the DMA problem. With the b43 driver enabled, I seem to be unable to reliably suspend and resume. Sometimes the machine just locks up hard, but sometimes I get something like this on the resume path: b43-phy0 debug: Resuming... b43-phy0 debug: Device resumed. ... b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23) b43-phy0 debug: b2062: Using crystal tab entry 19200 kHz. b43-phy0 debug: RC calib: Failed to switch to channel 7, error = -5 b43-phy0 debug: Chip initialized b43-phy0 debug: PIO initialized b43-phy0 debug: QoS disabled b43-phy0 debug: Wireless interface started b43-phy0 debug: Adding Interface type 2 and when that happens, it appears that then the _next_ suspend/resume cycle will fail with a hard lockup. And sometimes the hard lockup happens on the very first resume. But maybe that Failed to switch to channel 7 error is entirely unrelated to the Locks up hard on resume problem. But the lock-up seems to be tied to the b43 driver too - the machine seems stable if I don't load that module at all. What seems a bit odd is how the b43_lpphy_op_init() seems to try to switch to channel 7 _twice_. It does: ... lpphy_radio_init(dev); lpphy_calibrate_rc(dev); err = b43_lpphy_op_switch_channel(dev, 7); ... and that lpphy_calibrate_rc() call will already have done the channel switch for the lpphy_rev0_1_rc_calib() case. Maybe it should just switch to channel 7 unconditionally before doing the lpphy_calibrate_rc()? What we do is exactly what the spec calls for - specifically, rev.2+ cards don't switch to channel 7 during RC calibration, while rev.0/1 SoCs can have an NVRAM variable specifying a predetermined RC-Cap value, in which case the actual RC calibration doesn't even run (though the latter is not yet implemented). However, just switching to channel 7 at the beginning looks saner - Larry, what do you think about it? I dunno. I don't know the code, I don't know the hardware, the above is just a random musing based on looking at the code around that warning case. Linus -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 fatal DMA errors
On Sun, Oct 25, 2009 at 7:17 PM, Linus Torvalds torva...@linux-foundation.org wrote: Ok, so I got myself (or rather, Patricia) a new Dell 11 inspiron laptop, and everything seems to work, except for the wireless. It's a Broadcom BCM4312b/g LP-PHY. In fact, even the wireless works at least to _some_ degree, because I saw the wireless networks listed once (but I can't seem to recreate that now), but: - I get a _lot_ of noise in dmesg: b43-phy0 ERROR: Fatal DMA error: 0x0400, 0x, 0x, 0x, 0x, 0x b43-phy0: Controller RESET (DMA error) ... b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23) b43-phy0: Controller restarted - the 'phy0' kernel thread seems to spend all its time presumably doing that firmware reloading (looks like 20% CPU time in top) - the wireless doesn't seem to actually ever succeed in connecting even the one time it saw something, and 'rmmod b43' just hangs. The network I'm trying to connect to is just a random 128-bit WEP thing. But while I once got far enough to see it (I think that was with the 4.150.10.5 firmware - I started out using the wrong one by mistake), now I can't even see the networks, so I doubt that matters. Maybe it's all as simple as me just having the wrong firmware version or something. But it's the version documented at http://linuxwireless.org/en/users/Drivers/b43 for the LP-PHY case. This is with current -git (v2.6.32-rc5-81-g964fe08), and lspci reports 08:00.0 0280: 14e4:4315 (rev 01) Subsystem: 1028:000c Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 17 Region 0: Memory at f060 (64-bit, non-prefetchable) [size=16K] Capabilities: access denied Kernel driver in use: b43-pci-bridge Kernel modules: ssb 00: e4 14 15 43 06 00 10 00 01 00 80 02 10 00 00 00 10: 04 00 60 f0 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 28 10 0c 00 30: 00 00 00 00 40 00 00 00 00 00 00 00 0a 01 00 00 with dmesg saying b43-pci-bridge :08:00.0: PCI INT A - GSI 17 (level, low) - IRQ 17 b43-pci-bridge :08:00.0: setting latency timer to 64 ... cfg80211: Calling CRDA to update world regulatory domain ... cfg80211: World regulatory domain updated: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) (2402000 KHz - 2472000 KHz @ 4 KHz), (300 mBi, 2000 mBm) (2457000 KHz - 2482000 KHz @ 2 KHz), (300 mBi, 2000 mBm) (2474000 KHz - 2494000 KHz @ 2 KHz), (300 mBi, 2000 mBm) (517 KHz - 525 KHz @ 4 KHz), (300 mBi, 2000 mBm) (5735000 KHz - 5835000 KHz @ 4 KHz), (300 mBi, 2000 mBm) b43-phy0: Broadcom 4312 WLAN found (core revision 15) ... phy0: Selected rate control algorithm 'minstrel' Registered led device: b43-phy0::tx Registered led device: b43-phy0::rx Registered led device: b43-phy0::radio Broadcom 43xx driver loaded [ Features: PML, Firmware-ID: FW13 ] ... cfg80211: Calling CRDA for country: US cfg80211: Regulatory domain changed to country: US (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) (2402000 KHz - 2472000 KHz @ 4 KHz), (300 mBi, 2700 mBm) (517 KHz - 525 KHz @ 4 KHz), (300 mBi, 1700 mBm) (525 KHz - 533 KHz @ 4 KHz), (300 mBi, 2000 mBm) (549 KHz - 571 KHz @ 4 KHz), (300 mBi, 2000 mBm) (5735000 KHz - 5835000 KHz @ 4 KHz), (300 mBi, 3000 mBm) ... b43 ssb0:0: firmware: requesting b43/ucode15.fw b43 ssb0:0: firmware: requesting b43/lp0initvals15.fw b43 ssb0:0: firmware: requesting b43/lp0bsinitvals15.fw b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23) ... b43-phy0 ERROR: Fatal DMA error: 0x0400, 0x, 0x, 0x, 0x, 0x b43-phy0: Controller RESET (DMA error) ... b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23) b43-phy0 ERROR: b43-phy0: Fatal DMA error: 0x0400, 0x, 0x, 0x, 0x, 0x b43-phy0: Controller RESET (DMA error) ... Controller restarted b43-phy0 ERROR: Fatal DMA error: 0x0400, 0x, 0x, 0x, 0x, 0x b43-phy0: Controller RESET
Re: b43 fatal DMA errors
2009/10/25 Linus Torvalds torva...@linux-foundation.org: On Sun, 25 Oct 2009, Gábor Stefanik wrote: Could you please test the tag master-2009-08-26 from wireless-testing? That one was the first version that worked, and in that specific build, my card (exactly the same as yours) worked perfectly, leading me to suspect a regression (probably not in the b43 driver, but in something else interfering with b43). Will try. Are you using that same firmware version? Yes, I have v478 also. However, I tried to build the latest wireless-testing tree, but I can't reproduce the error here. One thing I have noticed is that everyone so far with this error appears to have a HP or Dell laptop - I have tested with a custom-built desktop with an Asus motherboard. I will test my other 4312 in my Acer laptop later (I don't own a Dell or a HP). Could you describe the exact HW configuration of your system (including the BIOS type - my Acer has InsydeH2O, while my desktop is AMI-based)? Does the wl_hybrid driver work for you? (If it does work, please try building the latest compat-wireless for the kernel on which wl_hybrid worked, and post the results. Try the compat-wireless driver both on a cold boot and after wl_hybrid has been unloaded.) Also try apic=off acpi=off (IIRC another DMA error victim, but with error code 0x0800 had ACPI clobbering his DMA). Ok, will try that separately. Also, is there any reference to a failed channel switch in the log? Nope. Then it's a different bug than the 0x0800 one, which also caused channel switching to fail. Linus -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 fatal DMA errors
On Sun, 25 Oct 2009 19:30:56 +0100 Gábor Stefanik netrolller...@gmail.com wrote: Also try apic=off acpi=off (IIRC another DMA error victim, but with error code 0x0800 had ACPI clobbering his DMA). Specifically me, and I resolved it, until it is fixed, by blacklisting the 'processor' ACPI module. (However in my case I am using an Atom N270 processor and that may make a difference.) Chris ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 fatal DMA errors
On Sun, Oct 25, 2009 at 10:39 PM, Linus Torvalds torva...@linux-foundation.org wrote: On Sun, 25 Oct 2009, Linus Torvalds wrote: Ok, this machine is a 1.3GHz Core 2 Duo, so no Atom crap. Oh, and I compile for x86-64, in case anybody cares. But I assume all sane developers have long since abandoned 32-bit mode, so I can't imagine that there is some 32-vs-64-bit issue. Btw, here's the dmesg from a few seconds after loading that driver with CONFIG_B43_DEBUG enabled. Just for fun, I'll also try what FORCE_PIO results in.. Linus 0x0400 is DMA PCI Descriptor Error - not sure what it actually means. BTW your dmidecode reveals that this is a modified PhoenixBIOS (non-Award) - I wonder if others with this error are also PhoenixBios users... Another thing to test: boot into Windows (or any other OS where the card works), initialize the card, reboot (not cold-boot) into Linux, try to load b43. If this succeeds, then we are missing something in the init routine. --- b43-phy1: Broadcom 4312 WLAN found (core revision 15) b43-phy1 debug: Found PHY: Analog 6, Type 5, Revision 1 b43-phy1 debug: Found Radio: Manuf 0x17F, Version 0x2062, Revision 2 phy1: Selected rate control algorithm 'minstrel' Registered led device: b43-phy1::tx Registered led device: b43-phy1::rx Registered led device: b43-phy1::radio Broadcom 43xx driver loaded [ Features: PML, Firmware-ID: FW13 ] b43 ssb0:0: firmware: requesting b43/ucode15.fw b43 ssb0:0: firmware: requesting b43/lp0initvals15.fw b43 ssb0:0: firmware: requesting b43/lp0bsinitvals15.fw b43-phy1: Loading firmware version 478.104 (2008-07-01 00:50:23) b43-phy1 debug: b2062: Using crystal tab entry 19200 kHz. b43-phy1 debug: Chip initialized b43-phy1 debug: 64-bit DMA initialized b43-phy1 debug: QoS enabled b43-phy1 debug: Wireless interface started b43-phy1 ERROR: Fatal DMA error: 0x0400, 0x, 0x, 0x, 0x, 0x b43-phy1: Controller RESET (DMA error) ... b43-phy1 debug: Adding Interface type 2 b43-phy1 debug: Wireless interface stopped b43-phy1 debug: DMA-64 rx_ring: Used slots 0/64, Failed frames 0/0 = 0.0%, Average tries 0.00 b43-phy1 debug: DMA-64 tx_ring_AC_BK: Used slots 0/256, Failed frames 0/0 = 0.0%, Average tries 0.00 b43-phy1 debug: DMA-64 tx_ring_AC_BE: Used slots 0/256, Failed frames 0/0 = 0.0%, Average tries 0.00 b43-phy1 debug: DMA-64 tx_ring_AC_VI: Used slots 0/256, Failed frames 0/0 = 0.0%, Average tries 0.00 b43-phy1 debug: DMA-64 tx_ring_AC_VO: Used slots 0/256, Failed frames 0/0 = 0.0%, Average tries 0.00 b43-phy1 debug: DMA-64 tx_ring_mcast: Used slots 0/256, Failed frames 0/0 = 0.0%, Average tries 0.00 b43-phy1: Loading firmware version 478.104 (2008-07-01 00:50:23) b43-phy1 debug: b2062: Using crystal tab entry 19200 kHz. b43-phy1 debug: Chip initialized b43-phy1 debug: 64-bit DMA initialized b43-phy1 debug: QoS enabled b43-phy1 debug: Wireless interface started b43-phy1: Controller restarted b43-phy1 ERROR: Fatal DMA error: 0x0400, 0x, 0x, 0x, 0x, 0x b43-phy1: Controller RESET (DMA error) ... b43-phy1 ERROR: Fatal DMA error: 0x0400, 0x, 0x, 0x, 0x, 0x b43-phy1: Controller RESET (DMA error) ... b43-phy1 debug: Wireless interface stopped b43-phy1 debug: DMA-64 rx_ring: Used slots 0/64, Failed frames 0/0 = 0.0%, Average tries 0.00 b43-phy1 debug: DMA-64 tx_ring_AC_BK: Used slots 0/256, Failed frames 0/0 = 0.0%, Average tries 0.00 b43-phy1 debug: DMA-64 tx_ring_AC_BE: Used slots 0/256, Failed frames 0/0 = 0.0%, Average tries 0.00 b43-phy1 debug: DMA-64 tx_ring_AC_VI: Used slots 0/256, Failed frames 0/0 = 0.0%, Average tries 0.00 b43-phy1 debug: DMA-64 tx_ring_AC_VO: Used slots 0/256, Failed frames 0/0 = 0.0%, Average tries 0.00 b43-phy1 debug: DMA-64 tx_ring_mcast: Used slots 0/256, Failed frames 0/0 = 0.0%, Average tries 0.00 b43-phy1: Loading firmware version 478.104 (2008-07-01 00:50:23) b43-phy1 debug: b2062: Using crystal tab entry 19200 kHz. b43-phy1 debug: Chip initialized b43-phy1 debug: 64-bit DMA initialized b43-phy1 debug: QoS enabled b43-phy1 debug: Wireless interface started b43-phy1 ERROR: b43-phy1: Controller restarted Fatal DMA error: 0x0400, 0x, 0x, 0x, 0x, 0x b43-phy1: Controller RESET (DMA error) ... b43-phy1 debug: Wireless interface stopped b43-phy1 debug: DMA-64 rx_ring: Used slots 0/64, Failed frames 0/0 = 0.0%, Average tries 0.00 ADDRCONF(NETDEV_UP): wlan0: link is not ready b43-phy1 debug: DMA-64 tx_ring_AC_BK: Used slots 0/256, Failed frames 0/0 = 0.0%, Average tries 0.00 b43-phy1 debug: DMA-64 tx_ring_AC_BE: Used slots 0/256, Failed frames 0/0 = 0.0%, Average tries 0.00 b43-phy1 debug: DMA-64 tx_ring_AC_VI: Used slots 0/256, Failed frames 0/0 = 0.0%, Average tries 0.00 b43-phy1 debug: DMA-64 tx_ring_AC_VO: Used slots 0/256, Failed
Re: b43 fatal DMA errors
On 10/25/2009 03:46 PM, Gábor Stefanik wrote: 2009/10/25 Linus Torvalds torva...@linux-foundation.org: On Sun, 25 Oct 2009, Gábor Stefanik wrote: Could you please test the tag master-2009-08-26 from wireless-testing? That one was the first version that worked, and in that specific build, my card (exactly the same as yours) worked perfectly, leading me to suspect a regression (probably not in the b43 driver, but in something else interfering with b43). Will try. Are you using that same firmware version? Yes, I have v478 also. However, I tried to build the latest wireless-testing tree, but I can't reproduce the error here. One thing I have noticed is that everyone so far with this error appears to have a HP or Dell laptop - I have tested with a custom-built desktop with an Asus motherboard. I will test my other 4312 in my Acer laptop later (I don't own a Dell or a HP). Could you describe the exact HW configuration of your system (including the BIOS type - my Acer has InsydeH2O, while my desktop is AMI-based)? Does the wl_hybrid driver work for you? (If it does work, please try building the latest compat-wireless for the kernel on which wl_hybrid worked, and post the results. Try the compat-wireless driver both on a cold boot and after wl_hybrid has been unloaded.) Also try apic=off acpi=off (IIRC another DMA error victim, but with error code 0x0800 had ACPI clobbering his DMA). Ok, will try that separately. Also, is there any reference to a failed channel switch in the log? Nope. Then it's a different bug than the 0x0800 one, which also caused channel switching to fail. I do not see the DMA problem on an HP dv2815, no matter whether I run kernels from wireless-testing, mainline 2.6.32-rcX, or 2.6.31.5 from openSUSE 11.2 RC1 with compat-wireless later than 1-OCT-2009. For completeness, the specification page at http://bcm-v4.sipsolutions.net/802.11/Registers shows the error 0x0800 to be a PCI data error and 0x0400 to be a DMA descriptor error. For netbooks with Atom CPUs, the PCI data error seems to be due to ACPI errors. It is not clear what causes the DMA descriptor error. Too bad one of the devs doesn't see this error. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 fatal DMA errors
On Sun, 25 Oct 2009 22:40:50 +0100 Gábor Stefanik netrolller...@gmail.com wrote: Another thing to test: boot into Windows (or any other OS where the card works), initialize the card, reboot (not cold-boot) into Linux, try to load b43. If this succeeds, then we are missing something in the init routine. You already know that this eliminates the DMA errors. I have reported twice that if I boot up with the 2.6.27 kernel and install the broadcom b43 driver to intialise the wireless device, and then do a warm reboot to 2.6.32-rc5, then b43 works correctly. I was informed that this was irrelevant and that since acpi=off works then it must be an ACPI problem. By the way, my machine does use Phoenix BIOS. Chris ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 fatal DMA errors
On Sun, 25 Oct 2009 21:57:08 + Chris Vine ch...@cvine.freeserve.co.uk wrote: On Sun, 25 Oct 2009 22:40:50 +0100 Gábor Stefanik netrolller...@gmail.com wrote: Another thing to test: boot into Windows (or any other OS where the card works), initialize the card, reboot (not cold-boot) into Linux, try to load b43. If this succeeds, then we are missing something in the init routine. You already know that this eliminates the DMA errors. I have reported twice that if I boot up with the 2.6.27 kernel and install the broadcom b43 driver to intialise the wireless device, and then do a warm reboot to 2.6.32-rc5, then b43 works correctly. Sorry, I meant if I boot up with the 2.6.27 kernel and install the broadcom wl driver to intialise the wireless device (ie if I do a first (cold) boot with the proprietary driver). Chris ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 fatal DMA errors
On Sun, 25 Oct 2009 15:08:11 -0700 (PDT) Linus Torvalds torva...@linux-foundation.org wrote: On Sun, 25 Oct 2009, Chris Vine wrote: On Sun, 25 Oct 2009 22:40:50 +0100 Gábor Stefanik netrolller...@gmail.com suggested: Another thing to test: boot into Windows (or any other OS where the [..] You already know that this eliminates the DMA errors. I have reported twice that if I boot up with the 2.6.27 kernel and install the broadcom b43 driver to intialise the wireless device, and then do a warm reboot to 2.6.32-rc5, then b43 works correctly. Is there some way to dump all the device registers behind the SSB bridge? If so, dumping them for the warm-boot and cold-boot cases, and seeing where they are different might be an obvious clue, and point to something that isn't initialized correctly. And Chris, just out of interest - does FORCE_PIO work for you too? Yes. Chris ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 fatal DMA errors
On Sun, Oct 25, 2009 at 11:08 PM, Linus Torvalds torva...@linux-foundation.org wrote: On Sun, 25 Oct 2009, Chris Vine wrote: On Sun, 25 Oct 2009 22:40:50 +0100 Gábor Stefanik netrolller...@gmail.com suggested: Another thing to test: boot into Windows (or any other OS where the [..] You already know that this eliminates the DMA errors. I have reported twice that if I boot up with the 2.6.27 kernel and install the broadcom b43 driver to intialise the wireless device, and then do a warm reboot to 2.6.32-rc5, then b43 works correctly. Is there some way to dump all the device registers behind the SSB bridge? If so, dumping them for the warm-boot and cold-boot cases, and seeing where they are different might be an obvious clue, and point to something that isn't initialized correctly. I don't know of such a method; however I have previously succeeded in using mmiotrace to find differences between wl and b43, so it might be of help in this case. However, this might be completely irrelevant, as I suspect that PhoenixBIOS is interfering with the DMA mappings of the card, which wl (and the Windows driver) works around somehow. (Is this PR41573? In that case, it's possible that the calibration patch - maybe in conjunction with a proper PHY reset - will fix it.) Larry: what BIOS are you testing on? And Chris, just out of interest - does FORCE_PIO work for you too? Linus -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 fatal DMA errors
On 10/25/2009 05:28 PM, Gábor Stefanik wrote: On Sun, Oct 25, 2009 at 11:08 PM, Linus Torvalds torva...@linux-foundation.org wrote: On Sun, 25 Oct 2009, Chris Vine wrote: On Sun, 25 Oct 2009 22:40:50 +0100 Gábor Stefanik netrolller...@gmail.com suggested: Another thing to test: boot into Windows (or any other OS where the [..] You already know that this eliminates the DMA errors. I have reported twice that if I boot up with the 2.6.27 kernel and install the broadcom b43 driver to intialise the wireless device, and then do a warm reboot to 2.6.32-rc5, then b43 works correctly. Is there some way to dump all the device registers behind the SSB bridge? If so, dumping them for the warm-boot and cold-boot cases, and seeing where they are different might be an obvious clue, and point to something that isn't initialized correctly. I don't know of such a method; however I have previously succeeded in using mmiotrace to find differences between wl and b43, so it might be of help in this case. However, this might be completely irrelevant, as I suspect that PhoenixBIOS is interfering with the DMA mappings of the card, which wl (and the Windows driver) works around somehow. (Is this PR41573? In that case, it's possible that the calibration patch - maybe in conjunction with a proper PHY reset - will fix it.) Larry: what BIOS are you testing on? The splash screen shows it to be a Phoenix BIOS. With dmidecode I see the following: BIOS Information Vendor: Hewlett-Packard Version: F.21 Release Date: 02/28/2008 Address: 0xE7060 Runtime Size: 102304 bytes ROM Size: 1024 kB Characteristics: ISA is supported PCI is supported PC Card (PCMCIA) is supported PNP is supported APM is supported BIOS is upgradeable BIOS shadowing is allowed ESCD support is available Boot from CD is supported ACPI is supported USB legacy is supported AGP is supported BIOS boot specification is supported Targeted content distribution is supported BIOS Revision: 15.33 Firmware Revision: 81.81 Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 fatal DMA errors
2009/10/25 Larry Finger larry.fin...@lwfinger.net: On 10/25/2009 05:28 PM, Gábor Stefanik wrote: On Sun, Oct 25, 2009 at 11:08 PM, Linus Torvalds torva...@linux-foundation.org wrote: On Sun, 25 Oct 2009, Chris Vine wrote: On Sun, 25 Oct 2009 22:40:50 +0100 Gábor Stefanik netrolller...@gmail.com suggested: Another thing to test: boot into Windows (or any other OS where the [..] You already know that this eliminates the DMA errors. I have reported twice that if I boot up with the 2.6.27 kernel and install the broadcom b43 driver to intialise the wireless device, and then do a warm reboot to 2.6.32-rc5, then b43 works correctly. Is there some way to dump all the device registers behind the SSB bridge? If so, dumping them for the warm-boot and cold-boot cases, and seeing where they are different might be an obvious clue, and point to something that isn't initialized correctly. I don't know of such a method; however I have previously succeeded in using mmiotrace to find differences between wl and b43, so it might be of help in this case. However, this might be completely irrelevant, as I suspect that PhoenixBIOS is interfering with the DMA mappings of the card, which wl (and the Windows driver) works around somehow. (Is this PR41573? In that case, it's possible that the calibration patch - maybe in conjunction with a proper PHY reset - will fix it.) Larry: what BIOS are you testing on? The splash screen shows it to be a Phoenix BIOS. Kinda odd - apparently not all Phoenix BIOS versions are affected. (Or is this Phoenix AwardBIOS, Award Modular BIOS's successor? That would explain why it doesn't reproduce the error.) With dmidecode I see the following: BIOS Information Vendor: Hewlett-Packard Version: F.21 Release Date: 02/28/2008 Address: 0xE7060 Runtime Size: 102304 bytes ROM Size: 1024 kB Characteristics: ISA is supported PCI is supported PC Card (PCMCIA) is supported PNP is supported APM is supported BIOS is upgradeable BIOS shadowing is allowed ESCD support is available Boot from CD is supported ACPI is supported USB legacy is supported AGP is supported BIOS boot specification is supported Targeted content distribution is supported BIOS Revision: 15.33 Firmware Revision: 81.81 Is this all that dmidecode outputs? There is an important element towards the end of the dump that identifies a PhoenixBIOS, even if it is cloaked. Larry -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 fatal DMA errors
On 10/25/2009 05:58 PM, Gábor Stefanik wrote: 2009/10/25 Larry Finger larry.fin...@lwfinger.net: On 10/25/2009 05:28 PM, Gábor Stefanik wrote: On Sun, Oct 25, 2009 at 11:08 PM, Linus Torvalds torva...@linux-foundation.org wrote: On Sun, 25 Oct 2009, Chris Vine wrote: On Sun, 25 Oct 2009 22:40:50 +0100 Gábor Stefanik netrolller...@gmail.com suggested: Another thing to test: boot into Windows (or any other OS where the [..] You already know that this eliminates the DMA errors. I have reported twice that if I boot up with the 2.6.27 kernel and install the broadcom b43 driver to intialise the wireless device, and then do a warm reboot to 2.6.32-rc5, then b43 works correctly. Is there some way to dump all the device registers behind the SSB bridge? If so, dumping them for the warm-boot and cold-boot cases, and seeing where they are different might be an obvious clue, and point to something that isn't initialized correctly. I don't know of such a method; however I have previously succeeded in using mmiotrace to find differences between wl and b43, so it might be of help in this case. However, this might be completely irrelevant, as I suspect that PhoenixBIOS is interfering with the DMA mappings of the card, which wl (and the Windows driver) works around somehow. (Is this PR41573? In that case, it's possible that the calibration patch - maybe in conjunction with a proper PHY reset - will fix it.) Larry: what BIOS are you testing on? The splash screen shows it to be a Phoenix BIOS. Kinda odd - apparently not all Phoenix BIOS versions are affected. (Or is this Phoenix AwardBIOS, Award Modular BIOS's successor? That would explain why it doesn't reproduce the error.) With dmidecode I see the following: BIOS Information Vendor: Hewlett-Packard Version: F.21 Release Date: 02/28/2008 Address: 0xE7060 Runtime Size: 102304 bytes ROM Size: 1024 kB Characteristics: ISA is supported PCI is supported PC Card (PCMCIA) is supported PNP is supported APM is supported BIOS is upgradeable BIOS shadowing is allowed ESCD support is available Boot from CD is supported ACPI is supported USB legacy is supported AGP is supported BIOS boot specification is supported Targeted content distribution is supported BIOS Revision: 15.33 Firmware Revision: 81.81 Is this all that dmidecode outputs? There is an important element towards the end of the dump that identifies a PhoenixBIOS, even if it is cloaked. I think the part you want is Handle 0x0019, DMI type 150, 14 bytes OEM-specific Type Header and Data: 96 0E 19 00 01 01 00 00 00 00 00 00 00 00 Strings: ABSOLUTE(PHOENIX) CLM Handle 0x001A, DMI type 127, 4 bytes End Of Table There is a lot more, but the other stuff refers to memory, CPU, etc. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
