From owner-freebsd-hackers Fri May 28 11:17:19 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from etinc.com (et-gw.etinc.com [207.252.1.2]) by hub.freebsd.org (Postfix) with ESMTP id B2FDA14DC5 for ; Fri, 28 May 1999 11:17:15 -0700 (PDT) (envelope-from dennis@etinc.com) Received: from dbsys (dbsys.etinc.com [207.252.1.18]) by etinc.com (8.9.3/8.9.3) with SMTP id OAA08532 for ; Fri, 28 May 1999 14:17:11 -0400 (EDT) Message-Id: <199905281817.OAA08532@etinc.com> X-Sender: dennis@etinc.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 28 May 1999 13:13:36 -0400 To: hackers@freebsd.org From: Dennis Subject: Re: mbuf stuff Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 10:40 AM 5/28/99 -0700, you wrote: >network devices need splimp() to block them > >the mbuf calls are splimp() protected. OOOOK, so that goes back to my original question....shouldnt the routines that would cause drivers to allocate mbufs to fail call splimp instead of splnet()? Dennis > >julian > > >On Fri, 28 May 1999, Dennis wrote: > >> > >#10 0xf01cbe1a in l2_int () >> > >#11 0xf01dd8cd in ethintr_pci () >> > >#12 0xf01388f6 in rtalloc1 (dst=0xf01e8f18, report=1, ignflags=65536) >> > > at ../../net/route.c:132 >> > >#13 0xf01388ac in rtalloc_ign (ro=0xf01e8f14, ignore=65536) >> > > at ../../net/route.c:108 >> >> Am I wrong in assuming that this was in rtalloc1 when the interrupt >> occured? How can a network device interrupt a routine protected by splnet()? >> >> >> >In your specific case, rtalloc() calls rtalloc1(), which raises the >> >processor priority to splnet (I'm looking at a 3.1 source base). You >> >can interrupt rtalloc() without harm. I do wonder why you're always >> >in that routine when this occurs, but I can't provide any >> >illumination there. How frequently does this occur? >> >> it just started happening, which is wierd because the box has a month of >> uptime before upgrading the driver. Something may have gotten mucked up, >> but I'm trying to trace the actual cause to figure out what it might be. >> Its a T3 line, so its passing millions of packets in-between failures. >> >> I can toss te packets easy enough, but I've never seen this failure on a T1 >> line with months of uptime...so its baffling. >> >> thanks, >> >> Dennis >> >> >> >> To Unsubscribe: send mail to majordomo@FreeBSD.org >> with "unsubscribe freebsd-hackers" in the body of the message >> > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message