Date: Fri, 21 Aug 2009 17:27:11 +0200 From: Max Laier <max@love2party.net> To: freebsd-current@freebsd.org Cc: Ian Freislich <ianf@clue.co.za> Subject: Re: panic: in pf_reassemble() ? Message-ID: <200908211727.11400.max@love2party.net> In-Reply-To: <E1MeVcA-000Dg2-0b@clue.co.za> References: <E1MeVcA-000Dg2-0b@clue.co.za>
next in thread | previous in thread | raw e-mail | index | archive | help
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 =3D 10; apic id =3D 0a > instruction pointer =3D 0x20:0xffffffff801bc111 > stack pointer =3D 0x28:0xffffff81ccae46b0 > frame pointer =3D 0x28:0xffffff81ccae4710 > code segment =3D base 0x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > current process =3D 11 (irq258: bce2) > trap number =3D 9 > panic: general protection fault > cpuid =3D 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 =3D 0xffffffff801bc111, rsp =3D 0xffffff81ccae46b0, rbp= =3D > 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=20 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 =3D 0, rsp =3D 0xffffff81ccae4d30, rbp =3D 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 detail= s. > This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols > found)... Attempt to extract a component of a value that is not a structu= re > 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. =46rom a very first glance this could be a byte order mismatch in ip_len or= the=20 like, so if you could take a look at the ip header in the involved mbufs. = =20 Anything that looks like swapped bytes. Are you using jumbo frames? Thanks. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200908211727.11400.max>