Date: Tue, 02 Feb 1999 13:53:57 -0800 From: Mike Smith <mike@smith.net.au> To: Jason Thorpe <thorpej@nas.nasa.gov> Cc: Emmanuel Duros <Emmanuel.Duros@sophia.inria.fr>, freebsd-hackers@FreeBSD.ORG Subject: Re: writing network device driver - pb with interrupt levels Message-ID: <199902022153.NAA01166@dingo.cdrom.com> In-Reply-To: Your message of "Tue, 02 Feb 1999 11:32:24 PST." <199902021932.LAA26228@lestat.nas.nasa.gov>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Tue, 2 Feb 1999 20:17:34 +0100 (MET) > Emmanuel Duros <Emmanuel.Duros@sophia.inria.fr> wrote: > > > When writing on the IDE drive, the fifo of the card gets completely > > filled and therefore loses bytes. In fact I cannot read data as fast as > > it arrives because the CPU is busy with I/O accesses on the IDE > > drive. It seems the drive I/O have higher interrupt level than the card > > has. (BTW, the code works fine with an SCSI drive instead !?!??!) > > In NetBSD, we fixed this by enforcing an "spl heirarchy". > > Note, in my example, I say splnet, because in NetBSD network soft interrupts > are "splsoftnet". > > splbio <= splnet <= spltty <= splimp > > This allows you to block other interrupts from things which are less likely > to lose data if their interrupt is not serviced quickly. > > So, in your device interrupt handler (which is implicitly run at splnet), > bio interrupts are also implicitly blocked so that your driver can work > unhindered (but serial interrrupts, which are less freqent and more prone > to data loss, can still come through). If it is actually interrupt-related, it's fairly manifest that this isn't actually the problem, as otherwise the splimp() around the handler loop would have drastically reduced the incidence of overflows. (ie. artificially implementing priority of 'dv' over 'wd' interrupts). -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902022153.NAA01166>