Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 2 Oct 2006 16:55:05 +0900
From:      Pyun YongHyeon <pyunyh@gmail.com>
To:        current@FreeBSD.org
Subject:   Re: em stability issues + panic
Message-ID:  <20061002075505.GB41981@cdnetworks.co.kr>
In-Reply-To: <20061002072634.GB80527@funkthat.com>
References:  <20061002072634.GB80527@funkthat.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Oct 02, 2006 at 12:26:34AM -0700, John-Mark Gurney wrote:
 > Well, I will admit I have a bit older if_em.c, v1.147, but I haven't
 > been doing much w/ my em, probably not even passing close to 100mbit
 > of traffic (in gige mode)...  I recently obtained a crash dump from
 > em_txeof where the tx_buffer is NULL at line 2958:
 > 2958                    if (tx_buffer->m_head) {
 > 
 > If any one want some additional data, I can provide info from the
 > crash dump...   Just as a bit of trivia, I did load a few kld's..
 > bktr.ko, bktrau.ko and iic.ko (plus respective other kld's that got
 > auto loaded)...   It also seems that interactiveness is more likely
 > to hang em than other traffic...  I've been running the box as a nfs
 > server for a while w/o issues, but I log in and run ffmpeg, and it
 > almost immediately hangs requiring an down/up to bring back the
 > interface...
 > 
 > The panic was when I was bringing the interface back up... Though when
 > I it paniced, I had down/up'd the interface a few times w/o success in
 > bringing it back...
 > 
 > Fatal trap 12: page fault while in kernel mode
 > cpuid = 0; apic id = 00
 > fault virtual address   = 0x0
 > fault code              = supervisor read, page not present
 > instruction pointer     = 0x20:0xc047155e
 > stack pointer           = 0x28:0xe1d1cc50
 > frame pointer           = 0x28:0xe1d1cc64
 > code segment            = base 0x0, limit 0xfffff, type 0x1b
 >                         = DPL 0, pres 1, def32 1, gran 1
 > processor eflags        = interrupt enabled, resume, IOPL = 0
 > current process         = 12 (swi4: clock sio)
 > Physical memory: 999 MB
 > Dumping 225 MB: 210 194 178 162 146 130 114 98 82 66 50 34 18 2
 > 
 > #9  0xc066f56a in calltrap () at ../../../i386/i386/exception.s:138
 > #10 0xc047155e in em_txeof (adapter=0xc34df800) at ../../../dev/em/if_em.c:2956
 > #11 0xc046e502 in em_watchdog (ifp=0xc3502400) at ../../../dev/em/if_em.c:963
 > #12 0xc0585b22 in if_slowtimo (arg=0x0) at ../../../net/if.c:1415
 > #13 0xc0529fa9 in softclock (dummy=0x0) at ../../../kern/kern_timeout.c:271
 > #14 0xc050a57a in ithread_execute_handlers (p=0xc33c38d0, ie=0xc341c580)
 >     at ../../../kern/kern_intr.c:662
 > #15 0xc050a673 in ithread_loop (arg=0xc33a2940)
 >     at ../../../kern/kern_intr.c:745
 > #16 0xc050981b in fork_exit (callout=0xc050a624 <ithread_loop>, 
 >     arg=0xc33a2940, frame=0xe1d1cd38) at ../../../kern/kern_fork.c:818
 > #17 0xc066f5cc in fork_trampoline () at ../../../i386/i386/exception.s:199
 > 

I think bringing the interface down while Rx is active may corrupt
internal hardware state because em_rxeof() runs without driver lock.
See http://lists.freebsd.org/pipermail/freebsd-current/2006-September/066203.html
You may need to protect em_rxeof with dirver lock in em_handle_rxtx().
(Remember dropping driver lock before invoking if_input in em_rxeof.)
-- 
Regards,
Pyun YongHyeon



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061002075505.GB41981>