From owner-freebsd-hackers Tue Feb 2 11:44:09 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA22847 for freebsd-hackers-outgoing; Tue, 2 Feb 1999 11:44:09 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from bright.fx.genx.net (bright.fx.genx.net [206.64.4.154]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA22840 for ; Tue, 2 Feb 1999 11:44:04 -0800 (PST) (envelope-from bright@hotjobs.com) Received: from localhost (bright@localhost) by bright.fx.genx.net (8.9.1/8.9.1) with ESMTP id OAA02511; Tue, 2 Feb 1999 14:47:58 -0500 (EST) (envelope-from bright@hotjobs.com) X-Authentication-Warning: bright.fx.genx.net: bright owned process doing -bs Date: Tue, 2 Feb 1999 14:47:58 -0500 (EST) From: Alfred Perlstein X-Sender: bright@bright.fx.genx.net To: Jason Thorpe cc: Emmanuel Duros , freebsd-hackers@FreeBSD.ORG Subject: Re: writing network device driver - pb with interrupt levels In-Reply-To: <199902021932.LAA26228@lestat.nas.nasa.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 2 Feb 1999, Jason Thorpe wrote: > 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). He may just be using the worst method of IDE access, last i checked freebsd doesn't automatically turn on DMA and multiblock options like NetBSD does. I think if he adjusts his IDE flags it will fix things. flags 0xe0ffe0ff That is very interesting how you have recreated interupt levels. I love my netbsd box. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message