Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 21 Sep 1997 16:37:29 -0400
From:      Charles Henrich <henrich@crh.cl.msu.edu>
To:        freebsd-hackers@freebsd.org
Subject:   SCSI Nastiness (bad Quantum?)
Message-ID:  <19970921163729.47395@crh.cl.msu.edu>

next in thread | raw e-mail | index | archive | help
Okay I have this Quantum XP32150W (last time I *ever* buy Quantum, 4 of the 12
drives I bought in January have so far gone bad.. 5 is working real hard at it
right now).  Its part of a CCD array, so I would like to if possible bring
this disk back alive enough to get its data copied off to another disk.

When its active I see this (2.2.2-RELEASE):

Sep 21 14:36:32 msunews /kernel: sd23(ahc0:3:0): MEDIUM ERROR info:16bb11 csi:4,7f,7,48 asc:11,0 Unrecovered read error sks:80,70
Sep 21 14:36:32 msunews /kernel: , retries:4
Sep 21 14:36:34 msunews /kernel: sd23(ahc0:3:0): MEDIUM ERROR info:16bb11 csi:4, 7f,7,48 asc:11,0 Unrecovered read error sks:80,70
Sep 21 14:36:34 msunews /kernel: , retries:3
Sep 21 14:36:36 msunews /kernel: sd23(ahc0:3:0): MEDIUM ERROR info:16bb11 csi:4, 7f,7,48 asc:11,0 Unrecovered read error sks:80,70
Sep 21 14:36:36 msunews /kernel: , retries:2 
Sep 21 14:36:39 msunews /kernel: sd23(ahc0:3:0): MEDIUM ERROR info:16bb11 csi:4, 7f,7,48 asc:11,0 Unrecovered read error sks:80,70
Sep 21 14:36:39 msunews /kernel: , retries:1
Sep 21 14:36:41 msunews /kernel: sd23(ahc0:3:0): MEDIUM ERROR info:16bb11 csi:4,
7f,7,48 asc:11,0 Unrecovered read error sks:80,70
Sep 21 14:36:41 msunews /kernel: , FAILURE
Sep 21 14:40:14 msunews /kernel: sd23(ahc0:3:0): MEDIUM ERROR info:16bb11 csi:4, 7f,7,48 asc:11,0 Unrecovered read error sks:80,e0
Sep 21 14:40:14 msunews /kernel: , retries:4 
Sep 21 14:40:17 msunews /kernel: sd23(ahc0:3:0): MEDIUM ERROR info:16bb11 csi:4, 7f,7,48 asc:11,0 Unrecovered read error sks:80,e0
Sep 21 14:40:17 msunews /kernel: , retries:3
Sep 21 14:44:49 msunews /kernel: sd23(ahc0:3:0): SCB 0xd - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0
Sep 21 14:44:49 msunews /kernel: SEQADDR = 0x6 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT 1 = 0xa
Sep 21 14:44:49 msunews /kernel: Ordered Tag queued
Sep 21 14:44:49 msunews /kernel: sd23(ahc0:3:0): SCB 0x3 timedout while recovery in progress
Sep 21 14:44:49 msunews /kernel: sd23(ahc0:3:0): SCB 0xe timedout while recovery in progress
Sep 21 14:44:54 msunews /kernel: sd23(ahc0:3:0): SCB 0xd - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0
Sep 21 14:44:54 msunews /kernel: SEQADDR = 0x7 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT 1 = 0xa
Sep 21 14:44:54 msunews /kernel: sd23(ahc0:3:0): Queueing an Abort SCB
Sep 21 14:44:54 msunews /kernel: sd23(ahc0:3:0): Abort Message Sent
Sep 21 14:44:54 msunews /kernel: sd23(ahc0:3:0): SCB 13 - Abort Tag Completed.
Sep 21 14:44:54 msunews /kernel: sd23(ahc0:3:0): no longer in timeout
Sep 21 14:44:54 msunews /kernel: Ordered Tag sent
Sep 21 14:44:56 msunews /kernel: sd23(ahc0:3:0): SCB 0x7 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0
Sep 21 14:44:56 msunews /kernel: SEQADDR = 0x9 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT 1 = 0xa
Sep 21 14:44:56 msunews /kernel: Ordered Tag queued

... Ad Nausem.  I've run Adaptec's verify tool, and it happily reports several
bad sectors, and asks if I wish to remap.  When I say yes, it appears to do
nothing, and a re-verify pass pops up the "remap?" requestor on the same
sectors, so obviously the quantum is ignoring those remap requests.  I also
have AWRE/ARRE on that drive.  Any ideas?

Thanks a bunch!

-Crh

       Charles Henrich     Michigan State University     henrich@msu.edu

                         http://pilot.msu.edu/~henrich



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970921163729.47395>