Thread View: pl.comp.os.bsd
4 messages
4 total messages
Started by Sokim
Sun, 15 Feb 2009 22:59
FBSD kernel panic:/
Author: Sokim
Date: Sun, 15 Feb 2009 22:59
Date: Sun, 15 Feb 2009 22:59
107 lines
5665 bytes
5665 bytes
Hej,
od dłuższego czasu walczę z niespodziewanymi rebootami routera z FreeBSD
7.1 na pokładzie. Sprawa jest bardzo dziwna, czasami router wytrzymuje
ponad dwa tygodnie bez reboota, a czasami reboot następuje dwa razy w
ciągu jednego dnia. Przeprowadziłem procedurę debugowania i wydaje się
że problem leży w ip_nat.c. Wyniki debugera przesyłam poniżej.
Zaczynam się już zastanawiać nad przejściem na pf, lecz wolałbym zostać
przy ipf:/. Macie jakieś pomysły?
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 = 1; apic id = 01
fault virtual address = 0x4
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc0494aa7
stack pointer = 0x28:0xe5769974
frame pointer = 0x28:0xe5769a0c
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 = 23 (em0 taskq)
trap number = 12
panic: page fault
cpuid = 1
Uptime: 5h7m13s
Physical memory: 2034 MB
Dumping 282 MB: 267 251 235 219 203 187 171 155 139 123 107 91 75 59 43
27 11
Reading symbols from /boot/kernel/acpi.ko...Reading symbols from
/boot/kernel/acpi.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/acpi.ko
#0 doadump () at pcpu.h:196
196 __asm __volatile("movl %%fs:0,%0" : "=r" (td));
(kgdb)
(kgdb) list *0xc0494aa7
0xc0494aa7 is in nat_new
(/usr/src/sys/contrib/ipfilter/netinet/ip_nat.c:2577).
2572 nat->nat_ifps[1] = np->in_ifps[1];
2573 nat->nat_ptr = np;
2574 nat->nat_p = fin->fin_p;
2575 nat->nat_mssclamp = np->in_mssclamp;
2576 if (nat->nat_p == IPPROTO_TCP)
2577 nat->nat_seqnext[0] = ntohl(tcp->th_seq);
2578
2579 if ((np->in_apr != NULL) && ((ni->nai_flags & NAT_SLAVE)
== 0))
2580 if (appr_new(fin, nat) == -1)
2581 return -1;
(kgdb) backtrace
#0 doadump () at pcpu.h:196
#1 0xc0732f88 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418
#2 0xc0733265 in panic (fmt=Variable "fmt" is not available.
) at /usr/src/sys/kern/kern_shutdown.c:574
#3 0xc09d8674 in trap_fatal (frame=0xe5769934, eva=4) at
/usr/src/sys/i386/i386/trap.c:939
#4 0xc09d88c4 in trap_pfault (frame=0xe5769934, usermode=0, eva=4) at
/usr/src/sys/i386/i386/trap.c:852
#5 0xc09d9236 in trap (frame=0xe5769934) at
/usr/src/sys/i386/i386/trap.c:530
#6 0xc09c0a3b in calltrap () at /usr/src/sys/i386/i386/exception.s:159
#7 0xc0494aa7 in nat_new (fin=0xe5769a84, np=0xc9950e00, natsave=0x0,
flags=Variable "flags" is not available.
) at /usr/src/sys/contrib/ipfilter/netinet/ip_nat.c:2577
#8 0xc0498f83 in fr_checknatin (fin=0xe5769a84, passp=0xe5769a80) at
/usr/src/sys/contrib/ipfilter/netinet/ip_nat.c:4122
#9 0xc048b546 in fr_check (ip=0xc8da8810, hlen=20, ifp=0xc523d800,
out=0, mp=0xe5769b6c) at /usr/src/sys/contrib/ipfilter/netinet/fil.c:2572
#10 0xc048df16 in fr_check_wrapper (arg=0x0, mp=0xe5769b6c,
ifp=0xc523d800, dir=1) at
/usr/src/sys/contrib/ipfilter/netinet/ip_fil_freebsd.c:178
#11 0xc07d311a in pfil_run_hooks (ph=0xc0b6dfa0, mp=0xe5769bc4,
ifp=0xc523d800, dir=1, inp=0x0) at /usr/src/sys/net/pfil.c:78
#12 0xc07f9684 in ip_input (m=0xc8d67300) at
/usr/src/sys/netinet/ip_input.c:417
#13 0xc07d1994 in netisr_dispatch (num=2, m=0xc8d67300) at
/usr/src/sys/net/netisr.c:185
#14 0xc07c9540 in ether_demux (ifp=0xc523d800, m=0xc8d67300) at
/usr/src/sys/net/if_ethersubr.c:834
#15 0xc07c991a in ether_input (ifp=0xc523d800, m=0xc8d67300) at
/usr/src/sys/net/if_ethersubr.c:692
#16 0xc0571d43 in em_rxeof (adapter=0xc524a000, count=99) at
/usr/src/sys/dev/e1000/if_em.c:4539
#17 0xc0572834 in em_handle_rxtx (context=0xc524a000, pending=1) at
/usr/src/sys/dev/e1000/if_em.c:1702
#18 0xc07647d8 in taskqueue_run (queue=0xc523b780) at
/usr/src/sys/kern/subr_taskqueue.c:282
#19 0xc07649cb in taskqueue_thread_loop (arg=0xc524e35c) at
/usr/src/sys/kern/subr_taskqueue.c:401
#20 0xc070ed31 in fork_exit (callout=0xc0764916 <taskqueue_thread_loop>,
arg=0xc524e35c, frame=0xe5769d38) at /usr/src/sys/kern/kern_fork.c:804
#21 0xc09c0ab0 in fork_trampoline () at
/usr/src/sys/i386/i386/exception.s:264
(kgdb) quit
Re: FBSD kernel panic:/
Author: Maciej Wierzbicki
Date: Tue, 17 Feb 2009 10:03
Date: Tue, 17 Feb 2009 10:03
13 lines
1271 bytes
1271 bytes
Sokim wrote on 2009-02-15 23:59: > Przeprowadziłem procedurę debugowania i wydaje się > że problem leży w ip_nat.c. Wyniki debugera przesyłam poniżej. > Zaczynam się już zastanawiać nad przejściem na pf, lecz wolałbym zostać > przy ipf:/. Macie jakieś pomysły? Z ciekawości (bez chęci wywołania flame), jakie jest uzasadnienie do korzystania z IPF zamiast z PF? -- * Maciej Wierzbicki * At paranoia's poison door * * VOO1-RIPE *
Re: FBSD kernel panic:/
Author: Sokim
Date: Tue, 17 Feb 2009 10:33
Date: Tue, 17 Feb 2009 10:33
23 lines
2093 bytes
2093 bytes
Maciej Wierzbicki pisze: > Sokim wrote on 2009-02-15 23:59: > >> Przeprowadziłem procedurę debugowania i wydaje się że problem leży w >> ip_nat.c. Wyniki debugera przesyłam poniżej. >> Zaczynam się już zastanawiać nad przejściem na pf, lecz wolałbym >> zostać przy ipf:/. Macie jakieś pomysły? > > Z ciekawości (bez chęci wywołania flame), jakie jest uzasadnienie do > korzystania z IPF zamiast z PF? > No cóż mam kilka powodów - ipf + ipnat można ładnie powiązać z ipfw+dummynet, na którym aktualnie mam zrobione całe kolejkowanie. Przejście na pf będzie oznaczało również przejście an altq i pisanie wszystkich regułek od nowa. W praniu okaże się, że aby pf dobrze działało muszę pogrzebać w sysctrl, albo pozmieniać coś w źródłach, a ipf już mam opanowany ;) Kiedyś próbowałem przejść na pf ale za każdym razem odbijałem się od ftp-proxy niby działało ale aktywne sesje ftp nie chciały się łączyć:/ Myślę, że jak bym miał przejść na pf to już przeszedł bym na OpenBSD. Poza tym altq też ma błędy: http://www.freebsd.org/cgi/query-pr.cgi?pr=131753
Re: FBSD kernel panic:/
Author: Maciej Wierzbicki
Date: Tue, 17 Feb 2009 10:54
Date: Tue, 17 Feb 2009 10:54
32 lines
2334 bytes
2334 bytes
Sokim wrote on 2009-02-17 11:33: > No cóż mam kilka powodów - ipf + ipnat można ładnie powiązać z > ipfw+dummynet, na którym aktualnie mam zrobione całe kolejkowanie. > Przejście na pf będzie oznaczało również przejście an altq i pisanie > wszystkich regułek od nowa. W praniu okaże się, że aby pf dobrze > działało muszę pogrzebać w sysctrl, albo pozmieniać coś w źródłach, a > ipf już mam opanowany ;) E, raczej nic nie trzeba grzebać w sysctlach (no chyba że chodzi Ci ogólnie o limity systemowe, a nie kwestie związane bezpośrednio z PF). > Kiedyś próbowałem przejść na pf ale za każdym razem odbijałem się od > ftp-proxy niby działało ale aktywne sesje ftp nie chciały się łączyć:/ Mi działa. :-) > Poza tym altq też ma błędy: > http://www.freebsd.org/cgi/query-pr.cgi?pr=131753 Oj, ALTQ ma kupę innych błędów niestety. Błędne raportowanie kolejek przez pfctl (w stosunku do faktycznego ruchu), przepuszczanie znacząco większej ilości ruchu niż zadana przy CBQ i tak dalej. Na szczęście trwają jakieś tam prace nad integracją dummynet z PF, czekam z niecierpliwością na efekty, bo też mam dość ALTQ. Na razie jest to patchologia, ale idzie w dobrą stronę. http://www.mavetju.org/mail/view_thread.php?list=freebsd-pf&id=2835644&thread=yes -- * Maciej Wierzbicki * At paranoia's poison door * * VOO1-RIPE *
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads