Re: repeating crashes with 8.1

On Sat, 23 Oct 2010, Mike Tancsa wrote:

Hi all,

> At 12:41 AM 10/23/2010, Jack Vogel wrote:
>> Odd, can you make any connection between this and the em complaints??
>
> I dont think so.

neither do I think so.  The initial issue

> This is on an igb nic and a different panic/behaviour. I 
> have the box sitting at the debugger prompt in the FreeBSD netperf cluster, 
> so hopefully someone can take a look and see what is the issue.

Ok, and I seem to have another email telling me the machine;-)


>> >>>>> Oct 22 02:06:02 i4 kernel: em1: discard frame w/o packet header
>> >>>>> Oct 22 02:06:10 i4 kernel: em2: discard frame w/o packet header

is if_em(4) receiving a packet and then passing it up in em_rxeof()
by calling ifp->if_input ending up in
sys/net/if_ethersubr.c:ether_input() and there's an early check on
1) that the interface is up, and 2)
  580         /*
  581          * Do consistency checks to verify assumptions
  582          * made by code past this point.
  583          */
  584         if ((m->m_flags & M_PKTHDR) == 0) {
  585                 if_printf(ifp, "discard frame w/o packet header\n");
  586                 ifp->if_ierrors++;
  587                 m_freem(m);
  588                 return;
  589         }

So whatever mbuf if_em(4) is passing up here isn't setup correctly and
it sounds like the mbuf chaining logic or receive ring handling could
have a problem, though I doubt that em_refresh_mbufs() would be at
fault ... but I'll leave that to Jack.



For the following one, I hope to know the problem for it and am
working on fixing this already.  This is most likely more new-arp
fallout and the last we currrently know of (despite some nd6 locking
problems which will need to be addressed separately and are under
discussion)

>> Fatal trap 9: general protection fault while in kernel mode
>> cpuid = 0; apic id = 00
>> instruction pointer     = 0x20:0xffffffff80740a50
>> stack pointer           = 0x28:0xffffff800005a890
>> frame pointer           = 0x28:0xffffff800005a930
>> 
>> code segment            = base 0x0, limit 0xfffff, type 0x1b
>>                        = DPL 0, pres 1, long 1, def32 0, gran 1
>> processor eflags        = interrupt enabled, resume, IOPL = 0
>> current process         = 12 (swi4: clock)
>> [thread pid 12 tid 100007 ]
>> Stopped at      in6_cksum+0x410:        movzwl  (%rsi),%r10d
>> db> bt
>> Tracing pid 12 tid 100007 td 0xffffff00025083e0
>> in6_cksum() at in6_cksum+0x410
>> icmp6_reflect() at icmp6_reflect+0x312
>> icmp6_error() at icmp6_error+0x1ec
>> nd6_llinfo_timer() at nd6_llinfo_timer+0x208
>> softclock() at softclock+0x2a6
>> intr_event_execute_handlers() at intr_event_execute_handlers+0x66
>> ithread_loop() at ithread_loop+0xb2
>> fork_exit() at fork_exit+0x12a
>> fork_trampoline() at fork_trampoline+0xe
>> --- trap 0, rip = 0, rsp = 0xffffff800005ad30, rbp = 0 ---
>> db>

Mike, as you found that in a lab setup and I was never able to
reproduce any of the reports before, I'll send you a patch over
the weekend and we'll see if you can still reproduce it after
patching.

/bz

-- 
Bjoern A. Zeeb                              Welcome a new stage of life.
         <ks> Going to jail sucks -- <bz> All my daemons like it!
   http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html
_______________________________________________
[e-mail] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[e-mail]"