LinuxLists.cc - ehci-hcd affects hda speed

[permalink] [raw]

Subject: Re: ehci-hcd affects hda speed

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

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

Uh oh...

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

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

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

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

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

Rene.

2008-03-05 20:03:23

[permalink] [raw]

Subject: Re: ehci-hcd affects hda speed

On Wed, Mar 5, 2008 at 5:19 PM, Rene Herman <[email protected]> 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 [email protected]
> 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)

2008-03-05 21:03:59

[permalink] [raw]

Subject: Re: ehci-hcd affects hda speed

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

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

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

- Dave

2008-03-06 16:25:43

[permalink] [raw]

Subject: Re: ehci-hcd affects hda speed

On Wed, Mar 5, 2008 at 10:03 PM, David Brownell <[email protected]> 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)

2008-03-06 20:40:26

[permalink] [raw]

Subject: Re: ehci-hcd affects hda speed

David,

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

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

-L

2008-03-10 10:12:18

[permalink] [raw]

Subject: Re: ehci-hcd affects hda speed

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

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

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

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

Thanks
-L

2008-03-15 22:46:47

[permalink] [raw]

Subject: Re: ehci-hcd affects hda speed

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

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

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

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

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

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

-L

2008-03-17 16:15:54

[permalink] [raw]

Subject: Re: ehci-hcd affects hda speed

On Sat, Mar 15, 2008 at 11:46 PM, Lev A. Melnikovsky
<[email protected]> 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)

2008-03-17 21:07:07

[permalink] [raw]

Subject: Re: ehci-hcd affects hda speed

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

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

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

- Dave

2008-03-17 23:23:08

[permalink] [raw]

Subject: Re: ehci-hcd affects hda speed

commit fb221b24a314069af26db8c9beb6c843efcafa38
Author: Rene Herman <[email protected]>
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 <[email protected]>
Signed-off-by: Rene Herman <[email protected]>

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

Attachments:

vt6212_ehci_sleep_time.diff (0.98 kB)

2008-03-17 23:26:01

[permalink] [raw]

Subject: Re: ehci-hcd affects hda speed

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

> On 17-03-08 22:00, David Brownell wrote:
>
>>> On 15-03-08 23:46, Lev A. Melnikovsky wrote:
>>>
>>>> changing the bit 5 (EHCI sleep time select: 0=1us 1=10us)
>>>> of register 0x4B seems to resolve my own problem.
>>
>> Note that 10 usec is the value used in the EHCI spec.
>>
>> And yes, waiting only 1 usec between schedule scans is
>> absolutely certain to hammer on the PCI bus quite rudely,
>> preventing other devices from getting Real Work done.
>>
>> Could someone put together an EHCI patch to make sure
>> that bit is set on vt6212 parts? For the VT8235 that
>> register seems to be marked (in an old document someone
>> forwarded to me) as "reserved, do not program"; so this
>> should be specific to vt6212 EHCI. (PCI vendor 0x1106,
>> device 0x3104, revision 0x60 ... the revision being what
>> says "vt6212" vs "vt8235" or "vt8237" etc.
>
> Just something like this? Completely untested as I've not the hardware
> anymore. Googling for an old lspci, I had a revision 0x63, and Lev has a
> revision 0x65. The VT6212(L) should be 0x60+ it seems.
>
> The "CC:" should be a "Tested-by:" if that's actually the case.
>
> But yes, as he also asked, should this be the fix at all?

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

Rene.

2008-03-18 00:00:38

[permalink] [raw]

Subject: Re: ehci-hcd affects hda speed

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

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

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

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

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

2008-03-18 00:31:20

[permalink] [raw]

Subject: Re: ehci-hcd affects hda speed

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

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

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

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

-L

2008-03-18 01:23:16

[permalink] [raw]

Subject: Re: ehci-hcd affects hda speed

commit fd96c2b26339f21a66504cb3f36579bb312a8f3b
Author: Rene Herman <[email protected]>
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 <[email protected]>
Signed-off-by: Rene Herman <[email protected]>

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

Attachments:

vt6212_ehci_sleep_time.diff (1.15 kB)

2008-03-18 01:26:39

[permalink] [raw]

Subject: Re: ehci-hcd affects hda speed

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

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

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

Rene.

2008-03-18 01:45:41

[permalink] [raw]

Subject: Re: ehci-hcd affects hda speed

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

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

- Dave

2008-03-18 01:55:55

[permalink] [raw]

Subject: Re: ehci-hcd affects hda speed

On Monday 17 March 2008, Rene Herman wrote:
> On 18-03-08 01:00, David Brownell wrote:
>
> > On Monday 17 March 2008, Rene Herman wrote:
> >> + case PCI_VENDOR_ID_VIA:
> >> + if (pdev->device == 0x3104 && pdev->revision >= 0x60) {
> >
> > Unless you have specific docs from VIA saying that this register
> > isn't revision-specific (at least in the sense that all revisions
> > after 0x60 define that bit in that way), this should probably be a
> > switch on pdev->revision and just include the known-safe revisions.
>
> I'm looking at a VIA datasheet which says the revision ID for the "VT6212 /
> VT6212L PCI USB2.0 Controller" is simply 0x60. The VT61212L I myself owned
> advertised a revision ID of 0x63 and Lev's VT6212L advertises 0x65.

Probably the same one I saw, from that URL.

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

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

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

No ... see below:

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

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

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

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

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

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

> > But otherwise, yes -- that's the kind of patch I'd sign off on
> > after making this comment a bit more informative about how
> > that 1 usec sleep time creates an amount of PCI bus hogging.
>
> Version with 0x6x and the somewhat more expansive comment. I'd like to be
> able to test VT8235/VT8237 first though...

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

Thanks!

- Dave

2008-03-18 03:12:55

[permalink] [raw]

Subject: Re: ehci-hcd affects hda speed

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

> On Monday 17 March 2008, Rene Herman wrote:

>> The thing is -- you don't necesarily immediately notice this problem. I
>> noticed it earlier on an old system, as did Lev, but even if on a modern
>> system you may not immediately see an IDE throughput drop, you may still
>> have a sucky system.
>
> True, and bothersome. All VIA would have to do is adopt a design
> and production methodology different than they've used for many
> years now, and this problem wouldn't appear. ;)

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

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

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

>> Version with 0x6x and the somewhat more expansive comment. I'd like to be
>> able to test VT8235/VT8237 first though...
>
> OK, I'll leave this in my mailbox for a few days waiting more
> testing results, and if nothing goes wrong I'll send it along
> for a post-2.6.25 merge.

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

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

Rene.

2008-03-19 23:01:36

[permalink] [raw]

Subject: Re: ehci-hcd affects hda speed

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

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

Thanks much for testing.

Rene.

2008-03-20 00:36:01

[permalink] [raw]

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

2008-03-20 00:40:47

[permalink] [raw]

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

2008-03-20 01:23:30

[permalink] [raw]

Subject: Re: ehci-hcd affects hda speed

On Tue, Mar 18, 2008 at 2:23 AM, Rene Herman <[email protected]> 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 <[email protected]>
> 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 <[email protected]>
> Signed-off-by: Rene Herman <[email protected]>
>
> 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 <[email protected]>

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

2008-03-20 05:08:53

[permalink] [raw]

Subject: Re: ehci-hcd affects hda speed

On Thu, Mar 20, 2008 at 1:31 AM, Rene Herman <[email protected]> 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)

2008-03-20 11:34:47

[permalink] [raw]

Subject: 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 <[email protected]> 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.

2008-03-20 21:08:19