Date: Fri, 23 Jul 1999 08:59:29 -0600 (MDT) From: "Kenneth D. Merry" <ken@plutotech.com> To: asami@FreeBSD.ORG (Satoshi - Ports Wraith - Asami) Cc: mike@smith.net.au, scsi@FreeBSD.ORG Subject: Re: error logs Message-ID: <199907231459.IAA94485@panzer.kdm.org> In-Reply-To: <199907230948.CAA10870@silvia.hip.berkeley.edu> from Satoshi - Ports Wraith - Asami at "Jul 23, 1999 02:48:01 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Satoshi - Ports Wraith - Asami wrote...
> * From: Mike Smith <mike@smith.net.au>
>
> Ken says (" * > ")
> * > If it gets retried, it gets retried above the CAM layer. When CAM prints
> * > out an error message, it almost always is after all retries have been
> * > completed. Read and write commands from the da driver have a retry count
> * > of 4.
>
> So, if I see three lines of the standard read error but not anything
> else, can I assume that the kernel retried it and the disk
> successfully read the sector(s) the second time around without any
> hitch?
Maybe, maybe not. :) It depends on how the upper level code handles it.
It may be that if the read failed, the upper level code passes back the
error to the userland application that generated the request, and what
happens then is up to the application. I really don't know what happens
above CAM, someone else may have a clue, though.
One thing to keep in mind is that once you get an error printout from the
da driver, it has already retried the command 4 times. While it is
possible that the command will succeed if retried again, I think it's
unlikely.
> * I would have expected to see a grown defect for 0x3cf817 somewhere in
> * the grown defect list, however there isn't one before 0x5dd84b. I
> * don't know where the threshold for reallocating a block is set on this
> * disk (Quantum XP34301).
>
> As for this particular disk, I see the following message at about the
> time you sent this out:
>
> Jul 21 17:41:58 bento /kernel: (pass7:ahc1:0:4:0): READ DEFECT DATA(10). CDB: 37 0 0 0 0 0 0 fd e8 0
> Jul 21 17:41:58 bento /kernel: (pass7:ahc1:0:4:0): RECOVERED ERROR asc:1c,0
> Jul 21 17:41:58 bento /kernel: (pass7:ahc1:0:4:0): Defect list not found sks:80,0
>
> Are you sure that the list itself isn't unreadable?
That error message sometimes gets printed out when the disk doesn't like
the defect list format you asked for. Quantums usually support block
format, but most every disk I've seen at least supports physical sector
format. Most IBM and Seagate disks do not support block format.
In some cases, if a drive doesn't support a given defect list format, it
will send back the defect list in some other format. camcontrol attempts
to deal with that scenario, if it can detect it. However it only ends up
working in some cases, either because the drives use different error codes
to indicate that they're returning a different defect list format, or
because the drive won't return a defect list at all if you don't ask for
one in a format it supports.
Ken
--
Kenneth Merry
ken@plutotech.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907231459.IAA94485>