Re: usb-storage: how to ruin your hardware(?)

[H.Rosmanith (Kernel Mailing List)]

> Back it up:
> dd if=/dev/sda of=/tmp/save bs=512 count=<number of blocks on your flash disk>

that was exactly the first thing I did when I got the exchange-flashdisk :->
 
> Clean it:
> dd if=/dev/zero of=/dev/sda bs=512 count=100
> 
> See what happens. If it does not work any longer, we can take a peek
> at the backup (especially the first few sectors).

overwriting the drive with zeroes doesn't harm it. but in the meantime,
I found out how I managed to confuse the drive. as I wrote in a previous
email, I tried to make the drive look like it has a "real partition table",
I just copied the one from /dev/hda. Then, I did an mke2fs. Of course,
my harddisk is larger then the flashdisk, but I expected an error-message
and not the behaviour I see. So, one can say, trying to access the drive
beyond its physical limits "ruins" it. But it's always possible to repair
such a drive with the vendor supplied formating utility, which is windows
only, which is why I didn't notice it until three days ago. (First time I
use such a thing).

so, I know now how to reliably "ruin" the drive:
  o fdisk /dev/sda
  o go to expert menu
  o change number of cylinders to 2048. the drive only has 1024.
  o make a partition with 1-2048 cylinders.
  o mke2fs this partition.

I know this is kinda useless. But I would expect getting errors from
the drive in case it tries to access memory not present, instead of
just shutting down. This also applies to the format-process: instead
of saying "error", formating will result in confusion of the machine.
Instead of getting an error-message, the usb-layer will experience
timeouts in usb_bulk_sumit(sp?). Two kernel processes, an [usb] and a
 [scsi]-module, will be in state D(efunct). The system load will climb
up to 2, eventually 3. Unplugging the USB-Stick won't help either,
but instead, the kernel-log will be flooded with usb-interrupt messages
(even though no usb-device present). In this state, one can only reboot
the machine.

After rebooting (or putting the flaskdisk into a different computer),
the "ruined" flashdrive doesn't react to simple scsi-commands anymore:

(I just stick the drive into the USB-slot):

root@clio# dmesg
sda : READ CAPACITY failed.
sda : status = 1, message = 00, host = 0, driver = 08
Info fld=0xa00 (nonstd), Current sd00:00: sns = 70  2
Raw sense data:0x70 0x00 0x02 0x00 0x00 0x0a 0x00 0x00
sda : block size assumed to be 512 bytes, disk size 1GB.
sda: test WP failed, assume Write Enabled
 sda: I/O error: dev 08:00, sector 0
 I/O error: dev 08:00, sector 0
 unable to read partition table
 I/O error: dev 08:00, sector 0
Device 08:30 not ready.
 I/O error: dev 08:30, sector 0
Device 08:30 not ready.
 I/O error: dev 08:30, sector 0

but no problem, as stated above, the vendor-formating utility will
bring the flashdisk back to live.

If you are interested, I can try to capture what happens when formating
the drive beyond its physical limits. I know the saying "garbage in,
garbage out", but probably im a bit puzzled that this makes the
machine unusable. I wonder if the never-ending printing of
usb-interrupt-messages, alltough no usb-device present, is the correct
behaviour or if there's something missing in the error-handling?

best regards,
h.rosmanith





-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/