Forward one step, back two.

I managed to get 2.6.22.19 booting - it seems the IDE and SATA drivers argue about who gets to go first (when you have one of each type of drive), and telling the IDE driver to leave the SATA drive the hell alone with "ide0=noprobe" fixes it.

So having got my 2.6.22.19 kernel as stripped down as I could (the idea being that will maximise ease of taking the configuration forward to newer kernels) - just 477 "yes" options and no modules, down from over 2k - I'm now trying to move forward to 2.6.25.20, thinking 3 minor revisions should be an achievable next step on the march to "latest" 2.6.32.x.

After having some fun with a gcc bug that caused it to emit assembler referencing a label it hadn't defined (gcc-4.4.1, fixed in gcc-4.4.2, trying to compile drivers/ide/ide-lib.c - gcc flag -fpreprocessed turns out to be useful when trying to cut down a testcase), I now have it compiling but once again refusing to boot.

So I decided to try out the nifty CONFIG_BOOT_PRINTK_DELAY option, to ask the kernel to pause after each console message during boot. When compiled in, you can add a boot_delay=n option to your boot command to delay n milliseconds for each message, with the caveat that you also need to specify the loops per jiffy (lpj) so that it knows how long a millisecond actually is when it hasn't calculated that itself yet. So find a suitable value:

zen% dmesg | grep lpj
Calibrating delay using timer specific routine.. 5649.45 BogoMIPS (lpj=2824728)
Calibrating delay using timer specific routine.. 5585.28 BogoMIPS (lpj=2792640)
zen% 

(oh yes, two cores) ... and add lpj=2824728 boot_delay=200 to the command line. So then it pauses a fifth of a second for each console message, right?

Wrong. Apparently it hangs. Search some, try setting boot_delay=10 instead: now it pauses a minute or so at startup, then prints a bunch of messages too fast to see, then continues staggering drunkenly through the boot sequence, sometimes scrolling fast sometimes slow.

Look at the code: oh super, printk(), the kernel's function to print console messages, calls boot_delay_msec() up front, as you'd expect it to. But it doesn't then output the message, it sticks it in a buffer. So I hack it instead to do the delay in the code that actually emits the message from the buffer, just after it sees a newline and emits a line's worth. (Patch attached, for posterity, marked UNSAFE simply because I don't know enough to say otherwise.)

Success, of a sort: now it does pause for each console message, about 3-5 seconds a time (10 milliseconds still being the requested delay, I'll have to try cutting it down to 4ms or so). I watch it for about 20 minutes, seeing a variety of interesting messages. Then, just at the point it's about to start looking at the disk drives, it speeds up again - I suspect it got to the point it decided it was no longer in system_state==SYSTEM_BOOTING, so the boot delay should no longer apply.

One of the messages I did see was ide_setup: ide0=noprobe -- OBSOLETE OPTION, WILL BE REMOVED SOON!. If I correctly understand what I've found, the IDE and SATA drivers have been combined into a single driver that should just do the right thing. So if it doesn't, I may just be SOOL. Still a few more things to try though.

Hugo