Messages in this thread | | | From | David Brownell <> | Subject | Re: External USB2 HDD affects speed hda | Date | Wed, 1 Jun 2005 12:40:09 -0700 |
| |
On Wednesday 01 June 2005 11:25 am, Rene Herman wrote: > Pavel Machek wrote: > > On Út 31-05-05 01:21:37, Rene Herman wrote: > > [ internal IDE HDD slowdown after switching on external USB2 HDD ] > > > USB controller generating extra DMA load? Try rmmoding usb to see if > > it goes away. > > I was sceptical about this since the drive is idle (or even switched off > again) but I recompiled EHCI modular and rmmodding ehci_hcd does in fact > bring back my 50 MB/s: > > : hdparm -t /dev/hda = 50 MB/s > 1. modprobe ehci_hcd : hdparm -t /dev/hda = 50 MB/s > 2. switch on USB2 drive : hdparm -t /dev/hda = 42 MB/s > 3. switch off USB drive : hdparm -t /dev/hda = 42 MB/s > 4. modprobe -r ehci_hcd : hdparm -t /dev/hda = 50 MB/s
So it's as if the controller remembers that the drive was once turned on, and then chews up 8+ MB/sec of bus bandwidth somehow until its driver is removed -- right? Unplugging the drive (vs just poweroff), same?
One more experiment to try: with CONFIG_USB_DEBUG, have a look at the relevant /sys/class/usb_host/usbN/registers file. Here's what one looks like on one system:
bus pci, device 0000:00:02.2 (driver 10 Dec 2004) nVidia Corporation nForce2 USB Controller EHCI 1.00, hcd state 1 ownership 01000001 linux SMI sts/enable 0xe0080000 structural params 0x00102486 capability params 0x0000a086 status 0008 FLR command 010009 (park)=0 ithresh=1 period=256 RUN intrenable 37 IAA FATAL PCD ERR INT uframe 0e1e port 1 status 001000 POWER sig=se0 port 2 status 001005 POWER sig=se0 PE CONNECT port 3 status 001000 POWER sig=se0 port 4 status 001000 POWER sig=se0 port 5 status 003802 POWER OWNER sig=j CSC port 6 status 001000 POWER sig=se0 irq normal 28 err 1 reclaim 18 (lost 0) complete 29 unlink 0
So there's a USB2 disk on port 2, a full speed device on port 5, and the controller isn't doing anything much at all ... the RUN command bit is set, which means it's sending out SOF tokens on all enabled port(s). (And it's not suspended, so there's probably a clock at 48 MHz or so.) But no transactions are active -- the "periodic" and "async" schedules are empty, ditto the Periodic and Async command bits are clear -- so it should be staying away from PCI, no DMA load at all.
The experiment: verify that only the RUN bit is set on your machine too. If "Periodic" and/or "Async" bits are set, then the controller is _supposed_ to be issuing DMA transfers over PCI, so less bandwidth will be available. Otherwise, not.
> There would not seem to be any extra DMA load with a drive that's idle > or switched off again though? Is the (VIA) USB2 controller playing bus > monopolizing tricks or something sinister like that? (the speed doesn't > drop immediately after loading ehci_hcd though, only after switching on > the USB2 HDD)
VIA's EHCI has been more consistently wierd than any other vendor's implementation. The VT6202 (initial implementation) has never seemed to work right. And although the newer implementations appear to work OK with the current driver, that's largely due to workarounds that address some fairly important IRQ dropouts. I've always suspected they have strange things going on with their DMA, too; performance patterns were just too wierd to explain otherwise.
> More detail --- it's a VIA VT6212L EHCI controller, on unshared IRQ3. > IDE0 is AMD756 on unshared IRQ14/15. The USB2 HDD does 30 MB/s (after a > hdparm -a 1024; with the default 256 it's 25MB/s) which I did think was > a very good speed.
The VT6212 never showed me any problems the last time I tested with it, other than the IRQ lossage I've seen with all VIA EHCI silicon. And yes, 30 MB/sec is pretty good; not all disks, or hosts, will do that.
A more hardware-oriented experiment would be to see if a non-VIA card does the same thing ... most NEC cards won't get you that same data transfer rate (newer ones might), maybe ALI will.
The most hardware-oriented experiment is to stick a logic analyser on your PCI bus and see what's up. Maybe it's not doing DMA, but it's still arbitrating for the bus or something. And maybe the AMD PCI is fighting with the VIA PCI somehow; I seem to recall problems of that ilk from chips of that era.
- Dave
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |