Date: Tue, 02 Feb 1999 19:43:49 -0500 From: Dennis <dennis@etinc.com> To: Mike Smith <mike@smith.net.au>, 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: <199902021938.TAA14862@etinc.com> In-Reply-To: <199902022153.NAA01166@dingo.cdrom.com> References: <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
At 01:53 PM 2/2/99 -0800, Mike Smith wrote: >> 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). Note, as I said before, it is VERY possible that the fifo simply isnt large enough... before jumping into analysis, the simple question of whether it is feasible to do needs to be answered. not everything can be done....... What is the transmission rate, and what is the size of the fifo? db 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?199902021938.TAA14862>