2011/8/18 Vítor Ferreira <vitor.dominor@xxxxxxxxx>: >>> Just a side note... Curiously with Intel VT, the b43 driver would start and > work >>> for some short time before it crashed, while the wl proprietary driver (from >>> Broadcom) would not even fully load. >> I hope you mean DMA errors, not really crashing. > > Yes, I mean DMA errors. It just seems it crashed, because it never recovers > until reboot. > >> What you describe here sounds like standard LP-PHY DMA issue resolved >> in 3.0 kernel. We got some timeouts-related bug, which didn't hit >> right after loading b43, usually some time (seconds-minutes) later. > > Well, lately there wasn't always a timeout after loading b43. Sometimes, the DMA > error occured only after doing some more network intensive activity, like > downloading a file or watching a video on the web. > >> The last patches are supposed to fix situation where DMA does not work >> at all. Not even for a second, not for a single packet. I'm really >> sure of that, unless you have some *really* bugged hardware accepting >> multiple "translation bits" (something my patches fix). >> Moreover LP-PHY DMA problems (timeouts issue) was known to be somehow >> CPU/BIOS-related. Which makes it even more probably that that's >> exactly what you were experiencing. > > Honestly, I wouldn't know. I don't have quite fully understood what is that dma > translation bug causing the dma fatal errors. > However, I suspect it might be one of those *really* bugged hardware. I'm just > guessing, perhaps it has something to do with the DMA features enabled by the > Intel Virtualization Technology for Directed I/O. It's too much of a coincidence > that the DMA errors only happen when Intel VT is enabled. > Just for your reference, this is the system log extract regarding DMA on my > system. > > kernel [ 0.257149] DMAR: Forcing write-buffer flush capability > kernel [ 0.257150] DMAR: Disabling IOMMU for graphics on this chipset > kernel [ 0.601514] PCI-DMA: Intel(R) Virtualization Technology for Directed > I/O > kernel [ 0.745975] ata1: SATA max UDMA/133 abar m2048@0xdf305000 port > 0xdf305100 irq 49 > kernel [ 0.745978] ata2: SATA max UDMA/133 abar m2048@0xdf305000 port > 0xdf305180 irq 49 > kernel [ 0.745983] ata5: SATA max UDMA/133 abar m2048@0xdf305000 port > 0xdf305300 irq 49 > kernel [ 0.745986] ata6: SATA max UDMA/133 abar m2048@0xdf305000 port > 0xdf305380 irq 49 > kernel [ 1.206589] ata1.00: ATA-8: FUJITSU MHZ2320BH G2, 8909, max UDMA/100 > kernel [ 1.207251] ata1.00: configured for UDMA/100 > kernel [ 1.682191] ata2.00: ATAPI: TSSTcorp CDDVDW TS-L633L, 0400, max > UDMA/100 > kernel [ 1.695900] ata2.00: configured for UDMA/100 > kernel [ 2.696557] mmc0: SDHCI controller on PCI [0000:06:00.1] using DMA > kernel [ 28.902798] DMAR:[DMA Read] Request device [02:00.0] fault addr > ffff4000 > kernel [ 28.902800] DMAR:[fault reason 06] PTE Read access is not set > kernel [ 28.902841] b43-phy0 ERROR: Fatal DMA error: 0x00000800, 0x00000000, > 0x00000000, 0x00000000, 0x00000000, 0x00000000 > kernel [ 28.902846] b43-phy0 ERROR: This device does not support DMA on your > system. It will now be switched to PIO. > kernel [ 28.902850] b43-phy0: Controller RESET (DMA error) ... > > From lspci, 02:00.0 refers to the Broadcom 4312 wireless card. > >> That's the tricky part. Kernel 3.0 should really work for you. Unless >> Fedora got some problem (mistake?) in compiling/numbering... > >> I think the important part was updating to the recent compat-wireless, >> not applying my patches. If you wish, you can still use that >> compat-wireless, revert my 2 patches and test again. I suspect card >> will be still working for you. > > I booted back to the kernel 3.0 from fedora, without your patches and any > compat-wireless. I checked again and the DMA errors really continue in these > circunstances. > Then I booted again to my updated 3.0.3.rc1 kernel and I applied the same recent > compat-wireless without your last patches. Again, the same DMA errors occurred > after loading b43, as shown in the log above. > Only after patching the compat-wireless with your last patches and rebooting did > those DMA errors disappear. So I am afraid the recent (unpatched) > compat-wireless isn't the solution. Hm, OK, it really seems you're right, there is something more we wasn't aware of. Thanks for your testing :) -- Rafał -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
