network devices need splimp() to block them the mbuf calls are splimp() protected.
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 [email protected] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [email protected] with "unsubscribe freebsd-hackers" in the body of the message
