From owner-freebsd-hackers Tue Feb 2 16:37:14 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA08539 for freebsd-hackers-outgoing; Tue, 2 Feb 1999 16:37:14 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from etinc.com (et-gw.etinc.com [207.252.1.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA08532 for ; Tue, 2 Feb 1999 16:37:11 -0800 (PST) (envelope-from dennis@etinc.com) Received: from dbsys (dbsys.etinc.com [207.252.1.18]) by etinc.com (8.8.8/8.6.9) with SMTP id TAA14862; Tue, 2 Feb 1999 19:38:21 GMT Message-Id: <199902021938.TAA14862@etinc.com> X-Sender: dennis@etinc.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Tue, 02 Feb 1999 19:43:49 -0500 To: Mike Smith , Jason Thorpe From: Dennis Subject: Re: writing network device driver - pb with interrupt levels Cc: Emmanuel Duros , freebsd-hackers@FreeBSD.ORG In-Reply-To: <199902022153.NAA01166@dingo.cdrom.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 01:53 PM 2/2/99 -0800, Mike Smith 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). > >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