Michael Buesch wrote: > 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). > So if I get this right, this code is responsible of handling the b43 devices, as well as several other PCI-E devices, correct? 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. - William -- 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
