Date: Mon, 2 Nov 1998 00:10:58 +0100 From: Bernd Walter <ticso@cicely.de> To: "Justin T. Gibbs" <gibbs@narnia.plutotech.com> Cc: current@FreeBSD.ORG Subject: Re: scsi disk (cam?) problems Message-ID: <19981102001058.41129@cicely.de> In-Reply-To: <199811011924.MAA08917@narnia.plutotech.com>; from Justin T. Gibbs on Sun, Nov 01, 1998 at 12:24:09PM -0700 References: <199811010132.UAA04810@bb01f39.unx.sas.com> <199811011924.MAA08917@narnia.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Nov 01, 1998 at 12:24:09PM -0700, Justin T. Gibbs wrote: > In article <19981101195246.10586@cicely.de> you wrote: > > Very interesting. > > I've saw the same message yesterday: > > Oct 31 20:10:18 cicely5 /kernel: (da23:ahc4:0:1:0): Invalidating pack > > What kinds of power supplies are all of you using? The reason the It's a new Power-Supply so maybe it's broken. The supply has only this SCSI-Chain with 4-CDOMs 1 Streamer 1 HDD and this MO Drive. Only the MO Drive was used from this Supply at the time of the error. Don't shure about the cabeling, because it's only up for 2 days. I'll check it. > pack is being invalidated is that the drive in question is not > responding within a selection timeout period (250ms). This is That's long - but I don't know how the drive handles media-errors. At least my Win-NT Host on which the drive was connected before has done serveral bus-resets in case of an media-problem. They were reproduceable on the same sectors. So maybe the firmware s broken. > usually because of a device no being there, but I suspect in this > case the cause is a parallel I/O load that pushes your drives > to their maximum power rating, saturating your power supply leaving > one or more devices starving for power. Any I/O attempted while > the drive is going through a power-on reset is likely to fail with > a selection timeout. If it was a complete power-on reset the old SCSI-code would have given me some information about during the next access - I asume CAM is doing the same. In case of a bus-problem I'm used to see things like bus-resets. I don't realy like them - especialy with Streamers on the same bus - but I'm shure sometimes they are sensefull. What I don't understand is why the system can't recover from that failure. as mentioned earlier the drive is still accessable via camcontrol but not via the mounted fsdriver. > > I will change the error handler for the selection timeout case to > return EIO instead of ENXIO, but this is just a temporary work around By the way I'm not so deep into this - what are the differences? > until we can provide a better pack invalidation scheme in the system. > > -- > Justin -- Mfg B.Walter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19981102001058.41129>