Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
On Thu, Mar 4, 2010 at 1:30 AM, Larry Finger larry.fin...@lwfinger.net wrote: On 03/02/2010 03:57 PM, Michael Buesch wrote: A bug in the PCI-E core code is able to show such behavior, because all memory transfers (MMIO and DMA) from the PCI device to the wireless core are translated by the PCI-E core. I think the whole PCI-E core code has to be audited (also the specs, probably). I have nearly finished the update on the code section of the specs page at http://bcm-v4.sipsolutions.net/PCI-E. The part that is not done involves the sections that read an address from the SPROM and perform operations on that address. I found that the chip common registers Do you mean the ChipCommon registers or the Backplane common registers? are mapped at 12K for newer cores on PCIe. This explains the 0x3XXX addresses. Similarly, the PCIe registers are mapped at 8K - the 0x2XXX addresses. The SPROM is shadowed at 4K or 0x1XXX. 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: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
On 03/03/2010 06:47 PM, Gábor Stefanik wrote: On Thu, Mar 4, 2010 at 1:30 AM, Larry Finger larry.fin...@lwfinger.net wrote: On 03/02/2010 03:57 PM, Michael Buesch wrote: A bug in the PCI-E core code is able to show such behavior, because all memory transfers (MMIO and DMA) from the PCI device to the wireless core are translated by the PCI-E core. I think the whole PCI-E core code has to be audited (also the specs, probably). I have nearly finished the update on the code section of the specs page at http://bcm-v4.sipsolutions.net/PCI-E. The part that is not done involves the sections that read an address from the SPROM and perform operations on that address. I found that the chip common registers Do you mean the ChipCommon registers or the Backplane common registers? Definitely, it is the chipcommon registers. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
On 03/02/2010 03:57 PM, Michael Buesch wrote: A bug in the PCI-E core code is able to show such behavior, because all memory transfers (MMIO and DMA) from the PCI device to the wireless core are translated by the PCI-E core. I think the whole PCI-E core code has to be audited (also the specs, probably). I have nearly finished the update on the code section of the specs page at http://bcm-v4.sipsolutions.net/PCI-E. The part that is not done involves the sections that read an address from the SPROM and perform operations on that address. I found that the chip common registers are mapped at 12K for newer cores on PCIe. This explains the 0x3XXX addresses. Similarly, the PCIe registers are mapped at 8K - the 0x2XXX addresses. The SPROM is shadowed at 4K or 0x1XXX. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
On Tuesday 02 March 2010 23:25:48 William Bourque wrote: So if I get this right, this code is responsible of handling the b43 devices, as well as several other PCI-E devices, correct? Nah, this is a broadcom specific thing of the on-chip SSB bus. Because now that you mention this, the wired network card (Marvel Yukon, with sky2 drivers) on this netbook also have a tons of issue (doesn't show in lspci on a clean boot, oops the kernel if network cable is unplugged while in use, fails to load if the module is ever unloaded, ... ) I thought it was unrelated but from your comment, I feel like this could be linked to the same PCI-E bugs as well. Uh, well. Are you sure your hardware is OK then? -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
Michael Buesch wrote: On Tuesday 02 March 2010 23:25:48 William Bourque wrote: So if I get this right, this code is responsible of handling the b43 devices, as well as several other PCI-E devices, correct? Nah, this is a broadcom specific thing of the on-chip SSB bus. Ok, sorry then :) Because now that you mention this, the wired network card (Marvel Yukon, with sky2 drivers) on this netbook also have a tons of issue (doesn't show in lspci on a clean boot, oops the kernel if network cable is unplugged while in use, fails to load if the module is ever unloaded, ... ) I thought it was unrelated but from your comment, I feel like this could be linked to the same PCI-E bugs as well. Uh, well. Are you sure your hardware is OK then? I sure hope so. The laptop is very new and I never had trouble with it, but to tell the truth, it is a refurbished model so can't say for sure. I think the hardware is fine but there is _very weird_ stuff about the laptop... I feel like their ACPI implemention is nowhere near standard and that might cause the problems. It's like everything on this laptop is under a very agressive power management that bypass the OS and confuse drivers. But again, it's just a feeling, I don't really have much facts that back up this theory ;) - William ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
On Monday 01 March 2010 01:22:50 Michael Buesch wrote: Well, you are confusing address spaces here. On a PCI based SSB device all host-side MMIO transfers go into the PCI device's address space first. The core-switching moves the window of the SSB address space that is mapped into 0-0xFFF of the PCI address space. So if you write to anything above 0xFFF on the PCI device, the write will not (directly) map to the SSB bus or any device on it. On the PCI device there is more stuff mapped on top of the SSB sliding window. For example the SPROM is mapped right on top of it. So it might be the case that on a PCI-E device the PCI-E-core's registers are permanently mapped into 0x2000 of the PCI address apace. This is to avoid sliding the SSB address space window when accessing the PCI-E core. This can have several reasons: For one speed (unlikely) and for another to avoid concurrency and ugly races when we need to access the PCI-E core while the wireless core is already running and generating interrupts. Note that this is a GUESS, but it would make sense to me. It would be cool if somebody could compare more registers of the PCI-E core using the sliding window and the 0x2000 + reg method to check my theory. So what's the status on this? I think the fact that the testing patch showed some improvement is a clear indicator that something in the PCI-E core init is wrong. It's also not surprising that something is going wrong there. The whole PCI-E core code basically is undebugged. I wrote most of it long time ago, but I still don't have a device that tests it (and probably won't get one anytime soon). So I'm really not surprised that there are bugs. There also are missing parts. A bug in the PCI-E core code is able to show such behavior, because all memory transfers (MMIO and DMA) from the PCI device to the wireless core are translated by the PCI-E core. I think the whole PCI-E core code has to be audited (also the specs, probably). -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
2010/2/28 Nathan Schulte rekl...@gmail.com: On Sat, Feb 27, 2010 at 7:03 PM, Nathan Schulte rekl...@gmail.com wrote: 2010/2/27 Larry Finger larry.fin...@lwfinger.net: The printk's I sent yesterday can have timing info, but the timestamps would not be exactly coordinated - printk values seem to be generated when logged, not when requested. I modified mmiotrace to log via printk as well, which should give the desired results. I will post the same mmiotraces as requested before, once I complete them. http://vulcan.ist.unomaha.edu/~nmschulte/mmiotraces_syslog.tar.bz2 *_syslog contains mmiotrace and pci read/write synchronously merged via printk to syslog. The log messages were prefixed with ~~, and are in context with the rest of syslog. A simple awk should be able to remove the context, but there's not much of it (and what there is is relevant to the drivers in question), so I left it in. -Nate OK, this dump shows the 0x280a write happening with core 3, i.e. PCIE, active. So, it is indeed probably the PCIE misc configuration routine. Why it's 0x280a is still a mystery to me, it should be 0x100a according to the specs. -- 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: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
Chris Vine wrote: On Sun, 28 Feb 2010 00:44:58 +0100 Gábor Stefanik netrolller...@gmail.com wrote: 2010/2/28 Nathan Schulte rekl...@gmail.com: 2010/2/27 Gábor Stefanik netrolller...@gmail.com: OK, I whipped up a quick test patch with changes found so far implemented. Please test if this improves the situation. Where can I find this patch? -Nate Oops... yes, I forgot it. Here it is! This doesn't help on my netbook, I am afraid. I confirm, it still crashes on my notebook as well. However the new fallback to PIO behavior introduced earlier do a fine job getting it back on track. Btw, you are often refering to some documentation that document the register for this device, where could I find it? I probably won't be able to do much, but I'm curious to see... - William ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
On Sun, Feb 28, 2010 at 7:00 PM, William Bourque william.bour...@polymtl.ca wrote: Chris Vine wrote: This doesn't help on my netbook, I am afraid. I confirm, it still crashes on my notebook as well. However the new fallback to PIO behavior introduced earlier do a fine job getting it back on track. Btw, you are often refering to some documentation that document the register for this device, where could I find it? I probably won't be able to do much, but I'm curious to see... - William The documentation is available @ bcm-v4.sipsolutions.net - however, this doesn't yet contain the SSB specs. -- 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: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
On Sun, Feb 28, 2010 at 7:00 PM, William Bourque william.bour...@polymtl.ca wrote: I confirm, it still crashes on my notebook as well. However the new fallback to PIO behavior introduced earlier do a fine job getting it back on track. Btw, you are often refering to some documentation that document the register for this device, where could I find it? I probably won't be able to do much, but I'm curious to see... - William Thanks! New test patch attached. Please CC linux-wirel...@vger.kernel.org on further e-mails, bcm43xx-dev appears to be having problems. -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) lpphy-test.patch Description: Binary data ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
2010/2/28 Gábor Stefanik netrolller...@gmail.com: On Sun, Feb 28, 2010 at 7:00 PM, William Bourque william.bour...@polymtl.ca wrote: I confirm, it still crashes on my notebook as well. However the new fallback to PIO behavior introduced earlier do a fine job getting it back on track. Btw, you are often refering to some documentation that document the register for this device, where could I find it? I probably won't be able to do much, but I'm curious to see... New test patch attached. Patch adds this /incorrect/ ssb_write32 to 0x280a, right? By incorrect I mean over range. Would be nice to see if dumping tool generates same log about 0x280a now (for wl and b43 patched). -- Rafał ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
On Sunday 28 February 2010 19:52:53 Gábor Stefanik wrote: 2010/2/28 Rafał Miłecki zaj...@gmail.com: 2010/2/28 Gábor Stefanik netrolller...@gmail.com: On Sun, Feb 28, 2010 at 7:00 PM, William Bourque william.bour...@polymtl.ca wrote: I confirm, it still crashes on my notebook as well. However the new fallback to PIO behavior introduced earlier do a fine job getting it back on track. Btw, you are often refering to some documentation that document the register for this device, where could I find it? I probably won't be able to do much, but I'm curious to see... New test patch attached. Patch adds this /incorrect/ ssb_write32 to 0x280a, right? By incorrect I mean over range. Would be nice to see if dumping tool generates same log about 0x280a now (for wl and b43 patched). I added both the incorrect 0x280a and the correct 0x80a here - it is possible that the 0x280a one takes advantage of an undocumented feature in PhoenixBIOS. Hell, it is pure luck that this does not blow up the whole machine. Please check the memory region of your wireless card with lspci -vvnn: 0001:10:12.0 Network controller [0280]: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller [14e4:4320] (rev 03) Subsystem: Apple Computer Inc. AirPort Extreme [106b:004e] 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: 16 Interrupt: pin A routed to IRQ 52 Region 0: Memory at a0006000 (32-bit, non-prefetchable) [size=8K] Capabilities: access denied Kernel driver in use: b43-pci-bridge Kernel modules: ssb It says 8k for all of my devices there. So an MMIO write to 0x2000 and above writes to completely random memory. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
New test patch attached. Please CC linux-wirel...@vger.kernel.org on further e-mails, bcm43xx-dev appears to be having problems. Hmm... I don't know if it is only coincidence, but this one seems to help somehow. The driver raised the DMA error again, but instead of being as soon as I brought up the interface, I had to stresstest (to transfert a file at full speed from my LAN) to make it happens. Before that I was able to DMA normally (loading web page ...). - William ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
On Sun, 28 Feb 2010 14:44:12 -0500 William Bourque william.bour...@polymtl.ca wrote: New test patch attached. Please CC linux-wirel...@vger.kernel.org on further e-mails, bcm43xx-dev appears to be having problems. Hmm... I don't know if it is only coincidence, but this one seems to help somehow. The driver raised the DMA error again, but instead of being as soon as I brought up the interface, I had to stresstest (to transfert a file at full speed from my LAN) to make it happens. Before that I was able to DMA normally (loading web page ...). I also found that it stayed up marginally longer (ie about 2 seconds longer in my case) but I think this is probably co-incidence. On commenting out the line setting the 0x280a memory location, and leaving the line setting the 0x80a memory location, it failed immediately; but these difference may just be random effects. Chris ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
On Sunday 28 February 2010 21:30:38 Chris Vine wrote: On Sun, 28 Feb 2010 19:58:11 +0100 Michael Buesch m...@bu3sch.de wrote: It says 8k for all of my devices there. So an MMIO write to 0x2000 and above writes to completely random memory. My BCM4312 device is 16K: Region 0: Memory at f800 (64-bit, non-prefetchable) [size=16K] Ok, then this write is _clearly_ not to be done unconditionally. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
Chris Vine wrote: On Sun, 28 Feb 2010 19:58:11 +0100 Michael Buesch m...@bu3sch.de wrote: It says 8k for all of my devices there. So an MMIO write to 0x2000 and above writes to completely random memory. My BCM4312 device is 16K: Region 0: Memory at f800 (64-bit, non-prefetchable) [size=16K] Now that you mention it, mine as well : 01:00.0 Network controller: Broadcom Corporation BCM4312 802.11b/g (rev 01) Subsystem: Hewlett-Packard Company Device 1507 Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at feafc000 (64-bit, non-prefetchable) [size=16K] Are all the failing devices have a 16k mem space? - William ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
On Sun, 28 Feb 2010 15:51:14 -0500 William Bourque william.bour...@polymtl.ca wrote: Chris Vine wrote: On Sun, 28 Feb 2010 19:58:11 +0100 Michael Buesch m...@bu3sch.de wrote: It says 8k for all of my devices there. So an MMIO write to 0x2000 and above writes to completely random memory. My BCM4312 device is 16K: Region 0: Memory at f800 (64-bit, non-prefetchable) [size=16K] Now that you mention it, mine as well : 01:00.0 Network controller: Broadcom Corporation BCM4312 802.11b/g (rev 01) Subsystem: Hewlett-Packard Company Device 1507 Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at feafc000 (64-bit, non-prefetchable) [size=16K] Are all the failing devices have a 16k mem space? And with 64-bit layout? (Michael's was 32-bit.) Chris ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
2010/2/28 Nathan Schulte rekl...@gmail.com: 2010/2/28 Gábor Stefanik netrolller...@gmail.com: OK, this dump shows the 0x280a write happening with core 3, i.e. PCIE, active. So, it is indeed probably the PCIE misc configuration routine. Why it's 0x280a is still a mystery to me, it should be 0x100a according to the specs. Unless I'm reading the logs wrong, isn't wl setting bit 0x8000 when core 1 is mapped (0 indexed cores, 0x18001000 mapped to space 0)? And b43 appears to do it when core 0 is mapped (0x1800 mapped to space 0). b43 also reads from 0x100a after writing to 0x280a, and it reads as 0x8000 not set (while the 0x280a check show it is set). This is when comparing the wl_cold and b43_cold logs. -Nate The latest patch, which is a partial success according to some testers, writes to core 1 (PCI-E) instead of core 0 (ChipCommon). -- 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: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
On Monday 01 March 2010 00:38:16 Nathan Schulte wrote: 2010/2/28 Gábor Stefanik netrolller...@gmail.com: The latest patch, which is a partial success according to some testers, writes to core 1 (PCI-E) instead of core 0 (ChipCommon). Then either I am misinterpreting the logs, or the last patch in this thread is not the patch you are referring to. A successful write/read to PCI config register 0x80 indicates that any following MMIO read/writes will be done on that core, correct? With the lpphy-test.patch you posted earlier, I see the following output from b43: Wrote 0x18003000 to pos 0x80 Read 0x18003000 from pos 0x80 MAP 1 0xf400 0xc900225b8000 0x4000 0x0 0 [snip some mmio read/writes and some PCI config read/writes] Wrote 0x1800 to pos 0x80 Read 0x1800 from pos 0x80 R 4 1 0xf400280a 0x6dbe 0x0 0 W 4 1 0xf400280a 0xedbe 0x0 0 This first maps core 3, does some read/writes with it, then maps core 0, and sets bit 0x8000, correct? Also, is the address space limited to the 4k range? wl maps core 1, but sets bit 0x8000 at address 0x280a, which when added to 0x18001000 is 0x1800380a, right in the PCIE cores address space (for address 0x100a). Well, you are confusing address spaces here. On a PCI based SSB device all host-side MMIO transfers go into the PCI device's address space first. The core-switching moves the window of the SSB address space that is mapped into 0-0xFFF of the PCI address space. So if you write to anything above 0xFFF on the PCI device, the write will not (directly) map to the SSB bus or any device on it. On the PCI device there is more stuff mapped on top of the SSB sliding window. For example the SPROM is mapped right on top of it. So it might be the case that on a PCI-E device the PCI-E-core's registers are permanently mapped into 0x2000 of the PCI address apace. This is to avoid sliding the SSB address space window when accessing the PCI-E core. This can have several reasons: For one speed (unlikely) and for another to avoid concurrency and ugly races when we need to access the PCI-E core while the wireless core is already running and generating interrupts. Note that this is a GUESS, but it would make sense to me. It would be cool if somebody could compare more registers of the PCI-E core using the sliding window and the 0x2000 + reg method to check my theory. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
On Sat, 27 Feb 2010 02:41:48 +0100 Gábor Stefanik netrolller...@gmail.com wrote: Someone should test the following: -Open drivers/ssb/driver_chipcommon_pmu.c -In ssb_pmu_init, replace 0x4325 with 0x4312. (This is not the correct way to fix this, but should be enough for a test. The correct fix would be special-casing for both 4312 and 4325, at least according to the MMIO trace produced using wl. Or maybe the if-branch is the wrong-way around - only Larry can tell.) For what it is worth, this does not solve the problem on my netbook. Chris ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
On Friday 26 February 2010 23:03:28 Gábor Stefanik wrote: BTW there is an interesting difference in the early init between wl and b43: b43 sets bit 0x200 in core register 0x600, while wl sets 0x8000 in register 0x280a - an undocumented register. Well, it is not only undocumented, it's also far beyond the address space. SSB core address space goes from 0-0xFFF. And (more important!) the PCI address space for MMIO is only 8k wide (I think there also are 4k devices). Are you really sure your dumping is correct? I suspect a bug in your mmio dumping tools. I'd say the undocumented register is a completely unrelated hardware access in a completely different device that just happens to be mapped right after ssb. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
On Saturday 27 February 2010 02:41:48 Gábor Stefanik wrote: Someone should test the following: -Open drivers/ssb/driver_chipcommon_pmu.c -In ssb_pmu_init, replace 0x4325 with 0x4312. Uh, wait a second. Do _all_ cards that show the behavior have a PMU on the SSB? If so, you should really make sure the PMU setup is correct. If the PMU cuts power to the device at inappropriate times, it sure does result in DMA errors (and silent MMIO errors). -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
On 02/27/2010 09:16 AM, Michael Buesch wrote: On Friday 26 February 2010 23:03:28 Gábor Stefanik wrote: BTW there is an interesting difference in the early init between wl and b43: b43 sets bit 0x200 in core register 0x600, while wl sets 0x8000 in register 0x280a - an undocumented register. Well, it is not only undocumented, it's also far beyond the address space. SSB core address space goes from 0-0xFFF. And (more important!) the PCI address space for MMIO is only 8k wide (I think there also are 4k devices). Are you really sure your dumping is correct? I suspect a bug in your mmio dumping tools. I'd say the undocumented register is a completely unrelated hardware access in a completely different device that just happens to be mapped right after ssb. There are definite instances where the vendor driver writes beyond 0xFFF. I'm pretty sure that some models shadow EEPROM above 0x1000. I don't know about 0x280A. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
On 02/27/2010 09:20 AM, Michael Buesch wrote: On Saturday 27 February 2010 02:41:48 Gábor Stefanik wrote: Someone should test the following: -Open drivers/ssb/driver_chipcommon_pmu.c -In ssb_pmu_init, replace 0x4325 with 0x4312. Uh, wait a second. Do _all_ cards that show the behavior have a PMU on the SSB? If so, you should really make sure the PMU setup is correct. If the PMU cuts power to the device at inappropriate times, it sure does result in DMA errors (and silent MMIO errors). Yes, all of the LP PHY 14e4:4315 devices have a PMU. Mine shows Found rev 1 PMU (capabilities 0x02A62F01). As I recall, at least one of the problem devices shows the same capabilities. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
On Saturday 27 February 2010 16:55:09 Larry Finger wrote: On 02/27/2010 09:16 AM, Michael Buesch wrote: On Friday 26 February 2010 23:03:28 Gábor Stefanik wrote: BTW there is an interesting difference in the early init between wl and b43: b43 sets bit 0x200 in core register 0x600, while wl sets 0x8000 in register 0x280a - an undocumented register. Well, it is not only undocumented, it's also far beyond the address space. SSB core address space goes from 0-0xFFF. And (more important!) the PCI address space for MMIO is only 8k wide (I think there also are 4k devices). Are you really sure your dumping is correct? I suspect a bug in your mmio dumping tools. I'd say the undocumented register is a completely unrelated hardware access in a completely different device that just happens to be mapped right after ssb. There are definite instances where the vendor driver writes beyond 0xFFF. I'm pretty sure that some models shadow EEPROM above 0x1000. I don't know about 0x280A. Well, writing beyond 0xFFF is one thing. But writing beyond 0x2000 is another. The latter one writes beyond the mapped PCI space. Which basically writes to random memory or whatever happens to be mapped there (arch dependent). I would also not rule out typos in the vendor driver. So, you might try if that particular write fixes the problem. But I doubt it can do so. And if it doesn't, we should not apply it, because it's obviously incorrect. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
On Saturday 27 February 2010 17:05:41 Larry Finger wrote: On 02/27/2010 09:20 AM, Michael Buesch wrote: On Saturday 27 February 2010 02:41:48 Gábor Stefanik wrote: Someone should test the following: -Open drivers/ssb/driver_chipcommon_pmu.c -In ssb_pmu_init, replace 0x4325 with 0x4312. Uh, wait a second. Do _all_ cards that show the behavior have a PMU on the SSB? If so, you should really make sure the PMU setup is correct. If the PMU cuts power to the device at inappropriate times, it sure does result in DMA errors (and silent MMIO errors). Yes, all of the LP PHY 14e4:4315 devices have a PMU. Mine shows Found rev 1 PMU (capabilities 0x02A62F01). As I recall, at least one of the problem devices shows the same capabilities. *HINT HINT HINT* ;) Please make sure the PMU code really is correct. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
On 02/27/2010 10:08 AM, Michael Buesch wrote: On Saturday 27 February 2010 17:05:41 Larry Finger wrote: On 02/27/2010 09:20 AM, Michael Buesch wrote: On Saturday 27 February 2010 02:41:48 Gábor Stefanik wrote: Someone should test the following: -Open drivers/ssb/driver_chipcommon_pmu.c -In ssb_pmu_init, replace 0x4325 with 0x4312. Uh, wait a second. Do _all_ cards that show the behavior have a PMU on the SSB? If so, you should really make sure the PMU setup is correct. If the PMU cuts power to the device at inappropriate times, it sure does result in DMA errors (and silent MMIO errors). Yes, all of the LP PHY 14e4:4315 devices have a PMU. Mine shows Found rev 1 PMU (capabilities 0x02A62F01). As I recall, at least one of the problem devices shows the same capabilities. *HINT HINT HINT* ;) Please make sure the PMU code really is correct. Where are the specs that were used to write the original code? I cannot find them in either the V3 or V4 pages. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
On Sat, Feb 27, 2010 at 5:37 PM, Larry Finger larry.fin...@lwfinger.net wrote: On 02/27/2010 10:08 AM, Michael Buesch wrote: On Saturday 27 February 2010 17:05:41 Larry Finger wrote: On 02/27/2010 09:20 AM, Michael Buesch wrote: On Saturday 27 February 2010 02:41:48 Gábor Stefanik wrote: Someone should test the following: -Open drivers/ssb/driver_chipcommon_pmu.c -In ssb_pmu_init, replace 0x4325 with 0x4312. Uh, wait a second. Do _all_ cards that show the behavior have a PMU on the SSB? If so, you should really make sure the PMU setup is correct. If the PMU cuts power to the device at inappropriate times, it sure does result in DMA errors (and silent MMIO errors). Yes, all of the LP PHY 14e4:4315 devices have a PMU. Mine shows Found rev 1 PMU (capabilities 0x02A62F01). As I recall, at least one of the problem devices shows the same capabilities. *HINT HINT HINT* ;) Please make sure the PMU code really is correct. Where are the specs that were used to write the original code? I cannot find them in either the V3 or V4 pages. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev So, a quick status update, from what I've found yesterday: 1. We get the PMU setup wrong. Bit 0x200 is being set, despite the PMU being rev1. Also, PMU setup is done too early - at least wl reads the SPROM before setting up the PMU. A write of 0xcbb to offset 0x618 is also missing - I seem to remember that this change has been tried already, to no avail; but it may be a prerequisite of the real fix. 2. Just before the SPROM readout, we are missing a Set 0x8000 in MMIO offset 0x280a. This looks curiously like PCI-E Miscellaneous Configuration, from http://bcm-v4.sipsolutions.net/PCI-E - and indeed, the value read out from 0x280a is identical to offset 0xa in my SPROM. So, the right thing to do here is probably Switch to the PCIE core, set 0x8000 in MIMO offset 0x80a (or maybe 0x1000a?), switch back to ChipCommon. I don't know what core is active during this write, as mmiotrace doesn't catch pci_read/write_config_dword calls. Larry, do you know a way to monitor PCI config space access in a way that can be matched (e.g. using timestamps) to the MMIO trace? 3. Right after the SPROM is read, wl writes zeros to MMIO offsets 0x58 and 0x5c (32-bit), then does the PMU setup. These are not valid registers for ChipCommon and PCIE, but for 802.11, they fall directly into the DMA area! So, if these writes happened with the 802.11 core active, they are probably significant. I second Larry's question: where are the specs for the PMU init code? -- 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: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
2010/2/27 Nathan Schulte rekl...@gmail.com: I've been following along with the linux-wireless thread, and wanted to bring up a few points. 1) If the report in reference by Gábor: Well, we have a report from someone with an Intel T7250, ... is mine, note that my processor is actually a T5670 @ 1.8GHz, not a T7250 @ 2.0GHz. Just for the record. I was referring to Lucas, he has a T7250 AFAIK. 2) My BIOS setup has only one option related to the chip: WLAN control: enabled/disabled, which just enables or disables the card. That's basically RFKILL, were it misconfigured, you wouldn't even get to the point where a DMA error can occur. 2) In regard to Michael's statement about having someone with the hardware who can do some real debug work; I have the hardware, I like to think I've got a fairly good idea of what's going on (I'm able to follow along), I can read and understand the src (but as mentioned, there is a lot of indirection, I have little idea what is actually happening when). I'm more than willing to help, but learning the ssb and b43 drivers in and out is quite a large task. Just my thoughts, hope I'm not just getting in the way. -Nate Thanks - but currently I'm still trying to find out how you can trace PCI config space accesses (pci_config_read/write_(d)word - if you have an idea on this, please post it). However, I will probably have a few test patches for you soon. -- 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: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
On Saturday 27 February 2010 20:45:50 Gábor Stefanik wrote: 2. Just before the SPROM readout, we are missing a Set 0x8000 in MMIO offset 0x280a. This looks curiously like PCI-E Miscellaneous Configuration, from http://bcm-v4.sipsolutions.net/PCI-E - and indeed, the value read out from 0x280a is identical to offset 0xa in my SPROM. So, the right thing to do here is probably Switch to the PCIE core, set 0x8000 in MIMO offset 0x80a (or maybe 0x1000a?), switch back to ChipCommon. I don't know what core is active during this Well, 0x280a and 0x80a basically is not the same in my part of the world. To ask it again: Is it possible that the 0x2000 bit of the address comes from some random burp/bug in the tracing code? It _really_ doesn't make any sense, because it's beyond the mapped space of the device. write, as mmiotrace doesn't catch pci_read/write_config_dword calls. Larry, do you know a way to monitor PCI config space access in a way that can be matched (e.g. using timestamps) to the MMIO trace? 3. Right after the SPROM is read, wl writes zeros to MMIO offsets 0x58 and 0x5c (32-bit), then does the PMU setup. These are not valid registers for ChipCommon and PCIE, but for 802.11, they fall directly into the DMA area! The writes (_if_ they happen on the 802.11 core) fall into the interrupt status and masks of the 8th DMA engine (they do not fall into the MMIO of the DMA engines). We don't use the 8th engine. It probably is a good idea to write zeros to the mask register anyway, so I'll spin up a quick test patch. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
On 02/27/2010 01:45 PM, Gábor Stefanik wrote: So, a quick status update, from what I've found yesterday: 1. We get the PMU setup wrong. Bit 0x200 is being set, despite the PMU being rev1. Also, PMU setup is done too early - at least wl reads the SPROM before setting up the PMU. A write of 0xcbb to offset 0x618 is also missing - I seem to remember that this change has been tried already, to no avail; but it may be a prerequisite of the real fix. 2. Just before the SPROM readout, we are missing a Set 0x8000 in MMIO offset 0x280a. This looks curiously like PCI-E Miscellaneous Configuration, from http://bcm-v4.sipsolutions.net/PCI-E - and indeed, the value read out from 0x280a is identical to offset 0xa in my SPROM. So, the right thing to do here is probably Switch to the PCIE core, set 0x8000 in MIMO offset 0x80a (or maybe 0x1000a?), switch back to ChipCommon. I don't know what core is active during this write, as mmiotrace doesn't catch pci_read/write_config_dword calls. Larry, do you know a way to monitor PCI config space access in a way that can be matched (e.g. using timestamps) to the MMIO trace? The printk's I sent yesterday can have timing info, but the timestamps would not be exactly coordinated - printk values seem to be generated when logged, not when requested. 3. Right after the SPROM is read, wl writes zeros to MMIO offsets 0x58 and 0x5c (32-bit), then does the PMU setup. These are not valid registers for ChipCommon and PCIE, but for 802.11, they fall directly into the DMA area! So, if these writes happened with the 802.11 core active, they are probably significant. That sounds promising. I think I found the section, which will have the following specs: 1. If the Chip Common revision = 20 a. Save the current core index a. Set core to chip common a. Write 0 to GPIO Pullup (register 0x58) a. Write 0 to GPIO Pulldown (register 0x5C) a. Restore the original core 1. If PMU Control Enabled a. Init the PMU ... A quick look ar the code suggests this should go into ssb_chipcommon_init() just after the return for not having a chip common. In addition, chip common will already be selected, thus that part can be skipped. I second Larry's question: where are the specs for the PMU init code? From what Michael replied, they do not exist in a public place other that the reference code for embedded systems. I have started them - there is now a PMU Init page and I'll fill them in as I can. If you have a specific routine, let me know. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
2010/2/28 Nathan Schulte rekl...@gmail.com: 2010/2/27 Gábor Stefanik netrolller...@gmail.com: OK, I whipped up a quick test patch with changes found so far implemented. Please test if this improves the situation. Where can I find this patch? -Nate Oops... yes, I forgot it. Here it is! -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) lpphy-test.patch Description: Binary data ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
2010/2/28 Nathan Schulte rekl...@gmail.com: 2010/2/27 Gábor Stefanik netrolller...@gmail.com: Oops... yes, I forgot it. Here it is! No luck from me either. And by the way, Lucas and I have the exact same hardware, so his is indeed a T5670 as well. -Nate Are you sure it is exactly the same? There are usually multiple configurations of the same laptop model available, e.g. I have an Acer 5720ZG with Pentium E2330, but it is also available with e.g. Pentium E2370. -- 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: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
On Fri, Feb 26, 2010 at 8:33 AM, Nathan Schulte rekl...@gmail.com wrote: 2010/1/25 Gábor Stefanik netrolller...@gmail.com A few things to check: -Is this on PhoenixBios? I have the same laptop as Lucas, a Dell Vostro 1510. As Lucas has mentioned, this is indeed a PhoenixBIOS -Does loading wl, doing a warm reboot and loading b43 make b43 work? I am running Debian Squeeze with the latest stock kernel (linux 2.6.32-5). I cold booted with b43 and ssb blacklisted, and loaded the wl module. I confirmed that it operated correctly, unloaded the wl module, and loaded b43 (and subsequently required modules). This did indeed make b43 work, contrary to Lucas's claim, at least for me. -Try updating the firmware to v478. (AFAIK there was someone on the list before with a DMA error on a non-ULV, and it was solved by updating the firmware. Broadcom's wl.ko uses a v5xx firmware for the record.) I am using the 4.178.10.4 driver as suggested on the linuxwireless page (http://downloads.openwrt.org/sources/broadcom-wl-4.178.10.4.tar.bz2), which it claims is actually 4.174.64.19. My logs state -- Loading firmware version 478.104. The firmware version included in 4.174.64.19 is 478.104 (notice that is is not 4178.104, but 478.104 - the driver and firmware versions are not related!). snip And the Fatal DMA error: 0x400 repeats from there. -Nate Hi! Could you post an mmiotrace of the following? - ssb+b43 failing on cold boot - wl loaded on cold boot - wl loaded on warm boot (with wl having been loaded prior to reboot) - ssb+b43 working on warm boot (same as above) Thanks, Gábor -- 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: Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
On Fri, Feb 26, 2010 at 12:12 PM, rekl...@gmail.com wrote: On Feb 26, 2010 3:23am, Gábor Stefanik netrolller...@gmail.com wrote: The firmware version included in 4.174.64.19 is 478.104 (notice that is is not 4178.104, but 478.104 - the driver and firmware versions are not related!). Ah yes, sorry for my confusion. Hi! Hello there! Thanks for the speedy reply, hopefully I can help get to the bottom of this. Could you post an mmiotrace of the following? Certainly. As the stock Debian kernel doesn't appear to have the MMIO tracer enabled, these are from a fresh linux 2.6.33 mainline build (with CONFIG_B43_DEBUG=y and CONFIG_B43_FORCE_PIO=n) (some time passes) Err... I seem to be having issues getting the driver to fail as before. I have had the driver fail on a 2.6.33 build just hours ago, but with my new configuration, it is not. Make sure to actually cut power to the system discharge any stray voltages by pressing the Power On button with the powrer still cut before cold boot tests. The effect of wl seems to survive reboots. I will test using the stock kernel config with mmiotracer enabled. Thanks, Gábor -Nate -- 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: Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
2010/2/26 Nathan Schulte rekl...@gmail.com: I apologize for so many messages. I wanted to note that the reasoning for lsmod only showing the ntfs module, is due the fact that ntfs (and b43 and ssb) are the only drivers compiled as modules. When loading b43 without mmiotrace running, I receive a Fatal DMA error: 0x800 within a few seconds. I receive no other errors following, but I am unable to associate with an access point. If I then unload b43 and ssb, and reload it, I receive a Fatal DMA error: 0x400 (and can generate one for every ifconfig wlan0 down/up I perform). The archive http://vulcan.ist.unomaha.edu/~nmschulte/traces.tar.bz2 contains two traces. The first trace (one) is after a cold boot, loading b43, associating with an access point, issuing ifconfig wlan0 down, ifconfig wlan0 up, and then stopping the trace. Immediately after stopping the trace, I receive a 0x800 error in my logs. I then unloaded b43 and ssb, and started a new mmiotrace (two). I then loaded b43, issued ifconfig wlan0 down, ifconfig wlan0 up, and again issued ifconfig wlan0 down/up (preceeded by trace markers denoting such), and then stopped the trace. It is expected that you only get a single DMA error with 2.6.33, as the driver was modified in 2.6.33 to give up after a single failure. The controller restart mechanism has yet to show a successful error recovery for any card, OTOH the repeated retries had nasty side effects on some machines (including lockups and crashes), so the entire retry mechanism was removed. However, you did not do what I requested - before the 2nd mmiotrace, load and unload wl (the hybrid driver), not b43 - it is wl that appears to make the card work. -- 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: Re: Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
On Fri, Feb 26, 2010 at 4:04 PM, rekl...@gmail.com wrote: On Feb 26, 2010 8:49am, Gábor Stefanik netrolller...@gmail.com wrote: However, you did not do what I requested - before the 2nd mmiotrace, load and unload wl (the hybrid driver), not b43 - it is wl that appears to make the card work. Correct, I did not do this. This is because (the current available version of) the hybrid driver does not build against 2.6.33. I need to build 2.6.32 vanilla, or the stock kernel. I will do that now. However, I thought it significant that using b43 from a cold boot works, so long as one is performing an mmiotrace. This is why I linked the tracers.tar.gz. That's odd... the error only occurs when you stop the mmiotrace?! BTW no need to load wl and b43 on the same kernel - the effect of loading wl survives a reboot or a kexec. -- 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: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
On 02/26/2010 09:27 AM, Gábor Stefanik wrote: On Fri, Feb 26, 2010 at 4:13 PM, rekl...@gmail.com wrote: On Feb 26, 2010 9:08am, Gábor Stefanik netrolller...@gmail.com wrote: That's odd... the error only occurs when you stop the mmiotrace?! Yes, the error only occurs when I stop the mmiotrace with b43 loaded, or if I load b43 outside of an mmiotrace. BTW no need to load wl and b43 on the same kernel - the effect of loading wl survives a reboot or a kexec. But then I cannot get you the mmiotrace as you requested. If all you're after is the mmiotrace of b43 from cold and b43 from warm with wl magic, I can do that now. I don't know how helpful this will be given that b43 appears to work so long as an mmiotrace is being performed. The differences will still be there in the dump, even if something related to mmiotrace seemingly works around the bug. However, the most helpful logs would be the ones produced by wl itself, on a cold boot. This thread is most interesting. Thanks for keeping it on the list, even though the OP doesn't seem to know about Reply All. The fact that the 4315 doesn't get the DMA errors until MMIO tracing is turned off suggests some kind of subtle timing difference. I'll look at the Broadcom code to see if there are some delay statements in the interrupt handling, or if their processing does things in a different order. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
2010/2/26 Larry Finger larry.fin...@lwfinger.net: On 02/26/2010 09:27 AM, Gábor Stefanik wrote: On Fri, Feb 26, 2010 at 4:13 PM, rekl...@gmail.com wrote: On Feb 26, 2010 9:08am, Gábor Stefanik netrolller...@gmail.com wrote: That's odd... the error only occurs when you stop the mmiotrace?! Yes, the error only occurs when I stop the mmiotrace with b43 loaded, or if I load b43 outside of an mmiotrace. BTW no need to load wl and b43 on the same kernel - the effect of loading wl survives a reboot or a kexec. But then I cannot get you the mmiotrace as you requested. If all you're after is the mmiotrace of b43 from cold and b43 from warm with wl magic, I can do that now. I don't know how helpful this will be given that b43 appears to work so long as an mmiotrace is being performed. The differences will still be there in the dump, even if something related to mmiotrace seemingly works around the bug. However, the most helpful logs would be the ones produced by wl itself, on a cold boot. This thread is most interesting. Thanks for keeping it on the list, even though the OP doesn't seem to know about Reply All. The fact that the 4315 doesn't get the DMA errors until MMIO tracing is turned off suggests some kind of subtle timing difference. I'll look at the Broadcom code to see if there are some delay statements in the interrupt handling, or if their processing does things in a different order. Larry Note that enabling MMIO trace touches quite a few areas of the kernel rather hard - for example, it AFAIK disables SMP. I wonder if acpi=off or blacklisting processor would have an effect here... -- 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: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
2010/2/26 Chris Vine ch...@cvine.freeserve.co.uk: On Fri, 26 Feb 2010 18:22:26 +0100 Gábor Stefanik netrolller...@gmail.com wrote: Note that enabling MMIO trace touches quite a few areas of the kernel rather hard - for example, it AFAIK disables SMP. I wonder if acpi=off or blacklisting processor would have an effect here... I have reported previously (some months ago) that this delays the onset of DMA errors, but it just masks the problem. It has the same effect as the earlier pm_qos patch. The real issue appears to lie somewhere else: it is noise introduced by timing differences. Chris I suspect that timing is not the true reason for the problem, rather, there is a race condition between PhoenixBIOS and b43, for which wl probably uses a (firmware?) workaround. BTW there is an interesting difference in the early init between wl and b43: b43 sets bit 0x200 in core register 0x600, while wl sets 0x8000 in register 0x280a - an undocumented register. Larry, do you have any info on this? -- 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: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
On Fri, 26 Feb 2010 23:03:28 +0100 Gábor Stefanik netrolller...@gmail.com wrote: I suspect that timing is not the true reason for the problem, rather, there is a race condition between PhoenixBIOS and b43, for which wl probably uses a (firmware?) workaround. I meant that it is the reason for the masking of the DMA errors, rather than their cause. (That is not to say that your diagnosis of the problem may not be right.) Chris ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
Someone should test the following: -Open drivers/ssb/driver_chipcommon_pmu.c -In ssb_pmu_init, replace 0x4325 with 0x4312. (This is not the correct way to fix this, but should be enough for a test. The correct fix would be special-casing for both 4312 and 4325, at least according to the MMIO trace produced using wl. Or maybe the if-branch is the wrong-way around - only Larry can tell.) BTW does anyone know of a way to trace pci_read/write_config_dword calls? Mmiotrace doesn't capture these. 2010/2/26 Chris Vine ch...@cvine.freeserve.co.uk: On Fri, 26 Feb 2010 23:03:28 +0100 Gábor Stefanik netrolller...@gmail.com wrote: I suspect that timing is not the true reason for the problem, rather, there is a race condition between PhoenixBIOS and b43, for which wl probably uses a (firmware?) workaround. I meant that it is the reason for the masking of the DMA errors, rather than their cause. (That is not to say that your diagnosis of the problem may not be right.) Chris -- 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: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
On 02/26/2010 07:41 PM, Gábor Stefanik wrote:
Someone should test the following:
-Open drivers/ssb/driver_chipcommon_pmu.c
-In ssb_pmu_init, replace 0x4325 with 0x4312. (This is not the correct
way to fix this, but should be enough for a test. The correct fix
would be special-casing for both 4312 and 4325, at least according to
the MMIO trace produced using wl. Or maybe the if-branch is the
wrong-way around - only Larry can tell.)
The latest Broadcom driver has changed this section. The new specs should be:
1. If the pmu revision is 1
a. Clear bit 0x200 in the PMU control register
1. Otherwise
a. Set bit 0x200 in the PMU control register
BTW does anyone know of a way to trace pci_read/write_config_dword
calls? Mmiotrace doesn't capture these.
The attached patch will log PCI config reads/writes to the system logs.
Larry
Index: wireless-testing/drivers/pci/access.c
===
--- wireless-testing.orig/drivers/pci/access.c
+++ wireless-testing/drivers/pci/access.c
@@ -24,6 +24,8 @@ static DEFINE_SPINLOCK(pci_lock);
#define PCI_word_BAD (pos 1)
#define PCI_dword_BAD (pos 3)
+static void pci_bus_log_buf(char *buf);
+
#define PCI_OP_READ(size,type,len) \
int pci_bus_read_config_##size \
(struct pci_bus *bus, unsigned int devfn, int pos, type *value) \
@@ -31,11 +33,14 @@ int pci_bus_read_config_##size \
int res;\
unsigned long flags;\
u32 data = 0; \
+ char buf[80]; \
if (PCI_##size##_BAD) return PCIBIOS_BAD_REGISTER_NUMBER; \
spin_lock_irqsave(pci_lock, flags);\
res = bus-ops-read(bus, devfn, pos, len, data); \
*value = (type)data;\
spin_unlock_irqrestore(pci_lock, flags); \
+ sprintf(buf, Read 0x%X from pos 0x%X\n, data, pos); \
+ pci_bus_log_buf(buf); \
return res; \
}
@@ -45,10 +50,13 @@ int pci_bus_write_config_##size \
{ \
int res;\
unsigned long flags;\
+ char buf[80]; \
if (PCI_##size##_BAD) return PCIBIOS_BAD_REGISTER_NUMBER; \
spin_lock_irqsave(pci_lock, flags);\
res = bus-ops-write(bus, devfn, pos, len, value); \
spin_unlock_irqrestore(pci_lock, flags); \
+ sprintf(buf, Wrote 0x%X to pos 0x%X\n, value, pos); \
+ pci_bus_log_buf(buf); \
return res; \
}
@@ -427,3 +435,8 @@ void pci_unblock_user_cfg_access(struct
spin_unlock_irqrestore(pci_lock, flags);
}
EXPORT_SYMBOL_GPL(pci_unblock_user_cfg_access);
+
+static void pci_bus_log_buf(char *buf)
+{
+ printk(KERN_DEBUG %s, buf);
+}
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
On Mon, Jan 25, 2010 at 9:15 PM, Lucas Thode ljth...@gmail.com wrote: ---start dmesg snippet--- [17189.121003] b43-pci-bridge :06:00.0: PCI INT A disabled [17192.494272] cfg80211: Using static regulatory domain info [17192.494279] cfg80211: Regulatory domain: US [17192.494283] (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp ) [17192.494292] (2402000 KHz - 2472000 KHz @ 4 KHz), (600 mBi, 2700 mBm) [17192.494299] (517 KHz - 519 KHz @ 4 KHz), (600 mBi, 2300 mBm) [17192.494306] (519 KHz - 521 KHz @ 4 KHz), (600 mBi, 2300 mBm) [17192.494314] (521 KHz - 523 KHz @ 4 KHz), (600 mBi, 2300 mBm) [17192.494321] (523 KHz - 533 KHz @ 4 KHz), (600 mBi, 2300 mBm) [17192.494328] (5735000 KHz - 5835000 KHz @ 4 KHz), (600 mBi, 3000 mBm) [17192.494418] cfg80211: Calling CRDA for country: US [17192.658174] b43-pci-bridge :06:00.0: PCI INT A - GSI 19 (level, low) - IRQ 19 [17192.658206] b43-pci-bridge :06:00.0: setting latency timer to 64 [17192.724352] ssb: Sonics Silicon Backplane found on PCI device :06:00.0 [17192.769108] b43-phy0: Broadcom 4312 WLAN found (core revision 15) [17192.843094] phy0: Selected rate control algorithm 'minstrel' [17192.844206] Registered led device: b43-phy0::tx [17192.84] Registered led device: b43-phy0::rx [17192.844500] Registered led device: b43-phy0::radio [17192.844859] Broadcom 43xx driver loaded [ Features: PMLS, Firmware-ID: FW13 ] [17196.776755] b43 ssb0:0: firmware: requesting b43/ucode15.fw [17196.780967] b43 ssb0:0: firmware: requesting b43/lp0initvals15.fw [17196.784551] b43 ssb0:0: firmware: requesting b43/lp0bsinitvals15.fw [17196.921708] b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10) [17202.497881] ADDRCONF(NETDEV_UP): wlan0: link is not ready [17202.934136] b43-phy0 ERROR: Fatal DMA error: 0x0800, 0x, 0x, 0x, 0x, 0x [17202.934153] b43-phy0: Controller RESET (DMA error) ... [17203.148369] b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10) [17208.681254] b43-phy0: Controller restarted [17208.696481] b43-phy0 ERROR: Fatal DMA error: 0x0400, 0x, 0x, 0x, 0x, 0x [17208.696490] b43-phy0: Controller RESET (DMA error) ... [17208.914882] b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10) [17214.461361] b43-phy0: Controller restarted [17214.461610] b43-phy0 ERROR: Fatal DMA error: 0x0400, 0x, 0x, 0x, 0x, 0x [17214.461626] b43-phy0: Controller RESET (DMA error) ... [17214.676285] b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10) ---end dmesg snippet---...and on and on the dma errors go. This occured about (sorry, not sure exactly, but I don't think it quite matters with this particular error) when I used iwlist scan to search for wireless networks after I used the b43-fwcutter from Debian testing to install the firmware and re-inserted the driver with 'modprobe -r b43; modprobe b43'. kb...@kb1rd-mobroost:~$ uname -a Linux kb1rd-mobroost 2.6.32-trunk-amd64 #1 SMP Sun Jan 10 22:40:40 UTC 2010 x86_64 GNU/Linux kb...@kb1rd-mobroost:~$ lspci -vvn | grep 43 -A7 06:00.0 0280: 14e4:4315 (rev 01) Subsystem: 1028:000b 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 19 Region 0: Memory at f400 (64-bit, non-prefetchable) [size=16K] Capabilities: access denied Kernel driver in use: b43-pci-bridge extraneous output having to do with my Ethernet chip snipped kb...@kb1rd-mobroost:~$ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 Duo CPU T5670 @ 1.80GHz stepping : 13 cpu MHz : 800.000 cache size : 2048 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm lahf_lm ida bogomips : 3590.43 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: output for core 1 snipped As you can tell, this processor is neither an Atom nor a ULV Core 2 Duo. The WLAN card is the Dell Wireless 1395 that came with the laptop (a Vostro 1510). I can build a custom kernel based on the Debian kernel sources if need be; just tell me
Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
On 01/25/2010 02:15 PM, Lucas Thode wrote: As you can tell, this processor is neither an Atom nor a ULV Core 2 Duo. The WLAN card is the Dell Wireless 1395 that came with the laptop (a Vostro 1510). I can build a custom kernel based on the Debian kernel sources if need be; just tell me what config options to flip/patches to apply. Also, wl.o works on this laptop with the Debian 2.6.30 kernel. Aptitude lists the kernel version as a 2.6.32-5. There is one other report of the DMA problem with a non-Atom CPU (I'm not sure about the non-ULV part.). We do not know what the wl driver does that we do not, or vice-versa. If you want to use b43, you need to build it to use PIO only. Choosing PIO is now available as a run-time option, but I do not think 2.6.32 has this feature. Debugging this problem has been most difficult as it only affects Intel CPUs and all my machines have AMD processors. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
2010/1/25 Lucas Thode ljth...@gmail.com 2010/1/25 Gábor Stefanik netrolller...@gmail.com A few things to check: -Is this on PhoenixBios? Indeed, the Vostro 1510 uses a (Dell branded) PhoenixBIOS. -Does loading wl, doing a warm reboot and loading b43 make b43 work? -Try updating the firmware to v478. (AFAIK there was someone on the list before with a DMA error on a non-ULV, and it was solved by updating the firmware. Broadcom's wl.ko uses a v5xx firmware for the record.) I will attempt a firmware upgrade (manually downloading/compiling/running b43-fwcutter) when I have access to this laptop again (later today). Debian bug #561450 covers the fact that the Debian b43-fwcutter package is too old; I have added a post to that bug report mentioning the v478 firmware + the Fatal DMA error message (the original bug reporter did not check his dmesg). UPDATE: Upgraded firmware to v478. The original Fatal DMA error (the code 0x800 one) no longer appears, replaced now by a code 0x400 one. Also, the wireless-LAN light on my laptop will flicker off and back on every so often, accompanied by a temporary system freeze. I assume that this is occurring in synchrony with the card restarting. --Lucas --Lucas -- 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: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
2010/1/25 Lucas Thode ljth...@gmail.com 2010/1/25 Lucas Thode ljth...@gmail.com 2010/1/25 Gábor Stefanik netrolller...@gmail.com A few things to check: -Is this on PhoenixBios? Indeed, the Vostro 1510 uses a (Dell branded) PhoenixBIOS. -Does loading wl, doing a warm reboot and loading b43 make b43 work? UPDATE 2: No, I tried loading my 2.6.30 kernel (which has working wireless using wl.ko) then Ctrl-Alt-Del-ing into my 2.6.32 kernel, and the Fatal DMA errors perisisted. (They seem to start happening shortly after system startup, too; no action on my part is needed to provoke them.) -Try updating the firmware to v478. (AFAIK there was someone on the list before with a DMA error on a non-ULV, and it was solved by updating the firmware. Broadcom's wl.ko uses a v5xx firmware for the record.) I will attempt a firmware upgrade (manually downloading/compiling/running b43-fwcutter) when I have access to this laptop again (later today). Debian bug #561450 covers the fact that the Debian b43-fwcutter package is too old; I have added a post to that bug report mentioning the v478 firmware + the Fatal DMA error message (the original bug reporter did not check his dmesg). UPDATE: Upgraded firmware to v478. The original Fatal DMA error (the code 0x800 one) no longer appears, replaced now by a code 0x400 one. Also, the wireless-LAN light on my laptop will flicker off and back on every so often, accompanied by a temporary system freeze. I assume that this is occurring in synchrony with the card restarting. --Lucas --Lucas -- 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
