Re: sk Panic in 8.0-CURRENT

On Wed, Feb 13, 2008 at 02:36:01PM -0800, Cy Schubert wrote:
 > In message <20080213003554.GA11251_at_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_at_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) _at_ /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