> >#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 majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
