Page fault in ipfw?

From: Sergey Zaharchenko <doublef-ctm_at_yandex.ru>
Date: Tue, 9 Jan 2007 14:52:27 +0300
Hello -current,

After updating from December to yesterday's CURRENT (to try catching the
SMB recursive locking) I observe the following fault when I connect to
the internet via PPP:

Unread portion of the kernel message buffer: [lines unwrapped]
-----------------------------------------------------------------------
Kernel page fault with the following non-sleepable locks held:
shared rw IPFW static rules r = 0 (0xc36dfc2c) locked _at_ /src/usr.src/sys/modules/ipfw/../../netinet/ip_fw2.c:2641
shared rw PFil hook read/write mutex r = 0 (0xc0a9fd38) locked _at_ /src/usr.src/sys/net/pfil.c:73
KDB: stack backtrace:
db_trace_self_wrapper(c0950f01) at db_trace_self_wrapper+0x25
kdb_backtrace(2,c3af3900,c,d6356724,d6356718,...) at kdb_backtrace+0x29
witness_warn(5,0,c097623a) at witness_warn+0x192
trap(d6356724) at trap+0x10f
calltrap() at calltrap+0x6
--- trap 0x1, eip = 0, esp = 0xd6356760, ebp = 0xd6356a10 ---
MAXCPU(0,0,0,53efbd93,c24317e5,...) at 0
MAXCPU(c3485138,29,2,dead0001,c3396400,...) at 0


Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x0
fault code              = supervisor read, page not present
instruction pointer     = 0x20:0xc36d7fe0
stack pointer           = 0x28:0xd6356764
frame pointer           = 0x28:0xd6356a04
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         = 1261 (ppp)
panic: from debugger
cpuid = 0
Uptime: 4m2s
Physical memory: 495 MB
Dumping 51 MB: 36 20 4
-----------------------------------------------------------------------

Yes, ipfw and ppp are in sync with the kernel.

# addr2line -e kernel.debug.2,3 0xc36d7fe0  ----\
??:0						|
						|
# kldstat					|
Id Refs Address    Size     Name		|
 1   27 0xc0400000 7c6d34   kernel		|
 3    1 0xc0bcb000 52b0     vesa.ko		|
 4    1 0xc0c91000 61f0     geom_label.ko	|
 5    1 0xc0c98000 5708     snd_ich.ko		|
 6    2 0xc0c9e000 3cf48    sound.ko		|
 7    1 0xc0cdb000 4cec     atapicam.ko		|
 8    1 0xc0ce0000 4a4c54   nvidia.ko		|
 9    1 0xc1185000 4694     uplcom.ko		|
10    2 0xc118a000 4384     ucom.ko		|
11    1 0xc118f000 5ac80    acpi.ko		|
12    1 0xc3617000 2000     msdosfs_iconv.ko	|
13    3 0xc3619000 3000     libiconv.ko		|
14    1 0xc36d3000 d000     ipfw.ko	     <--/
15    1 0xc389f000 b000     fuse.ko
16    1 0xc38f3000 4000     logo_saver.ko
17    1 0xc3efc000 1c000    smbfs.ko
18    2 0xc3716000 3000     libmchain.ko

Looks like I need to compile ipfw into the kernel to get a normal
address?

The backtrace doesn't seem helpful (I just panicked the debugger):

----------------------------------------------------------------------
#0  doadump () at pcpu.h:166
#1  0xc06c2f50 in boot (howto=260)
    at /src/usr.src/sys/kern/kern_shutdown.c:411
#2  0xc06c325a in panic (fmt=0xc0906a2f "from debugger")
    at /src/usr.src/sys/kern/kern_shutdown.c:567
#3  0xc0476a46 in db_panic (addr=-1016234016, have_addr=0, count=-1,
    modif=0xd635655c "") at /src/usr.src/sys/ddb/db_command.c:433
#4  0xc04769df in db_command (last_cmdp=0xc0a25424, cmd_table=0x0)
    at /src/usr.src/sys/ddb/db_command.c:401
#5  0xc0476a9a in db_command_loop () at /src/usr.src/sys/ddb/db_command.c:453
#6  0xc04786e5 in db_trap (type=12, code=0)
    at /src/usr.src/sys/ddb/db_main.c:222
#7  0xc06e1fd4 in kdb_trap (type=12, code=0, tf=0xd6356724)
    at /src/usr.src/sys/kern/subr_kdb.c:502
#8  0xc08be9ad in trap_fatal (frame=0xd6356724, eva=0)
    at /src/usr.src/sys/i386/i386/trap.c:859
#9  0xc08be033 in trap (frame=0xd6356724)
    at /src/usr.src/sys/i386/i386/trap.c:276
#10 0xc08a874b in calltrap () at /src/usr.src/sys/i386/i386/exception.s:139
#11 0x00000000 in ?? ()
Previous frame inner to this frame (corrupt stack?)
----------------------------------------------------------------------

The firewall works OK with the local network, everything gets sent and
filtered. PPP seems to matter. The only rule which matches (only) the
ppp interface is:

`ipfw add allow ip from any to any out xmit tun2 keep-state'

The system doesn't crash after adding a `1 allow ip from any to any'
ipfw rule, but that's not a real solution:)

Any ideas?

-- 
DoubleF
No virus detected in this message. Ehrm, wait a minute...
/kernel: pid 56921 (antivirus), uid 32000: exited on signal 9
Oh yes, no virus:)

Received on Tue Jan 09 2007 - 11:05:40 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:04 UTC