Date: Tue, 12 Feb 2008 10:43:12 +0900 From: Pyun YongHyeon <pyunyh@gmail.com> To: Cy Schubert <Cy.Schubert@spqr.komquats.com> Cc: freebsd-current@FreeBSD.org Subject: Re: sk Panic in 8.0-CURRENT Message-ID: <20080212014312.GA6953@cdnetworks.co.kr> In-Reply-To: <200802120010.m1C0AeTZ038250@cwsys.cwsent.com> References: <200802120010.m1C0AeTZ038250@cwsys.cwsent.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Feb 11, 2008 at 04:10:40PM -0800, Cy Schubert wrote: > Has anyone seen the following mutex panic in sk_jfree? The last time this > system booted was Jan 31. > [...] > panic: mtx_lock() of spin mutex (null) @ /dsk03/src/cvs-current/src/sys/modu > les/sk/../../dev/sk/if_sk.c:2439 > cpuid = 0 > KDB: enter: panic > [thread pid 12 tid 100038 ] > Stopped at kdb_enter+0x34: movl $0,kdb_why > db> bt > Tracing pid 12 tid 100038 td 0xc3363cc0 > kdb_enter(c0a36183,c0a36183) at kdb_enter+0x34 > panic(c0a34f9b,0,c0cefb36,987,e2583cc0,...) at panic+0x111 > _mtx_lock_flags(e2586bbc,0,c0cefb36,987,c35d1000,...) at > _mtx_lock_flags+0x70 > sk_jfree(c341f000,e2583cc0) at sk_jfree+0x3a > mb_free_ext(c35d1000) at mb_free_ext+0x18f > m_freem(c35d1000) at m_freem+0x1f > arpintr(c35d1000) at arpintr+0xc0b > netisr_dispatch(12,c35d1000) at netisr_dispatch+0x5d > ether_demux(c33d5400,c35d1000) at ether_demux+0x1c9 > ether_input(c33d5400,c35d1000,c33f36e0,0,c0cefb36,...) at ether_input+0x2f9 > sk_jumbo_rxeof(c33f36e0,c341f000,c33d5400,0,c342d340,...) at > sk_jumbo_rxeof+0x215 > sk_intr(c33f3680) at sk_intr+0xac > ithread_loop(c342ab40,e2589d38) at ithread_loop+0x175 > fork_exit(c06eded0,c342ab40,e2589d38) at fork_exit+0xb0 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip = 0, esp = 0xe2589d70, ebp = 0 --- > db> > I'm not sure whether this panic is related with recent phk's change to MEXTADD(). If this is the case, you may have to use standard MTU instead of 9000. Since FreeBSD now have physically contiguous jumbos I have plan to take advantage of it instead of use of local allocator. That would also eliminate a jlist lock required to serialize accessing jumbo buffers allocated from driver. Give me a couple of days. -- Regards, Pyun YongHyeon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080212014312.GA6953>