ehci-hcd affects hda speed

ehci-hcd affects hda speed

[Lev A. Melnikovsky]

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

Re: ehci-hcd affects hda speed

[Rene Herman]

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.

Re: ehci-hcd affects hda speed

[Alessandro Suardi]

On Wed, Mar 5, 2008 at 5:19 PM, Rene Herman <rene.herman@keyaccess.nl> 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)

Re: ehci-hcd affects hda speed

[David Brownell]

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

Re: ehci-hcd affects hda speed

[Alessandro Suardi]

On Wed, Mar 5, 2008 at 10:03 PM, David Brownell <david-b@pacbell.net> 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)

Re: ehci-hcd affects hda speed

[Lev A. Melnikovsky]

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

Re: ehci-hcd affects hda speed

[Lev A. Melnikovsky]

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

Re: ehci-hcd affects hda speed

[Lev A. Melnikovsky]

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

Re: ehci-hcd affects hda speed

[Alessandro Suardi]

On Sat, Mar 15, 2008 at 11:46 PM, Lev A. Melnikovsky
<melnikovsky@mail.ru> 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)

Re: ehci-hcd affects hda speed

[David Brownell]

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

Re: ehci-hcd affects hda speed

[Rene Herman]

[-- Attachment #1: Type: text/plain, Size: 1171 bytes --]

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.

[-- Attachment #2: vt6212_ehci_sleep_time.diff --]
[-- Type: text/plain, Size: 1008 bytes --]

commit fb221b24a314069af26db8c9beb6c843efcafa38
Author: Rene Herman <rene.herman@gmail.com>
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 <melnikovsky@mail.ru>
    Signed-off-by: Rene Herman <rene.herman@gmail.com>

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);

Re: ehci-hcd affects hda speed

[Rene Herman]

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.

Re: ehci-hcd affects hda speed

[David Brownell]

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;

Re: ehci-hcd affects hda speed

[Lev A. Melnikovsky]

  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

Re: ehci-hcd affects hda speed

[Rene Herman]

[-- Attachment #1: Type: text/plain, Size: 2166 bytes --]

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

[-- Attachment #2: vt6212_ehci_sleep_time.diff --]
[-- Type: text/plain, Size: 1177 bytes --]

commit fd96c2b26339f21a66504cb3f36579bb312a8f3b
Author: Rene Herman <rene.herman@gmail.com>
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 <melnikovsky@mail.ru>
    Signed-off-by: Rene Herman <rene.herman@gmail.com>

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);

Re: ehci-hcd affects hda speed

[Rene Herman]

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.

Re: ehci-hcd affects hda speed

[David Brownell]

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

Re: ehci-hcd affects hda speed

[David Brownell]

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

Re: ehci-hcd affects hda speed

[Rene Herman]

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.

Re: ehci-hcd affects hda speed

[Alessandro Suardi]

On Tue, Mar 18, 2008 at 2:23 AM, Rene Herman <rene.herman@keyaccess.nl> 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 <rene.herman@gmail.com>
>  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 <melnikovsky@mail.ru>
>     Signed-off-by: Rene Herman <rene.herman@gmail.com>
>
>  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 <alessandro.suardi@gmail.com>

(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)

Re: ehci-hcd affects hda speed

[Rene Herman]

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 <alessandro.suardi@gmail.com>
> 
> (going to mention the patch in my Fedora bugzilla entry)

Thanks much for testing.

Rene.

Re: ehci-hcd affects hda speed

[Lev A. Melnikovsky]

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- <TAbort- <MAbort+ >SERR- <PERR- INTx-
        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=<none>
        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- <TAbort- <MAbort+ >SERR- <PERR- INTx-
        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- <TAbort- <MAbort- <SERR- <PERR-
        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- <TAbort- <MAbort- >SERR- <PERR- INTx-
        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- <TAbort- <MAbort- >SERR- <PERR- INTx-
        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- <TAbort- <MAbort- >SERR- <PERR- INTx-
        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- <TAbort- <MAbort- >SERR- <PERR- INTx-
        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

Re: ehci-hcd affects hda speed

[Rene Herman]

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.

Re: ehci-hcd affects hda speed

[Alessandro Suardi]

On Thu, Mar 20, 2008 at 1:31 AM, Rene Herman <rene.herman@keyaccess.nl> 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)

Re: ehci-hcd affects hda speed

[Rene Herman]

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

> On Thu, Mar 20, 2008 at 1:31 AM, Rene Herman <rene.herman@keyaccess.nl> 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.

Re: ehci-hcd affects hda speed

[Alessandro Suardi]

On Thu, Mar 20, 2008 at 12:35 PM, Rene Herman <rene.herman@keyaccess.nl> wrote:
> On 20-03-08 06:08, Alessandro Suardi wrote:
>
>  > On Thu, Mar 20, 2008 at 1:31 AM, Rene Herman <rene.herman@keyaccess.nl> 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-Lists/Kernel/2006-10/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)

Re: ehci-hcd affects hda speed

[Lev A. Melnikovsky]

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

Re: ehci-hcd affects hda speed

[Oliver Neukum]

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

Re: ehci-hcd affects hda speed

[Rene Herman]

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
> 

Re: ehci-hcd affects hda speed

[Rene Herman]

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.

Re: ehci-hcd affects hda speed

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

Thanks
-L

Re: ehci-hcd affects hda speed

[David Brownell]

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

Re: ehci-hcd affects hda speed

[Oliver Neukum]

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

Re: ehci-hcd affects hda speed

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

Thnks
-L

Re: ehci-hcd affects hda speed

[Lev A. Melnikovsky]

  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

Re: ehci-hcd affects hda speed

[Oliver Neukum]

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