Via TECHNOLOGIES, VT6212 PCI USB 2.0 Controller

[IanB]

A good while ago I posted a thread, BW IO system performance measurements, to discuss the performance of the BW hardware.

Recently I stumbled across this chip specific code in the 2.6 linux kernel usb drivers source code, ehci-pci.c

Code: Select all

        case PCI_VENDOR_ID_VIA:
                if (pdev->device == 0x3104 && (pdev->revision & 0xf0) == 0x60) {
                        u8 tmp;

                        /* The VT6212 defaults to a 1 usec EHCI sleep time which
                         * hogs the PCI bus *badly*. Setting bit 5 of 0x4B makes
                         * that sleep time use the conventional 10 usec.
                         */
                        pci_read_config_byte(pdev, 0x4b, &tmp);
                        if (tmp & 0x20)
                                break;
                        pci_write_config_byte(pdev, 0x4b, tmp | 0x20);
                }
                break;

The VT6212 is the chip used by BW for their USB2 controller. It has a PCI device ID of 1106:3104

# cat /proc/pci
PCI devices found:
Bus 0, device 1, function 0:
...
Bus 0, device 2, function 2:
Class 0c03: PCI device 1106:3104 (rev 101).
IRQ 14.
Master Capable. Latency=32.
Non-prefetchable 32 bit memory at 0x60110100 [0x601101ff].

So checking what value the 0x4b, MAC turn around time parameter, had been set to we find it is the default, 0x09, EHCI sleep time, 1us, USB 2.0 MAC TX time, 9.

# hexdump /proc/bus/pci/00/02.2
0000000 1106 3104 0156 0210 2065 0c03 2008 0080 # Via VT6212
...
0000040 0000 000b 0000 0000 20a0 0900 0000 0000 # *0x4b == 0x09, Default value
...

Being an adventurous linux hacker, I tried poking that PCI register with the 10us EHCI sleep time value, 0x29, to see what effect this would have on system and usb performance.

# echo ')'|dd of=/proc/bus/pci/00/02.2 bs=1 seek=75 count=1 # ')' == 0x29; 0x4b == 75;

Well it's not a golden bullet, I observe a slight increase in USB disk transfer speed. The LiDiC seems a little more resilient but still crashes if you access a usb disk or stick while it is active.

I wonder what other VT6212 or EHCI driver tweaks are possible.

Warning! Poking values into linux kernel devices can have quite adverse effects on system integrity, try this at your own risk.

[prl]

...
Being an adventurous linux hacker, I tried poking that PCI register with the 10us EHCI sleep time value, 0x29, to see what effect this would have on system and usb performance.

# echo ')'|dd of=/proc/bus/pci/00/02.2 bs=1 seek=75 count=1 # ')' == 0x29; 0x4b == 75;

...

Oi! That's my hack there!

There's also some possibility that this hack will help with the bug in transferring recordings from the USB recording HDD to another USB HDD on the DP-H1, but I haven't had a chance to try it yet. If anyone else would like to try it and report back, I'd be grateful. I'll try it myself as soon as I can get some "hack time" on our H1.

[prl]

The 10us EHCI sleep time hack doesn't prevent copies from the DP-H1 recording USB HDD to another USB HDD from crashing. They may stumble on for a bit longer, but it's still not possible to copy anything of a reasonable length. And the copy speed while it's running is truly abysmal -- ~300-400kB/s (WD MyBook .Essentials 250GB -> WD MyBook Home Edition 500GB).