Hi, thanks for your reply.
Selon "Farahmand, Farinam" <[EMAIL PROTECTED]>: > Ben, > > I enumerated the questions you had in the link. I have answered the questions > to the best of my knowledge. I will provide the answers for the ones that I > don't know after talking to some of the engineers. > > > Technical questions > > ---------------------- > > > [...] > > - we are missing a functionality to "restart the modem when in unstable > state" : Initializing, Booting. This would permit to get back to a known > state avoiding to unplug / replug the modem (which is the only way to do it > currently) > > > > If we cannot read cmv from the modem in the unstable state, it means that the > L1 is not loaded properly. So we have to somehow reload the L1 ?? > > > > - could we change VPI / VCI "on the fly" and force new synchronization ? > > Yes. CNTL 0 2 should force the modem to re-sync. > Yes but sometimes the modem is in a very unsane state : even rebooting (so we use CNTL 0 2) don't work, the only way is to unplug it and replug it. Could it be possible that the modem is crashed ? > [...] > > 8 - Why the bulk mode produce lot's of missing atm cell, and invalid packet > (even with the windows driver http://castet.matthieu.free.fr/eagle/stat.png) > ? What the meaning of the command SET_TIMEOUT (control packet, > value=11,index=1) in bulk mode. Is there a speed limit with bulk mode ? What > the recomand setting for usb : number of urb, .... Windows driver use 22 urb > of 64*atm_cell Byte. > > > > I think there is a speed limit with bulk mode ( not sure! ) I will try to > find the answer. > Ok, but what's the meaning of the SET_TIMEOUT command ? Bulk mode is like tcp, it guarantee that the data is devilered, so it using an ack mecanism. Could it be possible the SET_TIMEOUT commands reduce the time the modem wait for an ack from the host in order to empty is received packet buffer for putting incomming adsl packets ? What about the last question (iso pipe and EILSEQ error)? After some tests it seems errors are produced on linux and windows, but only for packets that are empty (there is no empty packet with status=0(no error), and it seems there no missing paquets if we keep only the packets with status=0). Could it be a firmware issue ? the linux doc (error-codes.txt) say this error may happen because of : a) CRC mismatch b) no response packet received within the prescribed bus turn-around time c) unknown USB error In cases b) and c) either -EPROTO or -EILSEQ may be returned. Note that often the controller hardware does not distinguish among cases a), b), and c), so a driver cannot tell whether there was a protocol error, a failure to respond (often caused by device disconnect), or some other fault. and that - Error codes like -EPROTO, -EILSEQ and -EOVERFLOW normally indicate hardware problems such as bad devices (including firmware) or cables. - This is also one of several codes that different kinds of host controller use to to indicate a transfer has failed because of device disconnect. In the interval before the hub driver starts disconnect processing, devices may receive such fault reports for every request. It could be also an uhci problem in the linux implementation (didn't find ohci tester), but it wouldn't produce error on windows if it were the case or may be we were unlucky to test it on bad usb controller... regards, Matthieu CASTET
