On Mon, 23 Mar 2015, Marc Joliet wrote:
> OK, I got it down to 763 lines total because of various kernel messages and I
> was worried that they might provide important context, so it's not quite down to
> 200 lines, but I hope that's close enough. The logs for the reconnect start
> after line 323 ("kernel: usb 4-2: USB disconnect, device number 2").
All right. Here is the important part from the first connection
(starting at line 146):
Mär 22 23:06:53 marcec usbmon[193]: dd068e40 1.797762 S Bo:4:002:2 - 31 =
Mär 22 23:06:53 marcec usbmon[193]: 55534243 04000000 20000000 8000109e 10000000 00000000 00000000 200000
Mär 22 23:06:53 marcec usbmon[193]: U S B C . . . . . . . . . . . . . . . . . . . . . . . . .
Mär 22 23:06:53 marcec usbmon[193]: dd068e40 1.797775 C Bo:4:002:2 0 31 >
The computer sends a READ CAPACITY(16) command to the drive.
Mär 22 23:06:53 marcec usbmon[193]: d1705300 1.797782 S Bi:4:002:1 - 32 <
Mär 22 23:06:53 marcec usbmon[193]: d1705300 1.800050 C Bi:4:002:1 -121 16 =
Mär 22 23:06:53 marcec usbmon[193]: 00000001 5d50a3a7 00000200 00000000
Mär 22 23:06:53 marcec usbmon[193]: . . . . ] P . . . . . . . . . .
The drive responds, saying it has 5860533160 (1 + 0x15d50a3a7 in hex)
512-byte blocks.
Mär 22 23:06:53 marcec usbmon[193]: dd068e40 1.800064 S Bi:4:002:1 - 13 <
Mär 22 23:06:53 marcec usbmon[193]: dd068e40 1.800084 C Bi:4:002:1 0 13 =
Mär 22 23:06:53 marcec usbmon[193]: 55534253 04000000 14000000 00
Mär 22 23:06:53 marcec usbmon[193]: U S B S . . . . . . . . .
The drive sends a status response, saying the command completed
successfully but the output was 20 bytes shorter than requested, which
means that only the first 12 bytes of the 16-byte reply above were
valid. Since the first 8 bytes of the response are the highest block
number and the next 4 bytes are the block size, that's okay.
The same command and response were repeated starting at line 201.
After the second connection, the corresponding command occurs starting
at line 455:
Mär 22 23:08:12 marcec usbmon[1007]: 7c9d0900 14.350943 S Bo:4:003:2 - 31 =
Mär 22 23:08:12 marcec usbmon[1007]: 55534243 04000000 20000000 8000109e 10000000 00000000 00000000 200000
Mär 22 23:08:12 marcec usbmon[1007]: U S B C . . . . . . . . . . . . . . . . . . . . . . . . .
Mär 22 23:08:12 marcec usbmon[1007]: 7c9d0900 14.356106 C Bo:4:003:2 0 31 >
The computer sends a READ CAPACITY(16) command.
Mär 22 23:08:12 marcec usbmon[1007]: dc19be40 14.356130 S Bi:4:003:1 - 32 <
Mär 22 23:08:12 marcec usbmon[1007]: dc19be40 14.380292 C Bi:4:003:1 -121 16 =
Mär 22 23:08:12 marcec usbmon[1007]: 00000000 2baa1474 00001000 00000000
Mär 22 23:08:12 marcec usbmon[1007]: . . . . + . . t . . . . . . . .
The drive responds, saying it has 732566645 (1 + 0x2baa1474 in hex)
4096-byte blocks.
Mär 22 23:08:12 marcec usbmon[1007]: 7c9d0900 14.380318 S Bi:4:003:1 - 13 <
Mär 22 23:08:12 marcec usbmon[1007]: 7c9d0900 14.380336 C Bi:4:003:1 0 13 =
Mär 22 23:08:12 marcec usbmon[1007]: 55534253 04000000 14000000 00
Mär 22 23:08:12 marcec usbmon[1007]: U S B S . . . . . . . . .
And again, the status is okay but the response is 20 bytes shorter than
requested.
Interestingly, at line 503 there is a READ CAPACITY(10) command. The
response was the same as for the READ CAPACITY(16) -- this time the
10-byte form of the command was sufficient because now the block count
is able to fit into four bytes.
As you can see, the drive (or rather, the USB adapter) sent two
different responses to the very same READ CAPACITY(16) command. This
must be caused by the adapter's firmware.
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
