hi,
just today, I bought an "USB BAR", a 128MB flash disk. I managed to make
the device unusable and only get scsi-errors from it.
what I did:
the flask disk came with a strange partition table, and fdisk told about
partition not ending on boundaries. so I just deleted the partitions and
put a new one it, spanning the whole flask disk. then I mke2fs /dev/sda1
it, which seemed fine. as next step I wanted to install lilo on the
flask disk, because some boards can boot from USB and I wanted a
bootable linux on the "USB BAR".
now lilo complained about that it would write into the partition table?
why that?! quite strange!
this puzzled me - after all, the device should behave like
a standard scsi-device. so I just played around with /dev/sda, copying
the first 512 byte from /dev/hda to it and installed lilo then. then I
deleted everything again, copied /dev/zero (512 byte) to /dev/sda,
repartitioned, re-mke2fsd etc. etc...
and now all I ever see from the device are scsi-errors, like these:
: Raw sense data:0x70 0x00 0x03 0x00 0x00 0x00 0x00 0x0a 0x00 0x00
: 0x00 0x00 0x11 0x00 0x00 0x00 0x00 0x00
: I/O error: dev 08:00, sector 0
no matter what I try. I cant even clear this sector by dd if=/dev/zero
of=/dev/sda bs=512 count=1. I even booted the laptop of my collegue,
who has winXP on it, and tried to "format f:" (f: is usb removeable device),
but winXP quits with "error in IOCTL".
kernel version is 2.4.21.
root@themroc:/proc/scsi# cat /scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: Prolific Model: UsbFlashDisk Rev: PROL
Type: Direct-Access ANSI SCSI revision: 02
root@themroc:/proc/scsi# cat usb-storage-0/0
Host scsi0: usb-storage
Vendor: Prolific Technology Inc.
Product: USB_Storage
Serial Number: None
Protocol: 8070i
Transport: Bulk
GUID: 067b25170000000000000000
Attached: Yes
root@themroc:/proc/scsi# dmesg
usb-storage: act_altsettting is 0
usb-storage: id_index calculated to be: 94
usb-storage: Array length appears to be: 97
usb-storage: USB Mass Storage device detected
usb-storage: Endpoints: In: 0xcdb29b94 Out: 0xcdb29b80 Int: 0x00000000 (Period 0)
usb-storage: Found existing GUID 067b25170000000000000000
WARNING: USB Mass Storage data integrity not assured
USB Mass Storage device found at 3
now, say I make "dd if=/dev/zero of=/dev/sda bs=512 count=1", this will
produce:
root@themroc:/proc/scsi# dd if=/dev/zero of=/dev/sda bs=512 count=1
dd: writing `/dev/sda': Input/output error
1+0 records in
0+0 records out
root@themroc:/proc/scsi# dmesg
....
usb-storage: Bulk status Sig 0x53425355 T 0x26 R 1024 Stat 0x1
usb-storage: -- transport indicates command failure
usb-storage: Issuing auto-REQUEST_SENSE
usb-storage: Bulk command S 0x43425355 T 0x27 Trg 0 LUN 0 L 18 F 128 CL 12
usb-storage: Bulk command transfer result=0
usb-storage: usb_stor_transfer_partial(): xfer 18 bytes
usb-storage: usb_stor_bulk_msg() returned 0 xferred 18/18
usb-storage: usb_stor_transfer_partial(): transfer complete
usb-storage: Bulk data transfer result 0x0
usb-storage: Attempting to get CSW...
usb-storage: Bulk status result = 0
usb-storage: Bulk status Sig 0x53425355 T 0x27 R 0 Stat 0x0
usb-storage: -- Result from auto-sense is 0
usb-storage: -- code: 0x70, key: 0x3, ASC: 0x11, ASCQ: 0x0
usb-storage: Medium Error: (unknown ASC/ASCQ)
usb-storage: scsi cmd done, result=0x2
usb-storage: *** thread sleeping.
scsi0: ERROR on channel 0, id 0, lun 0, CDB: 0x28 00 00 00 00 00 00 00 02 00
Current sd08:00: sns = 70 3
ASC=11 ASCQ= 0
Raw sense data:0x70 0x00 0x03 0x00 0x00 0x00 0x00 0x0a 0x00 0x00 0x00 0x00 0x11
0x00 0x00 0x00 0x00 0x00
I/O error: dev 08:00, sector 0
oops, a Medium Error :-(
so it's possible to ruin your "USB BAR" flash disk by simply dumping some
random data to /dev/sda, sector 0? not good... I've heard so that e.g.
mke2fs on a compat flash will kill the compact flash, but I've always
been wondering if this is true. now I have the proof ...
is there any way to recover the medium?
thanks in advance,
h.rosmanith
For the vast majority of USB storage devices, it's not possible to kill the
device like you did.
It looks like the device firmware needs certain data on the first sector to
operate. The usb-storage communication is working just fine, but the
device is refusing commands.
Likely, the unit is unrecoverable unless you can figure out the magic that
the manufacturer uses to write that beginning few sectors of data.
Matt
P.S. I commonly put ext2/3 filesystems on my CF cards without any
problems.
P.P.S. The 'strange partition table' you saw probably wasn't a partition
table at all -- it was likely the start of a VFAT filesystem. I'm guessing
that if you had just mounted /dev/sda (notice no partition number!), it
would have worked.
On Thu, Aug 21, 2003 at 03:34:48AM +0200, H.Rosmanith (Kernel Mailing List) wrote:
>
> hi,
>
> just today, I bought an "USB BAR", a 128MB flash disk. I managed to make
> the device unusable and only get scsi-errors from it.
>
> what I did:
> the flask disk came with a strange partition table, and fdisk told about
> partition not ending on boundaries. so I just deleted the partitions and
> put a new one it, spanning the whole flask disk. then I mke2fs /dev/sda1
> it, which seemed fine. as next step I wanted to install lilo on the
> flask disk, because some boards can boot from USB and I wanted a
> bootable linux on the "USB BAR".
>
> now lilo complained about that it would write into the partition table?
> why that?! quite strange!
>
> this puzzled me - after all, the device should behave like
> a standard scsi-device. so I just played around with /dev/sda, copying
> the first 512 byte from /dev/hda to it and installed lilo then. then I
> deleted everything again, copied /dev/zero (512 byte) to /dev/sda,
> repartitioned, re-mke2fsd etc. etc...
>
> and now all I ever see from the device are scsi-errors, like these:
>
> : Raw sense data:0x70 0x00 0x03 0x00 0x00 0x00 0x00 0x0a 0x00 0x00
> : 0x00 0x00 0x11 0x00 0x00 0x00 0x00 0x00
> : I/O error: dev 08:00, sector 0
>
> no matter what I try. I cant even clear this sector by dd if=/dev/zero
> of=/dev/sda bs=512 count=1. I even booted the laptop of my collegue,
> who has winXP on it, and tried to "format f:" (f: is usb removeable device),
> but winXP quits with "error in IOCTL".
>
> kernel version is 2.4.21.
>
> root@themroc:/proc/scsi# cat /scsi
> Attached devices:
> Host: scsi0 Channel: 00 Id: 00 Lun: 00
> Vendor: Prolific Model: UsbFlashDisk Rev: PROL
> Type: Direct-Access ANSI SCSI revision: 02
> root@themroc:/proc/scsi# cat usb-storage-0/0
> Host scsi0: usb-storage
> Vendor: Prolific Technology Inc.
> Product: USB_Storage
> Serial Number: None
> Protocol: 8070i
> Transport: Bulk
> GUID: 067b25170000000000000000
> Attached: Yes
>
> root@themroc:/proc/scsi# dmesg
> usb-storage: act_altsettting is 0
> usb-storage: id_index calculated to be: 94
> usb-storage: Array length appears to be: 97
> usb-storage: USB Mass Storage device detected
> usb-storage: Endpoints: In: 0xcdb29b94 Out: 0xcdb29b80 Int: 0x00000000 (Period 0)
> usb-storage: Found existing GUID 067b25170000000000000000
> WARNING: USB Mass Storage data integrity not assured
> USB Mass Storage device found at 3
>
> now, say I make "dd if=/dev/zero of=/dev/sda bs=512 count=1", this will
> produce:
>
> root@themroc:/proc/scsi# dd if=/dev/zero of=/dev/sda bs=512 count=1
> dd: writing `/dev/sda': Input/output error
> 1+0 records in
> 0+0 records out
> root@themroc:/proc/scsi# dmesg
> ....
> usb-storage: Bulk status Sig 0x53425355 T 0x26 R 1024 Stat 0x1
> usb-storage: -- transport indicates command failure
> usb-storage: Issuing auto-REQUEST_SENSE
> usb-storage: Bulk command S 0x43425355 T 0x27 Trg 0 LUN 0 L 18 F 128 CL 12
> usb-storage: Bulk command transfer result=0
> usb-storage: usb_stor_transfer_partial(): xfer 18 bytes
> usb-storage: usb_stor_bulk_msg() returned 0 xferred 18/18
> usb-storage: usb_stor_transfer_partial(): transfer complete
> usb-storage: Bulk data transfer result 0x0
> usb-storage: Attempting to get CSW...
> usb-storage: Bulk status result = 0
> usb-storage: Bulk status Sig 0x53425355 T 0x27 R 0 Stat 0x0
> usb-storage: -- Result from auto-sense is 0
> usb-storage: -- code: 0x70, key: 0x3, ASC: 0x11, ASCQ: 0x0
> usb-storage: Medium Error: (unknown ASC/ASCQ)
> usb-storage: scsi cmd done, result=0x2
> usb-storage: *** thread sleeping.
> scsi0: ERROR on channel 0, id 0, lun 0, CDB: 0x28 00 00 00 00 00 00 00 02 00
> Current sd08:00: sns = 70 3
> ASC=11 ASCQ= 0
> Raw sense data:0x70 0x00 0x03 0x00 0x00 0x00 0x00 0x0a 0x00 0x00 0x00 0x00 0x11
> 0x00 0x00 0x00 0x00 0x00
> I/O error: dev 08:00, sector 0
>
>
>
> oops, a Medium Error :-(
>
> so it's possible to ruin your "USB BAR" flash disk by simply dumping some
> random data to /dev/sda, sector 0? not good... I've heard so that e.g.
> mke2fs on a compat flash will kill the compact flash, but I've always
> been wondering if this is true. now I have the proof ...
>
> is there any way to recover the medium?
>
> thanks in advance,
> h.rosmanith
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Matthew Dharm Home: [email protected]
Maintainer, Linux USB Mass Storage Driver
It was a new hope.
-- Dust Puppy
User Friendly, 12/25/1998
-- Start of PGP signed section.
> For the vast majority of USB storage devices, it's not possible to kill the
> device like you did.
>
> It looks like the device firmware needs certain data on the first sector to
> operate. The usb-storage communication is working just fine, but the
> device is refusing commands.
aha. do you know why the device is refusing commands? it relys on sector0
to contain some vital information and if this is not there, it refuses
commands?
> Likely, the unit is unrecoverable unless you can figure out the magic that
> the manufacturer uses to write that beginning few sectors of data.
pfhew....I once sent an email to Prolific (manufacturer of this device), but
never got an answer. so, one needs the layout of the first sectors and
a method how to write that ... I wonder if Prolific has this info on their
website ...
> Matt
>
> P.S. I commonly put ext2/3 filesystems on my CF cards without any
> problems.
>
> P.P.S. The 'strange partition table' you saw probably wasn't a partition
> table at all -- it was likely the start of a VFAT filesystem. I'm guessing
> that if you had just mounted /dev/sda (notice no partition number!), it
> would have worked.
I see. the whole flash disk is a single filesystem without partitions
(I used to format HDs this way in the old days :->
do you think it is possible to "mke2fs /dev/sda" (once I return the
USB BAR to the vendor and tell them it's "somehow damaged, no idea
why") on a new
> On Thu, Aug 21, 2003 at 03:34:48AM +0200, H.Rosmanith (Kernel Mailing List) wrote:
> >
> > hi,
> >
> > just today, I bought an "USB BAR", a 128MB flash disk. I managed to make
> > the device unusable and only get scsi-errors from it.
> >
> > what I did:
> > the flask disk came with a strange partition table, and fdisk told about
> > partition not ending on boundaries. so I just deleted the partitions and
> > put a new one it, spanning the whole flask disk. then I mke2fs /dev/sda1
> > it, which seemed fine. as next step I wanted to install lilo on the
> > flask disk, because some boards can boot from USB and I wanted a
> > bootable linux on the "USB BAR".
> >
> > now lilo complained about that it would write into the partition table?
> > why that?! quite strange!
> >
> > this puzzled me - after all, the device should behave like
> > a standard scsi-device. so I just played around with /dev/sda, copying
> > the first 512 byte from /dev/hda to it and installed lilo then. then I
> > deleted everything again, copied /dev/zero (512 byte) to /dev/sda,
> > repartitioned, re-mke2fsd etc. etc...
> >
> > and now all I ever see from the device are scsi-errors, like these:
> >
> > : Raw sense data:0x70 0x00 0x03 0x00 0x00 0x00 0x00 0x0a 0x00 0x00
> > : 0x00 0x00 0x11 0x00 0x00 0x00 0x00 0x00
> > : I/O error: dev 08:00, sector 0
> >
> > no matter what I try. I cant even clear this sector by dd if=/dev/zero
> > of=/dev/sda bs=512 count=1. I even booted the laptop of my collegue,
> > who has winXP on it, and tried to "format f:" (f: is usb removeable device),
> > but winXP quits with "error in IOCTL".
> >
> > kernel version is 2.4.21.
> >
> > root@themroc:/proc/scsi# cat /scsi
> > Attached devices:
> > Host: scsi0 Channel: 00 Id: 00 Lun: 00
> > Vendor: Prolific Model: UsbFlashDisk Rev: PROL
> > Type: Direct-Access ANSI SCSI revision: 02
> > root@themroc:/proc/scsi# cat usb-storage-0/0
> > Host scsi0: usb-storage
> > Vendor: Prolific Technology Inc.
> > Product: USB_Storage
> > Serial Number: None
> > Protocol: 8070i
> > Transport: Bulk
> > GUID: 067b25170000000000000000
> > Attached: Yes
> >
> > root@themroc:/proc/scsi# dmesg
> > usb-storage: act_altsettting is 0
> > usb-storage: id_index calculated to be: 94
> > usb-storage: Array length appears to be: 97
> > usb-storage: USB Mass Storage device detected
> > usb-storage: Endpoints: In: 0xcdb29b94 Out: 0xcdb29b80 Int: 0x00000000 (Period 0)
> > usb-storage: Found existing GUID 067b25170000000000000000
> > WARNING: USB Mass Storage data integrity not assured
> > USB Mass Storage device found at 3
> >
> > now, say I make "dd if=/dev/zero of=/dev/sda bs=512 count=1", this will
> > produce:
> >
> > root@themroc:/proc/scsi# dd if=/dev/zero of=/dev/sda bs=512 count=1
> > dd: writing `/dev/sda': Input/output error
> > 1+0 records in
> > 0+0 records out
> > root@themroc:/proc/scsi# dmesg
> > ....
> > usb-storage: Bulk status Sig 0x53425355 T 0x26 R 1024 Stat 0x1
> > usb-storage: -- transport indicates command failure
> > usb-storage: Issuing auto-REQUEST_SENSE
> > usb-storage: Bulk command S 0x43425355 T 0x27 Trg 0 LUN 0 L 18 F 128 CL 12
> > usb-storage: Bulk command transfer result=0
> > usb-storage: usb_stor_transfer_partial(): xfer 18 bytes
> > usb-storage: usb_stor_bulk_msg() returned 0 xferred 18/18
> > usb-storage: usb_stor_transfer_partial(): transfer complete
> > usb-storage: Bulk data transfer result 0x0
> > usb-storage: Attempting to get CSW...
> > usb-storage: Bulk status result = 0
> > usb-storage: Bulk status Sig 0x53425355 T 0x27 R 0 Stat 0x0
> > usb-storage: -- Result from auto-sense is 0
> > usb-storage: -- code: 0x70, key: 0x3, ASC: 0x11, ASCQ: 0x0
> > usb-storage: Medium Error: (unknown ASC/ASCQ)
> > usb-storage: scsi cmd done, result=0x2
> > usb-storage: *** thread sleeping.
> > scsi0: ERROR on channel 0, id 0, lun 0, CDB: 0x28 00 00 00 00 00 00 00 02 00
> > Current sd08:00: sns = 70 3
> > ASC=11 ASCQ= 0
> > Raw sense data:0x70 0x00 0x03 0x00 0x00 0x00 0x00 0x0a 0x00 0x00 0x00 0x00 0x11
> > 0x00 0x00 0x00 0x00 0x00
> > I/O error: dev 08:00, sector 0
> >
> >
> >
> > oops, a Medium Error :-(
> >
> > so it's possible to ruin your "USB BAR" flash disk by simply dumping some
> > random data to /dev/sda, sector 0? not good... I've heard so that e.g.
> > mke2fs on a compat flash will kill the compact flash, but I've always
> > been wondering if this is true. now I have the proof ...
> >
> > is there any way to recover the medium?
> >
> > thanks in advance,
> > h.rosmanith
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
>
> --
> Matthew Dharm Home: [email protected]
> Maintainer, Linux USB Mass Storage Driver
>
> It was a new hope.
> -- Dust Puppy
> User Friendly, 12/25/1998
-- End of PGP section, PGP failed!
I think what Matt is saying is that certain functionality of the USB
device is soft-coded. So once this data is gone from the device, trying
to write to or from it will fail, since the read and write commands are
(partially) soft-coded. If this is true, then writing to this device is
like trying to ping a computer that was booted up, but had no operating
system loaded. It would seem weird to create a device in such a manner,
but it is not outside the realm of possibility.
I had a printer (hp lj1000) that operated in exactly this fashion. To
work, its firmware needed to be cat'ed to the device before any printing
was done. I never got this working and instead just returned the printer
and replaced it with a postscript compliant model. I recommend that you
do similar. No sense eating the cost. It will be impetus for the
manufacturers to make robust and compatible devices.
-Brandon
H.Rosmanith (Kernel Mailing List) wrote:
>-- Start of PGP signed section.
>
>
>>For the vast majority of USB storage devices, it's not possible to kill the
>>device like you did.
>>
>>It looks like the device firmware needs certain data on the first sector to
>>operate. The usb-storage communication is working just fine, but the
>>device is refusing commands.
>>
>>
>
>aha. do you know why the device is refusing commands? it relys on sector0
>to contain some vital information and if this is not there, it refuses
>commands?
>
>
>
>
>>Likely, the unit is unrecoverable unless you can figure out the magic that
>>the manufacturer uses to write that beginning few sectors of data.
>>
>>
>
>pfhew....I once sent an email to Prolific (manufacturer of this device), but
>never got an answer. so, one needs the layout of the first sectors and
>a method how to write that ... I wonder if Prolific has this info on their
>website ...
>
>
>
>
>>Matt
>>
>>P.S. I commonly put ext2/3 filesystems on my CF cards without any
>>problems.
>>
>>P.P.S. The 'strange partition table' you saw probably wasn't a partition
>>table at all -- it was likely the start of a VFAT filesystem. I'm guessing
>>that if you had just mounted /dev/sda (notice no partition number!), it
>>would have worked.
>>
>>
>
>I see. the whole flash disk is a single filesystem without partitions
>(I used to format HDs this way in the old days :->
>
>do you think it is possible to "mke2fs /dev/sda" (once I return the
>USB BAR to the vendor and tell them it's "somehow damaged, no idea
>why") on a new
>
On Thu, 2003-08-21 at 04:05, H.Rosmanith (Kernel Mailing List) wrote:
> -- Start of PGP signed section.
> > For the vast majority of USB storage devices, it's not possible to kill the
> > device like you did.
> >
> > It looks like the device firmware needs certain data on the first sector to
> > operate. The usb-storage communication is working just fine, but the
> > device is refusing commands.
>
> aha. do you know why the device is refusing commands? it relys on sector0
> to contain some vital information and if this is not there, it refuses
> commands?
>
We sell a make of flashdisk (what we call your 'usb bar') that use
sector 0 with its encryption scheme. Basically as soon as you
'encrypt' or 'password protect' or whatever the device, you cannot
get a valid partition table, and sector 0 is not writable, so
repartitioning fails. I have not tried to just put a fs on the
whole disk, but I assume it will fail as well, as it should start
at sector 0.
Anyhow, the only way to fix this if you lost the password, is to
format the device with the software that comes with the device
(windows based only for ours) - might be the same thing your side,
you just got the device into 'lock down mode' via some fluke.
Hope this might be of some help, else take it back. Our side
at least if not burned or damaged, we would replace it.
Regards,
--
Martin Schlemmer
On Iau, 2003-08-21 at 02:34, H.Rosmanith (Kernel Mailing List) wrote:
> hi,
>
> just today, I bought an "USB BAR", a 128MB flash disk. I managed to make
> the device unusable and only get scsi-errors from it.
Are you sure it didnt just fail. The report you give basically says
"after the first write the flash device failed entirely". That doen't
seem an abnormal flash failure mode
> P.P.S. The 'strange partition table' you saw probably wasn't a partition
> table at all -- it was likely the start of a VFAT filesystem. I'm guessing
> that if you had just mounted /dev/sda (notice no partition number!), it
> would have worked.
I almost killed my USB 128mb flash (it's an mp3 player also).
I also noticed a strange partition and "fixed" it. And file transfers
where ok (VFAT, formatted), but suddenly it stopped playing audio. When I
redid the formatting as a plain DOS partition using fdisk command.
o create a new empty DOS partition table
MP3 started playing right.
It seems that many manufacturers rely on undocumented (yes, I haven't
found any pointers about partition table format, etc.) nuances
and settings.
Like your USB BAR's starting sector's data, that seemed to be garbage.
Maybe a message of caution should be displayed in usb-storage
configure help about attemtping to change partitions and/or filesystems on
USB storage devices.
Regards,
Maciej
Maciej Soltysiak wrote:
>
> Maybe a message of caution should be displayed in usb-storage
> configure help about attemtping to change partitions and/or filesystems on
> USB storage devices.
>
The stuff I have met with CompactFlash cards (*without* USB) - they
by default were coming formated with single FAT12 partition - no
partition table whatsoever.
I had no problems with partitioning and formating (in IDE emulation
mode).
But Windoz2kOfBugs was refusing to work with flashes which had
partition table, and was working Okay with /original/ FAT12 formated
flashes. Windoz wasn't even trying to read partition table, always
showing flash as one drive - and sure it was reporting stupid errors
when you were trying to do something with partitioned flash.
It looks like /agreement/ (with The Beast) that flashe/memory card
has to have FAT12.
No comments.
On Thu, Aug 21, 2003 at 02:35:43PM +0200, Ihar 'Philips' Filipau wrote:
> Maciej Soltysiak wrote:
> >
> >Maybe a message of caution should be displayed in usb-storage
> >configure help about attemtping to change partitions and/or filesystems on
> >USB storage devices.
> >
>
> The stuff I have met with CompactFlash cards (*without* USB) - they
> by default were coming formated with single FAT12 partition - no
> partition table whatsoever.
> I had no problems with partitioning and formating (in IDE emulation
> mode).
>
> But Windoz2kOfBugs was refusing to work with flashes which had
> partition table, and was working Okay with /original/ FAT12 formated
> flashes. Windoz wasn't even trying to read partition table, always
> showing flash as one drive - and sure it was reporting stupid errors
> when you were trying to do something with partitioned flash.
>
> It looks like /agreement/ (with The Beast) that flashe/memory card
> has to have FAT12.
To flesh this out.
Both using PC card adapter and USB the SmartMedia cards i've
used do have partition tables with only partition 1 being
defined. The filesystem type and ID has been either a FAT12
or FAT16 depending on size.
I have not tried changing the table or filesystem type since
i use them almost exclusively for the digicams.
--
________________________________________________________________
J.W. Schultz Pegasystems Technologies
email address: [email protected]
Remember Cernan and Schmitt
> On Iau, 2003-08-21 at 02:34, H.Rosmanith (Kernel Mailing List) wrote:
> > hi,
> >
> > just today, I bought an "USB BAR", a 128MB flash disk. I managed to make
> > the device unusable and only get scsi-errors from it.
>
> Are you sure it didnt just fail. The report you give basically says
I don't know, probably.
> "after the first write the flash device failed entirely". That doen't
no, I wrote several data to it, like partitioning it, writing /dev/zero
to it and so on. I moved it from computer to computer to try booting from
it, installed lilo on it and so on. After several hours of messing around
with the device, it failed.
Maybe it is just "forbidden" to partition it, since I know boldly ;)
did mke2fs /dev/sda on the exchanged flashdev and installed lilo on
it too. So far, no problems yet. Still can't boot from it, however
(is this an USB-HDD in bios or does the bios have to support some
USB-MEMORY-STICK boot-option?)
> seem an abnormal flash failure mode
>
> > "after the first write the flash device failed entirely". That doen't
>
> no, I wrote several data to it, like partitioning it, writing /dev/zero
> to it and so on. I moved it from computer to computer to try booting from
> it, installed lilo on it and so on. After several hours of messing around
> with the device, it failed.
okidok.... I got an new flashdisk from the vendor, but managed to ruin
it again. anyway, I also managed to repair it again. the vendor ships
a seperate formating-tool, which will repair the device, even when you
get "SCSI sense key errors".
however, I still don't understand what's going on and *why* it is not
allowed to format the drive "at will". I'd also would like to know how
this vendor supplied formating-tool works. Possibly some vendor-specific
usb-commands to ... do what? hm. I can only guess.
I purchased another driver (TraxData, USB-1, 6 euros cheaper and it
my mainboard can even boot from this device).
by the way: the manufacturer is Panram, http://www.panram.com.tw/ ... does anyone
of you have experience with them? Is it likely that one gets documentation
from them?
thx
h.rosmanith
On Wed, 27 Aug 2003, H.Rosmanith (Kernel Mailing List) wrote:
> > > "after the first write the flash device failed entirely". That doen't
> >
> > no, I wrote several data to it, like partitioning it, writing /dev/zero
> > to it and so on. I moved it from computer to computer to try booting from
> > it, installed lilo on it and so on. After several hours of messing around
> > with the device, it failed.
>
> okidok.... I got an new flashdisk from the vendor, but managed to ruin
> it again. anyway, I also managed to repair it again. the vendor ships
> a seperate formating-tool, which will repair the device, even when you
> get "SCSI sense key errors".
>
> however, I still don't understand what's going on and *why* it is not
> allowed to format the drive "at will". I'd also would like to know how
> this vendor supplied formating-tool works. Possibly some vendor-specific
> usb-commands to ... do what? hm. I can only guess.
>
> I purchased another driver (TraxData, USB-1, 6 euros cheaper and it
> my mainboard can even boot from this device).
>
> by the way: the manufacturer is Panram, http://www.panram.com.tw/ ... does anyone
> of you have experience with them? Is it likely that one gets documentation
> from them?
>
> thx
> h.rosmanith
>
Remember when AT Class machines had a BIOS that allowed you
to low-level format hard drives? When early IDE drives came
out, persons tried to format them and they got destroyed.
So, BIOS vendors took away the format capability.
The IDE drive companies started a lie that was repeated so
often that it seemed true. It was that IDE drives didn't
have 'formatters' and, therefore, could only be formatted
at the factory. Of course, if this was true, how come
the format command did anything?? The truth was that
these drives stored their parameters on the disk platters.
If you re-wrote the first real sectors on the drive, the
drive no longer 'knew' what its parameters were and the
drive was broken forever. The actual seeks to various
logical sectors would bypass these private sectors so,
normally, this was invisible to the end-user. However,
if you re-wrote a whole track (what format does), these
invisible sectors would be overwritten.
With your NVRAM drive, it is likely that the drive parameters
are 'protected' by a partition table. If you overwrite this
partition table, the drive becomes broken. This means that,
whatever you do, you can't modify some important portion
of that table.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.22 on an i686 machine (794.73 BogoMips).
Note 96.31% of all statistics are fiction.
H.Rosmanith (Kernel Mailing List) wrote:
>>>
> okidok.... I got an new flashdisk from the vendor, but managed to ruin
> it again. anyway, I also managed to repair it again. the vendor ships
> a seperate formating-tool, which will repair the device, even when you
> get "SCSI sense key errors".
>
Q for the specialists: What SCSI access can still work then? I'm
wondering if you can still write something to it. My first guess about
that vender tool was that it just writes a valid partition table to the
disk. The only problem is that you need to deduce the actual size of the
flashdisk. But that can be retrieved from some USB identification string.
But it's more likely that it just uses some propriety interface to reset
the device.
> however, I still don't understand what's going on and *why* it is not
> allowed to format the drive "at will". I'd also would like to know how
> this vendor supplied formating-tool works. Possibly some vendor-specific
> usb-commands to ... do what? hm. I can only guess.
>
You can use USB Snoopy <http://www.wingmanteam.com/usbsnoopy/> to find
out what that vendor tool (for Windows, I presume) does.
Bas.
>
> On Wed, 27 Aug 2003, H.Rosmanith (Kernel Mailing List) wrote:
>
> > > > "after the first write the flash device failed entirely". That doen't
<snip>
> Remember when AT Class machines had a BIOS that allowed you
> to low-level format hard drives? When early IDE drives came
> out, persons tried to format them and they got destroyed.
> So, BIOS vendors took away the format capability.
>
> The IDE drive companies started a lie that was repeated so
> often that it seemed true. It was that IDE drives didn't
> have 'formatters' and, therefore, could only be formatted
> at the factory. Of course, if this was true, how come
> the format command did anything?? The truth was that
This is actually true, and has been since around 80Mb or so.
There is no absolute positioning information on the disk drive that can
be used to lay down new positioning information for the tracks.
Before this, there used to be a stepper motor that could position the
head at track 743, or a seperate head that read track information from
a dedicated surface.
> these drives stored their parameters on the disk platters.
> If you re-wrote the first real sectors on the drive, the
This is more likely the problem, but
On Wed, 27 Aug 2003 [email protected] wrote:
> >
> > On Wed, 27 Aug 2003, H.Rosmanith (Kernel Mailing List) wrote:
> >
> > > > > "after the first write the flash device failed entirely". That doen't
> <snip>
> > Remember when AT Class machines had a BIOS that allowed you
> > to low-level format hard drives? When early IDE drives came
> > out, persons tried to format them and they got destroyed.
> > So, BIOS vendors took away the format capability.
> >
> > The IDE drive companies started a lie that was repeated so
> > often that it seemed true. It was that IDE drives didn't
> > have 'formatters' and, therefore, could only be formatted
> > at the factory. Of course, if this was true, how come
> > the format command did anything?? The truth was that
>
> This is actually true, and has been since around 80Mb or so.
> There is no absolute positioning information on the disk drive that can
> be used to lay down new positioning information for the tracks.
> Before this, there used to be a stepper motor that could position the
> head at track 743, or a seperate head that read track information from
> a dedicated surface.
>
No. Embedded servo-tracks have been used for this. Once a track is
written at the factory, even if the sectors are corrupt, it can
still be used for servo position because even corrupt data has
the spectral information necessary for the servo to find the
center of the track. The only possible problem is that you can't
find even one good sector to verify the track information. Both
the track number and the sector number is in the sector header.
You can low-level format many/most/all SCSI disks and ESDI disks
even though they also have embedded servo and voice-coil
positioners with no stepper motors and no feedback except from
the track information that you re-write.
Embedded servos work because the magnetic domains are always
too large for the data bits. This means that the system
ends up acting like a low-pass filter. The phase through
this filter changes, depending upon the position of the
head relative to when it was written. The servo nulls the
phase-shift to be what it was when the track was written.
This gets the head to the center of the track.
You do need some kind of independent positioner to write
the first tracks at the factory. Most use a 'formatter'
fixture that contains the feedback hardware necessary to do this.
Prototype drives get tracks written entirely using a software
approximation method where the first track is written slightly
off from the home position, the next tracks are written
where the read-level from the previous write has fallen
6 dB (50%), as the positioner current is 'bumped' to overcome
friction and move to the next incremental track location.
This is not done for production drives because it is too
slow. However, this will allow the designer to experimentally
determine the maximim possible capacity of the drive, i.e.,
maximum number of cylinders.
> > these drives stored their parameters on the disk platters.
> > If you re-wrote the first real sectors on the drive, the
>
> This is more likely the problem, but
>
Cheers,
Dick Johnson
Penguin : Linux version 2.4.22 on an i686 machine (794.73 BogoMips).
Note 96.31% of all statistics are fiction.
>
> With your NVRAM drive, it is likely that the drive parameters
> are 'protected' by a partition table. If you overwrite this
> partition table, the drive becomes broken. This means that,
> whatever you do, you can't modify some important portion
> of that table.
the contradiction to this is that the flashdisk can be used
in a "partition-less" state where it is possible to use the
whole device at one: "mke2fs /dev/sdb". you have to use the
vendor formating-tool to make the flashdisk look like an USB_FDD
device. but even in USB_HDD mode with partitions, the partitions
still look strange, not ending on cylinder boundaries and so on.
oh my. I guess I gonna contact Panram then and of course,
thanks for the URL to the USB-snoop utility.
thx
h.rosmanith
On Thu, Aug 28, 2003 at 04:59:14AM +0200, H.Rosmanith (Kernel Mailing List) wrote:
> the contradiction to this is that the flashdisk can be used
> in a "partition-less" state where it is possible to use the
> whole device at one: "mke2fs /dev/sdb". you have to use the
> vendor formating-tool to make the flashdisk look like an USB_FDD
> device. but even in USB_HDD mode with partitions, the partitions
> still look strange, not ending on cylinder boundaries and so on.
I have seen several posts from you, but all in this vague, almost
information-free style.
It would be of interest if you described your actions and the results
in detail. Or if you gave explicitly the partition table that you
consider strange.
[If you only think about cylinder boundaries: cylinders do not exist,
and cylinder boundaries do not exist either. So that in itself does
not mean a thing.]
Andries
> On Thu, Aug 28, 2003 at 04:59:14AM +0200, H.Rosmanith (Kernel Mailing List) wrote:
>
> > the contradiction to this is that the flashdisk can be used
> > in a "partition-less" state where it is possible to use the
> > whole device at one: "mke2fs /dev/sdb". you have to use the
> > vendor formating-tool to make the flashdisk look like an USB_FDD
> > device. but even in USB_HDD mode with partitions, the partitions
> > still look strange, not ending on cylinder boundaries and so on.
>
> I have seen several posts from you, but all in this vague, almost
> information-free style.
the information is vague, because I don't exactly know how I manage
to stop the drive working.
> It would be of interest if you described your actions and the results
> in detail. Or if you gave explicitly the partition table that you
> consider strange.
hm, that's not so easy. I notice that the drive stops working, but
I can't exactly tell when. Unfortunately I can't give you the
partition table of the new drive anymore, because it's alread gone ;-)
> [If you only think about cylinder boundaries: cylinders do not exist,
> and cylinder boundaries do not exist either. So that in itself does
> not mean a thing.]
well ... I would assume that a proper "emulation" of a harddisk by a
flashdrive would also look like a real harddisk, with correct
cylinder boundaries. But obviously, this is not the case. Should
I get a new drive, I will mail you the strange-looking partiotion-table:
it will look like "physical start at (0,3,3)" or similar.
best regards,
h.rosmanith
On Thu, Aug 28, 2003 at 06:18:22PM +0200, H.Rosmanith (Kernel Mailing List) wrote:
> > [If you only think about cylinder boundaries: cylinders do not exist,
> > and cylinder boundaries do not exist either. So that in itself does
> > not mean a thing.]
>
> well ... I would assume that a proper "emulation" of a harddisk by a
> flashdrive would also look like a real harddisk, with correct
> cylinder boundaries. But obviously, this is not the case. Should
> I get a new drive, I will mail you the strange-looking partiotion-table:
> it will look like "physical start at (0,3,3)" or similar.
Didnt you get formatting utilities to repair such situations?
But concerning cylinders: Also harddisks do not have cylinders in the
partition table sense. Disk geometry is a fiction. If you print a
partition table and it looks ugly given one fiction, this just means
that you can invent some other fiction that makes it look nicer.
There is no underlying reality to these cylinder boundaries.
"H.Rosmanith (Kernel Mailing List)" <[email protected]> writes:
>> On Thu, Aug 28, 2003 at 04:59:14AM +0200, H.Rosmanith (Kernel Mailing List) wrote:
>>
>> > the contradiction to this is that the flashdisk can be used
>> > in a "partition-less" state where it is possible to use the
>> > whole device at one: "mke2fs /dev/sdb". you have to use the
>> > vendor formating-tool to make the flashdisk look like an USB_FDD
>> > device. but even in USB_HDD mode with partitions, the partitions
>> > still look strange, not ending on cylinder boundaries and so on.
>>
>> I have seen several posts from you, but all in this vague, almost
>> information-free style.
>the information is vague, because I don't exactly know how I manage
>to stop the drive working.
Back it up:
dd if=/dev/sda of=/tmp/save bs=512 count=<number of blocks on your flash disk>
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).
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
[email protected] +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
"Dominate!! Dominate!! Eat your young and aggregate! I have grotty silicon!"
-- AOL CD when played backwards (User Friendly - 200-10-15)
> 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
> 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).
AFAIK NAND flash devices have bad sectors and a bad-block table usually at
the end of the device. That could be the reason why you can ruin your
device writing beyond the reported capacity. The formatting tool can reset
this area. You can try to save the area beyond the reported capacity,
overwrite it &c. as you did with the beginning of the drive. It's not
really kernel related. The point, as you pointed out, is that the kernel
should handle this failure better.
Peter Werner
But it's always possible to repair
> > such a drive with the vendor supplied formating utility, which is windows
by the way ... this is wrong. as it turned out later, it was not possible
to repair the usb-flashdisk-utility from the vendor. in w2k, it will
appears as "unknown security device" with a big yellow question mark.
so if you want to ruin your stick, proceed as follows:
- fdisk /dev/sd?
- go to expert menu
- set numer of cyls twice as high
- go back to normal menu
- make partition of full size with new cyl.count
happy mke2fsing ;-)
after rebooting (machine will be in unusable state), the device wont be recognized
as usb-storage device. reason: the number of usb-endpoints suddenly dropped to 0 (zero).
I don't know if every stick acts this way .. but the Panram one does definitely.
all right then. end of thread ...
h.rosmanith