ehci-hcd affects hda speed - Kernel

This is a discussion on ehci-hcd affects hda speed - Kernel ; Hi, I have recently installed a VT6212L-based PCI USB controller into my old rock-stable P3B-F computer just to discover that, even being idle, it significantly slows down main PATA hard drive. I have found an earlier thread with similar (?) ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 36

Thread: ehci-hcd affects hda speed

  1. ehci-hcd affects hda speed

    Hi,

    I have recently installed a VT6212L-based PCI USB controller into my old
    rock-stable P3B-F computer just to discover that, even being idle, it
    significantly slows down main PATA hard drive. I have found an earlier
    thread with similar (?) problem (archived at http://marc.info/?t=111749614000002&r=1&w=2 )
    but it provides no solution. Can this behaviour be explained? Can it be fixed?

    There's one thing that makes me optimistic: USB traffic _speeds_up_ hda.
    That is hdparm gives ~20% improvement in buffered reads if a USB flash is
    inserted and another xterm simultaneously runs
    # dd if=/dev/sda of=/dev/null bs=1024

    Here's what I see:

    ------------------------------------------------------------------------------
    # hdparm -t -T /dev/hda
    /dev/hda:
    Timing cached reads: 312 MB in 2.01 seconds = 155.60 MB/sec
    Timing buffered disk reads: 88 MB in 3.06 seconds = 28.77 MB/sec
    # modprobe ehci-hcd
    # hdparm -t -T /dev/hda
    /dev/hda:
    Timing cached reads: 274 MB in 2.01 seconds = 136.58 MB/sec
    Timing buffered disk reads: 44 MB in 3.10 seconds = 14.20 MB/sec
    # rmmod ehci-hcd
    # hdparm -t -T /dev/hda
    /dev/hda:
    Timing cached reads: 286 MB in 2.01 seconds = 142.48 MB/sec
    Timing buffered disk reads: 90 MB in 3.06 seconds = 29.44 MB/sec
    ------------------------------------------------------------------------------

    And here's what I have (kernel 2.6.24.3):

    ------------------------------------------------------------------------------
    #lspci -v

    00:09.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 62) (prog-if 00 [UHCI])
    Subsystem: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller
    Flags: medium devsel, IRQ 5
    I/O ports at d000 [size=32]
    Capabilities: [80] Power Management version 2

    00:09.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 62) (prog-if 00 [UHCI])
    Subsystem: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller
    Flags: medium devsel, IRQ 9
    I/O ports at b800 [size=32]
    Capabilities: [80] Power Management version 2

    00:09.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 65) (prog-if 20 [EHCI])
    Subsystem: VIA Technologies, Inc. USB 2.0
    Flags: bus master, medium devsel, latency 32, IRQ 11
    Memory at d3800000 (32-bit, non-prefetchable) [size=256]
    Capabilities: [80] Power Management version 2

    # cat /proc/interrupts
    CPU0
    0: 100814528 XT-PIC-XT timer
    1: 4057 XT-PIC-XT i8042
    2: 0 XT-PIC-XT cascade
    3: 1013 XT-PIC-XT
    4: 2 XT-PIC-XT
    5: 7165568 XT-PIC-XT bttv0, FM801, uhci_hcd:usb2, uhci_hcd:usb3
    8: 25956003 XT-PIC-XT
    9: 661413 XT-PIC-XT eth1, uhci_hcd:usb4
    10: 4 XT-PIC-XT
    11: 13526145 XT-PIC-XT eth0, ehci_hcd:usb1
    12: 1068179 XT-PIC-XT i8042
    14: 710123 XT-PIC-XT ide0
    15: 4365 XT-PIC-XT ide1
    NMI: 0 Non-maskable interrupts
    TRM: 0 Thermal event interrupts
    SPU: 0 Spurious interrupts
    ERR: 0
    ------------------------------------------------------------------------------

    Please let me know if I missed something important.

    Thanks
    -L
    --
    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/

  2. Re: ehci-hcd affects hda speed

    On 04-03-08 23:27, Lev A. Melnikovsky wrote:

    > I have recently installed a VT6212L-based PCI USB controller into my old
    > rock-stable P3B-F computer


    Uh oh...

    > just to discover that, even being idle, it significantly slows down main
    > PATA hard drive. I have found an earlier thread with similar (?) problem
    > (archived at http://marc.info/?t=111749614000002&r=1&w=2 ) but it
    > provides no solution. Can this behaviour be explained? Can it be fixed?


    Yes, that one was my same problem. It was diagnosed to the VT6212L doing
    decidedly weird things with toggling the Async bit and tying up the bus.
    People seemed reluctant to either confirm or deny my suspicion that this was
    VIA trying to shine on benchmarks while screwing you over so what exactly
    that amounts to I don't know. My own solution has consisted of replacing the
    controller with a somewhat slower but decent NEC controller and selling of
    the VIA crapware to some unsuspecting poor sod...

    > There's one thing that makes me optimistic: USB traffic _speeds_up_ hda.
    > That is hdparm gives ~20% improvement in buffered reads if a USB flash
    > is inserted and another xterm simultaneously runs
    > # dd if=/dev/sda of=/dev/null bs=1024


    Sort of interesting. I doubt something can be done about the idle thing
    though but David is the person to talk to. Leaving in the rest:

    > Here's what I see:
    >
    > ------------------------------------------------------------------------------
    >
    > # hdparm -t -T /dev/hda
    > /dev/hda:
    > Timing cached reads: 312 MB in 2.01 seconds = 155.60 MB/sec
    > Timing buffered disk reads: 88 MB in 3.06 seconds = 28.77 MB/sec
    > # modprobe ehci-hcd
    > # hdparm -t -T /dev/hda
    > /dev/hda:
    > Timing cached reads: 274 MB in 2.01 seconds = 136.58 MB/sec
    > Timing buffered disk reads: 44 MB in 3.10 seconds = 14.20 MB/sec
    > # rmmod ehci-hcd
    > # hdparm -t -T /dev/hda
    > /dev/hda:
    > Timing cached reads: 286 MB in 2.01 seconds = 142.48 MB/sec
    > Timing buffered disk reads: 90 MB in 3.06 seconds = 29.44 MB/sec
    > ------------------------------------------------------------------------------
    >
    >
    > And here's what I have (kernel 2.6.24.3):
    >
    > ------------------------------------------------------------------------------
    >
    > #lspci -v
    >
    > 00:09.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
    > Controller (rev 62) (prog-if 00 [UHCI])
    > Subsystem: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller
    > Flags: medium devsel, IRQ 5
    > I/O ports at d000 [size=32]
    > Capabilities: [80] Power Management version 2
    >
    > 00:09.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
    > Controller (rev 62) (prog-if 00 [UHCI])
    > Subsystem: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller
    > Flags: medium devsel, IRQ 9
    > I/O ports at b800 [size=32]
    > Capabilities: [80] Power Management version 2
    >
    > 00:09.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 65) (prog-if
    > 20 [EHCI])
    > Subsystem: VIA Technologies, Inc. USB 2.0
    > Flags: bus master, medium devsel, latency 32, IRQ 11
    > Memory at d3800000 (32-bit, non-prefetchable) [size=256]
    > Capabilities: [80] Power Management version 2
    >
    > # cat /proc/interrupts
    > CPU0
    > 0: 100814528 XT-PIC-XT timer
    > 1: 4057 XT-PIC-XT i8042
    > 2: 0 XT-PIC-XT cascade
    > 3: 1013 XT-PIC-XT
    > 4: 2 XT-PIC-XT
    > 5: 7165568 XT-PIC-XT bttv0, FM801, uhci_hcd:usb2,
    > uhci_hcd:usb3
    > 8: 25956003 XT-PIC-XT
    > 9: 661413 XT-PIC-XT eth1, uhci_hcd:usb4
    > 10: 4 XT-PIC-XT
    > 11: 13526145 XT-PIC-XT eth0, ehci_hcd:usb1
    > 12: 1068179 XT-PIC-XT i8042
    > 14: 710123 XT-PIC-XT ide0
    > 15: 4365 XT-PIC-XT ide1
    > NMI: 0 Non-maskable interrupts
    > TRM: 0 Thermal event interrupts
    > SPU: 0 Spurious interrupts
    > ERR: 0
    > ------------------------------------------------------------------------------
    >
    >
    > Please let me know if I missed something important.


    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/

  3. Re: ehci-hcd affects hda speed

    On Wed, Mar 5, 2008 at 5:19 PM, Rene Herman wrote:
    > On 04-03-08 23:27, Lev A. Melnikovsky wrote:
    >
    > > I have recently installed a VT6212L-based PCI USB controller into my old
    > > rock-stable P3B-F computer

    >
    > Uh oh...
    >
    > > just to discover that, even being idle, it significantly slows down main
    > > PATA hard drive. I have found an earlier thread with similar (?) problem
    > > (archived at http://marc.info/?t=111749614000002&r=1&w=2 ) but it
    > > provides no solution. Can this behaviour be explained? Can it be fixed?

    >
    > Yes, that one was my same problem. It was diagnosed to the VT6212L doing
    > decidedly weird things with toggling the Async bit and tying up the bus.
    > People seemed reluctant to either confirm or deny my suspicion that this was
    > VIA trying to shine on benchmarks while screwing you over so what exactly
    > that amounts to I don't know. My own solution has consisted of replacing the
    > controller with a somewhat slower but decent NEC controller and selling of
    > the VIA crapware to some unsuspecting poor sod...
    >
    > > There's one thing that makes me optimistic: USB traffic _speeds_up_ hda.
    > > That is hdparm gives ~20% improvement in buffered reads if a USB flash
    > > is inserted and another xterm simultaneously runs
    > > # dd if=/dev/sda of=/dev/null bs=1024

    >
    > Sort of interesting. I doubt something can be done about the idle thing
    > though but David is the person to talk to. Leaving in the rest:
    >
    > > Here's what I see:
    > >
    > > ------------------------------------------------------------------------------
    > >
    > > # hdparm -t -T /dev/hda
    > > /dev/hda:
    > > Timing cached reads: 312 MB in 2.01 seconds = 155.60 MB/sec
    > > Timing buffered disk reads: 88 MB in 3.06 seconds = 28.77 MB/sec
    > > # modprobe ehci-hcd
    > > # hdparm -t -T /dev/hda
    > > /dev/hda:
    > > Timing cached reads: 274 MB in 2.01 seconds = 136.58 MB/sec
    > > Timing buffered disk reads: 44 MB in 3.10 seconds = 14.20 MB/sec
    > > # rmmod ehci-hcd
    > > # hdparm -t -T /dev/hda
    > > /dev/hda:
    > > Timing cached reads: 286 MB in 2.01 seconds = 142.48 MB/sec
    > > Timing buffered disk reads: 90 MB in 3.06 seconds = 29.44 MB/sec
    > > ------------------------------------------------------------------------------
    > >
    > >
    > > And here's what I have (kernel 2.6.24.3):
    > >
    > > ------------------------------------------------------------------------------
    > >
    > > #lspci -v
    > >
    > > 00:09.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
    > > Controller (rev 62) (prog-if 00 [UHCI])
    > > Subsystem: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller
    > > Flags: medium devsel, IRQ 5
    > > I/O ports at d000 [size=32]
    > > Capabilities: [80] Power Management version 2
    > >
    > > 00:09.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
    > > Controller (rev 62) (prog-if 00 [UHCI])
    > > Subsystem: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller
    > > Flags: medium devsel, IRQ 9
    > > I/O ports at b800 [size=32]
    > > Capabilities: [80] Power Management version 2
    > >
    > > 00:09.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 65) (prog-if
    > > 20 [EHCI])
    > > Subsystem: VIA Technologies, Inc. USB 2.0
    > > Flags: bus master, medium devsel, latency 32, IRQ 11
    > > Memory at d3800000 (32-bit, non-prefetchable) [size=256]
    > > Capabilities: [80] Power Management version 2
    > >
    > > # cat /proc/interrupts
    > > CPU0
    > > 0: 100814528 XT-PIC-XT timer
    > > 1: 4057 XT-PIC-XT i8042
    > > 2: 0 XT-PIC-XT cascade
    > > 3: 1013 XT-PIC-XT
    > > 4: 2 XT-PIC-XT
    > > 5: 7165568 XT-PIC-XT bttv0, FM801, uhci_hcd:usb2,
    > > uhci_hcd:usb3
    > > 8: 25956003 XT-PIC-XT
    > > 9: 661413 XT-PIC-XT eth1, uhci_hcd:usb4
    > > 10: 4 XT-PIC-XT
    > > 11: 13526145 XT-PIC-XT eth0, ehci_hcd:usb1
    > > 12: 1068179 XT-PIC-XT i8042
    > > 14: 710123 XT-PIC-XT ide0
    > > 15: 4365 XT-PIC-XT ide1
    > > NMI: 0 Non-maskable interrupts
    > > TRM: 0 Thermal event interrupts
    > > SPU: 0 Spurious interrupts
    > > ERR: 0
    > > ------------------------------------------------------------------------------
    > >
    > >
    > > Please let me know if I missed something important.

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


    I reported this problem well over an year ago, and it was never fixed.

    http://lkml.org/lkml/2006/10/29/81

    That old K7-800 is still serving as my bittorrent 24x7 box, now
    under the last FC6 kernel released. I plan to upgrade it to
    Fedora 9 once it's out, and it would be great if a fix to this bug
    could be found...

    --alessandro

    "We act as though comfort and luxury were the chief requirements
    of life, when all that we need to make us really happy is
    something to be enthusiastic about."

    (Charles Kingsley)
    --
    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/

  4. Re: ehci-hcd affects hda speed

    On Wednesday 05 March 2008, Alessandro Suardi wrote:
    > I reported this problem well over an year ago, and it was never fixed.


    Yeah, nobody who can debug the problem has hardware that ill-behaved.

    It'd be great if someone could chase this down.

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

  5. Re: ehci-hcd affects hda speed

    On Wed, Mar 5, 2008 at 10:03 PM, David Brownell wrote:
    > On Wednesday 05 March 2008, Alessandro Suardi wrote:
    > > I reported this problem well over an year ago, and it was never fixed.

    >
    > Yeah, nobody who can debug the problem has hardware that ill-behaved.


    Heh but the box is doing fine, uptime in triple digits, bittorrenting away
    without any issue since I replaced a faulty RAM stick many moons ago...

    > It'd be great if someone could chase this down.


    I'm always available to test patches - but I don't have the skill and
    knowledge to understand this much

    --alessandro

    "We act as though comfort and luxury were the chief requirements
    of life, when all that we need to make us really happy is
    something to be enthusiastic about."

    (Charles Kingsley)
    --
    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/

  6. Re: ehci-hcd affects hda speed

    David,

    On Wed, 5 Mar 2008 at 1:03pm, David Brownell wrote:

    DB> Yeah, nobody who can debug the problem has hardware that ill-behaved.
    DB> It'd be great if someone could chase this down.
    Well, you are right. I do understand how electrons travel through the slot
    lead, I can even read/write in C/assembly but I have no idea how PCI nor
    USB buses work. To say truth, I don't really care. If they do, that is...
    But I can type whatever you ask and can report what I see. Do you need a
    monkey? Try us :-)

    -L
    --
    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/

  7. Re: ehci-hcd affects hda speed

    ....meanwhile, I have tried to change (as suggested in another thread) the
    timeout value in the following line:

    (void)handshake(ehci, &ehci->regs->status, STS_ASS, 0, 1500);

    Makes no difference. Neither introducing additional delays to provide
    safety margins at several other loci helped a bit. Any idea what to try
    next?

    Also, does anyone have a VT6212L datasheet? Unfortunately, Google haven't
    found it for me.

    Thanks
    -L
    --
    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/

  8. Re: ehci-hcd affects hda speed


    LAM> Also, does anyone have a VT6212L datasheet? Unfortunately, Google
    I have eventually found it. An enlightening reading, really. If I
    understood all words, I mean :-). Particularly, what does "MAC turn around
    time" stand for with respect to EHCI? I would appreciate some reference,
    thanks.

    On Wed, 5 Mar 2008 at 5:19pm, Rene Herman wrote:

    RH> It was diagnosed to the VT6212L doing decidedly weird things with
    RH> toggling the Async bit and tying up the bus.
    Yes, it really looks like the chip owns the bus when it shouldn't. Suppose
    VT6212L has damaged its brains somehow. Can we fix this by ignoring its
    requests unless they are legitimate? I mean make the driver enable bus
    mastering only for short periods when the controller is expected to do
    something useful. It is easy (I have already done myself) to implement for
    asynchronous schedule, but there's still periodic schedule. Is it
    possible? How? Please advise.

    Being positive, I didn't have much time to play with it yet, but changing
    the bit 5 (EHCI sleep time select: 0=1us 1=10us) of register 0x4B seems
    to resolve my own problem. I wonder if this is going to help others
    (Alessandro?):

    setpci -s 00:09.2 4b.b=29

    [don't forget to adjust the device address].

    -L
    --
    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/

  9. Re: ehci-hcd affects hda speed

    On Sat, Mar 15, 2008 at 11:46 PM, Lev A. Melnikovsky
    wrote:
    >
    > LAM> Also, does anyone have a VT6212L datasheet? Unfortunately, Google
    > I have eventually found it. An enlightening reading, really. If I
    > understood all words, I mean :-). Particularly, what does "MAC turn around
    > time" stand for with respect to EHCI? I would appreciate some reference,
    > thanks.
    >
    > On Wed, 5 Mar 2008 at 5:19pm, Rene Herman wrote:
    >
    > RH> It was diagnosed to the VT6212L doing decidedly weird things with
    > RH> toggling the Async bit and tying up the bus.
    > Yes, it really looks like the chip owns the bus when it shouldn't. Suppose
    > VT6212L has damaged its brains somehow. Can we fix this by ignoring its
    > requests unless they are legitimate? I mean make the driver enable bus
    > mastering only for short periods when the controller is expected to do
    > something useful. It is easy (I have already done myself) to implement for
    > asynchronous schedule, but there's still periodic schedule. Is it
    > possible? How? Please advise.
    >
    > Being positive, I didn't have much time to play with it yet, but changing
    > the bit 5 (EHCI sleep time select: 0=1us 1=10us) of register 0x4B seems
    > to resolve my own problem. I wonder if this is going to help others
    > (Alessandro?):
    >
    > setpci -s 00:09.2 4b.b=29
    >
    > [don't forget to adjust the device address].


    00:09.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 63)

    heh, I don't even have to...

    [root@donkey ~]# hdparm -t /dev/hda

    /dev/hda:
    Timing buffered disk reads: 54 MB in 3.03 seconds = 17.83 MB/sec
    [root@donkey ~]# setpci -s 00:09.2 4b.b=29
    [root@donkey ~]# hdparm -t /dev/hda

    /dev/hda:
    Timing buffered disk reads: 78 MB in 3.06 seconds = 25.53 MB/sec

    Well, that does look much better. Not on par with the non-EHCI case,
    but way better ! Thanks a lot !

    Of course if you wish me to run anything else, just say so

    --alessandro

    "We act as though comfort and luxury were the chief requirements
    of life, when all that we need to make us really happy is
    something to be enthusiastic about."

    (Charles Kingsley)
    --
    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/

  10. Re: ehci-hcd affects hda speed

    On Saturday 15 March 2008, Lev A. Melnikovsky wrote:
    > Particularly, what does "MAC turn around
    > time" stand for with respect to EHCI? I would appreciate some reference,
    > thanks.


    Blame VIA for that one. Notice how their descriptions of the
    fields in that register don't even mention a MAC.

    But the relevant bit is the "sleep time" and that's described
    in the EHCI specification. It basically means how long it waits,
    after noticing a "no work for me" async schedule ring, before
    scanning that schedule again. It seems your system had that
    set to just 1 usec, meaning it would hardly give anything else
    a chance to get onto the PCI bus. That's probably why the EHCI
    spec uses a value of 10 usec: basic fairness.

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

  11. Re: ehci-hcd affects hda speed

    On 17-03-08 22:00, David Brownell wrote:

    >> On 15-03-08 23:46, Lev A. Melnikovsky wrote:
    >>
    >>> changing the bit 5 (EHCI sleep time select: 0=1us 1=10us)
    >>> of register 0x4B seems to resolve my own problem.

    >
    > Note that 10 usec is the value used in the EHCI spec.
    >
    > And yes, waiting only 1 usec between schedule scans is
    > absolutely certain to hammer on the PCI bus quite rudely,
    > preventing other devices from getting Real Work done.
    >
    > Could someone put together an EHCI patch to make sure
    > that bit is set on vt6212 parts? For the VT8235 that
    > register seems to be marked (in an old document someone
    > forwarded to me) as "reserved, do not program"; so this
    > should be specific to vt6212 EHCI. (PCI vendor 0x1106,
    > device 0x3104, revision 0x60 ... the revision being what
    > says "vt6212" vs "vt8235" or "vt8237" etc.


    Just something like this? Completely untested as I've not the hardware
    anymore. Googling for an old lspci, I had a revision 0x63, and Lev has a
    revision 0x65. The VT6212(L) should be 0x60+ it seems.

    The "CC:" should be a "Tested-by:" if that's actually the case.

    But yes, as he also asked, should this be the fix at all?

    Rene.

    commit fb221b24a314069af26db8c9beb6c843efcafa38
    Author: Rene Herman
    Date: Tue Mar 18 00:02:16 2008 +0100

    USB: VIA VT6212 10us EHCI sleep time select

    The VIA VT6212 uses a 1us EHCI sleep time by default which
    hammers the PCI bus bad. Use the 10us spec value instead
    as suggested by Lev A. Melnikovsky.

    CC: Lev A. Melnikovsky
    Signed-off-by: Rene Herman

    diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c
    index 3ba0166..35a6ccb 100644
    --- a/drivers/usb/host/ehci-pci.c
    +++ b/drivers/usb/host/ehci-pci.c
    @@ -152,6 +152,15 @@ static int ehci_pci_setup(struct usb_hcd *hcd)
    break;
    }
    break;
    + case PCI_VENDOR_ID_VIA:
    + if (pdev->device == 0x3104 && pdev->revision >= 0x60) {
    + u8 tmp;
    +
    + /* VT6212: EHCI sleep time 10us (default 1) */
    + pci_read_config_byte(pdev, 0x4b, &tmp);
    + pci_write_config_byte(pdev, 0x4b, tmp | 0x20);
    + }
    + break;
    }

    ehci_reset(ehci);


  12. Re: ehci-hcd affects hda speed

    On 18-03-08 00:23, Rene Herman wrote:

    > On 17-03-08 22:00, David Brownell wrote:
    >
    >>> On 15-03-08 23:46, Lev A. Melnikovsky wrote:
    >>>
    >>>> changing the bit 5 (EHCI sleep time select: 0=1us 1=10us)
    >>>> of register 0x4B seems to resolve my own problem.

    >>
    >> Note that 10 usec is the value used in the EHCI spec.
    >>
    >> And yes, waiting only 1 usec between schedule scans is
    >> absolutely certain to hammer on the PCI bus quite rudely,
    >> preventing other devices from getting Real Work done.
    >>
    >> Could someone put together an EHCI patch to make sure
    >> that bit is set on vt6212 parts? For the VT8235 that
    >> register seems to be marked (in an old document someone
    >> forwarded to me) as "reserved, do not program"; so this
    >> should be specific to vt6212 EHCI. (PCI vendor 0x1106,
    >> device 0x3104, revision 0x60 ... the revision being what
    >> says "vt6212" vs "vt8235" or "vt8237" etc.

    >
    > Just something like this? Completely untested as I've not the hardware
    > anymore. Googling for an old lspci, I had a revision 0x63, and Lev has a
    > revision 0x65. The VT6212(L) should be 0x60+ it seems.
    >
    > The "CC:" should be a "Tested-by:" if that's actually the case.
    >
    > But yes, as he also asked, should this be the fix at all?


    And, as usual, I can not reach Lev as some mailer along the way is telling
    me his address is unroutable.

    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/

  13. Re: ehci-hcd affects hda speed

    On Monday 17 March 2008, Rene Herman wrote:
    > +*******case PCI_VENDOR_ID_VIA:
    > +***************if (pdev->device == 0x3104 && pdev->revision >= 0x60) {


    Unless you have specific docs from VIA saying that this register
    isn't revision-specific (at least in the sense that all revisions
    after 0x60 define that bit in that way), this should probably be a
    switch on pdev->revision and just include the known-safe revisions.

    At one point I had a table mapping those revision codes to
    specific VIA chips. Too bad I didn't keep it. ISTR that the
    VT6212 has a newer revision code than the vt8235 southbridge,
    and probably not as new as the vt8237 one...

    But otherwise, yes -- that's the kind of patch I'd sign off on
    after making this comment a bit more informative about how
    that 1 usec sleep time creates an amount of PCI bus hogging.


    > +***********************u8 tmp;
    > +
    > +***********************/* VT6212: EHCI sleep time 10us (default 1) */
    > +***********************pci_read_config_byte(pdev, 0x4b, &tmp);
    > +***********************pci_write_config_byte(pdev , 0x4b, tmp | 0x20);
    > +***************}
    > +***************break;



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

  14. Re: ehci-hcd affects hda speed


    On Mon, 17 Mar 2008 at 11:26pm, Rene Herman wrote:

    RH> And, as usual, I can not reach Lev as some mailer along the way is
    RH> telling me his address is unroutable.
    I'm here, don't worry :-)

    On Mon, 17 Mar 2008 at 4:00pm, David Brownell wrote:

    DB> On Monday 17 March 2008, Rene Herman wrote:
    DB> > +šššššššcase PCI_VENDOR_ID_VIA:
    DB> > +šššššššššššššššif (pdev->device == 0x3104 && pdev->revision >= 0x60) {
    DB> Unless you have specific docs from VIA saying that this register
    DB> isn't revision-specific (at least in the sense that all revisions
    DB> after 0x60 define that bit in that way), this should probably be a
    DB> switch on pdev->revision and just include the known-safe revisions.
    May I suggest this should be a module parameter? Because a side effect is
    a USB slow-down, which may be more important for somebody...

    -L
    --
    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/

  15. Re: ehci-hcd affects hda speed

    On 18-03-08 01:24, Lev A. Melnikovsky wrote:

    > DB> On Monday 17 March 2008, Rene Herman wrote:
    > DB> > + case PCI_VENDOR_ID_VIA:
    > DB> > + if (pdev->device == 0x3104 && pdev->revision >= 0x60) {
    > DB> Unless you have specific docs from VIA saying that this register
    > DB> isn't revision-specific (at least in the sense that all revisions
    > DB> after 0x60 define that bit in that way), this should probably be a
    > DB> switch on pdev->revision and just include the known-safe revisions.
    > May I suggest this should be a module parameter? Because a side effect is
    > a USB slow-down, which may be more important for somebody...


    If the 10us is a EHCI specification, I'd personally think not. But if need
    be...

    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/

  16. Re: ehci-hcd affects hda speed

    On 18-03-08 01:00, David Brownell wrote:

    > On Monday 17 March 2008, Rene Herman wrote:
    >> + case PCI_VENDOR_ID_VIA:
    >> + if (pdev->device == 0x3104 && pdev->revision >= 0x60) {

    >
    > Unless you have specific docs from VIA saying that this register
    > isn't revision-specific (at least in the sense that all revisions
    > after 0x60 define that bit in that way), this should probably be a
    > switch on pdev->revision and just include the known-safe revisions.


    I'm looking at a VIA datasheet which says the revision ID for the "VT6212 /
    VT6212L PCI USB2.0 Controller" is simply 0x60. The VT61212L I myself owned
    advertised a revision ID of 0x63 and Lev's VT6212L advertises 0x65.

    The thing is -- you don't necesarily immediately notice this problem. I
    noticed it earlier on an old system, as did Lev, but even if on a modern
    system you may not immediately see an IDE throughput drop, you may still
    have a sucky system.

    With 0x60 documented and 0x63 and 0x65 confirmed as VT6212L, I'd personally
    still go with >= 0x60 and assume either backwards-compatibility or a "don't
    care" definition if some later revision were to not define this hack.

    > At one point I had a table mapping those revision codes to
    > specific VIA chips. Too bad I didn't keep it. ISTR that the
    > VT6212 has a newer revision code than the vt8235 southbridge,
    > and probably not as new as the vt8237 one...


    Some googling seems to indicate that:

    VT6202 = 0x5x (0x50, 0x51 at least)
    VT6212 = 0x6x (0x60, 0x61, 0x63, 0x65 at least)
    VT8235 = 0x82
    VT8237 = 0x86
    VT*800 = 0x90 (KM800Pro, VN800, K8N800, ...)

    Do you want one with 0x6x? I feel it's very likely that everyone on anything
    later will then still have a sucky system. Tons of people with VT8235/VT8237
    around (although not me). Any quick test available for them?

    > But otherwise, yes -- that's the kind of patch I'd sign off on
    > after making this comment a bit more informative about how
    > that 1 usec sleep time creates an amount of PCI bus hogging.


    Version with 0x6x and the somewhat more expansive comment. I'd like to be
    able to test VT8235/VT8237 first though...

    Still totally untested ofcourse.

    Rene

    commit fd96c2b26339f21a66504cb3f36579bb312a8f3b
    Author: Rene Herman
    Date: Tue Mar 18 00:02:16 2008 +0100

    USB: VIA VT6212(L) 10us EHCI sleep time select.

    The VIA VT6212(L) uses a 1us EHCI sleep time by default which hogs
    the bus bad. Use the 10us EHCI spec value instead as suggested by
    Lev A. Melnikovsky.

    CC: Lev A. Melnikovsky
    Signed-off-by: Rene Herman

    diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c
    index 3ba0166..bdc8af9 100644
    --- a/drivers/usb/host/ehci-pci.c
    +++ b/drivers/usb/host/ehci-pci.c
    @@ -152,6 +152,20 @@ static int ehci_pci_setup(struct usb_hcd *hcd)
    break;
    }
    break;
    + case PCI_VENDOR_ID_VIA:
    + if (pdev->device == 0x3104 && (pdev->revision & 0xf0) == 0x60) {
    + u8 tmp;
    + /*
    + * The VT6212 defaults to a 1us EHCI sleep time which
    + * hogs the bus badly. Setting bit 5 of 0x4B sets the
    + * sleep time to the EHCI standard 10us.
    + */
    + pci_read_config_byte(pdev, 0x4b, &tmp);
    + if (tmp & 0x20)
    + break;
    + pci_write_config_byte(pdev, 0x4b, tmp | 0x20);
    + }
    + break;
    }

    ehci_reset(ehci);


  17. Re: ehci-hcd affects hda speed

    On Monday 17 March 2008, Rene Herman wrote:
    > On 18-03-08 01:24, Lev A. Melnikovsky wrote:
    >
    > > DB> On Monday 17 March 2008, Rene Herman wrote:
    > > DB> > + case PCI_VENDOR_ID_VIA:
    > > DB> > + if (pdev->device == 0x3104 && pdev->revision >= 0x60) {
    > >
    > > DB> Unless you have specific docs from VIA saying that this register
    > > DB> isn't revision-specific (at least in the sense that all revisions
    > > DB> after 0x60 define that bit in that way), this should probably be a
    > > DB> switch on pdev->revision and just include the known-safe revisions.

    >
    > > May I suggest this should be a module parameter? Because a side effect is
    > > a USB slow-down, which may be more important for somebody...

    >
    > If the 10us is a EHCI specification, I'd personally think not. But if need
    > be...


    It's not exactly a specification, but it's what they use as an
    example of a "reasonable" value. I think pretty much everyone
    except VIA uses it as-is. Since 1 usec is such a broken value,
    I see no reason to support anything except 10 usec.

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

  18. Re: ehci-hcd affects hda speed

    On Monday 17 March 2008, Rene Herman wrote:
    > On 18-03-08 01:00, David Brownell wrote:
    >
    > > On Monday 17 March 2008, Rene Herman wrote:
    > >> + case PCI_VENDOR_ID_VIA:
    > >> + if (pdev->device == 0x3104 && pdev->revision >= 0x60) {

    > >
    > > Unless you have specific docs from VIA saying that this register
    > > isn't revision-specific (at least in the sense that all revisions
    > > after 0x60 define that bit in that way), this should probably be a
    > > switch on pdev->revision and just include the known-safe revisions.

    >
    > I'm looking at a VIA datasheet which says the revision ID for the "VT6212 /
    > VT6212L PCI USB2.0 Controller" is simply 0x60. The VT61212L I myself owned
    > advertised a revision ID of 0x63 and Lev's VT6212L advertises 0x65.


    Probably the same one I saw, from that URL.


    > The thing is -- you don't necesarily immediately notice this problem. I
    > noticed it earlier on an old system, as did Lev, but even if on a modern
    > system you may not immediately see an IDE throughput drop, you may still
    > have a sucky system.


    True, and bothersome. All VIA would have to do is adopt a design
    and production methodology different than they've used for many
    years now, and this problem wouldn't appear.


    > With 0x60 documented and 0x63 and 0x65 confirmed as VT6212L, I'd personally
    > still go with >= 0x60 and assume either backwards-compatibility or a "don't
    > care" definition if some later revision were to not define this hack.


    No ... see below:


    > > At one point I had a table mapping those revision codes to
    > > specific VIA chips. Too bad I didn't keep it. ISTR that the
    > > VT6212 has a newer revision code than the vt8235 southbridge,
    > > and probably not as new as the vt8237 one...

    >
    > Some googling seems to indicate that:


    .... I was wrong about the vt8235 preceding the vt6212 then!


    > VT6202 = 0x5x (0x50, 0x51 at least)
    > VT6212 = 0x6x (0x60, 0x61, 0x63, 0x65 at least)
    > VT8235 = 0x82
    > VT8237 = 0x86
    > VT*800 = 0x90 (KM800Pro, VN800, K8N800, ...)
    >
    > Do you want one with 0x6x?


    I'd take that. Thing is, someone sent me a vt8235 datasheet
    which explicitly says "do not write that register", which
    makes the ">= 0x60" test a lose.


    > I feel it's very likely that everyone on anything
    > later will then still have a sucky system. Tons of people with VT8235/VT8237
    > around (although not me). Any quick test available for them?


    They could try the "setpci" thing you used ... but even if
    that works, I'd really want to avoid writing into registers
    where the docs say "do not write". Unless VIA comes out and
    says "just kidding!" ...


    > > But otherwise, yes -- that's the kind of patch I'd sign off on
    > > after making this comment a bit more informative about how
    > > that 1 usec sleep time creates an amount of PCI bus hogging.

    >
    > Version with 0x6x and the somewhat more expansive comment. I'd like to be
    > able to test VT8235/VT8237 first though...


    OK, I'll leave this in my mailbox for a few days waiting more
    testing results, and if nothing goes wrong I'll send it along
    for a post-2.6.25 merge.

    Thanks!

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

  19. Re: ehci-hcd affects hda speed

    On 18-03-08 02:55, David Brownell wrote:

    > On Monday 17 March 2008, Rene Herman wrote:


    >> The thing is -- you don't necesarily immediately notice this problem. I
    >> noticed it earlier on an old system, as did Lev, but even if on a modern
    >> system you may not immediately see an IDE throughput drop, you may still
    >> have a sucky system.

    >
    > True, and bothersome. All VIA would have to do is adopt a design
    > and production methodology different than they've used for many
    > years now, and this problem wouldn't appear.


    I just concluded that buying anything with the word VIA on it is a
    spectacularly bad idea.

    >> Do you want one with 0x6x?

    >
    > I'd take that. Thing is, someone sent me a vt8235 datasheet
    > which explicitly says "do not write that register", which
    > makes the ">= 0x60" test a lose.


    Ah yes, if it's explicit, never mind the VT8235/37 thing then.

    >> Version with 0x6x and the somewhat more expansive comment. I'd like to be
    >> able to test VT8235/VT8237 first though...

    >
    > OK, I'll leave this in my mailbox for a few days waiting more
    > testing results, and if nothing goes wrong I'll send it along
    > for a post-2.6.25 merge.


    It'll mean that the problem will be much less visible and as such you might
    not get (as) many new testers anymore to get to the root problem so if one
    of the current reporters can test somewhat freely, this would probably be
    the time...

    But I'll just stick with my NEC controller now and consider myself not
    interested anymore :-)

    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/

  20. Re: ehci-hcd affects hda speed

    On 18-03-08 23:02, Alessandro Suardi wrote:

    > Works for me on top of 2.6.25-rc6-git2 Thanks folks !
    >
    > Tested-by: Alessandro Suardi
    >
    > (going to mention the patch in my Fedora bugzilla entry)


    Thanks much for testing.

    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/

+ Reply to Thread
Page 1 of 2 1 2 LastLast