7.2 Stable Crash - possibly related to if_re

[Pyun YongHyeon]

On Thu, Oct 29, 2009 at 09:56:19PM -0700, Norbert Papke wrote:
> This occurred shortly after "scp"ing from a VirtualBox VM to the host.  The 
> file transfer got stuck.  The "re" interface stopped working.  Shortly 
> afterwards, the host crashed.  The "re" interface was used by the host, the 
> guest was using a different NIC in bridged mode.
> 
> 
> FreeBSD proven.lan 7.2-STABLE FreeBSD 7.2-STABLE #5 r198666: Thu Oct 29 
> 18:36:57 PDT 2009
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address   = 0x18

It looks like a NULL pointer dereference, possibly mbuf related
one.

> fault code              = supervisor write data, page not present
> instruction pointer     = 0x8:0xffffffff80d476ee
> stack pointer           = 0x10:0xffffff8000078ae0
> frame pointer           = 0x10:0xffffff8000078b40
> code segment            = base 0x0, limit 0xfffff, type 0x1b
>                         = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags        = interrupt enabled, resume, IOPL = 0
> current process         = 18 (swi5: +)
> Physical memory: 8177 MB
> 
> 
> (kgdb) bt
> #0  doadump () at pcpu.h:195
> #1  0xffffffff801d5faf in db_fncall (dummy1=Variable "dummy1" is not 
> available.
> ) at /usr/public/freebsd/sources/stable/sys/ddb/db_command.c:516
> #2  0xffffffff801d64b9 in db_command (last_cmdp=0xffffffff80b46ac8, 
> cmd_table=0x0, dopager=1)
>     at /usr/public/freebsd/sources/stable/sys/ddb/db_command.c:413
> #3  0xffffffff801d66bb in db_command_loop () 
> at /usr/public/freebsd/sources/stable/sys/ddb/db_command.c:466
> #4  0xffffffff801d8197 in db_trap (type=Variable "type" is not available.
> ) at /usr/public/freebsd/sources/stable/sys/ddb/db_main.c:228
> #5  0xffffffff8054ab45 in kdb_trap (type=12, code=0, tf=0xffffff8000078a30)
>     at /usr/public/freebsd/sources/stable/sys/kern/subr_kdb.c:524
> #6  0xffffffff807fcdd3 in trap_fatal (frame=0xffffff8000078a30, 
> eva=Variable "eva" is not available.
> )
>     at /usr/public/freebsd/sources/stable/sys/amd64/amd64/trap.c:772
> #7  0xffffffff807fd185 in trap_pfault (frame=0xffffff8000078a30, usermode=0)
>     at /usr/public/freebsd/sources/stable/sys/amd64/amd64/trap.c:693
> #8  0xffffffff807fd9bd in trap (frame=0xffffff8000078a30)
>     at /usr/public/freebsd/sources/stable/sys/amd64/amd64/trap.c:464
> #9  0xffffffff807e710e in calltrap () 
> at /usr/public/freebsd/sources/stable/sys/amd64/amd64/exception.S:218
> #10 0xffffffff80d476ee in re_rxeof () from /boot/kernel/if_re.ko

Hmm, I think there is a missing information here. Not sure where it
dereferenced a NULL pointer in re_rxeof(). Because that this is the
first report for NULL pointer dereference in Rx handler I need more
information how to reproduce it with minimal configuration. Can you
also reproduce the issues without virtual box?
By chance, did you stop the re0 interface with ifconfig when you
noticed the file transfer got stuck?

> #11 0xffffffff80d4a481 in re_int_task (arg=Variable "arg" is not available.
> )
>     
> at /usr/public/freebsd/sources/stable/sys/modules/re/../../dev/re/if_re.c:2191
> #12 0xffffffff80554d46 in taskqueue_run (queue=0xffffff000192f300)
>     at /usr/public/freebsd/sources/stable/sys/kern/subr_taskqueue.c:282
> #13 0xffffffff804fbc1d in ithread_loop (arg=0xffffff00019433a0)
>     at /usr/public/freebsd/sources/stable/sys/kern/kern_intr.c:1126
> #14 0xffffffff804f83c4 in fork_exit (callout=0xffffffff804fbaa5 
> <ithread_loop>, arg=0xffffff00019433a0,
>     frame=0xffffff8000078c80) 
> at /usr/public/freebsd/sources/stable/sys/kern/kern_fork.c:811
> #15 0xffffffff807e74ee in fork_trampoline ()
>     at /usr/public/freebsd/sources/stable/sys/amd64/amd64/exception.S:554
>