2.2.8 vanilla, booted on a rather slow machine (p5/133 UP) using initrd,
causes the kernel to lock up hard after the ramdisk is detected. The
manual translation of the OOPS on the screen gives:
c0110bc8 wake_up_process + 8
c0126655 refile_buffer + 150 (call wakeup_bdflush)
c012902b block_write + 1095 (call refile_buffer)
c01728d3 inflate_codes + 1051 (call flush_window)
c0173155 inflate_dynamic + 1405 (call inflate_codes)
c0171e81 initrd_read + 77 (call __generic_copy_to_user)
c017325f inflate_block + 207 (call inflate_dynamic)
c01732de inflate + 70 (call inflate_block)
0xc0110bc8 <wake_up_process+8>: movl $0x0,(%edx)
0xc0110bce <wake_up_process+14>: cmpl $0x0,0x3c(%edx)
0xc0110bd2 <wake_up_process+18>: jne 0xc0110c00 <wake_up_process+64>
eax: 00000000 ebx: 00000002 ecx: 00000286 edx: 00000000
esi: c0fc96e0 edi: c0fc96e0 ebp: c0003360 esp: c0003368
It seems that the kernel is trying to wake up bdflush and bdflush is not
quite ready... bdflush_tsk == NULL and that NULL propagates all the way to
%edx in wake_up_process. main.c does try to start bdflush before playing
with initrd, so it looks like a race condition to me. BTW, the same kernel
with the same initrd boots fine on a much faster machine (K6/350 UP).
This is not good for a production kernel. Was it really necessary to add
those bdflush changes?...
Thanks,
Ion
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/