Date: Sat, 24 Oct 1998 15:13:47 -0600 (MDT) From: "Kenneth D. Merry" <ken@plutotech.com> To: braukmann@tse-online.de (Andreas Braukmann) Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: bad sectors Message-ID: <199810242113.PAA02688@panzer.plutotech.com> In-Reply-To: <19981024083139.H365@paert.tse-online.de> from Andreas Braukmann at "Oct 24, 98 08:31:39 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Andreas Braukmann wrote... > Hi again, > > ... I have to admit, that I've simply forgotten to peek into > /var/log/messages (the console is 600m away from me). > And there are the error messages: > > Oct 23 07:32:04 paert /kernel: (pass1:ncr0:0:1:0): extraneous data discarded. > Oct 23 07:32:05 paert /kernel: (pass1:ncr0:0:1:0): COMMAND FAILED (9 0) @0xf0e88200. Well, that explains some things, I guess. :) It at least explains why the command is coming back with no SCSI sense information. It shouldn't be coming back with a CAM status of 0, though, since that means the request is still in progress. (it obviously isn't) I don't know how to decipher NCR error messages, though, so I can't tell you why the command is failing. :( > On Fri, Oct 23, 1998 at 07:30:56AM +0200, Andreas Braukmann wrote: > > On Thu, Oct 22, 1998 at 05:10:02PM -0600, Kenneth D. Merry wrote: > > > Andreas Braukmann wrote... > > > > from dmesg: > > > > da1 at ncr0 bus 0 target 1 lun 0 > > > > da1: <IBM DDRS-39130W S92A> Fixed Direct Access SCSI2 device > > > > da1: 40.0MB/s transfers (20.0MHz, offset 15, 16bit), Tagged Queueing Enabled > > > > da1: 8715MB (17850000 512 byte sectors: 255H 63S/T 1111C) > > > > > > > > any hints? is it my fault? the drive's fault? > > > > > > Try a different format (the other choices are 'bfi' and 'block'). Some > > > drives don't support all of the different formats. > > Hmmm. The results: > > paert# camcontrol defects -v -n da -u 1 -f block -P > > error reading defect list: Input/output error > > CAM status is 0 > > paert# camcontrol defects -v -n da -u 1 -f phys -P > > error reading defect list: Input/output error > > CAM status is 0 > > paert# camcontrol defects -v -n da -u 1 -f bfi -P > > error reading defect list: Input/output error > > CAM status is 0 > > > > IMHO strange. I get the same for '-G'. > > > > > the command line, you'll get sense information that will tell you why the > > > command is failing. > > hhm. The i/o ist failing, but camcontrol doesn't print any sense information. > > > > Two questions arise: > > a) Are the IBM drives supposed to deliver the requested error > > information? Yes, they are. I've got IBM drives that will happily report their bad block information. > > b) I might build a kernel with some CAM-debug options. Would this > > be helpful. I doubt it, really. The reason is that there are two types of debugging information you can get from the kernel: - function-level tracing - CDB printouts The latter is the only one that is really useful. In this case, we know what command is getting sent to the disk, because it's created in camcontrol and passed down through the passthrough driver. It looks like the NCR driver is spitting the command out for some reason. I don't know what that reason is, however. Sorry. Stefan Esser would probably be able to tell you what the NCR error messages mean. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810242113.PAA02688>