Hi,

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/