David Hedley ([EMAIL PROTECTED]) wrote: > > 2) pppoa2 freezes under heavy load. > > I use the excellent userland ppp which uses pppoa2. Under heavy load, > the pppoa2 process which reads from the USB hangs in > pusb_endpoint_read in pusb-bsd.c. This will normally be observed as an > LQR timeout in the upper PPP layer (assuming you enable LQR). I'm not > sure why this is happening. The only way I've found to unwedge it is > to send the pppoa2 process a signal. To this end, the following patch > uses a watchdog timer to ensure the process doesn't get wedged:
Well we are experimenting similar problems with GNU/Linux pppoa3 (well it's posix compliant but for an unknown reason, it still doesn't work with BSD systems). The daemon hangs in a pusb_endpoint_read. But we have noticed this bug occurs when using a buggy usb chipset. But we are not sure. Special sequences of bytes seems to hang up the pppoa slave in a usb read ioctl, just like you. So this is a problem in the way we use the usb or the kernel usb implementation. > 3) Heavy usages causes large amounts of bad data to be read from the USB. In the >logs this looks like: > > Jul 3 13:58:35 exoserver pppoa2[6631]: Cell had wrong VPI(4068)/VCI(31234) (OAM?) >PTI=0x06 > [...] > > Not sure why this is happening - it doesn't seem to affect throughput > that much but is quite noisy. It seems to result from a read from > pusb_endpoint_read which returns a non-integer number of ATM > cells. This looks to me like a synchronisation/locking issue between > the read syscall in pppoa2 and the USB subsystem. You're right, the modem is supposed to give us atm cells, so we expect an integer number of cells in our little atm stack implementation. I should have write it again to make it more robust, but i'm actually very lazy. But for sure i'll write a new atm stack before September. This kind of things would not occur anymore if i do the code more complete (the current code is small and very fast, i think it could even be fooled by wrong atm cells - DoS - Attack ?) > 4) Random kernel panics > > This is the most disturbing bug of the lot. It looks like there's some > memory corruption happening inside the USB subsystem that occasionally > causes random kernel panics - the panic will typically occur as a > fatal trap inside kernel malloc. Good luck to anyone attempting to > track that one down.... Well as the driver is userland, the kernel panic must be caused by the kernel code itself. And as you say... "Good luck to anyone attempting to track that one down...." Btw i'll have a look at all your patches (not the kernel one) to update both pppoa3 and pppoa2. -- Edouard Gomez Liste de diffusion modem ALCATEL SpeedTouch USB Pour se désinscrire : mailto:[EMAIL PROTECTED]?subject=unsubscribe
