From owner-freebsd-hackers  Tue Feb  2 11:32:40 1999
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id LAA21478
          for freebsd-hackers-outgoing; Tue, 2 Feb 1999 11:32:40 -0800 (PST)
          (envelope-from owner-freebsd-hackers@FreeBSD.ORG)
Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA21473
          for <freebsd-hackers@FreeBSD.ORG>; Tue, 2 Feb 1999 11:32:39 -0800 (PST)
          (envelope-from thorpej@lestat.nas.nasa.gov)
Received: from lestat (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.8/8.6.12) with ESMTP id LAA26228; Tue, 2 Feb 1999 11:32:25 -0800 (PST)
Message-Id: <199902021932.LAA26228@lestat.nas.nasa.gov>
To: Emmanuel Duros <Emmanuel.Duros@sophia.inria.fr>
Cc: freebsd-hackers@FreeBSD.ORG
Subject: Re: writing network device driver - pb with interrupt levels 
Reply-To: Jason Thorpe <thorpej@nas.nasa.gov>
From: Jason Thorpe <thorpej@nas.nasa.gov>
Date: Tue, 02 Feb 1999 11:32:24 -0800
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

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).

        -- Jason R. Thorpe <thorpej@nas.nasa.gov>


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message