ehci-hcd affects hda speed - Kernel

This is a discussion on ehci-hcd affects hda speed - Kernel ; Hi, again Just in case - I do have an A7V8X-based PC in the office and have performed a simple experiment. #1. Idle USB controller has no effect on PCI performance (I again measured hda throughput). #2. Default value for ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 36 of 36

Thread: ehci-hcd affects hda speed

  1. Re: ehci-hcd affects hda speed

    Hi, again

    Just in case - I do have an A7V8X-based PC in the office and have
    performed a simple experiment.

    #1. Idle USB controller has no effect on PCI performance (I again
    measured hda throughput).

    #2. Default value for register 4Bh is 09h.

    #3. I have detected no effect of changing [4Bh]=29h. Particularly, USB
    FLASH read speed is ~8MB/s and hda read speed is ~40MB/s regardless of
    [4Bh] content. During hda timing, "dd if=/dev/sda of=/dev/null bs=1024"
    was running in another window (/dev/sda being the USB stick).

    My interpretation, is that bit5 at offset 4B may _not_ be an "EHCI sleep
    time select" like it is for VT6212. Am I missing something?

    Here's lspci output for the reference:

    # lspci -vv
    00:00.0 Host bridge: VIA Technologies, Inc. VT8377 [KT400/KT600 AGP] Host Bridge
    Subsystem: ASUSTeK Computer Inc. A7V8X motherboard
    Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
    Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Latency: 0
    Region 0: Memory at f0000000 (32-bit, prefetchable) [size=128M]
    Capabilities: [80] AGP version 3.5
    Status: RQ=32 Iso- ArqSz=0 Cal=2 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3+ Rate=x4,x8
    Command: RQ=32 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- Rate=
    Capabilities: [c0] Power Management version 2
    Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
    Status: D0 PME-Enable- DSel=0 DScale=0 PME-

    00:01.0 PCI bridge: VIA Technologies, Inc. VT8235 PCI Bridge (prog-if 00 [Normal decode])
    Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
    Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Latency: 0
    Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
    Memory behind bridge: e6000000-e7dfffff
    Prefetchable memory behind bridge: e7f00000-efffffff
    Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- BridgeCtl: Parity- SERR- NoISA- VGA+ MAbort- >Reset- FastB2B-
    PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
    Capabilities: [80] Power Management version 2
    Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
    Status: D0 PME-Enable- DSel=0 DScale=0 PME-
    ....

    00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80) (prog-if 00 [UHCI])
    Subsystem: ASUSTeK Computer Inc. VT6202 USB2.0 4 port controller
    Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Latency: 32, Cache Line Size: 32 bytes
    Interrupt: pin A routed to IRQ 17
    Region 4: I/O ports at d800 [size=32]
    Capabilities: [80] Power Management version 2
    Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
    Status: D0 PME-Enable- DSel=0 DScale=0 PME-

    00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80) (prog-if 00 [UHCI])
    Subsystem: ASUSTeK Computer Inc. VT6202 USB2.0 4 port controller
    Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Latency: 32, Cache Line Size: 32 bytes
    Interrupt: pin B routed to IRQ 17
    Region 4: I/O ports at d400 [size=32]
    Capabilities: [80] Power Management version 2
    Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
    Status: D0 PME-Enable- DSel=0 DScale=0 PME-

    00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80) (prog-if 00 [UHCI])
    Subsystem: ASUSTeK Computer Inc. VT6202 USB2.0 4 port controller
    Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Latency: 32, Cache Line Size: 32 bytes
    Interrupt: pin C routed to IRQ 17
    Region 4: I/O ports at d000 [size=32]
    Capabilities: [80] Power Management version 2
    Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
    Status: D0 PME-Enable- DSel=0 DScale=0 PME-

    00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82) (prog-if 20 [EHCI])
    Subsystem: ASUSTeK Computer Inc. A7V8X motherboard
    Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Latency: 32, Cache Line Size: 64 bytes
    Interrupt: pin D routed to IRQ 17
    Region 0: Memory at e5000000 (32-bit, non-prefetchable) [size=256]
    Capabilities: [80] Power Management version 2
    Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
    Status: D0 PME-Enable- DSel=0 DScale=0 PME+


    DB> > I'm looking at a VIA datasheet which says the revision ID for the "VT6212 /
    DB> > VT6212L PCI USB2.0 Controller" is simply 0x60. The VT61212L I myself owned
    The same file here.

    DB> > advertised a revision ID of 0x63 and Lev's VT6212L advertises 0x65.
    Yes, it does. And UHCI part has rev.ID=0x62.

    HTH
    -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 20-03-08 00:47, Lev A. Melnikovsky wrote:

    > Just in case - I do have an A7V8X-based PC in the office and have
    > performed a simple experiment.
    >
    > #1. Idle USB controller has no effect on PCI performance (I again
    > measured hda throughput).
    >
    > #2. Default value for register 4Bh is 09h.
    >
    > #3. I have detected no effect of changing [4Bh]=29h. Particularly, USB
    > FLASH read speed is ~8MB/s and hda read speed is ~40MB/s regardless of
    > [4Bh] content. During hda timing, "dd if=/dev/sda of=/dev/null bs=1024"
    > was running in another window (/dev/sda being the USB stick).
    >
    > My interpretation, is that bit5 at offset 4B may _not_ be an "EHCI sleep
    > time select" like it is for VT6212. Am I missing something?


    No, very useful test, thanks much. Patch as submitted for revision 0x6x will
    stand then.

    I do wonder -- is your hda throughput also the same before _ever_ attaching
    anything to the EHCI controller and after? In my case, the slow down only
    happened after switching on my external USB drive once, and would persist
    from that time until reboot (or unloading ehci-hcd, which I kept modular for
    exactly that reason).

    The sleep time wasn't the core problem, so I wonder of later VIA chips do
    still have the active async schedule problem...

    Alessandro? You said there still was a difference for you between no EHCI at
    all and EHCI after tweaking 4B as Lev showed. How much?

    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 Tue, Mar 18, 2008 at 2:23 AM, 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.
    >
    > 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);


    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)

    --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 Thu, Mar 20, 2008 at 1:31 AM, Rene Herman wrote:
    > On 20-03-08 00:47, Lev A. Melnikovsky wrote:
    >
    > > Just in case - I do have an A7V8X-based PC in the office and have
    > > performed a simple experiment.
    > >
    > > #1. Idle USB controller has no effect on PCI performance (I again
    > > measured hda throughput).
    > >
    > > #2. Default value for register 4Bh is 09h.
    > >
    > > #3. I have detected no effect of changing [4Bh]=29h. Particularly, USB
    > > FLASH read speed is ~8MB/s and hda read speed is ~40MB/s regardless of
    > > [4Bh] content. During hda timing, "dd if=/dev/sda of=/dev/null bs=1024"
    > > was running in another window (/dev/sda being the USB stick).
    > >
    > > My interpretation, is that bit5 at offset 4B may _not_ be an "EHCI sleep
    > > time select" like it is for VT6212. Am I missing something?

    >
    > No, very useful test, thanks much. Patch as submitted for revision 0x6x will
    > stand then.
    >
    > I do wonder -- is your hda throughput also the same before _ever_ attaching
    > anything to the EHCI controller and after? In my case, the slow down only
    > happened after switching on my external USB drive once, and would persist
    > from that time until reboot (or unloading ehci-hcd, which I kept modular for
    > exactly that reason).
    >
    > The sleep time wasn't the core problem, so I wonder of later VIA chips do
    > still have the active async schedule problem...
    >
    > Alessandro? You said there still was a difference for you between no EHCI at
    > all and EHCI after tweaking 4B as Lev showed. How much?


    When used setpci to tweak the setting, my hdparm -t went
    from 17 to 25MB/s on /dev/hda.

    With your patch applied, now after booting it says 33MB/s for
    hda and 37MB/s on hdb (and I can burn DVDs at a stable 6x
    now, while growisofs backed off to 4x in less than a minute
    before the patch).

    If the patch does exactly what setpci did, then perhaps I had
    other activity on hda at the moment I ran the test...

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

  5. Re: ehci-hcd affects hda speed

    On 20-03-08 06:08, Alessandro Suardi wrote:

    > On Thu, Mar 20, 2008 at 1:31 AM, Rene Herman wrote:


    >> I do wonder -- is your hda throughput also the same before _ever_ attaching
    >> anything to the EHCI controller and after? In my case, the slow down only
    >> happened after switching on my external USB drive once, and would persist
    >> from that time until reboot (or unloading ehci-hcd, which I kept modular for
    >> exactly that reason).
    >>
    >> The sleep time wasn't the core problem, so I wonder of later VIA chips do
    >> still have the active async schedule problem...
    >>
    >> Alessandro? You said there still was a difference for you between no EHCI at
    >> all and EHCI after tweaking 4B as Lev showed. How much?

    >
    > When used setpci to tweak the setting, my hdparm -t went
    > from 17 to 25MB/s on /dev/hda.
    >
    > With your patch applied, now after booting it says 33MB/s for
    > hda and 37MB/s on hdb (and I can burn DVDs at a stable 6x
    > now, while growisofs backed off to 4x in less than a minute
    > before the patch).
    >
    > If the patch does exactly what setpci did, then perhaps I had
    > other activity on hda at the moment I ran the test...


    Yes, should be the exact same. It could be what I noted -- that you have the
    33/37 just after booting, and a drop to 25 again after having switched
    on/used a EHCI device for the first time? That would be interesting.

    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/

  6. Re: ehci-hcd affects hda speed

    On Thu, Mar 20, 2008 at 12:35 PM, Rene Herman wrote:
    > On 20-03-08 06:08, Alessandro Suardi wrote:
    >
    > > On Thu, Mar 20, 2008 at 1:31 AM, Rene Herman wrote:

    >
    >
    > >> I do wonder -- is your hda throughput also the same before _ever_ attaching
    > >> anything to the EHCI controller and after? In my case, the slow down only
    > >> happened after switching on my external USB drive once, and would persist
    > >> from that time until reboot (or unloading ehci-hcd, which I kept modular for
    > >> exactly that reason).
    > >>
    > >> The sleep time wasn't the core problem, so I wonder of later VIA chips do
    > >> still have the active async schedule problem...
    > >>
    > >> Alessandro? You said there still was a difference for you between no EHCI at
    > >> all and EHCI after tweaking 4B as Lev showed. How much?

    > >
    > > When used setpci to tweak the setting, my hdparm -t went
    > > from 17 to 25MB/s on /dev/hda.
    > >
    > > With your patch applied, now after booting it says 33MB/s for
    > > hda and 37MB/s on hdb (and I can burn DVDs at a stable 6x
    > > now, while growisofs backed off to 4x in less than a minute
    > > before the patch).
    > >
    > > If the patch does exactly what setpci did, then perhaps I had
    > > other activity on hda at the moment I ran the test...

    >
    > Yes, should be the exact same. It could be what I noted -- that you have the
    > 33/37 just after booting, and a drop to 25 again after having switched
    > on/used a EHCI device for the first time? That would be interesting.
    >
    > Rene.


    It just seems to be oscillating. The following is a series of
    consecutive hdparm -t (when one is finished, I hit up-arrow
    and then Enter again):

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

    /dev/hda:
    Timing buffered disk reads: 86 MB in 3.01 seconds = 28.57 MB/sec
    [root@donkey ~]# hdparm -t /dev/hda

    /dev/hda:
    Timing buffered disk reads: 88 MB in 3.00 seconds = 29.30 MB/sec
    [root@donkey ~]# hdparm -t /dev/hda

    /dev/hda:
    Timing buffered disk reads: 92 MB in 3.04 seconds = 30.31 MB/sec
    [root@donkey ~]# hdparm -t /dev/hda

    /dev/hda:
    Timing buffered disk reads: 88 MB in 3.05 seconds = 28.86 MB/sec
    [root@donkey ~]# hdparm -t /dev/hda

    /dev/hda:
    Timing buffered disk reads: 98 MB in 3.03 seconds = 32.38 MB/sec


    hdb is definitely more stable...

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

    /dev/hdb:
    Timing buffered disk reads: 108 MB in 3.02 seconds = 35.79 MB/sec
    [root@donkey ~]# hdparm -t /dev/hdb

    /dev/hdb:
    Timing buffered disk reads: 110 MB in 3.03 seconds = 36.36 MB/sec
    [root@donkey ~]# hdparm -t /dev/hdb

    /dev/hdb:
    Timing buffered disk reads: 110 MB in 3.04 seconds = 36.24 MB/sec
    [root@donkey ~]# hdparm -t /dev/hdb

    /dev/hdb:
    Timing buffered disk reads: 110 MB in 3.04 seconds = 36.24 MB/sec


    Though I only have light activity on /dev/hda - four torrents
    uploading at a cumulative 33KB/s via bittorrent-4.4.0-2
    (and no activity on /dev/hdb).

    /dev/sda, the USB external storage, is mounted but currently
    not really accessed. However, the slowdown for me did
    appear even modprob'ing ehci_hcd - without even mounting
    /dev/sda.

    Oh, now that you make me look... /dev/sda hdparm -t dropped
    from 22MB/s to ~16MB/s - see my email of a while ago

    http://linux.derkeiler.com/Mailing-L.../msg09679.html

    versus the current

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

    /dev/sda:
    Timing buffered disk reads: 48 MB in 3.02 seconds = 15.90 MB/sec
    [root@donkey ~]# hdparm -t /dev/sda

    /dev/sda:
    Timing buffered disk reads: 48 MB in 3.02 seconds = 15.90 MB/sec

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

  7. Re: ehci-hcd affects hda speed

    hi,

    Sorry, I had virtually no time to answer earlier. If (hopefully) someone
    is still interested, here's my feedback

    On Thu, 20 Mar 2008 at 3:50am, Rene Herman wrote:

    RH> I do wonder -- is your hda throughput also the same before _ever_
    RH> attaching anything to the EHCI controller and after? In my case, the
    RH> slow down only happened after switching on my external USB drive once,
    RH> and would persist from that time until reboot (or unloading ehci-hcd,
    RH> which I kept modular for exactly that reason).
    I have repeated experiments with P3B-F and VT6212L combination (to
    improve visibility the AsyncSchedSleepTime is set to 1us):

    #0. Nothing is connected to USB, no ehci-hcd loaded
    hda throughput 28+-1MB/s

    #1. ehci-hcd loaded, still no USB peripherals
    hda throughput 28+-1 MB/s

    #2. Something (USB hub and FLASH drive tested) is attached
    hda throughput 15+-1 MB/s

    #3. All USB peripherals are removed
    hda throughput 15+-1 MB/s

    #4. ehci-hcd is rmmod'ed
    hda throughput 28+-1MB/s

    The oddest peculiarity for me is the hysteretic difference between #1 and
    #3 states. I mean experimental data (hda throughput) depends not on the
    state (hardware/loaded modules), but on the path we followed.

    Interestingly enough, sampling registers (via /sys) often shows Async bit
    set of the status register in the state #3. It is always cleared in #1.
    The async file is empty in both states. I wonder, how many degrees of
    freedom does an empty schedule have? Does "empty" mean "has no incomplete
    requests" or "has no requests at all"? Just guessing...

    RH> The sleep time wasn't the core problem, so I wonder of later VIA chips do
    RH> still have the active async schedule problem...
    I don't think this is purely VIA problem. I did not _try_ to install that
    VT6212L card into newer motherboard, but my _feeling_ is that we see an
    "incompatibility" between older PCI mobo chipsets and VIA USB controller.
    Actually, taking into account superior PCI bandwidth of modern PCs (if
    compared with my old P3B-F motherboard) I am not sure we can perform a
    clean reliable test without PCI bus analyzer.

    -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

    Am Dienstag, 15. April 2008 21:56:24 schrieb Lev A. Melnikovsky:
    > The oddest peculiarity for me is the hysteretic difference between #1 and
    > #3 states. I mean experimental data (hda throughput) depends not on the
    > state (hardware/loaded modules), but on the path we followed.


    Did you compile with CONFIG_USB_SUSPEND?

    Regards
    Oliver

    --
    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 15-04-08 21:56, Lev A. Melnikovsky wrote:

    > Sorry, I had virtually no time to answer earlier. If (hopefully) someone
    > is still interested, here's my feedback


    Interested yes, although being no longer in posession of the hardware it's a
    somewhat academic interest...

    > I have repeated experiments with P3B-F and VT6212L combination (to
    > improve visibility the AsyncSchedSleepTime is set to 1us):
    >
    > #0. Nothing is connected to USB, no ehci-hcd loaded
    > hda throughput 28+-1MB/s
    >
    > #1. ehci-hcd loaded, still no USB peripherals
    > hda throughput 28+-1 MB/s
    >
    > #2. Something (USB hub and FLASH drive tested) is attached
    > hda throughput 15+-1 MB/s
    >
    > #3. All USB peripherals are removed
    > hda throughput 15+-1 MB/s
    >
    > #4. ehci-hcd is rmmod'ed
    > hda throughput 28+-1MB/s
    >
    > The oddest peculiarity for me is the hysteretic difference between #1 and
    > #3 states. I mean experimental data (hda throughput) depends not on the
    > state (hardware/loaded modules), but on the path we followed.


    On the chip having inited itself at least. Yes, your results match what I
    experienced.

    > Interestingly enough, sampling registers (via /sys) often shows Async bit
    > set of the status register in the state #3. It is always cleared in #1.
    > The async file is empty in both states. I wonder, how many degrees of
    > freedom does an empty schedule have? Does "empty" mean "has no incomplete
    > requests" or "has no requests at all"? Just guessing...


    Should leave this up to David, but as far as I'm aware "no at all".

    > RH> The sleep time wasn't the core problem, so I wonder of later VIA chips do
    > RH> still have the active async schedule problem...
    > I don't think this is purely VIA problem. I did not _try_ to install that
    > VT6212L card into newer motherboard, but my _feeling_ is that we see an
    > "incompatibility" between older PCI mobo chipsets and VIA USB controller.


    I very much doubt that. Can't really imagine an off-silicon reason the chip
    would keep scanning the async schedule. I'm also now using a NEC controller
    card in that same machine and it also shows no problems.

    > Actually, taking into account superior PCI bandwidth of modern PCs (if
    > compared with my old P3B-F motherboard) I am not sure we can perform a
    > clean reliable test without PCI bus analyzer.


    http://lkml.org/lkml/2005/5/30/259

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

  10. Re: ehci-hcd affects hda speed

    On 15-04-08 21:56, Lev A. Melnikovsky wrote:

    [ sorry, hit send prematurely by accident ]

    > Sorry, I had virtually no time to answer earlier. If (hopefully) someone
    > is still interested, here's my feedback


    Interested yes, although being no longer in posession of the hardware it's a
    somewhat academic interest...

    > I have repeated experiments with P3B-F and VT6212L combination (to
    > improve visibility the AsyncSchedSleepTime is set to 1us):
    >
    > #0. Nothing is connected to USB, no ehci-hcd loaded
    > hda throughput 28+-1MB/s
    >
    > #1. ehci-hcd loaded, still no USB peripherals
    > hda throughput 28+-1 MB/s
    >
    > #2. Something (USB hub and FLASH drive tested) is attached
    > hda throughput 15+-1 MB/s
    >
    > #3. All USB peripherals are removed
    > hda throughput 15+-1 MB/s
    >
    > #4. ehci-hcd is rmmod'ed
    > hda throughput 28+-1MB/s
    >
    > The oddest peculiarity for me is the hysteretic difference between #1 and
    > #3 states. I mean experimental data (hda throughput) depends not on the
    > state (hardware/loaded modules), but on the path we followed.


    On the chip having inited itself at least. Yes, your results match what I
    experienced precisely.

    > Interestingly enough, sampling registers (via /sys) often shows Async bit
    > set of the status register in the state #3. It is always cleared in #1.
    > The async file is empty in both states. I wonder, how many degrees of
    > freedom does an empty schedule have? Does "empty" mean "has no incomplete
    > requests" or "has no requests at all"? Just guessing...


    Should leave this up to David, but as far as I'm aware "no at all".

    > RH> The sleep time wasn't the core problem, so I wonder of later VIA chips do
    > RH> still have the active async schedule problem...
    > I don't think this is purely VIA problem. I did not _try_ to install that
    > VT6212L card into newer motherboard, but my _feeling_ is that we see an
    > "incompatibility" between older PCI mobo chipsets and VIA USB controller.


    I very much doubt that. Can't really imagine an off-silicon reason the chip
    would keep scanning the async schedule. I'm also now using a NEC controller
    card in that same machine and it shows no problems.

    > Actually, taking into account superior PCI bandwidth of modern PCs (if
    > compared with my old P3B-F motherboard) I am not sure we can perform a
    > clean reliable test without PCI bus analyzer.


    In my original thread on the issue:

    http://lkml.org/lkml/2005/5/30/259

    there's was some indication that a rev 0x86 VIA (more modern) does something
    similar due to Grant Coady in there also being able to see the Async bit on
    at all while looking at it so while throughput may not be hindered much, the
    issue could probably still be debugged/seen on newer (VIA) hardware by
    examing that state file.

    You are probably by now one of the best positioned users to debug the issue
    though with a VT2612 in an older machine so perhaps you can work with David
    Brownell to perhaps for once and all confirm that it's just unfixable VIA
    silicon or something which can be helped. As indicated, I just gave up on
    the bloody controller :-)

    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/

  11. Re: ehci-hcd affects hda speed


    On Wed, 16 Apr 2008 at 12:02am, Oliver Neukum wrote:

    ON> Am Dienstag, 15. April 2008 21:56:24 schrieb Lev A. Melnikovsky:
    ON> > The oddest peculiarity for me is the hysteretic difference between #1 and
    ON> > #3 states. I mean experimental data (hda throughput) depends not on the
    ON> > state (hardware/loaded modules), but on the path we followed.
    ON>
    ON> Did you compile with CONFIG_USB_SUSPEND?

    # CONFIG_USB_SUSPEND is not set

    Does this explain something?

    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/

  12. Re: ehci-hcd affects hda speed

    On Tuesday 15 April 2008, Lev A. Melnikovsky wrote:

    > I have repeated experiments with P3B-F and VT6212L combination (to
    > improve visibility the AsyncSchedSleepTime is set to 1us):


    Which you *know* is aggravating the problem. What numbers
    do you observe with a generic 2.6.25-rc9 kernel? (That is,
    without that abusive 1 usec setting ... that kernel includes
    the patch switching to a more customary 10 usec value.)


    > The oddest peculiarity for me is the hysteretic difference between #1 and
    > #3 states. I mean experimental data (hda throughput) depends not on the
    > state (hardware/loaded modules), but on the path we followed.
    >
    > Interestingly enough, sampling registers (via /sys) often shows Async bit
    > set of the status register in the state #3. It is always cleared in #1.


    With 2.6.25-rc9's default setting for async sleep time?


    > The async file is empty in both states. I wonder, how many degrees of
    > freedom does an empty schedule have? Does "empty" mean "has no incomplete
    > requests" or "has no requests at all"? Just guessing...


    Means "none at all". So if the "Async" status bit is set
    while the "Async" command is clear, it means the hardware
    is clearly misbehaving. That status bit is supposed to
    turn itself off after the command bit is cleared ... within
    a couple milliseconds.


    > I don't think this is purely VIA problem.


    We've certainly seen enough "purely on VIA hardware" issues
    though; and I don't recall evidence showing this is NOT
    another one of those. Example, that bogus 1 usec default...

    One hopes that when http://linux.via.com.tw finally appears,
    it will include errata for all relevant chipsets.

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

  13. Re: ehci-hcd affects hda speed

    Am Dienstag, 15. April 2008 22:41:19 schrieb Lev A. Melnikovsky:
    >
    > On Wed, 16 Apr 2008 at 12:02am, Oliver Neukum wrote:
    >
    > ON> Am Dienstag, 15. April 2008 21:56:24 schrieb Lev A. Melnikovsky:
    > ON> > The oddest peculiarity for me is the hysteretic difference between #1 and
    > ON> > #3 states. I mean experimental data (hda throughput) depends not on the
    > ON> > state (hardware/loaded modules), but on the path we followed.
    > ON>
    > ON> Did you compile with CONFIG_USB_SUSPEND?
    >
    > # CONFIG_USB_SUSPEND is not set
    >
    > Does this explain something?


    EHCI should not scan an empty async. However this manufacturer
    has shown a liberal attitude about conforming with specifications.
    If the root hub is suspended, it can't do DMA. So it might help.

    Regards
    Oliver
    --
    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

    Oliver,

    ON> EHCI should not scan an empty async. However this manufacturer
    ON> has shown a liberal attitude about conforming with specifications.
    ON> If the root hub is suspended, it can't do DMA. So it might help.
    Yes, it does, thank you. No DMA when suspended. Auto-suspend is executed
    if external hub is the only attached device. Can this be used to block
    spurious schedule traversal?

    Thnks
    -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 Wed, 16 Apr 2008 at 3:17am, David Brownell wrote:

    DB> Which you *know* is aggravating the problem. What numbers
    DB> do you observe with a generic 2.6.25-rc9 kernel? (That is,
    DB> without that abusive 1 usec setting ... that kernel includes
    DB> the patch switching to a more customary 10 usec value.)
    ~29.5 MB/s with ehci_hcd unloaded,
    ~26.0 MB/s with ehci_hcd loaded + USB hub is connected

    The machine is mostly idle.

    LM> #0. Nothing is connected to USB, no ehci-hcd loaded
    LM> hda throughput 28+-1MB/s
    LM> #1. ehci-hcd loaded, still no USB peripherals
    LM> hda throughput 28+-1 MB/s
    LM> #2. Something (USB hub and FLASH drive tested) is attached
    LM> hda throughput 15+-1 MB/s
    LM> #3. All USB peripherals are removed
    LM> hda throughput 15+-1 MB/s
    LM> #4. ehci-hcd is rmmod'ed
    LM> hda throughput 28+-1MB/s
    DB> > The oddest peculiarity for me is the hysteretic difference between #1 and
    DB> > #3 states. I mean experimental data (hda throughput) depends not on the
    DB> > state (hardware/loaded modules), but on the path we followed.
    DB> >
    DB> > Interestingly enough, sampling registers (via /sys) often shows Async bit
    DB> > set of the status register in the state #3. It is always cleared in #1.
    DB>
    DB> With 2.6.25-rc9's default setting for async sleep time?
    Yes. Async bit is oscillating and the frequency I see it set is much lower
    than that with 1us sleep time, but it is possible to catch the bit set
    high anyway. Here's one sample:

    $ cat /sys/class/usb_host/usb_host4/registers

    bus pci, device 0000:00:09.2 (driver 10 Dec 2004)
    EHCI Host Controller
    EHCI 1.00, hcd state 1
    ownership 00000001
    SMI sts/enable 0xc0080000
    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 28e0
    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 18 err 0 reclaim 4 (lost 0)
    complete 18 unlink 1

    DB> Means "none at all". So if the "Async" status bit is set
    DB> while the "Async" command is clear, it means the hardware
    DB> is clearly misbehaving. That status bit is supposed to
    DB> turn itself off after the command bit is cleared ... within
    DB> a couple milliseconds.
    Yes, I understand that, but... I am not going to defend VIA, the chip does
    misbehave. I just wonder what is the difference between the states #1 and
    #3? Command register is the same, hardware is the same. If we know the
    difference, can we benefit from our understanding?

    Namely: is it possible that an (empty) schedule is different?

    DB> One hopes that when http://linux.via.com.tw finally appears,
    OK, two hope :-)

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

  16. Re: ehci-hcd affects hda speed

    Am Donnerstag, 17. April 2008 00:23:08 schrieb Lev A. Melnikovsky:
    > Oliver,
    >
    > ON> EHCI should not scan an empty async. However this manufacturer
    > ON> has shown a liberal attitude about conforming with specifications.
    > ON> If the root hub is suspended, it can't do DMA. So it might help.
    > Yes, it does, thank you. No DMA when suspended. Auto-suspend is executed
    > if external hub is the only attached device. Can this be used to block
    > spurious schedule traversal?


    Obviously, yes, if only hubs are attached. The question is whether it
    should be. It would be better to find a way to fix the chip bug in the active
    state. However, as fixing all hardware bugs for that vendor may be difficult
    I wanted to test whether a partial work around is available.

    Regards
    Oliver
    --
    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 2 of 2 FirstFirst 1 2