On Monday 30 April 2007, Dirk Försterling wrote: > Thanks for the explanation(s), David! > > David Brownell wrote: > >> ehci_hcd 0000:00:13.2: MWI active > > > > That's the good one. It means that a more efficient PCI transaction > > will be used when writing memory ... "memory write invalidate" so the > > CPU data cache is managed with less overhead. > > > > In fact this is the first time I've ever seen that message. I think it's > > because your CPU has a relatively small CPU cacheline size. Larger > > ones prevent Linux from turning MWI (doesn't seem right to me, but > > that's the way it works for now). > > Maybe there are not so many people trying to get USB 2.0 working on > old boxes? Mine is still working fine and I have a few spare parts > in case of failures :)
My old K6 died a few years back, unfortunately. It was the first box I dedicated to Linux. Sigh. :( > >> status a008 Async Recl FLR > > ^^^^^ > >> command 010009 (park)=0 ithresh=1 period=256 RUN > > > > And that's the problem. The controller is scanning the async > > schedule ... but it shouldn't be, since it's not enabled in the > > command word. Where "scanning" means it's doing DMA to read > > an empty async schedule ring ... a LOT of DMA, keeping your > > network controllers from their DMA. > > Hmm. DMA. Yes. I measured disk-I/O and found that it dropped from > about 24MB/s down to 2.3MB/s when ehci-hcd is loaded and active. Disks too, yes. > > This could well be the root cause of some problems other folk > > have reported. It's a "not supposed to be possible" thing. > > So... this could still be an issue with the card or mainboard > or the combination of both? I used a VT6212 for a while, found it pleasantly more robust than its VT6202 predecessor ... as in, it actually worked, and didn't need workarounds for silicon bugs! VIA controllers have been problems for various reasons, but other than the VT6202 I've been more inclined to blame most issues on differences in timings than on silicon bugs. That is, to say that the driver needs to handle those cases. In your case, "slow" PCI plus strange timings would be a fine way to shake out little timing races that other systems could mask. Back when I started that driver, I ran it on every different EHCI implementation I could find, to shake out such differences. > > The only tricky thing about turning the async schedule on or > > off is that it's done in a non-blocking way. So my guess > > would be that on some code path ASE is cleared before ASS > > gets set, or there's a similar no-no ... likely a race of some > > kind, since not every system seems to experience such problems. > > Could this eventually be caused/supported by some bad BIOS setting > concerning the PCI bus? At the level of pci 2.1 vs pci 2.3 for example? I suppose it could be; the very first EHCI cards I got from VIA (VT6202) didn't work at all on many systems ... they didn't even boot with those cards! I'd check that out, but wouldn't think that's likely to be a problem here. Your symptom seems to resemble something other systems have reported. No; track down that CMD_ASE/STS_ASS thing and I expect this problem will just vanish. - Dave ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Linux-usb-users@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
