lkml.org 
[lkml]   [2005]   [Jun]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: External USB2 HDD affects speed hda
    David Brownell wrote:

    > On Wednesday 01 June 2005 11:25 am, Rene Herman wrote:

    >> : 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?

    Right.

    > Unplugging the drive (vs just poweroff), same?

    Yes, unplugging does not make a difference.

    > One more experiment to try: with CONFIG_USB_DEBUG, have a look at
    > the relevant /sys/class/usb_host/usbN/registers file.

    [ snip ]

    > 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.

    Thanks for all the explanation. Indeed only the run bit is set here it
    seems. Here are two instances of /sys/class/usb_host/usb1/registers; the
    first one immediately after modprobe ehci_hcd, while hdparm -t /dev/hda
    still gives me 50 MB/s:

    ===
    bus pci, device 0000:00:09.2 (driver 10 Dec 2004)
    EHCI 1.00, hcd state 1
    structural params 0x00002204
    capability params 0x00006872
    status 0008 FLR
    command 010009 (park)=0 ithresh=1 period=256 RUN
    intrenable 37 IAA FATAL PCD ERR INT
    uframe 01d4
    port 1 status 001000 POWER sig=se0
    port 2 status 001000 POWER sig=se0
    port 3 status 001000 POWER sig=se0
    port 4 status 001000 POWER sig=se0
    irq normal 0 err 0 reclaim 0 (lost 0)
    complete 0 unlink 0
    ===

    and one after switching on the USB2 HDD, when the hdparm result for hda
    has dropped to 42 MB/s:

    ===
    bus pci, device 0000:00:09.2 (driver 10 Dec 2004)
    EHCI 1.00, hcd state 1
    structural params 0x00002204
    capability params 0x00006872
    status a008 Async Recl FLR
    command 010009 (park)=0 ithresh=1 period=256 RUN
    intrenable 37 IAA FATAL PCD ERR INT
    uframe 21cc
    port 1 status 001005 POWER sig=se0 PE CONNECT
    port 2 status 001000 POWER sig=se0
    port 3 status 001000 POWER sig=se0
    port 4 status 001000 POWER sig=se0
    irq normal 136 err 0 reclaim 17 (lost 0)
    complete 27 unlink 0
    ===

    Not much difference between the two but I though I'd post them both in
    case that "reclaim" number means anything to you. In any case, the
    "command" line is the same as the example one you posted so no answers
    there it seems.

    > 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.

    "Strange goings on" I can confirm at least. By the way, as seen from the
    above, the USB2 HDD is now on port1. It was on port 3, with a (Iiyama
    monitor) USB 1.1 HUB on port 1, with my mouse connected to that hub.
    After seeing you comment in the other thread that UHCI did always do DMA
    I compiled out UHCI, re-enabled my onboard OHCI controller (I have it
    disabled since I put in this controller since it takes yet another IRQ
    and seems rather superfluous) and plugged the monitor hub into that again.

    No change whatsoever unfortunately (but I guess I should keep it this
    way, EHCI and OHCI, no UHCI?)

    No change with UHCI _nor_ OHCI loaded either.

    The VT6212 is on a combo controller with a unused NEC firewire
    controller, different IRQ. Also no change between ohci1394 loaded or
    unloaded.

    Which was to be expected, but hey, I'll try anything by now...

    >>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.

    The disk is a Western Digital Essential 160G.

    > 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.

    Unfortunately I don't have a second controller available to test. Until
    recently I only had the onboard OHCI controller. Bought this one
    together with the drive. Thought I was buying a NEC one by the way; the
    information on the manufacturer's website said so, but when it arrived
    it was a "Rev. B" with the VIA VT6212L. I _really_ hope this is not some
    VIA specific crapola again...

    > 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.

    Sound scary. Must say I do generally have a lot of faith in this chipset
    (AMD751/756). The machine's been as stable as a rock for years now. A
    logic analyser I do not have, nor the ability to interpret it if I did.

    I did just now try two different PCI slots. Again no change.

    Erhhm. rmmoding ehci-hcd works. I suppose it tells the hardware to shut
    up on module_exit. is there any way to have it tell the hardware the
    same while keeping it loaded? Any other ideas?

    Thanks,
    Rene.
    -
    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/

    \
     
     \ /
      Last update: 2005-06-02 00:28    [W:4.927 / U:0.704 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site