panic: in pf_reassemble() ?

[Max Laier]

On Friday 21 August 2009 17:01:14 Ian Freislich wrote:
> So, I thought I'd run a benchmark and see how my forwarding did.
> I got the following panic, easily provokable:
>
> Fatal trap 9: general protection fault while in kernel mode
> cpuid = 10; apic id = 0a
> instruction pointer     = 0x20:0xffffffff801bc111
> stack pointer           = 0x28:0xffffff81ccae46b0
> frame pointer           = 0x28:0xffffff81ccae4710
> 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         = 11 (irq258: bce2)
> trap number             = 9
> panic: general protection fault
> cpuid = 10
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
> panic() at panic+0x182
> trap_fatal() at trap_fatal+0x2ad
> trap() at trap+0x10b
> calltrap() at calltrap+0x8
> --- trap 0x9, rip = 0xffffffff801bc111, rsp = 0xffffff81ccae46b0, rbp =
> 0xffffff 81ccae4710 ---
> pf_reassemble() at pf_reassemble+0xb1
> pf_normalize_ip() at pf_normalize_ip+0x694

Can you get me line numbers for these two?

> pf_test() at pf_test+0x78e
> pf_check_in() at pf_check_in+0x39
> pfil_run_hooks() at pfil_run_hooks+0x9c
> ip_fastforward() at ip_fastforward+0x319

Does switching fast forward off change the situation - not that it should, but 
it might help with finding the culprit.

> ether_demux() at ether_demux+0x131
> ether_input() at ether_input+0x1e0
> ether_demux() at ether_demux+0x6f
> ether_input() at ether_input+0x1e0
> bce_intr() at bce_intr+0x398
> intr_event_execute_handlers() at intr_event_execute_handlers+0x100
> ithread_loop() at ithread_loop+0x8e
> fork_exit() at fork_exit+0x117
> fork_trampoline() at fork_trampoline+0xe
> --- trap 0, rip = 0, rsp = 0xffffff81ccae4d30, rbp = 0 ---
>
> I also got a core, but it's totally useless:
>
> [firewall2.jnb1] ~ # kgdb -c /var/crash/vmcore.10 /boot/kernel/kernel
> 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 "amd64-marcel-freebsd"...(no debugging symbols
> found)... Attempt to extract a component of a value that is not a structure
> pointer. Attempt to extract a component of a value that is not a structure
> pointer. Attempt to extract a component of a value that is not a structure
> pointer. Attempt to extract a component of a value that is not a structure
> pointer. kgdb: kvm_read: invalid address (0xffffff009c31a460)
> #0  0x0000000000000000 in ?? ()
>
> I can setup remote GDB and set this panic off again if there's
> something specific someone would like me to look at.

From a very first glance this could be a byte order mismatch in ip_len or the 
like, so if you could take a look at the ip header in the involved mbufs.  
Anything that looks like swapped bytes.  Are you using jumbo frames?

Thanks.

-- 
/"\  Best regards,                      | mlaier at freebsd.org
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier at EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News