Date: Thu, 24 Sep 1998 18:50:30 -0400 (EDT) From: Simon Shapiro <shimon@simon-shapiro.org> To: "Justin T. Gibbs" <gibbs@plutotech.com> Cc: current@FreeBSD.ORG, Adam McDougall <mcdougall@ameritech.net>, Eivind Eklund <eivind@yes.no> Subject: Re: options DPT_LOST_IRQ Message-ID: <XFMail.980924185030.shimon@simon-shapiro.org> In-Reply-To: <199809241837.MAA28761@pluto.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Justin T. Gibbs, On 24-Sep-98 you wrote:
> >This option is necessary due to interrupts being eaten by the serial
> >driver 'fast interrupt' code (which in some cases blocks interrupts
> >longer than the DPT assert them).
>
> Wow. I thought that the fast interrupt code could only cause interrupts
> to be deferred, never eaten. Did anyone ever talk to Bruce about this?
> I'd hate to have a situation where lots of drivers each have their own
> little timeout handler to deal with this problem.
Yes, I did. IT appears I am one of the few who can both reproduce it and
have enough hardware and DPT internals savvy to actually trace it well.
The LOST_IRQ option was a hack. I kept it this way in the hope that CAM
will make the problem go away. I can add it back in, especially if there
are reports that it is still needed.
General Background:
a. I did, in the original driver, carefully read the auxiliary status
register first, and only read the formal status register later in
dpt_intr. Here is why; Reading the status register clears (from the
DPT point of view) the interrupt and causes it to immediately start the
next process, which might wipe out the status packet, the completion
packet or both. This will mean certain disaster.
b. In the case of a cache hit, the DPT will complete operations and
generate interrupts less than a microsecond apart. The (now removed,
soon to be added again) measure_performance option demonstrates this
clearly. Such bursts can have up to 64 interrupts per burst. The
FreeBSD interrupt code has known holes in it, that will cause such
closely spaced interrupts to be lost. This can also cause the system to
hang.
c. If you carefully examine the original dpt_irq you will see this code.
d. If you need/want to know something about the DPT hardware that is not
in the public documentation, I am still available and eager to answer
:-)
I do not think the the lost_irq option was a good solution, but a necessary
hack. I am quite open to suggestions on how to go about it.
Simon
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?XFMail.980924185030.shimon>