On Monday 07 February 2005 16:52, Emanuel Strobl wrote: > Resuming work on this, I managed to get a remote console to the box and > here's what I get with today's RELENG_5 and the following command, also I > need to set debug.mpsafenet to 0 otherwise my ruleset doesn't work (do what > it should do and does when set to 0 but not when default 1): > pfctl -F all -f /etc/pf.conf > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0xdeadc1d7 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc047ac48 > stack pointer = 0x10:0xd0a44728 > frame pointer = 0x10:0xd0a44730 > 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 = 1053 (sshd) > [thread pid 1053 tid 100081 ] > Stopped at pf_state_compare_lan_ext+0x18: movzbl 0xf9(%esi),%eax > db> trace > Tracing pid 1053 tid 100081 td 0xc177e190 > pf_state_compare_lan_ext(c176ca00,d0a447d8,d0a44758,c047c095,c176cac0) at > pf_state_compare_lan_ext+0x18 > pf_state_tree_lan_ext_RB_FIND(c176cac0,d0a447d8,0,c176ca00,d0a448e4) at > pf_state_tree_lan_ext_RB_FIND+0x29 > pf_find_state_recurse(c176ca00,d0a447d8,0,da7a0000,c0586400) at > pf_find_state_recurse+0x45 > pf_test_state_tcp(d0a4492c,2,c176ca00,c1746b00,14) at > pf_test_state_tcp+0xb0 pf_test(2,c1586000,d0a44a1c,c19ff168,c1756720) at > pf_test+0x981 > pf_check_out(0,d0a44a1c,c1586000,2,c19ff168) at pf_check_out+0x4e > pfil_run_hooks(c07f05a0,d0a44aa8,c1586000,2,c19ff168) at > pfil_run_hooks+0x15b ip_output(c1746b00,0,d0a44a74,0,0) at ip_output+0x3ef > tcp_output(c1a02710,c1744900,c076ed93,280,0) at tcp_output+0x984 > tcp_usr_send(c1b5fdec,0,c1744900,0,0) at tcp_usr_send+0x239 > sosend(c1b5fdec,0,d0a44c84,c1744900,0) at sosend+0x62b > soo_write(c1c5c264,d0a44c84,c1b0f680,0,c177e190) at soo_write+0x49 > dofilewrite(5,8081000,a0,ffffffff,ffffffff) at dofilewrite+0xac > write(c177e190,d0a44d14,c,431,3) at write+0x77 > syscall(2f,2f,2f,8071d88,a0) at syscall+0x137 > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (4, FreeBSD ELF32, write), eip = 0x282ef73f, esp = 0xbfbfddfc, > ebp =0xbfbfde18 --- > > Tell me how I can help, I'll later hand in the trace of the slef-lock when > debug.mpsafenet is 1.
Do you have pfsync compiled in? Is it up? If that's the case, can you try to reproduce with a kernel without "device pfsync", please? Can you also please try the attached diff and see if it turns up anything - though I certainly doubt that. Really except to see pfsync being the culprit here. Tell me if removeing it helps. Thanks. I'm a bit busy these days so I can't do extensive testing myself. It'd be a great help if you could verify that I am looking at the right thing. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News
Index: pf.c
===================================================================
RCS file: /usr/store/mlaier/fcvs/src/sys/contrib/pf/net/pf.c,v
retrieving revision 1.26
diff -u -r1.26 pf.c
--- pf.c 20 Jan 2005 18:07:35 -0000 1.26
+++ pf.c 8 Feb 2005 13:10:32 -0000
@@ -862,6 +862,7 @@
{
struct pf_src_node *cur, *next;
+ PF_ASSERT(MA_OWNED);
for (cur = RB_MIN(pf_src_tree, &tree_src_tracking); cur; cur = next) {
next = RB_NEXT(pf_src_tree, &tree_src_tracking, cur);
@@ -889,6 +890,7 @@
{
u_int32_t timeout;
+ PF_ASSERT(MA_OWNED);
if (s->src_node != NULL) {
if (--s->src_node->states <= 0) {
timeout = s->rule.ptr->timeout[PFTM_SRC_NODE];
@@ -923,6 +925,7 @@
{
struct pf_state *cur, *next;
+ PF_ASSERT(MA_OWNED);
for (cur = RB_MIN(pf_state_tree_id, &tree_id);
cur; cur = next) {
next = RB_NEXT(pf_state_tree_id, &tree_id, cur);
pgpvd39NW0YEk.pgp
Description: PGP signature
