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 NewsReceived on Fri Aug 21 2009 - 13:27:13 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:54 UTC