Our website would like to use cookies to store information on your computer. You may delete and block all cookies from this site, but parts of the site will not work as a result. Find out more about how we use cookies.

Login or Register

Powered by
Powered by Novacaster
 
Frustrated
by Hugo van der Sanden at 04:35 13/01/10 (Blogs::Hugo)
Ugh, kernels
Where's the "tell me how you were built" flag?

Tell me, please?

(This flag would also be useful on hardware, I suspect.)

Hugo

<< Bone idle CPUs Domains >>
View Comments (Threaded Mode) Printer Version
Frustrated Hugo van der Sanden - 04:35 13/01/10
Re: Frustrated Simon - 10:16 13/01/10
Sorry Hugo - no idea.

This thread any use?

--
simon

Working boot_delay Hugo van der Sanden - 16:06 18/01/10

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

Attachments...
Plain text (0 K) (*UNSAFE*) move boot printk delay to point of emitting console message
Re: Working boot_delay Simon - 16:26 18/01/10
This is still all in an attempt to determine what's going wrong with the timings across the two cores yes?

I suppose you've tried booting from a LiveCD of the kernel version you're trying to end up at and checked the original problem doesn't still exist at that release?

Just saying...
--
simon

Re: Working boot_delay Hugo van der Sanden - 16:51 18/01/10
This is still all in an attempt to determine what's going wrong with the timings across the two cores yes?

No, this is trying to upgrade the software to a) learn a bit about what's going on, and b) improve my graphics support to the point I can try out the game Wurm and get more than 0.4 fps.

The intent is to build an up-to-date kernel, and then X, and then see where I can go from there. I had thought the kernel would be the easy bit though.

I suppose you've tried booting from a LiveCD of the kernel version you're trying to end up at and checked the original problem doesn't still exist at that release?

No, I don't have any such useful CDs - I probably ought to find myself one. In any case, I'm pretty sure though that the CPU speed is a hardware or firmware issue.

Hugo