vm_page_fault: unhandled page fault in kernel space at 0x23, ip 0x8002c525 (in "block notifier/writer")

[umccullough]

Came home to my Haiku machine sitting in KDL. Hooked up serial cable and gathered the following:

kdebug> info
kernel build: Feb  1 2009 22:13:22
SVN revision: 29126

cpu count: 2, active times:
  [1] 79810235595
  [2] 80233573755
pages:          76871 (521888 max)
sems:           2316 (131072 max)
ports:          165 (4096 max)
threads:        148 (4096 max)
teams:          20 (2048 max)
kdebug> message
vm_page_fault: unhandled page fault in kernel space at 0x23, ip 0x8002c525

kdebug> bt
stack trace for thread 12 "block notifier/writer"
    kernel stack: 0x8018a000 to 0x8018e000
frame               caller     <image>:function + offset
 0 8018d834 (+  48) 8005bd85   <kernel_x86>:invoke_debugger_command + 0x00f5
 1 8018d864 (+  64) 8005bb75   <kernel_x86> invoke_pipe_segment(debugger_command_pipe*: 0x80122a60, int32: 0, 0x0 "<NULL>") + 0x0079
 2 8018d8a4 (+  64) 8005befc   <kernel_x86>:invoke_debugger_command_pipe + 0x009c
 3 8018d8e4 (+  48) 8005d484   <kernel_x86> ExpressionParser<0x8018d998>::_ParseCommandPipe(0x8018d994) + 0x0234
 4 8018d914 (+  64) 8005c8be   <kernel_x86> ExpressionParser<0x8018d998>::EvaluateCommand(0x80113ca0 "bt", 0x8018d994) + 0x02ba
 5 8018d954 (+ 224) 8005e8ac   <kernel_x86>:evaluate_debug_command + 0x0088
 6 8018da34 (+  64) 80059c82   <kernel_x86> kernel_debugger_loop() + 0x01ae
 7 8018da74 (+  32) 8005ab05   <kernel_x86>:kernel_debugger + 0x004d
 8 8018da94 (+ 192) 8005aaad   <kernel_x86>:panic + 0x0029
 9 8018db54 (+  80) 800babf5   <kernel_x86>:vm_page_fault + 0x0139
10 8018dba4 (+  64) 800cab7d   <kernel_x86>:page_fault_exception + 0x00d9
11 8018dbe4 (+  12) 800ce266   <kernel_x86>:int_bottom + 0x0036
kernel iframe at 0x8018dbf0 (end = 0x8018dc40)
 eax 0x0            ebx 0x813fe6e8      ecx 0x812a39a8   edx 0x1f
 esi 0x812a3988     edi 0x812a3988      ebp 0x8018dc68   esp 0x8018dc24
 eip 0x8002c525  eflags 0x210203
 vector: 0xe, error code: 0x2
12 8018dbf0 (+ 120) 8002c525   <kernel_x86> notify_transaction_listeners(block_cache*: 0x81205e88, cache_transaction*: 0x813fe6c8, int32: 4) + 0x00f9
13 8018dc68 (+  64) 8002eeef   <kernel_x86>:cache_end_transaction + 0x009b
14 8018dca8 (+ 224) 8081a1b5   <bfs> Journal<0x81205f78>::_WriteTransactionToLog(0x812a39a8, 0x8018ddf8, 0x8081a1ee, 0x8082899c, int8: -88, 0x8018de40, 0x246) + 0x090d
15 8018dd88 (+  48) 8081a275   <bfs> Journal<0x81205f78>::_FlushLog(false) + 0x0095
16 8018ddb8 (+  48) 8081989f   <bfs> Journal<0x00000736>::_TransactionIdle(int32: 8, int32: -2128584840, 0x8002c422) + 0x002b
17 8018dde8 (+  96) 8002c121   <kernel_x86> flush_pending_notifications(block_cache*: 0x81205e88) + 0x01a1
18 8018de48 (+  64) 8002c211   <kernel_x86> flush_pending_notifications() + 0x006d
19 8018de88 (+ 336) 8002e509   <kernel_x86> block_notifier_and_writer(NULL) + 0x0055
20 8018dfd8 (+  32) 800514eb   <kernel_x86> _create_kernel_thread_kentry() + 0x001b
21 8018dff8 (+2145853448) 80051488   <kernel_x86> thread_kthread_exit() + 0x0000
kdebug>

Still sitting in KDL for a bit if there's any additional info I can provide.

Configuration is gcc2 Haiku hrev29126 on core 2 duo with 2gb RAM using 500gb SATA disk and "ata" bus_manager.

Had two different distributed computing clients running: dnetc and sb17, with Firefox open and idling as well.

[umccullough]

Couple more things i grabbed, getting ready to reboot the machine:

kdebug> transaction 0x813fe6c8
TRANSACTION 0x813fe6c8
 id:             1846
 num block:      3
 main num block: 1
 sub num block:  3
 has sub:        1
 state:          open
 idle:           88094 secs
 listeners:

[*** READ FAULT at 0x1f, pc: 0x8002e0fc ***]
kdebug> block_cache 0x81205e88
BLOCK CACHE: 0x81205e88
 fd:         0
 max_blocks: 9767520
 block_size: 2048
 next_transaction_id: 1847
 1421 blocks total, 3 dirty, 0 discarded, 218 referenced, 1201 in unused.
kdebug>

[umccullough]

Would this have been likely fixed since hrev29126? I haven't seen it occur since.

[axeld]

Who knows, but I haven't seen this in a long time either. One can always reopen the bug if it's not yet gone.