[speedtouch] Re: speedtouch 330 - a lot of "usb_submit_urb returned -22" messages
07-01-01, Duncan Sands <[EMAIL PROTECTED]> napisał(a): > > > usb 1-2: usbdev_ioctl: SUBMITURB > > usb 1-2: bulk urb > > usb 1-2: submit urb > > usb 1-2: direction=IN > > usb 1-2: userurb=bf82efec > > usb 1-2: transfer_buffer_length=6 > > usb 1-2: actual_length=0 > > usb 1-2: data: c0 01 0f 00 00 00 > > usb 1-2: usbfs: usb_submit_urb returned -22 > > It looks to me like -EINVAL (-22) is being returned > from the host controller driver (hcd). Which one > are you using? uhci_hcd, ehci_hcd, ohci_hcd ? uhci_hcd #lspci -v |grep USB 00:07.2 USB Controller: Intel Corporation 82371AB/EB/MB PIIX4 USB (rev 01) (prog-if 00 [UHCI]) in file /usr/src/linux/Documentation/usb/error-codes.txt I found this(maybe it can help): [...] ** * Error codes returned by usb_submit_urb * ** [...] -EINVAL a) Invalid transfer type specified (or not supported) b) Invalid or unsupported periodic transfer interval c) ISO: attempted to change transfer interval d) ISO: number_of_packets is < 0 e) various other cases [...] Liste de diffusion modem ALCATEL SpeedTouch USB Pour se désinscrire : mailto:[EMAIL PROTECTED]
[speedtouch] packet loss with kernel 2.6.17.8
Duncan Sands wrote: > Hi > >> I wonder if you could help me with a problem I have with my kernel >> and ST330? My ST330 (V4, black) is connected to an old K6 400Mhz >> box which runs kernel 2.6.17.8 and used to run for days on end with >> a 2Mb link. Since I was upgraded 8Mb the modem has synced at maximum >> rate and works fine. >> >> But since the DSL upgrade, at some time between a few minutes and >> two weeks after bringing the ppp link up I experience massive packet >> loss (80-90% is typical). This does not cure itself unless I reboot, >> and even that doesn't always clear the problem. The problem goes on for >> hours. There are no messages of any kind in the logs. > > please rebuild your kernel with CONFIG_USB_DEBUG=y. You may well then > get some helpful messages. > >> However, from time to time, and seemingly unconnected to the packet-loss >> events I see a reference to an urb having failed (I'm afraid I no longer >> have a log file to look at, so I cannot be precise about the message). >> Well, here are the results... Dec 31 15:09:26 pfw pppd[3927]: Plugin pppoatm.so loaded. Dec 31 15:09:26 pfw pppd[3927]: PPPoATM plugin_init Dec 31 15:09:26 pfw pppd[3927]: PPPoATM setdevname_pppoatm - SUCCESS:0.38 Dec 31 15:09:26 pfw pppd[3927]: pppd 2.4.4 started by root, uid 0 Dec 31 15:09:26 pfw kernel: ATM dev 0: usbatm_atm_open: vpi 0, vci 38 Dec 31 15:09:26 pfw kernel: ATM dev 0: usbatm_atm_open: allocated vcc data 0xd5963980 Dec 31 15:09:26 pfw pppd[3927]: Using interface ppp0 Dec 31 15:09:26 pfw pppd[3927]: Connect: ppp0 <--> 0.38 Dec 31 15:09:29 pfw pppd[3927]: CHAP authentication succeeded Dec 31 15:09:29 pfw pppd[3927]: CHAP authentication succeeded Dec 31 15:09:29 pfw pppd[3927]: local IP address xxx.xxx.xxx.xxx Dec 31 15:09:29 pfw pppd[3927]: remote IP address yyy.yyy.yyy.yyy 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)! Dec 31 21:01:39 pfw last message repeated 4 times Dec 31 21:01:39 pfw kernel: ATM dev 0: usbatm_extract_one_cell: bogus pdu_length 1536 (sarb->len: 1488, vcc: 0xd6812400)! Dec 31 21:01:40 pfw kernel: ATM dev 0: usbatm_extract_one_cell: bogus pdu_length 1536 (sarb->len: 1488, vcc: 0xd6812400)! Dec 31 21:01:40 pfw kernel: ATM dev 0: usbatm_extract_one_cell: packet failed crc check (vcc: 0xd6812400)! Dec 31 21:01:43 pfw last message repeated 3 times Dec 31 21:01:54 pfw kernel: printk: 1 messages suppressed. Dec 31 21:01:54 pfw kernel: ATM dev 0: usbatm_extract_one_cell: packet failed crc check (vcc: 0xd6812400)! Dec 31 21:01:54 pfw kernel: ATM dev 0: usbatm_extract_one_cell: bogus pdu_length 1536 (sarb->len: 1488, vcc: 0xd6812400)! Dec 31 21:02:01 pfw kernel: printk: 4 messages suppressed. Dec 31 21:02:01 pfw kernel: ATM dev 0: usbatm_extract_one_cell: bogus pdu_length 1536 (sarb->len: 1488, vcc: 0xd6812400)! Dec 31 21:02:07 pfw kernel: ATM dev 0: usbatm_extract_one_cell: packet failed crc check (vcc: 0xd6812400)! Dec 31 21:55:56 pfw kernel: ATM dev 0: usbatm_extract_one_cell: packet failed crc check (vcc: 0xd6812400)! Dec 31 21:56:21 pfw last message repeated 10 times Dec 31 21:56:28 pfw kernel: ATM dev 0: usbatm_extract_one_cell: packet failed crc check (vcc: 0xd6812400)! Dec 31 21:56:30 pfw kernel: ATM dev 0: usbatm_extract_one_cell: packet failed crc check (vcc: 0xd6812400)! Dec 31 21:56:32 pfw kernel: ATM dev 0: usbatm_extract_one_cell: bogus pdu_length 144 (sarb->len: 96, vcc: 0xd6812400)! Dec 31 21:56:34 pfw kernel: ATM dev 0: usbatm_extract_one_cell: packet failed crc check (vcc: 0xd6812400)! Dec 31 21:56:44 pfw last message repeated 2 times Dec 31 21:56:47 pfw kernel: ATM dev 0: usbatm_extract_one_cell: bogus pdu_length 192 (sarb->len: 144, vcc: 0xd6812400)! Dec 31 21:56:52 pfw kernel: ATM dev 0: usbatm_extract_one_cell: bogus pdu_length 1344 (sarb->len: 1296, vcc: 0xd6812400)! Dec 31 21:56:52 pfw kernel: ATM dev 0: usbatm_extract_one_cell: packet failed crc check (vcc: 0xd6812400)! Dec 31 21:56:52 pfw kernel: ATM dev 0: usbatm_extract_one_cell: packet failed crc check (vcc: 0xd6812400)! Dec 31 21:56:56 pfw kernel: printk: 2 messages suppressed. Dec 31 21:56:56 pfw kernel: ATM dev 0: usbatm_extract_one_cell: bogus pdu_length Then there was a continuous stream of similar messages unt
[speedtouch] Re: gyp from kernel > 2.6.17.8
Duncan Sands wrote: NET: Unregistered protocol family 20 speedtch: Unknown symbol usbatm_usb_disconnect speedtch: Unknown symbol usbatm_usb_probe >>> I don't know what these unknown symbols are about. >> Neither do I > > Just a thought: do you have CONFIG_MODULE_FORCE_UNLOAD > set in your kernel's .config? > Yes, once MODULE_UNLOAD is set MODULE_FORCE_UNLOAD is on via the default configuration options in 2.6.19.1. That said, looking back through my cvs it seems that I on earlier versions I had explicitly set it (although why I don't know). Should I try unsetting it? Steve Liste de diffusion modem ALCATEL SpeedTouch USB Pour se désinscrire : mailto:[EMAIL PROTECTED]
[speedtouch] Re: gyp from kernel > 2.6.17.8
> 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. Fixed you say? Oh dear. # lspci 00:00.0 Host bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3] (rev 04) 00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598/694x [Apollo MVP3/Pro133x AGP] 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C586/A/B PCI-to-ISA [Apollo VP] (rev 47) 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) 00:07.2 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 02) 00:07.3 Host bridge: VIA Technologies, Inc. VT82C586B ACPI (rev 10) The motherboard is that well-known turkey, the TI5-VG+, with its broken mouse ports, PCI bus which works only in an advisory capacity and so on. That said, USB serial ports & flash sticks work fine on <2.6.17.8. I've not tested a later kernel with other USB devices. > 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 Interesting. I'm currently using ZZZL_3.012 from http://www.speedtouchdsl.com/download/drivers/USB/SpeedTouch330_firmware_3012.zip this being the only file which the firmware extractor at http://www.linux-usb.org/SpeedTouch/firmware/firmware-extractor.tar.gz will extract. I tried the URL you quoted but it has moved, so I briefly scouted their web site and came up with a few possibles: None of the links on http://www.speedtouch.co.uk/codepages/content3.asp?c=7&ProductID=471 work whilst http://www.speedtouch.com/support.htm leads to http://www.speedtouch.com/download/drivers/USB/SpeedTouch330_firmware_3012.zip which looks like what I'm running now. Any ideas where the new firmware is? Do I need a new firmware extractor too? > Maybe usbatm is built into the kernel, but speedtouch is a module, or > vice-versa? Nope, USB is modular. > 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. That's fine, I'll set up some monitoring scripts. > As for > the above, I think it would be best to wait for the CONFIG_USB_DEBUG results > before speculating. Here are the results of booting the box with CONFIG_USB_DEBUG on: If I boot 2.6.19.1 with the modem is plugged in during the boot the results are no different to what you've seen already. I assume this is something to do with klogd not having started at that point in the boot. The results do not change if dl_512_first=1 is in modprobe.conf or not. If I put enable_isoc=1 in modprobe.conf the boot now proceeds past loading the speedtch module, allowing other modules to load normally. The messages are unchanged however. But if I unplug the modem during the boot and plug it in after logging in it all becomes much clearer. Here is an snippet of the relevant messages: boot usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb USB Universal Host Controller Interface driver v3.0 uhci_hcd :00:07.2: UHCI Host Controller drivers/usb/core/inode.c: creating file 'devices' drivers/usb/core/inode.c: creating file '001' uhci_hcd :00:07.2: new USB bus registered, assigned bus number 1 uhci_hcd :00:07.2: detected 2 ports uhci_hcd :00:07.2: uhci_check_and_reset_hc: cmd = 0x uhci_hcd :00:07.2: Performing full reset uhci_hcd :00:07.2: irq 11, io base 0xd400 usb usb1: default language 0x0409 usb usb1: new device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: UHCI Host Controller usb usb1: Manufacturer: Linux 2.6.19.1-skas3-v9-pre9 uhci_hcd usb usb1: SerialNumber: :00:07.2 usb usb1: uevent usb usb1: usb_probe_device usb usb1: configuration #1 chosen from 1 choice usb usb1: adding 1-0:1.0 (config #1, interface 0) usb 1-0:1.0: uevent hub 1-0:1.0: usb_probe_interface hub 1-0:1.0: usb_probe_interface - got id hub 1-0:1.0: USB hub found hub 1-0:1.0: 2 ports detected hub 1-0:1.0: standalone hub hub 1-0:1.0: no power switching (usb 1.0) hub 1-0:1.0: individual port over-current protection hub 1-0:1.0: power on to power good time: 2ms hub 1-0:1.0: local power source is good hub 1-0:1.0: trying to enable port power on non-switchable hub hub 1-0:1.0: state 7 ports 2 chg evt drivers/usb/core/inode.c: creating file '001' uhci_hcd :00:07.2: port
[speedtouch] Re: speedtouch 330 - a lot of "usb_submit_urb returned -22" messages
> usb 1-2: usbdev_ioctl: SUBMITURB > usb 1-2: bulk urb > usb 1-2: submit urb > usb 1-2: direction=IN > usb 1-2: userurb=bf82efec > usb 1-2: transfer_buffer_length=6 > usb 1-2: actual_length=0 > usb 1-2: data: c0 01 0f 00 00 00 > usb 1-2: usbfs: usb_submit_urb returned -22 It looks to me like -EINVAL (-22) is being returned from the host controller driver (hcd). Which one are you using? uhci_hcd, ehci_hcd, ohci_hcd ? Ciao, Duncan. Liste de diffusion modem ALCATEL SpeedTouch USB Pour se désinscrire : mailto:[EMAIL PROTECTED]
[speedtouch] Re: gyp from kernel > 2.6.17.8
> >> NET: Unregistered protocol family 20 > >> speedtch: Unknown symbol usbatm_usb_disconnect > >> speedtch: Unknown symbol usbatm_usb_probe > > > > I don't know what these unknown symbols are about. > > Neither do I Just a thought: do you have CONFIG_MODULE_FORCE_UNLOAD set in your kernel's .config? Duncan. Liste de diffusion modem ALCATEL SpeedTouch USB Pour se désinscrire : mailto:[EMAIL PROTECTED]
