You should be more careful about the words you use.  The usbmon 
interface in debugfs monitors URBs.  It does not monitor USB 

Make sure you have CONFIG_PRINTK_TIME enabled so that you get 
high-resolution timestamps in the dmesg log.  Although these timestamps 
are not the same as the values used in usbmon, the difference between 
them remains fixed.  Therefore you can match up events between the two 
logs.

But you don't need a detailed comparison to find out which URB timed 
out.  You can tell by looking at the status code in the URB's 
completion line; a timeout will set the status to -2.

Alan Stern

--

[ message continues ]

Hi alan:



Recently I trace scsi and usb storage driver and try to improve the
read speed of my usb stick.
I have some questions about them:
1.  below is the struct of scsi cmd, and there is a list seems for
linking multiple scsi cmd
But I found usb storage driver seems always get one cmd at a time.
why don't upper layer link more of them to send it once?

struct scsi_cmnd {
	struct scsi_device *device;
	struct list_head list;  /* scsi_cmnd participates in queue lists */
    .........
    ...........

2. I have traced upper layer source code to find out where the scsi
cmd come from and I found it just pass from  cmd = req->special; one
of element of request_queue that passes to scsi_request_fn?
where and how upper layer made it?(I guess it should made from block layer )

great appreciate your kind help :)
vichy
--

[ message continues ]

hi all:


I can see -2 on the log of usbmon right now.
And it seems from usbmon_urb_complete
but if the timeout happen, which function call usbmon_urb_complete?

appreciate your kind help :)
vichy
--

[ message continues ]