Date: Fri, 28 May 1999 10:59:59 -0400 From: Dennis <dennis@etinc.com> To: hackers@freebsd.org Subject: Re: mbuf stuff Message-ID: <199905281603.MAA07818@etinc.com>
next in thread | raw e-mail | index | archive | help
> >#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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199905281603.MAA07818>