Date: Thu, 14 Feb 2008 09:04:17 +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: <20080214000417.GA15446@cdnetworks.co.kr> In-Reply-To: <200802132236.m1DMa1P0079893@cwsys.cwsent.com> References: <20080213003554.GA11251@cdnetworks.co.kr> <200802132236.m1DMa1P0079893@cwsys.cwsent.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Feb 13, 2008 at 02:36:01PM -0800, Cy Schubert wrote: > In message <20080213003554.GA11251@cdnetworks.co.kr>, Pyun YongHyeon writes: > > > > --PNTmBPCT7hxwcZjr > > Content-Type: text/plain; charset=us-ascii > > Content-Disposition: inline > > > > On Mon, Feb 11, 2008 at 07:45:31PM -0800, Cy Schubert wrote: > > > In message <20080212014312.GA6953@cdnetworks.co.kr>, Pyun YongHyeon writes > > : > > > > 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/s > > ys/mo > > > > du > > > > > 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 > > +0x2f > > > > 9 > > > > > 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. > > > > > > Thanks. Reducing the MTU from 9000 to default (1500) circumvents the panic > > . > > > > > > > Would you try attached patch? > > Great! The patch fixes jumbo frames. Thanks. > Ok, I'll commit it. Thanks for testing! -- Regards, Pyun YongHyeon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080214000417.GA15446>