On Wed, 25 Jun 2008 04:04:48 +0000, UHAP023 wrote:

> Dear All,
> 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?
>
> Thanks
> Tom Crane.
>

I believe you your vendor should also, tell them the same thing that you
told us. Don't mention Linux when you talk to them, just say that you ran
a disk diagnostic. Who did you buy the FLASH drive from?

on Wednesday 25 June 2008 14:04
in the Usenet newsgroup comp.os.linux.hardware
UHAP023@alpha1.rhbnc.ac.uk wrote:

> Dear All,
> 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?
[snip]

32 bit limit?


--
sig goes here...
Peter D.

On Wed, 25 Jun 2008 22:38:54 +1000, Peter D. wrote:

> on Wednesday 25 June 2008 14:04
> in the Usenet newsgroup comp.os.linux.hardware
> UHAP023@alpha1.rhbnc.ac.uk wrote:
>
>> Dear All,
>> 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?
> [snip]
>
> 32 bit limit?

First generation SD card readers were limited to 2G, the SDHC standard
raised that. I don't know if there was ever a limit for USB FLASH drives,
I doubt it because the controller is part of the drive. Also the fact
that the OP's systems see the drive as 8G would indicate that there isn't
any hardware limit.

General Schvantzkopf wrote:
: On Wed, 25 Jun 2008 22:38:54 +1000, Peter D. wrote:

: > on Wednesday 25 June 2008 14:04
: > in the Usenet newsgroup comp.os.linux.hardware
: > UHAP023@alpha1.rhbnc.ac.uk wrote:
: >
: >> Dear All,
: >> 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?
: > [snip]
: >
: > 32 bit limit?

: First generation SD card readers were limited to 2G, the SDHC standard
: raised that. I don't know if there was ever a limit for USB FLASH drives,
: I doubt it because the controller is part of the drive. Also the fact
: that the OP's systems see the drive as 8G would indicate that there isn't
: any hardware limit.

Agreed. Also my first bad block seems rather far from the 2GB limit;

tmp$ echo $[2**31] ! 2GB limit as bytes
2147483648
tmp$ echo $[1024*2059776] ! My first bad block as bytes
2109210624
tmp$ echo $[(2147483648-2109210624)/(1024*1024)] ! difference as MB.
36

Could anybody with a known good 8GB USB stick and similar kernel
reproduce/refute my results?

Cheers
Tom Crane.

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

In article ,
wrote:
> General Schvantzkopf wrote:
> : On Wed, 25 Jun 2008 22:38:54 +1000, Peter D. wrote:
>
> : > on Wednesday 25 June 2008 14:04
> : > in the Usenet newsgroup comp.os.linux.hardware
> : > UHAP023@alpha1.rhbnc.ac.uk wrote:
> : >
> : >> 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?
> : > [snip]
> : >
> : > 32 bit limit?
>
> : First generation SD card readers were limited to 2G, the SDHC standard
> : raised that. I don't know if there was ever a limit for USB FLASH drives,
> : I doubt it because the controller is part of the drive. Also the fact
> : that the OP's systems see the drive as 8G would indicate that there isn't
> : any hardware limit.
>
> Agreed. Also my first bad block seems rather far from the 2GB limit;
>
> tmp$ echo $[2**31] ! 2GB limit as bytes
> 2147483648
> tmp$ echo $[1024*2059776] ! My first bad block as bytes
> 2109210624
> tmp$ echo $[(2147483648-2109210624)/(1024*1024)] ! difference as MB.
> 36

So that's 36 MB into a what, 100 MB file? Sounds like a failure criterion
to me. Can you try something like

0/:
file_00
file_01
...
file_09
1/:
file_10
file_11
...
file_19
....
7/:
file_70
file_71
...
file_79

Why are you making a bunch of identical big files anyway? Just to fill
up the stick?

--
A well-lovd and corrctly traind domstc cnine is gnrlly slobbry, excitbl,
noisy, scatologically obsessed, xenophobic, pathetically unjudgmental,
embrrssngly uninhbtd, unreasnngly dvtd, hrtbrkngly dpndnt and wretchedly
craven. All othr knds of dog cmpre unfvrbly wth ths picture. - PB, AFCA

UHAP023@alpha1.rhbnc.ac.uk schrob:

> Dear All,
> 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?

A year ago vendors deliberately mislabelled their devices with incorrect
capacities. Someone from heise wrote a test tool für this case:
http://www.wintotal.de/Software/?id=4379
I don't know if it tells you more than you already know (because I haven't
used it yet), but you can still have a look.
--
Gruß | Greetings | Qapla'
What do you call a dead bee? - A was.

Hactar wrote:
: In article ,
: wrote:
: > General Schvantzkopf wrote:
: > : On Wed, 25 Jun 2008 22:38:54 +1000, Peter D. wrote:
: >
: > : > on Wednesday 25 June 2008 14:04
: > : > in the Usenet newsgroup comp.os.linux.hardware
: > : > UHAP023@alpha1.rhbnc.ac.uk wrote:
: > : >
: > : >> 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?
: > : > [snip]
: > : >
: > : > 32 bit limit?
: >
: > : First generation SD card readers were limited to 2G, the SDHC standard
: > : raised that. I don't know if there was ever a limit for USB FLASH drives,
: > : I doubt it because the controller is part of the drive. Also the fact
: > : that the OP's systems see the drive as 8G would indicate that there isn't
: > : any hardware limit.
: >
: > Agreed. Also my first bad block seems rather far from the 2GB limit;
: >
: > tmp$ echo $[2**31] ! 2GB limit as bytes
: > 2147483648
: > tmp$ echo $[1024*2059776] ! My first bad block as bytes
: > 2109210624
: > tmp$ echo $[(2147483648-2109210624)/(1024*1024)] ! difference as MB.
: > 36

: So that's 36 MB into a what, 100 MB file? Sounds like a failure criterion
: to me. Can you try something like

: 0/:
: file_00
: file_01
: ...
: file_09
: 1/:
: file_10
: file_11
: ...
: file_19
: ...
: 7/:
: file_70
: file_71
: ...
: file_79

That is pretty much what I was doing, except I had everything in the root
directory -- the total number of files was small after-all.

: Why are you making a bunch of identical big files anyway? Just to fill
: up the stick?

Exactly. It was just an easy way to check all its memory by checking
each file for integrity since I already had its md5 checksum. Any
corrupt space on the device then shows up easily.

Regards
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

Frank Steinmetzger wrote:
: UHAP023@alpha1.rhbnc.ac.uk schrob:

: > Dear All,
: > I have an 8GB USB memory stick which I believe is faulty. I know
[cut]
: > Below is the set of tests I've used. Is there anything I've overlooked?

: A year ago vendors deliberately mislabelled their devices with incorrect
: capacities. Someone from heise wrote a test tool f?r this case:
: http://www.wintotal.de/Software/?id=4379
: I don't know if it tells you more than you already know (because I haven't
: used it yet), but you can still have a look.

Many thanks for that tip. I've tested the memory stick with it on a
couple of different machines. Both give the same diagnostic as
follows;

The media is likely to be defective.
1.9 GByte OK (4087424 sectors)
5.8 GByte DATA LOST (12274048 sectors)
Details:5.8 GByte overwritten (12274048 sectors)
0 KByte slightly changed (< 8 bit/sector, 0 sectors)
0 KByte corrupted (0 sectors)
2 KByte aliased memory (4 sectors)
First error at offset: 0x000000007cbd0000
Expected: 0x000000007cbd0000
Found: 0x000000007cbcf800
H2testw version 1.3
Writing speed: 6.33 MByte/s
Reading speed: 12.9 MByte/s
H2testw v1.4

I don't think there can be any doubt now that the USB stick is faulty.

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

In article ,
wrote:
> Hactar wrote:
> : Can you try something like
>
> : 0/:
> : file_00
> : file_01
> : ...
> : file_09
> : 1/:
> : file_10
> : file_11
> : ...
> : file_19
> : ...
> : 7/:
> : file_70
> : file_71
> : ...
> : file_79
>
> That is pretty much what I was doing, except I had everything in the root
> directory -- the total number of files was small after-all.
>
> : Why are you making a bunch of identical big files anyway? Just to fill
> : up the stick?
>
> Exactly. It was just an easy way to check all its memory by checking
> each file for integrity since I already had its md5 checksum. Any
> corrupt space on the device then shows up easily.

Instead of 80 100-MB files, try 40 200-MB files and 160 50-MB files.
See whether it fails in about the same place.

--
-eben QebWenE01R@vTerYizUonI.nOetP royalty.mine.nu:81
> A: It's annoying as hell
> Q: Why do most people hate top-posting? -- Lots42 The Library Avenger
http://www.fscked.co.uk/writing/top-posting-cuss.html

On Wed, 25 Jun 2008 04:04:48 +0000 (UTC) UHAP023@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?

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.

Also, what do you get from doing this command (which would destroy all the
contents on the device, including the partition table):

dd if=/dev/urandom of=/dev/sda oflag=direct bs=4096 count=2049467

You can restore the partition table by writing zeroes and repartitioning
using the information from doing a partition list:

dd if=/dev/zero of=/dev/sda oflag=direct bs=4096 count=16
fdisk /dev/sda



| tmp# time badblocks -vw /dev/sda
| Checking for bad blocks in read-write mode
| From block 0 to 8197868
| Testing with pattern 0xaa: done
| Reading and comparing: done
| Testing with pattern 0x55: done
| Reading and comparing: done
| Testing with pattern 0xff: done
| Reading and comparing: done
| Testing with pattern 0x00: done
| Reading and comparing: done
| Pass completed, 0 bad blocks found.
|
| real 107m56.476s
| user 2m48.195s
| sys 0m33.890s
| tmp# time badblocks -vw -t random /dev/sda
| Checking for bad blocks in read-write mode
| From block 0 to 8197868
| Testing with random pattern: done
| Reading and comparing: 2059776
| 2059777
| 2059778
| 2059779
| 2059780
| 2059781
| 2059782
| 2059783
| 2059784
| 2059785
| 2059786
| 2059787
| 2059788
| 2059789
| 2059790
| 2059791
| 2059792
| 2059793
| 2059794
| 2059795
| 2059796
| etc...

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.

What I'd do in this case is create a regular disk file with exactly the same
number of blocks as the USB key (so you need 8GB free space on disk somewhere)
and compare the data:

dd if=/dev/urandom of=random.bits bs=4096 count=2049467
dd if=random.bits of=/dev/sda oflag=direct bs=4096 count=2049467
cmp -l random.bits /dev/sda | tree random.errs

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.

================================================== ==============
root@faraday:/root 1# time badblocks -v -w -t random /dev/sdc
Checking for bad blocks in read-write mode
From block 0 to 2000880
Testing with random pattern: done
Reading and comparing: done
Pass completed, 0 bad blocks found.
[[ 4m32s real 272.337 - user 4.891 - sys 1.034 - 2.17% ]]
root@faraday:/root 2# time badblocks -v -w -t random /dev/sdd
Checking for bad blocks in read-write mode
From block 0 to 1985024
Testing with random pattern: done
Reading and comparing: done
Pass completed, 0 bad blocks found.
[[ 9m19s real 559.866 - user 4.865 - sys 0.814 - 1.01% ]]
root@faraday:/root 3# time badblocks -v -w -t random /dev/sde
Checking for bad blocks in read-write mode
From block 0 to 4007752
Testing with random pattern: done
Reading and comparing: done
Pass completed, 0 bad blocks found.
[[ 12m21s real 741.825 - user 9.872 - sys 1.593 - 1.54% ]]
root@faraday:/root 4# od -x < /dev/sdc | head
0000000 7022 f72b c339 2309 e054 4770 c955 c9b8
0000020 1412 d9e8 159d 4a98 d3e8 2697 6dff 21a4
0000040 d0dd 1618 2193 e739 a901 562e e673 851f
0000060 07fa 975e f61d 05e1 78c9 c82c d0e6 c3e9
0000100 01a0 33da 1322 241a 48bd 307a 9a2e 28b5
0000120 13a1 bebf a009 d3c4 f019 ff9b 85c0 61c2
0000140 9c86 a994 afb0 6dcd 47f7 269d 52e1 834e
0000160 0e65 6e41 05ae c741 ddf5 b6c6 8962 e817
0000200 ab25 d591 5e5a 5242 dfa6 8778 c631 960a
0000220 4cd4 8305 4651 474a 1123 85fd 149a bf6e
root@faraday:/root 5# od -x < /dev/sdd | head
0000000 20a8 7780 6916 5043 dffd 0473 c242 7177
0000020 79fc f9f5 141d 9790 3822 0392 5e00 a9bc
0000040 3c7e 9520 64a5 a2e5 5943 86a7 1e1b 17f7
0000060 ec98 b510 a100 224c ded9 da26 e23c ba83
0000100 a31e c34f 3507 4b66 0d8e a9d1 c82b c3c0
0000120 d0b5 b578 c471 4bd8 fea2 de25 a8e0 fe99
0000140 e84b 53c1 271d ab9e 6f34 6054 1437 ec23
0000160 9ce5 56a2 7a60 03a1 c678 58e1 7a6e ba56
0000200 1763 800d ab3f 732c 801a 51d3 f795 7a3e
0000220 e093 f3d0 725a d2f6 d838 a72a 8052 b561
root@faraday:/root 6# od -x < /dev/sde | head
0000000 9427 ab08 dab1 5033 d214 274d 8908 9515
0000020 64c3 64df 8843 0b56 d904 706c 0ee9 10a7
0000040 afa3 54bb ee8a 9ea5 f2c1 c9c5 db7c 3f5e
0000060 3e3f 82a3 f9c6 ca8e fad3 bc3b e209 accc
0000100 8792 1c00 a576 37ba 8098 1400 5e5b 9a53
0000120 f69c 621c aaf0 c32d 68a5 ae7f 4b4a dc5a
0000140 5ad2 48f8 b300 987f 7f33 8eac ffde 7a28
0000160 44f5 e5dd 0aef 94a8 2772 bc42 9c72 4599
0000200 91f6 f68d 0d44 778e 3a8c 6a05 2d39 2fe5
0000220 c272 6114 bdcc 3ef5 37e4 57fa 93d3 c99c
root@faraday:/root 7# od -x < /dev/sdc | fgrep '7022 f72b c339 2309 e054 4770 c955 c9b8' | head
0000000 7022 f72b c339 2309 e054 4770 c955 c9b8
0200000 7022 f72b c339 2309 e054 4770 c955 c9b8
0400000 7022 f72b c339 2309 e054 4770 c955 c9b8
0600000 7022 f72b c339 2309 e054 4770 c955 c9b8
1000000 7022 f72b c339 2309 e054 4770 c955 c9b8
1200000 7022 f72b c339 2309 e054 4770 c955 c9b8
1400000 7022 f72b c339 2309 e054 4770 c955 c9b8
1600000 7022 f72b c339 2309 e054 4770 c955 c9b8
2000000 7022 f72b c339 2309 e054 4770 c955 c9b8
2200000 7022 f72b c339 2309 e054 4770 c955 c9b8
root@faraday:/root 8# od -x < /dev/sdd | fgrep '20a8 7780 6916 5043 dffd 0473 c242 7177' | head
0000000 20a8 7780 6916 5043 dffd 0473 c242 7177
0200000 20a8 7780 6916 5043 dffd 0473 c242 7177
0400000 20a8 7780 6916 5043 dffd 0473 c242 7177
0600000 20a8 7780 6916 5043 dffd 0473 c242 7177
1000000 20a8 7780 6916 5043 dffd 0473 c242 7177
1200000 20a8 7780 6916 5043 dffd 0473 c242 7177
1400000 20a8 7780 6916 5043 dffd 0473 c242 7177
1600000 20a8 7780 6916 5043 dffd 0473 c242 7177
2000000 20a8 7780 6916 5043 dffd 0473 c242 7177
2200000 20a8 7780 6916 5043 dffd 0473 c242 7177
root@faraday:/root 9# od -x < /dev/sde | fgrep '9427 ab08 dab1 5033 d214 274d 8908 9515' | head
0000000 9427 ab08 dab1 5033 d214 274d 8908 9515
0200000 9427 ab08 dab1 5033 d214 274d 8908 9515
0400000 9427 ab08 dab1 5033 d214 274d 8908 9515
0600000 9427 ab08 dab1 5033 d214 274d 8908 9515
1000000 9427 ab08 dab1 5033 d214 274d 8908 9515
1200000 9427 ab08 dab1 5033 d214 274d 8908 9515
1400000 9427 ab08 dab1 5033 d214 274d 8908 9515
1600000 9427 ab08 dab1 5033 d214 274d 8908 9515
2000000 9427 ab08 dab1 5033 d214 274d 8908 9515
2200000 9427 ab08 dab1 5033 d214 274d 8908 9515
root@faraday:/root 10#
================================================== ==============

--
|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) |

phil-news-nospam@ipal.net wrote:
: On Wed, 25 Jun 2008 04:04:48 +0000 (UTC) UHAP023@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

On Fri, 11 Jul 2008 15:45:15 +0000 (UTC) UHAP023@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) |