I reported this error earlier, but I now believe the problem may be with the kernel rather than my own inability to set things up.
The kernel will hang during processing of /sbin/init, but before the INIT message appears on the console. Doing a magic sysreq reveals that processing is stuck in /sbin/init. The call stack will show some of the following functions, in no particular order:
common_interrupt
do_invalid_op
do_IRQ
do_notify_resume
do_signal
do_softirq
do_timer
error_code
force_sig_info
get_signal_to_deliver
i8042_timer_func
run_timer_softirq
timer_interrupt
update_wall_time
work_notifysig
Each time I do a sysreq, I get a different call stack. But it seems the functions the call stack contains will be limited to those listed above. The system is not deadlocked, I can still do capslock, and CTRL-ALT-DLT will reboot the system.
o The setup is Mandrake 9.1, with the latest patches.
o The problem is not /sbin/init, because this machine boots just fine with 2.4.21mdk. Furthermore, I downloaded and compiled from source /sbin/init, making sure that gcc maintained i386 compatibility.
o Downgrading the processor compatibility has no effect. The entire kernel was compiled with i386 compatibility. But it doesn't matter whether I use i586, Cyrix III, or i386, the boot still hangs.
o It's unlikely a problem with my .config, because doing a make oldconfig, adding only the minimal additional options to have a functioning system (the CONSOLE parameters, for example), has the same exact problem.
o The problem is not with Mandrake 9.1 recompiling kernels, because I was able to recompile and boot the 2.4.21mdk kernel.
o The problem is not with Mandrake 9.1 recompiling 2.6 kernels, because I was able to recompile and boot the 2.6 kernel on another machine (Intel P4).
o Recent versions of module-init-tools are installed, but it made no difference between 9.9 and 9.11a.
o The issue is the same in 2.6.0-test2 and 2.6.0-test3
I have attached the .config I have been using. Keep in mind that the standard Mandrake distribution config was no different. I think the issue is compatibility with Cyrix III because of the do_invalid_op instructions.
Any help, suggestions, or pointers are appreciated.
-Brandon