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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[email protected]"
