Hide Forgot
Description of problem: I bought a new USB Stick, a KINGSTON 100 G3/32GB [0951:1666]. I reformatted it from exFAT to FAT32. If I "cp" large files to it they get corrupted. dmesg says on mount: [2754474.126374] usb-storage 3-5:1.0: USB Mass Storage device detected [2754474.126487] scsi host6: usb-storage 3-5:1.0 [2754475.130068] scsi 6:0:0:0: Direct-Access Kingston DataTraveler 3.0 PMAP PQ: 0 ANSI: 6 [2754475.130541] sd 6:0:0:0: Attached scsi generic sg2 type 0 [2754476.534135] sd 6:0:0:0: [sdb] 60632064 512-byte logical blocks: (31.0 GB/28.9 GiB) [2754476.534237] sd 6:0:0:0: [sdb] Write Protect is off [2754476.534239] sd 6:0:0:0: [sdb] Mode Sense: 23 00 00 00 [2754476.534357] sd 6:0:0:0: [sdb] No Caching mode page found [2754476.534358] sd 6:0:0:0: [sdb] Assuming drive cache: write through [2754476.537396] sdb: sdb1 [2754476.538608] sd 6:0:0:0: [sdb] Attached SCSI removable disk lsusb: Bus 003 Device 061: ID 0951:1666 Kingston Technology DataTraveler G4 Version-Release number of selected component (if applicable): How reproducible: I use f3read/f3write from package "f3" to test it. First I start f3write --start-at=1 --end-at=3 /run/media/<path> then I remove the stick and attach it again. f3read shows no errors. Then I copy 1.h2w to my local disk (md5sum is ok) Then I copy it back to the usb stick with plain "cp". md5sum differs and another f3read shows (2.h2w was copied back in this case): $ f3read KINGSTON SECTORS ok/corrupted/changed/overwritten Validating file 1.h2w ... 2097152/ 0/ 0/ 0 Validating file 2.h2w ... 2096920/ 232/ 0/ 0 Validating file 3.h2w ... 2097152/ 0/ 0/ 0 Watching the check it seems that all the errors are beyond 512MB. This also fits to the fact that copying small amounts or smaller files does no harm. It seems f3write uses a method to write which does not cause damage as well. Using "dd bs=1MB if=... of=..." makes not difference to "cp". Doing the copy to disk and back to stick on Windows 10 does no harm to the files. Steps to Reproduce: 1. use given USB Stick 2. install package "f3" 3. do the steps described above Actual results: Files get corrupted Expected results: Files get copied correctly Additional info: I don't know if this is a design flaw in the Stick and I should RMA it, but since it seems to work on Windows I opened the bug first.
I got a replacement from Kingston. Same issue: $ f3read . SECTORS ok/corrupted/changed/overwritten Validating file 1.h2w ... 2097152/ 0/ 0/ 0 Validating file 2.h2w ... 2097152/ 0/ 0/ 0 Data OK: 2.00 GB (4194304 sectors) Data LOST: 0.00 Byte (0 sectors) Corrupted: 0.00 Byte (0 sectors) Slightly changed: 0.00 Byte (0 sectors) Overwritten: 0.00 Byte (0 sectors) Average reading speed: 389.07 MB/s $ cp *.h2w /run/media/xxxxx/KINGSTON/ $ f3read /run/media/xxxxx/KINGSTON/ SECTORS ok/corrupted/changed/overwritten Validating file 1.h2w ... 2097072/ 80/ 0/ 0 Validating file 2.h2w ... 2096720/ 432/ 0/ 0 Data OK: 2.00 GB (4193792 sectors) Data LOST: 256.00 KB (512 sectors) Corrupted: 256.00 KB (512 sectors) Slightly changed: 0.00 Byte (0 sectors) Overwritten: 0.00 Byte (0 sectors) Average reading speed: 66.57 MB/s
A final update: These sticks work on up to 4.6.x with $ cat /etc/modprobe.d/unusual_usb.conf options usb-storage quirks=0951:1666:m I posted a patch to the kernel usb mailinglist which was not accepted since it doesn't fix the root cause of the problem. Setting max_sectors manually via /sys/devices/pci0000:00/0000:00:14.0/usb4/4-1/4-1:1.0/host6/target6:0:0/6:0:0:0/max_sectors works as well. Both "64" and "2048" works. Since kernel 4.7.x "2048" is used by default instead of "240" and the stick works as far as I can tell. Kingston is aware of this problem. Ticket Nr is "SR404587 B".
Sorry, but it wasn't the final update... Just had a corrupted file with max_sectors 2048 as well. It seems much more unlikely, but it still happens. This was on 4.6.4-301.fc24.x86_64 with max_sectors set to 2048 manually. Will try with most recent kernel soon.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 24 kernel bugs. Fedora 24 has now been rebased to 4.7.4-200.fc24. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 25, and are still experiencing this issue, please change the version to Fedora 25. If you experience different issues, please open a new bug report for those.
yes, this still happens. Less often since the change to max_sectors 2048, but # cat /etc/modprobe.d/unusual_usb.conf options usb-storage quirks=0951:1666:g is the only way to safely operate this stick. My first report that 2048 works as well proofed to be wrong meanwhile. Kingston closed the case after I reported that the quirks works. They most likely ignore that their sticks are broken by design causing data loss.
I had the same problem. I complained to Kingston and they sent me a replacement. I can not reproduce the bug with the replacement. The replacement has the same USB id, but some of the numbers written on the side are different, so maybe it is a new revision after all.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There are a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 24 kernel bugs. Fedora 25 has now been rebased to 4.10.9-100.fc24. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 26, and are still experiencing this issue, please change the version to Fedora 26. If you experience different issues, please open a new bug report for those.
*********** MASS BUG UPDATE ************** This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 2 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.