Diagnosing a faulty 8GB USB drive
in [Linux Hardware]
|
From: UHAP023 on 11 Jul 2008 11:45 phil-news-nospam(a)ipal.net wrote: : On Wed, 25 Jun 2008 04:04:48 +0000 (UTC) UHAP023(a)alpha1.rhbnc.ac.uk wrote: : | I have an 8GB USB memory stick which I believe is faulty. I know : | there are duff USB sticks out there on the market. The vendor assures : | me that all items are checked before dispatch and so I would like to : | demonstrate/verify the problem for him. : | : | The device identifies its capacity as 8GB and will format OK (under : | both WinXP PRO SP2 / FAT32 and Linux Ext2 & FAT32). The symptoms are : | if less than ~2GB is used the data remains valid. If more than ~2GB : | is used corrupt files result. Running badblocks in default write mode : | (fills the whole device & then verifies, with in turn; 0xaa, 0x55, : | 0xff, 0x00) shows no errors but in random byte mode, beyond block : | 2059776 (ie. approx. 2GB) is flagged as bad. : | : | Below is the set of tests I've used. Is there anything I've overlooked? Unfortunately I've returned the USB stick to the vendor who offered a full refund. : This would give me some bit of more accurate info: : fdisk -lu /dev/sda : The "u" specifies to give partitions in sectors instead of cylinders. Sure but I would be surprised if the partition table were bad, firstly because Linux fdisk created and subsequently reported it as OK and secondly because the first corrupt sector reported by badblocks was consistently far above the first 512 bytes (~2GB). : I'd be curious just what specific errors happened. Bit inversions? : Copy between blocks? Shifting? Apparently whatever error is : something not affected by the non-random pattern. Yes, this would have been interesting to know. However 0xaa, 0x55, 0xff & 0x00 is not a bad test suite since it checks all bits with and without different bit neighbours. The other possibility as you say is that adjacent (or even other non-adjacent) (byte) locations have a corrupting effect. I copied some MP3 files to the device and those lying beyond the first ~2GB were, IIRC quite corrupt. Dumping some of the files I used shows they comprise a short header with title/track etc. information followed by a block of 0x00 bytes and then the (naturally high entropy) coded audio data. IIRC those read back files beyond ~2GB were unrecognisable -- eg. no blocks of identical data as one would get with bit-inverted blocks of 0x00. Then again this was being done under an FS which certainly had acquired corruptions... : I just ran the badblocks test on a 2GB CF card (sdc), a 2GB SD card (sdd), and : a 4GB USB key (sde), and got no errors. So you are definitely getting something : I have not gotten. So there's no way someone can say that the output you see is : in any way a normal output. OTOH, these are not perfect random patterns they : use, as they do repeat and could fail to detect certain leakage issues. Thanks for running these tests. In particular your successful /dev/sde test indicates 2GB size limits were probably not the problem as was suggested might be the case further up this thread. Cheers Tom. Ps. The email address in the header is just a spam-trap. -- Tom Crane, Dept. Physics, Royal Holloway, University of London, Egham Hill, Egham, Surrey, TW20 0EX, England. Email: T.Crane at rhul dot ac dot uk Fax: +44 (0) 1784 472794
From: phil-news-nospam on 12 Jul 2008 13:08
On Fri, 11 Jul 2008 15:45:15 +0000 (UTC) UHAP023(a)alpha1.rhbnc.ac.uk wrote: | Unfortunately I've returned the USB stick to the vendor who offered a | full refund. Well at least you get to start over with a new one, if you elect to buy another. | Yes, this would have been interesting to know. However 0xaa, 0x55, | 0xff & 0x00 is not a bad test suite since it checks all bits with and | without different bit neighbours. The other possibility as you say is | that adjacent (or even other non-adjacent) (byte) locations have a | corrupting effect. I copied some MP3 files to the device and those | lying beyond the first ~2GB were, IIRC quite corrupt. Dumping some of | the files I used shows they comprise a short header with title/track | etc. information followed by a block of 0x00 bytes and then the | (naturally high entropy) coded audio data. IIRC those read back files | beyond ~2GB were unrecognisable -- eg. no blocks of identical data as | one would get with bit-inverted blocks of 0x00. Then again this was | being done under an FS which certainly had acquired corruptions... I've found that pattern sequence has failed to detect RAM errors in the past. There are a lot of ways to leak between bits and this pattern could line up with one leak and always leak the same bit and hence not be seen. -- |WARNING: Due to extreme spam, googlegroups.com is blocked. Due to ignorance | | by the abuse department, bellsouth.net is blocked. If you post to | | Usenet from these places, find another Usenet provider ASAP. | | Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) | |