Port-amiga archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Reading bad disk



Hi,

On Thu, May 01, 2003 at 01:21:26AM +0100, Lars Hecking wrote:

>  My idea was whether I could salvage anything from that disk via NetBSD,
>  but it seems to be next to impossible. Here's the relevant part of dmesg:

i


> 
> 
> NetBSD 1.6.1 (RUSTY) #3: Mon Apr 28 00:59:53 IST 2003
>     root@localhost:/usr/src/sys/arch/amiga/compile/RUSTY
> Amiga 3000 (m68040 CPU/MMU/FPU)
> total memory = 22528 KB
> avail memory = 19312 KB
> using 153 buffers containing 1224 KB of memory
> memory segment 0 at 08000000 size 00600000
> memory segment 1 at 07000000 size 01000000
> memory segment 2 at 00000000 size 00200000
> mainbus0 (root)
> clock0 at mainbus0: CIA B system hz 100 hardware hz 709379
> Calibrating delay loop... 111/1024 us
> a34kbbc0 at mainbus0
> ser0 at mainbus0: input fifo 512 output fifo 256
> par0 at mainbus0
> kbd0 at mainbus0: CIA A type Amiga
> ms0 at mainbus0
> grfcc0 at mainbus0
> grf0 at grfcc0: width 640 height 400 colors 4
> ite0 at grf0: rows 0 cols 0 repeat at (30/100)s next at (10/100)s has keyboard
> fdc0 at mainbus0: dmabuf pa 0x1e525c: dmabuf ka 0x8b9f25c
> fd0 at fdc0 unit 0: 3.5dd 80 cyl, 2 head, 11 sec [9 sec], 512 bytes/sec
> ahsc0 at mainbus0
> scsibus0 at ahsc0: 8 targets, 8 luns per target
> aucc0 at mainbus0
> audio0 at aucc0: half duplex
> zbus0 at mainbus0: i/o size 0x00200000
> grfcl0 at zbus0 pa 0x40000000 man/pro 2193/1
> grf3 at grfcl0: width 640 height 480 colors 16
> ite3 at grf3: rows 60 cols 80 repeat at (30/100)s next at (10/100)s has 
> keyboard
> grfcl: 2MB Spectrum being used
> grfcl1 at zbus0 pa 0xe90000 man/pro 2193/2
> ite at grfcl1:  not configured
> scsibus0: waiting 2 seconds for devices to settle...
> ahsc0: target 0 now synchronous, period=208ns, offset=12.
> sd0 at scsibus0 target 0 lun 0: <IBM, DPES-31080, S31Q> SCSI2 0/direct fixed
> sd0: 1034 MB, 4903 cyl, 4 head, 108 sec, 512 bytes/sect x 2118144 sectors
> ahsc0: target 1 now synchronous, period=208ns, offset=12.
> sd1 at scsibus0 target 1 lun 0: <IBM, DCAS-34330, S61A> SCSI2 0/direct fixed
> sd1: 4134 MB, 8205 cyl, 6 head, 171 sec, 512 bytes/sect x 8467200 sectors
> ahsc0: target 2 now synchronous, period=208ns, offset=12.
> sd2 at scsibus0 target 2 lun 0: <SEAGATE, ST31200N SUN1.05, 8564> SCSI2 
> 0/direct fixed
> sd2: 1006 MB, 2700 cyl, 9 head, 84 sec, 512 bytes/sect x 2061108 sectors
> ahsc0: target 3 now synchronous, period=208ns, offset=12.
> sd3 at scsibus0 target 3 lun 0: <SEAGATE, ST31200N SUN1.05, 8564> SCSI2 
> 0/direct fixed
> sd3: 1006 MB, 2700 cyl, 9 head, 84 sec, 512 bytes/sect x 2061108 sectors
> 4 views configured
> warning unknown dostype: 0x53575000 marking unused
> warning found rdb->secpercyl(756) != rdb->nsectors(85) * rdb->nheads(9)
> sd3(ahsc0:0:3:0):  Check Condition on CDB: 0x08 00 00 00 01 00
>     SENSE KEY:  Media Error
>      ASC/ASCQ:  Address Mark Not Found for ID Field
>      FRU CODE:  0xe8
>          SKSV:  Actual Retry Count: 0
> 
> sd3: rdb scan I/O error
> 
>  Does anybody have ideas what I could do? There is no critical data on the
>  system, in fact, the configuration of the NetBSD disk is almost identical,
>  give or take a few ports/packages. But it would be nice to salvage as much
>  as possible.

Ok.... you have the CDB, so you know the block number.
In this case, it is a Read(6) command (first byte 0x08).

LUN is 0 (leftmost 3 bits in 2nd byte), block number is 0x000000 (2nd, 
3rd and 4th byte), Transfer length is 1 (5th byte). The last byte contains
some flags not relevant here.

You can tell the disk to reassign that block, using the scsictl command.

Only problem is, you'll lose the contents, and it most probably is the
RDB header block! In case you wrote down the RDB parameters on paper
somewhere and can repartition the disk to the same values, you'll
probably lose everything. 

So what you might try, is:

write a program that reads a block (512 bytes) at offset 0 off the raw disk
(/dev/rsd3c in this case), and repeats on error, at least a couple of times.

Once it succeeds, it should:

a) write that block to a _different_ disk (onto a file!) 

_Then_ you reassign the block,
_Then_ you write the saved block back.

(Hm, a shell loop around dd might work, too).

Good luck!

Regards,
        -is
-- 
seal your e-mail: http://www.gnupg.org/

Attachment: pgpGj_Vpk23OZ.pgp
Description: PGP signature



Home | Main Index | Thread Index | Old Index