Date: Mon, 28 Aug 1995 20:02:09 -0700 (PDT) From: Julian Elischer <julian@ref.tfs.com> To: hsu@cs.hut.fi (Heikki Suonsivu) Cc: rashid@haven.ios.com, freebsd-hackers@freefall.FreeBSD.org Subject: Re: S.O.S -2.1Stable and ASUSP54TP4 Message-ID: <199508290302.UAA15622@ref.tfs.com> In-Reply-To: <199508290120.EAA08982@shadows.cs.hut.fi> from "Heikki Suonsivu" at Aug 29, 95 04:20:02 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > One of the SCSI disks becomes unreachable: IBM 0662's say "Disk dribe is > becoming ready", often survies, Seagates lock up. Usually we get IO > errors, panic, and the system gets stuck in SCSI BIOS probes (probably, it > says WAIT and sits there until reset, sometimes requiring several resets or > a power cycle). > [...] > hang in BIOS probes (assuming that Buslogic & NCR did their code right). > This has been around since spring, at least. I've seen SCSI devices hang the scsi bus so solidly that they freeze the SCSI adapter just as solid half way through a DMA.... EVERYTHING stops.. I figure the mechanism is: DMA from SCSI to shared memory buffer on board freezes. DMA to motherboard cannot get Data ACK, and also freezes, holding an outsanding cycle on the EISA/VESA/Whatever bus which freezes the CPU :( > > that certain sequences of disk accesses kill the SCSI. certain patterns of data allowed the SCSI block agregation code to produce a really big DMA request.. Other Operating systems often don't do this so there are certainly several drive models out there that fail on this.. > Maybe seagate did something wrong in their disks? Tagged queuing? When it > came around? > have you tried en/dis abling this? > -- > Heikki Suonsivu, T{ysikuu 10 C 83/02210 Espoo/FINLAND, > hsu@cs.hut.fi home +358-0-8031121 work -4513377 fax -4555276 riippu SN >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199508290302.UAA15622>