Date: Tue, 6 Jun 1995 08:11:18 -0400 (EDT) From: Peter Dufault <dufault@hda.com> To: taob@gate.sinica.edu.tw (Brian Tao) Cc: freebsd-hackers@freebsd.org Subject: Re: Quantum hardware errors (Deferred Error: HARDWARE FAILURE asc:87,0) Message-ID: <199506061211.IAA16611@hda.com> In-Reply-To: <Pine.BSI.3.91.950606122646.3207K-100000@leo> from "Brian Tao" at Jun 6, 95 01:07:07 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Brian Tao writes: > > I mknod'd a 13:536870912 character special file and now it works. > Did the 2.0.5 installation mess up the minor device numbers? I don't > see any *.ctl devices on my pre-2.0.5 machines, so I presume this is a > new feature (and thus couldn't have been left over from previous > installs)? Anyhow, you were right about the write-cache: > > # scsi -f rsd0.ctl -m 8 > WCE: 1 <--- (write cache enabled, for the -hackers folks) > MF: 0 > RCD: 0 > Demand Retention Priority: 0 > Write Retention Priority: 0 > Disable Pre-fetch Transfer Length: 0 -> yours is 65535 > Minumum Pre-fetch: 8 -> yours is 0 > Maximum Pre-fetch: 128 > Maximum Pre-fetch Ceiling: 128 > > So this is the firmware on the *drive* and not the controller > then... is this something we have to watch out for in 2.0.5, or has it > just been lurking around for the past six months on my 2.0 systems > without causing any trouble? No, your drive has always had this setting. You were living dangerously in the event of a power failure. Everyone should check their drives and disable this. Be sure you also have Automatic Write Reallocation Enabled and Automatic Read Reallocation Enabled in mode page 1. The nature of the deferred error is that the OS thought the write succeeded and then later on reports back an error (in this case, it said the write succeeded when it cached the data on the disk, and then reported the failure when it couldn't transfer the cache to disk for some reason). In 2.1 the system will sanity check the mode page settings during boot and will comment on anything it thinks is set wrong. > I then used "scsi -f /dev/rsd2.ctl -m 8 -e -P 3" to turn off > write-cache enable. The minimum pre-fetch on my drive was set to 8, > but I noticed yours is 0. I suppose this value means the drive will > always try to grab 8 blocks at once? It is set to 0 now, to match > yours, if it makes any difference. Mine may not be correct; it is just set as the vendor shipped it. Quantum may have some reason they want the drives set that way. > Noticed another error from syslog that happened about 8 hours after: > > /kernel: sd0(ncr0:6:0): Deferred Error: HARDWARE FAILURE asc:87,0 > [...8 hours...] > /kernel: vnode_pager_input: I/O read error > /kernel: vm_fault: pager input (probably hardware) error, PID 163 failure > > Same cause? Or something completely different? As for the first > error, I'll see if my dealer has the tech books from Quantum (unless > someone knows Quantum's number in Taipei). Something completely different, I think. You are saying there is an 8 hour delay between the hardware failure and the read complaint from the vnode pager? It looks to be a bug that there was no read fail message immediately before the vnode message. Peter -- Peter Dufault Real Time Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 dufault@hda.com Fax: 508 433 5267
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199506061211.IAA16611>