On Wed, 17 Nov 2010 david.schueler@xxxxxxxxxxxxxxxxxxx wrote:
> -----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);
In theory you should print atomic_read(&urb->use_count) instead of
urb->use_count itself. That explains why you got the ridiculous value.
> 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/
This is the wrong directory -- it is the directory for bus 1. You need
the directory for bus 2: /sys/kernel/debug/usb/ohci/0000:00:04.0/
> 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.
If you plug your FTDI device into bus 1 instead of bus 2, does the
weather-station program then work okay?
> 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
Here's where that directory name comes from.
Alan Stern
--
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
