On Saturday 09 October 2004 1:48 pm, Luca wrote: > > I am developing a driver for an USB2 Camera controller. Everytime an URB is > (re)submitted from the isochronous endpoint, usb_submit_urb() exists with > error -108 (-ESHUTDOWN). After that, the device is disconnected > automatically from the USB2 host controller:
ESHUTDOWN means the HC died for some reason, so it'd be pointless to try submitting anything ... > ehci_hcd 0000:00:09.2: fatal error > ehci_hcd 0000:00:09.2: HC died; cleaning up > usb 4-1: USB disconnect, address 2 OK, there are two interesting things I see right away: - Using EHCI with isochronous transfers. That's experimental, and there's a known bug of some kind in the full speed scheduling. (Depending on configuration, it may just make noise instead of playing sound, for example; dunno about IN transfers.) I think it's just some quirk in split transaction scheduling. But I've not heard of any issues with high speed transfers, even at high bandwidth (8 MByte/sec and up). They wouldn't be at all surprising to me though. - A "fatal error", which some folk have been reporting recently but usually just at driver startup, not after it's worked well enough to enumerate anything. (So I think that's a different issue.) If _every_ isochronous URB you submit makes that happen, I've got to wonder if the URB itself is set up OK. > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x82 EP 2 IN > bmAttributes 1 > Transfer Type Isochronous > Synch Type none > wMaxPacketSize 0 > bInterval 1 Well that's bogus, maybe even illegal: wMaxPacketSize should be at least one byte! And you have two of those strange things in the default altsetting (rather than no endpoints at all). (Plus a bulk endpoint.) But it "shouldn't matter" either. > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x82 EP 2 IN > bmAttributes 1 > Transfer Type Isochronous > Synch Type none > wMaxPacketSize 5120 > bInterval 1 Looks like your "lsusb" is rather old. Get an updated one that knows about USB 2.0 and various other kinds of descriptor, maybe usbutils-0.12 from cvs at linux-usb.sf.net ... That 0x1400 doesn't parse as 5120 bytes, it parses as a bitfield with value 2 (+1 = 3) and one as 1024, combining to mean this endpoint is "high bandwidth" and involves three packets, of 1 KB each, per microframe (125 usec). > Bus 004 Device 001: ID 0000:0000 > Device Descriptor: > bLength 18 > bDescriptorType 1 > bcdUSB 2.00 > bDeviceClass 9 Hub > bDeviceSubClass 0 > bDeviceProtocol 1 > bMaxPacketSize0 8 > idVendor 0x0000 > idProduct 0x0000 > bcdDevice 2.06 > iManufacturer 3 Linux 2.6.9-rc3-bk5n ehci_hcd > iProduct 2 VIA Technologies, Inc. USB 2.0 > iSerial 1 0000:00:09.2 Urk. The VIA southbridge chips (VT8235, VT8237, etc) aren't much trouble, but it looks like your system is a P3/PIIX4 with one of the VIA add-in card that's got a VT6202 ... that particular chip's been a lot of trouble. (The VT6212 is much better, using silicon more like what's in the VT8237.) I've never gotten a good handle on what's up with the VT6202, but it's certainly acted rather unlike any other EHCI controller I've used. And I don't remember testing it with ISO of any kind, so trouble there wouldn't surprise me. If you're going to use add-in EHCI cards, try some other kind ... NEC cards tend to be solid, and as widely available as the VT6202 ones. > PCI: Found IRQ 9 for device 0000:00:09.2 > PCI: Sharing IRQ 9 with 0000:00:0b.0 > PCI: Sharing IRQ 9 with 0000:00:0b.1 One of the problems with the VT6202 was dropping IRQs. I'm not sure whether sharing made too much of a difference, but it could certainly aggravate some kinds of timing-related problems. > ehci_hcd 0000:00:09.2: VIA Technologies, Inc. USB 2.0 > ehci_hcd 0000:00:09.2: reset hcs_params 0x2204 dbg=0 cc=2 pcc=2 ordered !ppc > ports=4 > ehci_hcd 0000:00:09.2: reset hcc_params 0002 thresh 0 uframes 256/512/1024 > ehci_hcd 0000:00:09.2: irq 9, pci mem d0878000 > ehci_hcd 0000:00:09.2: new USB bus registered, assigned bus number 4 > ehci_hcd 0000:00:09.2: reset command 080002 (park)=0 ithresh=8 period=1024 > Reset HALT > ehci_hcd 0000:00:09.2: init command 010009 (park)=0 ithresh=1 period=256 RUN > ehci_hcd 0000:00:09.2: USB 2.0 enabled, EHCI 0.95, driver 2004-May-10 The basic issue with the VT6202 was that it was the first version of that silicon cell from VIA, to the 0.95 draft of the EHCI spec. The later versions of their EHCI cell behave better. > ehci_hcd 0000:00:09.2: supports USB remote wakeup > usb usb4: new device strings: Mfr=3, Product=2, SerialNumber=1 > usb usb4: default language 0x0409 > usb usb4: Product: VIA Technologies, Inc. USB 2.0 > usb usb4: Manufacturer: Linux 2.6.9-rc3-bk5n ehci_hcd > usb usb4: SerialNumber: 0000:00:09.2 > ... > hub 4-0:1.0: 4 ports detected > hub 4-0:1.0: standalone hub > hub 4-0:1.0: ganged power switching > hub 4-0:1.0: individual port over-current protection > hub 4-0:1.0: Single TT > hub 4-0:1.0: TT requires at most 8 FS bit times > hub 4-0:1.0: power on to power good time: 20ms > hub 4-0:1.0: local power source is good > hub 4-0:1.0: enabling power on all ports All that's fine, exactly as expected. Likewise with enumerating the device. However: > ehci_hcd 0000:00:09.2: GetStatus port 3 status 001030 POWER sig=se0 OCC OC > hub 4-0:1.0: over-current change on port 3 > hub 4-0:1.0: enabling power on all ports > ehci_hcd 0000:00:09.2: GetStatus port 4 status 001030 POWER sig=se0 OCC OC > hub 4-0:1.0: over-current change on port 4 > hub 4-0:1.0: enabling power on all ports Looks like powering up that port generated glitches on two other ports... I've been hearing a bunch of problems like that lately, but it looks like was no bad result in this case. And this would be your new driver: > Linux video capture interface: v1.00 > ------ > (*) dc1100: V4L2 driver for CT-DC1100 Video and Camera Controllers v1:1.00 > (*) dc1100: (C) 2004 Luca Risolia > dc1100 4-1:1.0: usb_probe_interface > dc1100 4-1:1.0: usb_probe_interface - got id > (*) usb 4-1: CT-DC1100 Video and Camera Controller detected (vid/pid > 0x0932/0x1100) > (*) usb 4-1: Device is at High-Speed mode > (*) usb 4-1: SAA7113H video source detected > (*) usb 4-1: Initialization succeeded > (*) usb 4-1: V4L2 device registered as /dev/video0 > usbcore: registered new driver dc1100 Can you report what happened after this and before the "fatal error"? If you #define EHCI_VERBOSE_DEBUG in "ehci-hcd.c" it will report a few interesting things. You may also need EHCI_URB_TRACE. > ehci_hcd 0000:00:09.2: fatal error > (*) usb 4-1: usb_submit_urb() failed, error -108 > ehci_hcd 0000:00:09.2: HC died; cleaning up > usb 4-1: USB disconnect, address 2 > usb 2-1: new full speed USB device using address 3 > usb 2-1: not running at top speed; connect to a high speed hub > usb 2-1: Product: USB 2.0 Camera > usb 2-1: Manufacturer: Crescentec Corp. - Dave ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
