From owner-freebsd-hackers Tue Feb 2 13:58:05 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA10789 for freebsd-hackers-outgoing; Tue, 2 Feb 1999 13:58:05 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA10722 for ; Tue, 2 Feb 1999 13:57:59 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id NAA01166; Tue, 2 Feb 1999 13:53:57 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199902022153.NAA01166@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Jason Thorpe cc: Emmanuel Duros , freebsd-hackers@FreeBSD.ORG Subject: Re: writing network device driver - pb with interrupt levels In-reply-to: Your message of "Tue, 02 Feb 1999 11:32:24 PST." <199902021932.LAA26228@lestat.nas.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 02 Feb 1999 13:53:57 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Tue, 2 Feb 1999 20:17:34 +0100 (MET) > Emmanuel Duros 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