Duncan Sands wrote:
>> Dec 31 16:21:31 pfw kernel: ATM dev 0: usbatm_extract_one_cell: unknown
>> vpi/vci (0/3656)!
>> Dec 31 16:44:42 pfw kernel: ATM dev 0: usbatm_extract_one_cell: unknown
>> vpi/vci (92/7393)!
>> Dec 31 18:57:27 pfw kernel: ATM dev 0: usbatm_extract_one_cell: unknown
>> vpi/vci (160/297)!
>> Dec 31 20:22:22 pfw kernel: ATM dev 0: usbatm_extract_one_cell: packet
>> failed crc check (vcc: 0xd6812400)!
>> Dec 31 20:22:27 pfw kernel: ATM dev 0: usbatm_extract_one_cell: packet
>> failed crc check (vcc: 0xd6812400)!
>> Dec 31 20:22:28 pfw kernel: ATM dev 0: usbatm_extract_one_cell: packet
>> failed crc check (vcc: 0xd6812400)!
>> Dec 31 20:22:31 pfw kernel: ATM dev 0: usbatm_extract_one_cell: bogus
>> pdu_length 192 (sarb->len: 144, vcc: 0xd6812400)!
>> Dec 31 21:01:38 pfw kernel: ATM dev 0: usbatm_extract_one_cell: packet
>> failed crc check (vcc: 0xd6812400)!
>
> OK, it looks like it got a corrupt packet, or part of a packet, and is
> failing to recover.
>
>> What does this look like to you? Noise on the line?
>
> Or electrical interference - try plugging into a different USB port, and make
> sure there
> are no power cables near the modem's usb cable.
>
> One thing that comes to mind, is that the driver's ability to recover from
> bad bulk packets
> was weakened slightly when the iso support went in. Does the following patch
> help?
>
> --- usbatm.c 26 Oct 2006 12:55:31 -0000 1.69
> +++ usbatm.c 3 Jan 2007 21:41:30 -0000
> @@ -421,7 +421,7 @@ static void usbatm_extract_cells(struct
> /* extract cells from incoming data, taking into account that
> * the length of avail data may not be a multiple of stride */
>
> - if (buf_usage > 0) {
> + if (0) {
> /* we have a partially received atm cell */
> unsigned char *cell_buf = instance->cell_buf;
> unsigned int space_left = stride - buf_usage;
>
Flushed with my success at getting 2.6.19.1 to connect I thought I'd
try transferring some data, but the problem remains. I have tried
this patch on 2.6.19.1 but I am now seeing lots more messages than
before, almost exclusively 'unknown vpi/vci' messages, for example:
ATM dev 0: usbatm_extract_one_cell: unknown vpi/vci (99/5068)!
printk: 101 messages suppressed.
ATM dev 0: usbatm_extract_one_cell: buffer overrun (sarb->len 1536, vcc:
0xd7e5c800)!
printk: 24 messages suppressed.
ATM dev 0: usbatm_extract_one_cell: unknown vpi/vci (133/17733)!
printk: 85 messages suppressed.
ATM dev 0: usbatm_extract_one_cell: unknown vpi/vci (38/1416)!
I have tried the following combinations:
* kernel 2.6.19.1 with the above patch - the connection lasts <10 seconds.
before I get a splurge like above. At that point jnettop shows packets
leaving ppp0 fine and <200 bytes being received per IP connection when
an IP connection is started, but after that nothing is received per IP
connection at all, although some really diddly packets (like DNS
queries & replies) do make it through from time to time.
* kernel 2.6.19.1 with the above patch and without enable_isoc=1 behaves
similarly.
* kernel 2.6.19.1 without the above patch and with enable_isoc=1 behaves
similarly.
* kernel 2.6.19.1 without the above patch and without enable_isoc=1
has produced the best results: 5 minutes full speed comms before
loss of RX data as described above! In this situation the messages
at the time of failure are are urb failed, followed by
usbatm_rx_process: status -63 in frame 1, and then back to the
unknown vpi/vci messages you see above.
I have also isolated that it is not electrical interference between
the computer and modem on the USB link by trying several different
wiring layouts and listening to the spectrum on a hand-held scanner
to locate the source of the crud.
I temporarily rigged up new DSL wires so they are away from the mains
but that does nothing either. Even moving the computer and modem so they
plugged into the master socket (via a filter) makes no difference.
Changing the filter to the other one supplied with the modem makes no
difference either.
Isolating the mains and running the computer on UPS did nothing.
The only thing I haven't tried is using a different USB port, because
I only have one port which is fast enough! Should I try getting a
PCI card with an EHCI chip on it? My m/b chipset provides UHCI.
These problems occur on every boot, so it is clearly /much/ worse
than it was with 2.6.17.8, which currently stays up for minutes/hours
before collapsing as described in my earlier posts.
Another thing I have wondered about is whether the problem would go
away if I could resync at a lower rate. However, so far I have not
managed to get the rate to drop. Since the 'upgrade' to 8Mbps, I've
been synced at 8128/448 all the time, apart from a yesterday when it
went down to 8000/448. I think this was a result of rebooting dozens
of times that day, but since then it has gone back up to 8128/448.
I even tried repeatedly plugging and unplugging the DSL cable to
force a resync at a lower rate, but it steadfastly refuses to slow
down. Aaarrrrgghh!
Oh, and another thing. atmdiag keeps telling me there are 0 errors
despite all the messages. How can this be?
Sorry for dragging on.
Steve.
PS. Do you have a tool which can show the signal levels (SNR etc.)
on a speedtouch? That runs on linux?
Liste de diffusion modem ALCATEL SpeedTouch USB
Pour se désinscrire : mailto:[EMAIL PROTECTED]
