Panic in RELENG_7_1 with fxp(4)

Sun Jan 4 06:12:43 UTC 2009

On Jan 3, 2009, at 5:17 PM, Brandon Weisz wrote:

> After running 7-PRERELEASE from around November 25th, I upgraded  
> today to find the system panics repeatably on RELENG_7_1 sources.  I  
> can boot back to the old kernel and it operates as expected.  It  
> seems to be related to fxp(4).
>
> FreeBSD didy.internal 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Sat Jan  3
> 18:11:18 CST 2009     bweisz at didy.internal:/usr/obj/usr/src/sys/ 
> DIDY  i386
>
> (19:00:35 bweisz at didy </usr/obj/usr/src/sys/DIDY>) 507 $ sudo kgdb  
> kernel.debug /var/crash/vmcore.2
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and  
> you are
> welcome to change it and/or distribute copies of it under certain  
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for  
> details.
> This GDB was configured as "i386-marcel-freebsd"...
>
> Unread portion of the kernel message buffer:
>
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address	= 0x40c
> fault code		= supervisor read, page not present
> instruction pointer	= 0x20:0xc0a94510
> stack pointer	        = 0x28:0xe677b878
> frame pointer	        = 0x28:0xe677b88c
> 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		= 843 (ntpd)
> trap number		= 12
> panic: page fault
> cpuid = 0
> Uptime: 25s
> Physical memory: 995 MB
> Dumping 94 MB: 79 63 47 31 15
>
> Reading symbols from /boot/kernel/vesa.ko...Reading symbols from / 
> boot/kernel/vesa.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/vesa.ko
> Reading symbols from /boot/kernel/accf_http.ko...Reading symbols  
> from /boot/kernel/accf_http.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/accf_http.ko
> Reading symbols from /boot/kernel/acpi.ko...Reading symbols from / 
> boot/kernel/acpi.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/acpi.ko
> Reading symbols from /boot/kernel/pflog.ko...Reading symbols from / 
> boot/kernel/pflog.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/pflog.ko
> Reading symbols from /boot/kernel/pf.ko...Reading symbols from /boot/ 
> kernel/pf.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/pf.ko
> Reading symbols from /boot/kernel/nullfs.ko...Reading symbols from / 
> boot/kernel/nullfs.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/nullfs.ko
> Reading symbols from /boot/kernel/logo_saver.ko...Reading symbols  
> from /boot/kernel/logo_saver.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/logo_saver.ko
> #0  doadump () at pcpu.h:196
> 196		__asm __volatile("movl %%fs:0,%0" : "=r" (td));
> (kgdb) list *0xc0a94510
> 0xc0a94510 is in _bus_dmamap_sync (/usr/src/sys/i386/i386/ 
> busdma_machdep.c:935).
> 930			CTR4(KTR_BUSDMA, "%s: tag %p tag flags 0x%x op 0x%x "
> 931			    "performing bounce", __func__, op, dmat, dmat->flags);
> 932	
> 933			if (op & BUS_DMASYNC_PREWRITE) {
> 934				while (bpage != NULL) {
> 935					bcopy((void *)bpage->datavaddr,
> 936					      (void *)bpage->vaddr,
> 937					      bpage->datacount);
> 938					bpage = STAILQ_NEXT(bpage, links);
> 939				}
> (kgdb) bt
> #0  doadump () at pcpu.h:196
> #1  0xc079c1b7 in boot (howto=260) at /usr/src/sys/kern/ 
> kern_shutdown.c:418
> #2  0xc079c489 in panic (fmt=Variable "fmt" is not available.
> ) at /usr/src/sys/kern/kern_shutdown.c:574
> #3  0xc0ab03bc in trap_fatal (frame=0xe677b838, eva=1036) at /usr/ 
> src/sys/i386/i386/trap.c:939
> #4  0xc0ab0640 in trap_pfault (frame=0xe677b838, usermode=0,  
> eva=1036) at /usr/src/sys/i386/i386/trap.c:852
> #5  0xc0ab0ffc in trap (frame=0xe677b838) at /usr/src/sys/i386/i386/ 
> trap.c:530
> #6  0xc0a96e6b in calltrap () at /usr/src/sys/i386/i386/exception.s: 
> 159
> #7  0xc0a94510 in _bus_dmamap_sync (dmat=0xc4048880, map=0xc416e800,  
> op=4) at /usr/src/sys/i386/i386/busdma_machdep.c:933
> #8  0xc05cc3cd in fxp_start_body (ifp=0xc4163000) at /usr/src/sys/ 
> dev/fxp/if_fxp.c:1396
> #9  0xc05ccc77 in fxp_start (ifp=0xc4163000) at /usr/src/sys/dev/fxp/ 
> if_fxp.c:1183
> #10 0xc0830a89 in if_start (ifp=0xc4163000) at /usr/src/sys/net/if.c: 
> 2768
> #11 0xc08374cb in ether_output_frame (ifp=0xc4163000, m=0xc43a5600)  
> at /usr/src/sys/net/if_ethersubr.c:405
> #12 0xc0837a7c in ether_output (ifp=0xc4163000, m=0xc43a5600,  
> dst=0xc423b710, rt0=0xc4489364) at /usr/src/sys/net/if_ethersubr.c:374
> #13 0xc087e115 in ip_output (m=0xc43a5600, opt=0x0, ro=0xe677bac4,  
> flags=Variable "flags" is not available.
> ) at /usr/src/sys/netinet/ip_output.c:554
> #14 0xc08eb9b9 in udp_send (so=0xc46ef9c0, flags=0, m=0xc43a5600,  
> addr=0xc4462ab0, control=0x0, td=0xc421f230) at /usr/src/sys/netinet/ 
> udp_usrreq.c:1074
> #15 0xc07f2546 in sosend_dgram (so=0xc46ef9c0, addr=0xc4462ab0,  
> uio=0xe677bbe8, top=0xc43a5600, control=0x0, flags=Variable "flags"  
> is not available.
> ) at /usr/src/sys/kern/uipc_socket.c:1059
> #16 0xc07efbef in sosend (so=0xc46ef9c0, addr=0xc4462ab0,  
> uio=0xe677bbe8, top=0x0, control=0x0, flags=0, td=0xc421f230) at / 
> usr/src/sys/kern/uipc_socket.c:1288
> #17 0xc07f6ef6 in kern_sendit (td=0xc421f230, s=23, mp=0xe677bc64,  
> flags=0, control=0x0, segflg=UIO_USERSPACE) at /usr/src/sys/kern/ 
> uipc_syscalls.c:805
> #18 0xc07fa141 in sendit (td=0xc421f230, s=23, mp=0xe677bc64,  
> flags=0) at /usr/src/sys/kern/uipc_syscalls.c:742
> #19 0xc07fa258 in sendto (td=0xc421f230, uap=0xe677bcfc) at /usr/src/ 
> sys/kern/uipc_syscalls.c:857
> #20 0xc0ab0995 in syscall (frame=0xe677bd38) at /usr/src/sys/i386/ 
> i386/trap.c:1090
> #21 0xc0a96ed0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/ 
> exception.s:255
> #22 0x00000033 in ?? ()
> Previous frame inner to this frame (corrupt stack?)
> (kgdb)
>
>
> I replaced the fxp(4) card with an old xl(4) card lying on my desk  
> and the panics stopped.  Is this a failing nic card or some other  
> trigger?
>
> Brandon

Memory serves me correctly an MFC was done not too long before 7.1  
release was setup.

Let's see what Pyun says...

-Garrett