Camcontrol not changing modepage

[Kenneth D. Merry]

On Mon, Nov 13, 2006 at 17:22:44 -0500, Tuc at T-B-O-H.NET wrote:
> > > 	I want to turn ARRE on, which is supposedly
> > > able to be re-written :
> > > 
> > > himinbjorg# camcontrol modepage da0 -m 1 -P 1
> > > AWRE (Auto Write Reallocation Enbld):  1
> > > ARRE (Auto Read Reallocation Enbld):  0
> > 
> > The page control value of 1 that you specified tells camcontrol to ask for
> > the bitmask of changeable bits in the page.
> > 
> > The 0, above, tells us that we cannot change the ARRE value.
> >
> 	OOOOOOOOHHHHHHH! I thought it was telling me that it was
> available for R/W, AND that it was currently set to zero.....
> > 
> > > TB (Transfer Block):  1
> > > RC (Read Continuous):  1
> > > EER (Enable Early Recovery):  1
> > > PER (Post Error):  1
> > > DTE (Disable Transfer on Error):  1
> > > DCR (Disable Correction):  1
> > > Read Retry Count:  191
> > > Correction Span:  250
> > > Head Offset Count:  204
> > > Data Strobe Offset Count:  5
> > > Write Retry Count:  70
> > > Recovery Time Limit:  3880
> >
> 	And I thought that because the above ones were not 0 or 1...
> >
> > > 
> > > 	I do the "-e" and insert in my editor :
> > > 
> > > ARRE (Auto Read Reallocation Enbld):  1
> > > 
> > > 	And I get back :
> > > 
> > > camcontrol: modepage entry "ARRE (Auto Read Reallocation Enbld)" is read-only; skipping.
> > > 
> > > 
> > > 	Am I doing something wrong?
> > 
> > That's the expected response for a bit marked read-only.  It looks like
> > your drive is probably broken, though.  It's returning the same values when
> > you set the page control field to 1 as the current values.  It should
> > return a bitmask instead.
> > 
> > What drive vendor/model is this?
> >
> umass0: Generic Mass Storage Device, rev 2.00/1.41, addr 2
> da0 at umass-sim0 bus 0 target 0 lun 0
> da0: <JetFlash TS4GJF2A/120 8.07> Removable Direct Access SCSI-2 device 
> da0: 1.000MB/s transfers
> da0: 3999MB (8191998 512 byte sectors: 255H 63S/T 509C)
> 
> 	USB pendrive......

That explains things...

> > 
> > In any case, it probably doesn't matter that much.  If the drive can't read
> > the block you're trying to read, there is a 99% likelihood that it won't be
> > able to do ARRE on that particular block, either.  ARRE is only useful for
> > blocks that can still be reconstructed with ECC information, not for blocks
> > that are beyond repair.
> >
> 	I was hoping it would "try" to move it, and mark it bad so I can
> atleast continue to use it as is. If something was destroyed, atleast I
> can get the rest of the information.

Your best bet is to write to that individual sector.  Since the drive seems
to support write reallocation, that should allow it to remap that sector,
and the rest of the drive should be useable. 

One way to try to pull all of the accessible data off the drive is phk's
'recoverdisk' program, located in /usr/src/tools/tools/recoverdisk.

It will pull as many blocks as it can off the drive.

You could pull off as many blocks as you can into a file that is an image
of the drive, and then dd that image back over the drive itself.

> > Although it would be good to turn on ARRE for any future bad blocks that
> > can be recovered on read.
> > 
> > I think the only way to do that with camcontrol for this particular drive
> > would probably be with 'camcontrol cmd'.  You'd have to format the CDB and
> > mode page by hand.  'camcontrol modepage' won't let you edit fields that
> > the drive says can't be edited.
> > 
> 	This is *W-A-Y* out of my league...... :-/

recoverdisk may be a little easier to deal with.

Ken
-- 
Kenneth Merry
ken at kdm.org