-----linux-usb-owner@xxxxxxxxxxxxxxx wrote: -----
>usb_kill_urb() blocks. But investigating that function won't help,
>because it blocks waiting for the hardware. Clearly the problem lies
>
>in your nVidia chipset.
Right. I added a printk to the usb_kill_urb() function just to see what's
in urb->use_count.
printk("%s() urb->use_count =
%i",__func__,urb->use_count);
wait_event(usb_kill_urb_queue,
atomic_read(&urb->use_count) == 0);
and it echos:
Nov 17 15:38:00 Server [ 5566.390101] drivers/usb/serial/ftdi_sio.c:
ftdi_close
Nov 17 15:41:14 Server [ 5566.390105] usb_kill_urb urb->use_count =
-2033381168
So, as you stated, investigating this function will not help because the
use_count variable will be changed from somewhere else in the kernel.
>If you want to delve deeper, make sure your kernel has
>CONFIG_USB_DEBUG
>and CONFIG_DEBUG_FS enabled. Mount a debugfs filesystem on
>/sys/kernel/debug. Then when the hang occurs, go into the
>appropriate
>subdirectory of /sys/kernel/debug/usb/ohci (the one corresponding to
>the controller your FTDI device is plugged into) and collect copies
>of
>the files there.
>
>Alan Stern
Okay here are the contents of the files while the controller hangs. But i
have no clue what these contents mean.
Server ~ # ls -al /sys/kernel/debug/usb/ohci/0000\:00\:02.0/
total 0
drwxr-xr-x 2 root root 0 Nov 17 15:05 .
drwxr-xr-x 4 root root 0 Nov 17 15:05 ..
-r--r--r-- 1 root root 0 Nov 17 15:05 async
-r--r--r-- 1 root root 0 Nov 17 15:05 periodic
-r--r--r-- 1 root root 0 Nov 17 15:05 registers
Server ~ # cat /sys/kernel/debug/usb/ohci/0000\:00\:02.0/async
Server ~ # cat /sys/kernel/debug/usb/ohci/0000\:00\:02.0/periodic
size = 32
Server ~ # cat /sys/kernel/debug/usb/ohci/0000\:00\:02.0/registers
bus pci, device 0000:00:02.0
OHCI Host Controller
ohci_hcd
OHCI 1.0, NO legacy support registers
control 0x683 RWE RWC HCFS=operational CBSR=3
cmdstatus 0x00000 SOC=0
intrstatus 0x00000024 FNO SF
intrenable 0x8000005a MIE RHSC UE RD WDH
ed_controlhead 0581f000
hcca frame 0xfb06
fmintvl 0xa7782edf FIT FSMPS=0xa778 FI=0x2edf
fmremaining 0x80001a18 FRT FR=0x1a18
periodicstart 0x2a2f
lsthresh 0x0700
hub poll timer off
roothub.a 01000206 POTPGT=1 NPS NDP=6(6)
roothub.b 00000000 PPCM=0000 DR=0000
roothub.status 00008000 DRWE
roothub.portstatus [0] 0x00000100 PPS
roothub.portstatus [1] 0x00000103 PPS PES CCS
roothub.portstatus [2] 0x00000100 PPS
roothub.portstatus [3] 0x00000100 PPS
roothub.portstatus [4] 0x00000100 PPS
roothub.portstatus [5] 0x00000100 PPS
It looks like the whole USB host controller for the bus 002 causes
problems, because if i do a lsusb -v then i get timeouts on the devices
connected to the bus 002. The bus 001 works without problems.
Server ~ # lsusb -v -s 002:002
Bus 002 Device 002: ID 0403:6001 Future Technology Devices International,
Ltd FT232 USB-Serial (UART) IC
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x0403 Future Technology Devices International, Ltd
idProduct 0x6001 FT232 USB-Serial (UART) IC
bcdDevice 6.00
iManufacturer 1
iProduct 2
iSerial 3
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 32
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 90mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 2
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
can't get device qualifier: Connection timed out
can't get debug descriptor: Connection timed out
cannot read device status, Connection timed out (110)
Server ~ # lsusb -v -s 001
Bus 002 Device 001: ID 1d6b:0001
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 0 Full speed (or root) hub
bMaxPacketSize0 64
idVendor 0x1d6b
idProduct 0x0001
bcdDevice 2.06
iManufacturer 3 Linux 2.6.34-gentoo-r12 ohci_hcd
iProduct 2 OHCI Host Controller
iSerial 1 0000:00:04.0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 25
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0002 1x 2 bytes
bInterval 255
Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 6
wHubCharacteristic 0x0002
No power switching (usb 1.0)
Ganged overcurrent protection
bPwrOn2PwrGood 1 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
DeviceRemovable 0x00
PortPwrCtrlMask 0xff
Hub Port Status:
Port 1: 0000.0103 power enable connect
Port 2: 0000.0103 power enable connect
Port 3: 0000.0100 power
Port 4: 0000.0100 power
Port 5: 0000.0100 power
Port 6: 0000.0100 power
Device Status: 0x0003
Self Powered
Remote Wakeup Enabled
Regards.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
