Messages in this thread | | | From | "H.Rosmanith (Kernel Mailing List)" <> | Subject | Re: usb-storage: how to ruin your hardware(?) | Date | Fri, 29 Aug 2003 18:11:57 +0200 (MET DST) |
| |
> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |