From owner-freebsd-current Thu Sep 24 10:08:17 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA02544 for freebsd-current-outgoing; Thu, 24 Sep 1998 10:08:17 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA02539 for ; Thu, 24 Sep 1998 10:08:14 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.1/8.7.3) id LAA01778; Thu, 24 Sep 1998 11:01:33 -0600 (MDT) Date: Thu, 24 Sep 1998 11:01:33 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199809241701.LAA01778@narnia.plutotech.com> To: Adam McDougall cc: current@FreeBSD.ORG Subject: Re: options DPT_LOST_IRQ Newsgroups: pluto.freebsd.current In-Reply-To: <199809240354.VAA03623@narnia.plutotech.com> <3609D94D.8397CF49@ameritech.net> User-Agent: tin/pre-1.4-971204 (UNIX) (FreeBSD/3.0-BETA (i386)) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > The symptom (at least on my system) is that the HD totally freezes up > with the light on, and the dpt sits there merrily idle, while freebsd > processes start losing sanity because the disk cannot be accessed (eg. > any interaction with the system which would trigger a HD access would > freeze up that portion of the system..) I know there is a 'irq > pending' led on the dpt which may indicate the condition has occurred > for some people, but mine didnt happen this way, and adding this kernel > option ceased the described lockups. I have a 2144UW, a Atlas II, and a > Mtech R534 motherboard. This looks like an "Atlas II firmware of death" problem, not a DPT problem. What firmware are you using? Before switching to LYK8, I saw similar behavior on an Adaptec controller with an AtlasII. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message