Hi John, thanks for the informative message. It sounds like you get an endpoint stall. Can you please recompile your kernel with USB debugging turned on, and send me the messages when this occurs. This makes some kind of sense because the packet size for the endpoint is 64 bytes with endpoint 1, and 32 bytes with endpoint 2, so buffer over/under-runs in the modem are more likely with endpoint 1.
Ciao, Duncan. On Saturday 21 February 2004 21:36, John Hysted wrote: > Duncan > > I requested the reversion to endpoint 2 in modem_run by default for the Rev > 0000 green frogs. > > If endpoint 1 is used in modem_run with these modems, pppoa3 fails with > "Error reading usb urb" randomly after a few hours when under heavy load > and this does not happen when endpoint 2 is used in modem_run. > It has been reported by other users in the past as a problem with the new > code in Version 1.2. My solution has been to revert to the Version 1.1 > version of modem_run and pppoa3 where the connection is stable for weeks at > a time. > > I was surprised to trace the problem to modem_run as I assumed it would be > a problem with pppoa3. I have extensively tested various existing versions > and created and tested a patched version of 1.2-beta3 modem_run. The log of > my testing is available by following the "spreadsheet" link from > http://www.hystedjp.pwp.blueyonder.co.uk/history.htm which demonstrates > that the "Error reading usb urb" occurs when modem_run uses alternate > endpoint 1. (Or if you use pppoa3 -e 1 with a green frog which you > shouldn't anyway.) > > For 330 modems I agree that endpoint 1 is required. However in modem_run it > was NOT left at endpoint 2 for older modems. > > John > > > > Liste de diffusion modem ALCATEL SpeedTouch USB > Pour se désinscrire : > mailto:[EMAIL PROTECTED] Liste de diffusion modem ALCATEL SpeedTouch USB Pour se désinscrire : mailto:[EMAIL PROTECTED]
