From owner-freebsd-scsi Fri Jul 23 8: 1: 3 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 69F1E14D66; Fri, 23 Jul 1999 08:00:54 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id IAA94485; Fri, 23 Jul 1999 08:59:29 -0600 (MDT) (envelope-from ken) Message-Id: <199907231459.IAA94485@panzer.kdm.org> Subject: Re: error logs In-Reply-To: <199907230948.CAA10870@silvia.hip.berkeley.edu> from Satoshi - Ports Wraith - Asami at "Jul 23, 1999 02:48:01 am" To: asami@FreeBSD.ORG (Satoshi - Ports Wraith - Asami) Date: Fri, 23 Jul 1999 08:59:29 -0600 (MDT) Cc: mike@smith.net.au, scsi@FreeBSD.ORG From: "Kenneth D. Merry" X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Satoshi - Ports Wraith - Asami wrote... > * From: Mike Smith > > 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