Hi,
I just wanted to add my two cents to the discussions about the connections that started first between Vladimir Vyskocil and Tim Woodall (was "USB read timeout with PIIX3 USB"), continued mainly with Yann Gloriau, Vladimir again and some others (was "Perte de connexion"). I tried to set up a firewall for my home network using *quite* old stuff: an old PIIX2 OHCI PCI motherboard with a 75 Mhz Pentium. This board had no USB connectors, I had to buy a PCI usb board to get my SpeedTouch attached to it. For the SpeedTouch I used version 1.1 of the sources. For the rest, the kernel was 2.4.18. Setting everything "by the book" (thanks to the documentation folks) I could get a connection and ping around the Internet and even ftp under the character interface. But then, the connection would freeze (while ppp0 interface "up and running" as of ifconfig). If I tried to browse with Netscape things would get worse and the connection would freeze very quickly. It always happened at random. In /var/log/messages I would get entries for USB errors and at some point a time out, the disconnection of the device (the Speedtouch) and it's immediate reconnection under a different USB ID. PPP would bail out in the mean time but ifconfig would still say it is living. Killing modem_run after microcode downloading helped a little. To speak the truth, the whole thing was unusable. I would then browse the SpeedTouch list archive and bump into the discussions just mentionned and Vladimir's patch that I applied immediately. Things got a bit better, but at some point the same problem rose again. I then moved to kernel 2.4.19: the change log said something about improved PIIX timing. No joy. I then tried a different direction. I noticed that the lockup happened quicker when there was a lot of activity (under X- window for instance). I then suspected a problem of competition for some kind of resource. It could not be the processor, because even with a 75 MHz Pentium, very little CPU was used in console mode. I then turned to PCI latency problems: maybe the USB board did not have enough time to send data flowing from the SpeedTouch. After all, the first error messages in /var/log/messages where "bulk transfer time out". An article, "PCI Latency Timer Howto" by Eric Seppanen (http://www.reric.net/linux/pci_latency.html) encouraged me to follow this trail. Another article "USB Latency Requirements and the Effect of Video Adapter PCI Retry Condition on Maintaining USB Streaming Pipelines" (http://www.usb.org/developpers/data/usblat~3.pdf, any complaint about the length of the title to be sent to the authors, Alberto Martinez and Sures Vadhva) described a quite similar problem, more scientifically investigated that my simple "guess". No modem was involved but a digital camera was. Their problem turned out to come from the competition between the USB and the graphics adaptator (it was before AGP days and with a PIIX3 chipset). To make a long story short I then decided to play around with the latency timer of my USB PCI board. When I loaded the pci-ohci the message would tell that the latency timer was set to 64. I decided to try other values. You can use the setpci for that purpose (it comes with pci utilities suite, that gives you the commonly used lspci). lspci gave me the ID of the board (00:0a.0 in my case). And then the fired a "setpci -s 00:0a.0 latency_timer=C0". Let me just explain this command: -s selects the device, the rest sets the latency timer to an hexadecimal value that corresponds to 192 = 64 x 3. I had now three times the initial value. The PCI bursts of my USB board could be much longer. I then run "the modem_run..", the "pppd call ...". Things run perfectly smooth! I could make serious downloads (the linux kernel, for instance or the W2k SP3) without a glitch, even under X-window with Netscape. I still experienced some problems under very heavy load (compiling the kernel while surfing the net on a 75 MHz Pentium is what I call very heavy load). I then decided to remove Vladimir's patch (is was a bit sick of the message to the console and to the logs every other 10 seconds, when there was no activity). I must stress here how gratefull I am to Vladimir: without is patch I would have lost hope and patience, given up and sent the all stuff to the junkyard!). It still runs fine without the patch. I have put up the firewall toghether (using Shorewall, perfect for total iptables idiot like myself). This success story need the confirmation of a long and heavy testing "in the trenches". But the preliminary results are so spectacular (up grading from a useless curiosity to a really operational system) that I wanted to share them with the list. I did not really try other values for latency timer. I suspect it is an 8 bits register as it accepted FFh and not 100h. Any the "good" values should be multiples of 8 (see the first quoted article for an explanation). I stick to C0h since it works fine and does not seem to have side-effects (I must say that the USB board only manages the SpeedTouch and that my system is really bare bones : a VGA adaptor, an NE2000 compatible PCI board, 2 old IDE disk, an IDE CDROM, a mouse and basta! ). I do not know how things work with other chip sets. PIIX in general seem to be peculiar from what you can read around and PIIX2 is *really* old stuff. So I do not claim this is a general solution for this kind of problems. I hope this helps Cheers, Serge Torres Acc�dez au courrier �lectronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,13 �/mn) ; t�l : 08 92 68 13 50 (0,34�/mn)" Liste de diffusion modem ALCATEL SpeedTouch USB Pour se d�sinscrire : mailto:[EMAIL PROTECTED]?subject=unsubscribe
