Date: Mon, 7 Dec 1998 19:41:16 -0500 (EST) From: Doug Ledford <dledford@redhat.com> To: "Holger.Lenz" <Holger.Lenz@m.dasa.de> Cc: Dirk Lutzebaeck <lutzeb@aeccom.com>, aic7xxx@FreeBSD.ORG Subject: Re: Async negotiation (Was: 2.0.36/5.1.4 and BIOS settings) Message-ID: <Pine.LNX.4.04.9812071937400.1399-100000@kabal.redhat.com> In-Reply-To: <36653337.579550@m.dasa.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2 Dec 1998, Holger.Lenz wrote:
> Dirk Lutzebaeck wrote:
> > Interesting that 5.1.4 doesnt care about the BIOS settings. I have
> > also bus hang problems with my Seagate DAT. I suspect its because the
> > u2w driver enables sync mode although async mode is set in the
> > BIOS. The DAT FAQ says to always use async mode... Bummer.
>
> I'm not so sure the driver isn't doing the RightThing(tm). The BIOS
> setting says not to _inititiate_ the sync negotiation, but maybe
> the target requests sync by itself (decent drives often have jumpers
> to have them initiate sync negotiation by themselves). Maybe someone
> very familiar with the SCSI spec could enlighten us here..
> In any case, it would be nice to have a way to force async transfers
> to get around those buggy peripheral pitfalls.
The 5.1.5 driver does fix a bug where devices that initiate their own
negotiation would not honor the SEEPROM based settings. A few people need
to choke their devices down to slower speeds for various reasons, such as
bus length, termination quality, whatever. However, in regards to the DAT
drive in question. If that FAQ says to always use async mode regardless
of the make or model of drive then they need to bite me. There are lots
of DAT drives out there that work great at sync speeds. HP and SONY tend
to run forever sync. If Seagate DATs have a problem in specific then
that's another matter, but last I knew, Seagate only says to disable sync
negotiation on the model ST8000N drives or something like that. It's a
SCSI Travan drive that doesn't reliably do sync (and doesn't work reliably
under linux for reasons other than the bus, the drive doesn't like some of
the commands the mid level SCSI code generates and issues error conditions
back to the tape driver).
Doug Ledford <dledford@redhat.com>
Opinions expressed are my own, but
they should be everybody's.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-aic7xxx" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.04.9812071937400.1399-100000>