Thank you for your analysis! I checked that the lost sector is not at the beginning, and I hope it's not in the middle either. So I can avoid using the last few sectors and live with it. Thanks again and sorry for wasting your time on a bug that's not in the linux kernel. On Mon, Apr 3, 2017 at 6:04 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Mon, 3 Apr 2017, Guan Xin wrote: > >> Not sure if attachments can be sent around on a mailing list. >> I'll put it into the content if you don't see the attached "usbmon.log >> (100004 bytes, 1398 lines)". > > Here's your answer. From the usbmon trace: > > ffff8800765753c0 1906124951 S Bo:1:015:4 -115 32 = 01000001 00000000 00000000 00000000 9e100000 00000000 00000000 00200000 > ffff8800765753c0 1906125049 C Bo:1:015:4 0 32 > > > 9e100000... is a READ CAPACITY(16) command. > > ffff8800765756c0 1906125174 C Bi:1:015:3 0 4 = 06000001 > ffff880076575c00 1906125177 S Bi:1:015:3 -115 112 < > ffff8800765759c0 1906125179 S Bi:1:015:1 -115 32 < > ffff8800765759c0 1906125299 C Bi:1:015:1 0 32 = 00000001 d1c0beae 00000200 00000000 00000000 00000000 00000000 00000000 > > The first 8 bytes of the response are the RETURNED LOGICAL BLOCK > ADDRESS, which is the block number of the highest available block on > the device. The value 0x1d1c0beae is equal to 7814037166, which means > the USB-SATA bridge is telling the computer that the drive has > 7814037167 blocks. > > The same command appears at several points in the trace, and the > response is always the same. > > So if there's a bug, it's in the USB-SATA bridge. > > 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
