Greetings, Recently, I've been testing an Asrock K7VT2 motherboard on Linux Kernel 2.4.21-pre2 with David Brownwell's EHCI patch dated 20th of December 2002. Since the application of the patch, there have been some improvements, but there are still many hangs. I've been in contact with David with regards to this and he recently suggested that I have a look at the log2_irq_thresh option.
After having a look, I came up with some surprising results. Without any log2_irq_thresh setting at all, I was able to keep the system stable enough (by not using the USB 2.0 storage device before the test) to get a reading from "hdparm -t /dev/sda": -- /dev/sda: Timing buffered disk reads: 64 MB in 15.05 seconds = 4.25 MB/sec -- With a setting of 1, I got: -- /dev/sda: Timing buffered disk reads: 64 MB in 18.16 seconds = 3.52 MB/sec -- A setting of 3 was slower yet, but I could use it for doing regular small file transfers without a hang (heavy loads would still hang): -- /dev/sda: Timing buffered disk reads: 64 MB in 40.21 seconds = 1.59 MB/sec -- A setting of 5 wouldn't hang at all, no matter how much stress I tried to put on the device, but as you can see, the speeds are far below USB 1.1. -- /dev/sda: Timing buffered disk reads: 64 MB in 119.39 seconds =548.92 kB/sec -- After all of this, I decided to test an NEC USB 2.0 card on this computer which worked completely stable on an Abit KT7A motherboard (KT133A chipset). This motherboard however would hang with the NEC card too, almost as often as the VIA USB 2.0. However, the BIOS on this board (an AMI BIOS, latest release from the motherboard vendor) has an option called "PCI Latency (PCI Clocks)" with a default setting of 32. I changed this to the maximum, which is 248 and the stability was far greater than before, on both NEC and VIA controllers. The NEC controller would not get a reading before hanging the machine, but with a PCI Latency Value of 248, I could get the following (at one stage, I got just over 9Mb/sec on the VIA controller): -- /dev/sda: Timing buffered disk reads: 64 MB in 7.32 seconds = 8.74 MB/sec -- These results are fairly consistent with those found on an EPIA-M and Epox (KT400) motherboard which leads me to think that many of the EHCI problems may be related to IRQ more than anything else. Does this provide any clues to the EHCI developers? I'd be very interested to hear what model motherboards (and/or storage devices) are known to work well with the current EHCI driver on the VIA USB 2.0 chipsets. Thanks, Jonathan ------------------------------------------------------- This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will allow you to extend the highest allowed 128 bit encryption to all your clients even if they use browsers that are limited to 40 bit encryption. Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
