> > Lots changed in the kernel and the USB layer. Nothing changed in
> > the speedtouch driver between 2.6.17 and 2.6.18. There were some
> > changes for 2.6.19.
>
> Yes, I noticed. My question was really to do with the USB stuff, mainly
> because this all started when I experienced massive packet loss with
> 2.6.17.8. In particular (and I think it was mentioned on this list) I
> remember reading of problems being experienced with failed URBs when a
> packet full of 0xff's was received; it seemed that the URBs would get
> lost somewhere in the USB stack, although I do not remember seeing a
> fix. Of course my memory could be deceiving me.
What host controller driver are you using? uhci underwent major surgery
during this time. Also, I understand that the 0xff problem you mentioned
was fixed.
> > Are you using enable_isoc=1?
>
> Nope. What does it do? The only option I have set is dl_512_first=1,
> which I turned on in a vain attempt to get speedtch working way back
> when I first bought the modem and was doing battle with udev. I'm sure I
> could remove it without it making any difference.
There's an experimental feature which only works with speedtouch 330s or
better: download using isochronous urbs, rather than bulk urbs. This
should improve performance on high speed connections. You can turn it
on with enable_isoc=1. It may be worth turning on, because one possible
explanation for your problem is that data is coming into the modem faster
than it is being extracted by the computer, and some buffers in the modem
are overflowing. Of course this wouldn't happen in a bug free world...
Try some recent firmware, such as bin/sachu3/zzzlp2.eni from
http://www.speedtouch.co.uk/downloads/330/301/UK3012%20Extended.zip
> > Do you also have the userspace driver
> > (it could be forceably disconnecting the kernel module).
>
> Nope. The only software running at this point is the kernel, udevd,
> udevtrigger and then udevsettle, plus whatever they spawn (modprobe and
> the mounting of /proc/bus/usb). Might udev have something to do with
> this, perhaps by loading modules before their dependencies are properly
> initialized?
Maybe usbatm is built into the kernel, but speedtouch is a module, or
vice-versa?
> On a further note, I have captured an instance of my connection going
> down inexplicably using 2.6.17.8, and I wonder if you could pass
> judgement on why this happens.
>
> At 21:39 on Boxing Day I started experiencing heavy packet loss. Apart
> from a few bots (like the news spool) which slowly choked to death,
> nothing much happened, and nothing appeared in the logs until this:
>
> Dec 26 21:59:12 pfw kernel: ATM dev 0: usbatm_complete: urb 0xd7135ba0
> failed (-84)!
> Dec 26 21:59:12 pfw kernel: ATM dev 0: usbatm_complete: urb 0xd7135b20
> failed (-84)!
> Dec 26 21:59:12 pfw kernel: ATM dev 0: usbatm_complete: urb 0xd7135ca0
> failed (-84)!
> Dec 26 21:59:12 pfw kernel: ATM dev 0: usbatm_complete: urb 0xd7135c20
> failed (-84)!
> Dec 26 21:59:13 pfw kernel: usb 1-2: USB disconnect, address 2
> Dec 26 21:59:13 pfw kernel: uhci_hcd :00:07.2: remove, state 1
> Dec 26 21:59:13 pfw kernel: usb usb1: USB disconnect, address 1
> Dec 26 21:59:13 pfw kernel: hub 1-0:1.0: hub_port_status failed (err = -19)
> Dec 26 21:59:13 pfw kernel: hub 1-0:1.0: connect-debounce failed, port 2
> disabled
> Dec 26 21:59:13 pfw kernel: hub 1-0:1.0: cannot disable port 2 (err = -19)
> Dec 26 21:59:13 pfw kernel: uhci_hcd :00:07.2: USB bus 1 deregistered
> Dec 26 21:59:13 pfw kernel: ACPI: PCI interrupt for device :00:07.2
> disabled
>
> after which packet loss was 100% (obviously), but pppd (2.4.4) remained
> up for hours until I rebooted. It has gone down a few times since then
> without so much as a squeak from the kernel, just massive packet loss.
> Any ideas?
The pppd behavior is known and annoying - it needs changes to the kernel's
pppoatm module, but I never managed to convince its author of that. As for
the above, I think it would be best to wait for the CONFIG_USB_DEBUG results
before speculating.
Best wishes,
Duncan.
Liste de diffusion modem ALCATEL SpeedTouch USB
Pour se désinscrire : mailto:[EMAIL PROTECTED]
