Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 23 Sep 1998 21:54:40 -0600 (MDT)
From:      "Justin T. Gibbs" <gibbs@narnia.plutotech.com>
To:        Adam McDougall <mcdougall@ameritech.net>
Cc:        current@FreeBSD.ORG
Subject:   Re: options DPT_LOST_IRQ
Message-ID:  <199809240354.VAA03623@narnia.plutotech.com>
In-Reply-To: <3609A685.A9B65B3A@ameritech.net>

next in thread | previous in thread | raw e-mail | index | archive | help
In article <3609A685.A9B65B3A@ameritech.net> you wrote:
> Does CAM still perform what is supposed to when using this kernel
> option? Because it doesn't show any evidence of it in Boot: -v and the
> unwanted behavior of not using this option is showing up again, even
> though its still in my kernel.

The CAM driver does not currently honor this option.  It could easily
be added again, but it would be nice to know why it is necessary.  Is
the symptom simply a timeout?

One thing I noticed that the Linux driver does in it's interrupt
handler that FreeBSD doesn't, is to watch for the busy bit in the
aux status register.  Is this important?  (I don't have any docs...)
Could it be that we inadvertantly clear an interrupt before the
status packet write is complete?

If the problem is in the FreeBSD interrupt code, we should find out
for sure.  I may not have a fast enough adapter (PM3224A) to make
the failure occur here, under a PCI bus analyzer, to determine one
way or the other.

> Thanks in advance..

--
Justin

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?199809240354.VAA03623>