David Laight wrote on 07/09/16 18:25: > I'd expect files much smaller than 500MB to fail if the problem was > actually to do with a 64 sector limit. > > So I'm guessing that this isn't the fix. > > Much more likely is that limiting the sector count to 64 stops transfers > crossing some sector boundary (maybe at 500MB ?). I did some more tests. The test system for these tests runs Fedora 24 with kernel 4.6.4-301.fc24.x86_64, 8GB RAM, i5-4670. The problems also occurs on the most recent 4.7.2-201.fc24.x86_64 on two other machines (HP EB 820 G1, ASUS Z170/i5-6500). I removed the quirks option and generated random files with different sizes with eg: dd if=/dev/urandom iflag=fullblock of=256MB.test bs=1M count=256 I tried: 256,320,352,368,376,380,382,383,384,512,640,768 I copied them multiple times to the stick with a small script doing cp .... sync sleep 20 and until now the smallest file with damage was the 352MB file. First I thought it's arround 384MB, but then smaller files failed sometimes as well. I checked some files with vbindiff and search for the damaged regions. They always start on clean 0x1000 borders and end with 0x3FFF, 0x7FFF, 0xAFFF or 0xFFFF. Most of the time 0x7FFF and 0xFFFF. 0x3FFF and 0xAFFF seem to occur only if it starts exactly at 0x0000 or 0x8000 and size is 0x4000. Sizes seen go from 0x1000 up to 0x7000. The larger the file gets it's more likely it's damaged. Up to 320MB all test files were ok. Starting at 352MB up to 384MB the likelyness raises and from 512MB up all files were damaged. I tried to find the first 8 hex bytes of the wrong sectors in the rest of the file, but they do not occure anywhere else, neither in the original file nor in the copy. So it's not a leftover from some other buffer of the same file. damaged regions: 352MB.test2: 0x1353B000-0x1353FFFF 368MB.test1: 0x15B4B000-0x15B4FFFF 376MB.test2: 0x13AB3000-0x13AB7FFF 380MB.test1: 0x138FC000-0x138FFFFF 0x14907000-0x14907FFF 0x14931000-0x14937FFF 0x1694C000-0x1694FFFF 381MB.test1: 0x14011000-0x14017FFF 382MB.test1: 0x135F8000-0x135FAFFF 383MB.test3: 0x0EC0A000-0x0EC0FFFF 0x15D0B000-0x15D0FFFF 384MB.test: 0x087FB000-0x087FFFFF 0x13959000-0x1395FFFF 384MB.test2: 0x159B2000-0x159B7FFF 0x169EC000-0x169EFFFF 384MB.test3: 0x151C3000-0x151C7FFF 512MB.test: 0x0FBA7000-0x0FBA7FFF 0x11BFC000-0x11BFFFFF 0x16C95000-0x16C97FFF 0x18CD4000-0x18CD7FFF 0x1ED7D000-0x1ED7FFFF 0x1FDAF000-0x1FDAFFFF 512MB.test2: 0x0705D000-0x0705FFFF 0x16263000-0x16267FFF 0x192AC000-0x192AFFFF 0x192E6000-0x192E7FFF 0x1F360000-0x1F363FFF 0x1F372000-0x1F377FFF If I can do anything else to find the source of this corruptions I will try to help. With kind regards, Wolfgang Breyha -- Wolfgang Breyha <wbreyha@xxxxxxx> | http://www.blafasel.at/ Vienna University Computer Center | Austria -- 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
