Panics along these lines often occur if there is a concurrency bug in a device driver such that it modifies an mbuf after dispatching to the network stack. E.g., by freeing it, reusing it, an errant dereference, etc. Not guaranteed, but that is where I'd start. Robert On Sat, 17 Nov 2012, Adrian Chadd wrote: > Check what mtod() is doing. > > mbuf.h:#define mtod(m, t) ((t)((m)->m_data)) > > .. so if m->m_data is NULL, bam. > > The question is why is m_data NULL here. Someone mbuf cluey is going > to have to answer that. I don't know whether the MH_dat stuff is being > treated as valid but m_data isn't being updated, or something. > > > Adrian > > On 17 November 2012 10:13, Ian FREISLICH <ianf_at_clue.co.za> wrote: >> Adrian Chadd wrote: >>> It's a NULL ponter deref. This is my line 484 in if_ethersubr.c: >>> >>> eh = mtod(m, struct ether_header *); >>> >>> >>> .. if that's yours, see if eh is NULL? >> >> (kgdb) frame 7 >> #7 0xffffffff8050f534 in ether_nh_input (m=0xfffffe012521e700) >> at /usr/src/sys/net/if_ethersubr.c:484 >> 484 eh = mtod(m, struct ether_header *); >> (kgdb) print eh >> No symbol "eh" in current context. >> (kgdb) print *m >> $2 = {m_hdr = {mh_next = 0x100000000000000, mh_nextpkt = 0x10000000000, >> mh_data = 0x0, mh_len = 60, mh_flags = 4259842, mh_type = 0, >> pad = "\000\000\000\000\000"}, M_dat = {MH = {MH_pkthdr = { >> rcvif = 0xfffffe000a1c2000, header = 0xffffffff, len = 60, flowid = 0, >> csum_flags = 3840, csum_data = 65535, tso_segsz = 0, PH_vt = { >> vt_vtag = 4, vt_nrecs = 4}, tags = {slh_first = 0x3c000000}}, >> MH_dat = {MH_ext = { >> ext_buf = 0x69e5498600000000 <Address 0x69e5498600000000 out of bounds>, ext_free = 0x10602, ext_arg1 = 0xc000000070000, ext_arg2 = 0x100, >> ext_size = 2048, ref_cnt = 0xfffffe0125236d8c, ext_type = 6}, >> MH_databuf = "\000\000\000\000\206Iеi\002\006\001\000\000\000\000\000\000\000\a\000\000\000\f\000\000\001\000\000\000\000\000\000\000\b\000\000\000\000\000\000\214m#%\001юяя\006", '\0' <repeats 118 times>}}, >> M_databuf = "\000 \034\n\000юяяяяяя\000\000\000\000<\000\000\000\000\000\000\000\000\017\000\000яя\000\000\000\000\004\000\000\000\000\000\000\000\000<\000\000\000\000\000\000\000\000\206Iеi\002\006\001\000\000\000\000\000\000\000\a\000\000\000\f\000\000\001\000\000\000\000\000\000\000\b\000\000\000\000\000\000\214m#%\001юяя\006", '\0' <repeats 118 times>}} >> >> >> Ian >> >> -- >> Ian Freislich >> >> _______________________________________________ >> freebsd-current_at_freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org" > _______________________________________________ > freebsd-current_at_freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"Received on Sat Nov 17 2012 - 20:31:19 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:32 UTC