Date: Thu, 24 Sep 1998 21:30:43 +0200 From: Eivind Eklund <eivind@yes.no> To: "Justin T. Gibbs" <gibbs@plutotech.com> Cc: Adam McDougall <mcdougall@ameritech.net>, current@FreeBSD.ORG Subject: Re: options DPT_LOST_IRQ Message-ID: <19980924213043.19742@follo.net> In-Reply-To: <199809241837.MAA28761@pluto.plutotech.com>; from Justin T. Gibbs on Thu, Sep 24, 1998 at 12:30:29PM -0600 References: <19980924200044.27705@follo.net> <199809241837.MAA28761@pluto.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Sep 24, 1998 at 12:30:29PM -0600, Justin T. Gibbs 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 didn't, at least, as I don't have the relevant equipment to reproduce the fault, and didn't learn about it until a month and a half ago, when somebody else (outside the FreeBSD camp proper) was already working on fixing that code. However, I believe that project has been abandoned for the time being. There are (according to my source - I don't have SMP and don't know the issues) a bunch of problems related to interrupts and SMP. I don't know if the DPT_LOST_IRQ problem only occur on SMP - Adam, do you have SMP? > I'd hate to have a situation where lots of drivers each have their own > little timeout handler to deal with this problem. I absolutely agree. However, no matter what, it is better for the DPT to work (with that kind of kludge) than for it to die. Eivind. 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?19980924213043.19742>