Hi alan:
2010/11/22 Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>:
> On Mon, 22 Nov 2010, vichy wrote:
>
>> > Did you monitor the bus while running a test with a 10-second timeout?
>> > Maybe comparing the results of the two tests will explain why the
>> > timeout occurs.
>> I found there is debugfs I can use to monitor each urb transaction.
>
> You should be more careful about the words you use. The usbmon
> interface in debugfs monitors URBs. It does not monitor USB
> transactions.
thanks for your correction :)
>
>> But I have one question?
>> how could I combine output of dmesg and debugfs together?
>> There is an timeout error message in usb driver and I want to combine
>> dmesg together with urb traffic such that I can find out the urb of
>> timeout happened.
>
> 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.
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
--
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
