2.6.39-rc5-git2 boot crashs

Yes, my kernel compiling / packaging / lilo.conf-writing script always do this: it makes 3 manners for boot: normal/grafics, text, initrd; for this it makes an initrd too. See below. Normally this also works without any problem. This is necessary if someone want to make an installer. And just because of this, I compile plenty things inside vmlinuz , not as modules, because nowadays people have any kind of devices with touchpad, touchscreen etc. And, last night, I tested all these boot methods, but in all attempts happened that error, that it didnt find the boot device, and then crashs, more strange because there also is a bootwait option in the command line (see below) (because nowadays people often have installed my distro on an usb key, or on an eee pc just the starter is on the internel flash chip, and the system with root fs is on an usb harddisk what takes time to be discovered).

But, now, the 2nd compilation, I made with the slackware huge configuration. And this works !! It boots normally, and it also don't crash if unzipping big files. So you were right, to use a more little config, for find out better the reason. However, remember, at the end (until -rc20) also the everythingyes config should work, because this always was the case, and have to work because nowadays people have all kinds of computers, laptops, phones, coffe machines, washmachines etc etc running Linux and the distro kernel have to run ANYWAY on ANY DEVICE.

That successful slackware huge config is in the middle between the slackware smp config explained above which didnt boot, and between my normal everythingyes configuration which gave plenty problems. So, the differences to both sides can make it more easy to find out, a) why the slackware smp config didnt boot at all, not finding the root fs, and to the other side, why b) my everythingyes config, which all the time worked (also on 2.6.34.8), give so many problems with 2.6.39-rcX.

Pls find, enclosed, as the 2nd file, the successful config which is still running on my computer and didnt crash yet (entering with slackware huge smp into menuconfig end going out without changes). Also, as the 3rd file, is the difference of this to my everythingyes config used for -git2 to -git4; from tese differences it should be possible to find better what cause the many problems in the sense of comparison b) above.

However, I should mention, that this successful config has a problem with the grafics. On the laptop of my neighbour, it switched to a wrong text mode where the characters are little and 3 times on the top of the screen. And on my computer, I cannot change to the text screen with CTRL-ALT-F1 etc.

wl

---
Professional hosting for everyone - http://www.host.ru

2011/5/1 werner <[email protected]>:

Ok, good. Now we have confirmation that it's not the SATA driver itself that causes problems, it's some other driver.

So what I'd suggest you try to do is a "config bisect" to see exactly _what_ config option it is that makes things break. Steve Rostedt wrote a tool ("ktest") for this exact thing, but I'm not entirely sure that it will work for your situation. I've added Steve to the email participants, and I'd suggest you read up on it:

http://lwn.net/Articles/414064/

would seem to be a good starting point.

Of course, you could just try to do it manually too - just turn one subsystem at a time from a module in the working slackware config into a compiled-in thing, so that eventually you end up with the non-working "almost everything compiled in" case. And see which subsystem it is that causes problems.

And then when you find the subsystem that makes the problem re-appear, you'd need to go back and try each driver at a time.

Linus

Note, from his email he has:

Which, if I understand this correctly, is three different configs: A, B and C and they have a relationship of A < B < C. Where A doesn't boot, B does, and C boots with problems.

config-bisect can definitely find the issues between B and C, which I think is a second issue. As for the problems of A and B it may not work so well. This would require a "reverse bisect" as "config bisect" is much like git bisect where it expects things to work then suddenly break. The difference between git bisect and config bisect is that a reverse wont work with config bisect (it might if you're lucky). That's because git may have branches, but configs have nasty dependencies.

The way config bisect works to find a bad config (one if set will break the kernel) is the following algorithm:

o You feed it a good config (does not have config that breaks the kernel), and a config that breaks the kernel (contains a bad config).

again:

o It will select all the configs that are in both of the configs and half of those configs that are in the difference of the two configs and run make oldnoconfig on it. Because these configs can select other configs or may depend on other configs not selected, it is possible that we end up with the bad or good config again. So ktest does a diff on this config to make sure it is different. If it is not then it will select the other half instead. If it is also the same, then it will select only one config at a time until it finds a config that is different.

o runs the test
(you can add CONFIG_BISECT_TYPE = build, BISECT_MANUAL = 1, which will just build the kernel and then wait for you to say if it was good or bad. This is handy if you don't want to set up all the automation of ktest and only want it to do the config bisect for you. Then you can install and reboot the kernel and then tell ktest if it worked or not). This still requires that the build machine to be on a separate box than the test machine.

o If the test fails, it takes this config as the new bad config, and the difference will be against this config and the good config.

o If the test passes, it believes all these configs that were selected are good, and will permanently select them for the remainder of the tests. We need to permanently select this configs because later configs (and perhaps the bad config) may have dependencies on these configs.

o If there's no more configs to compare, then the last config to be selected is the bad config, otherwise goto "again".

This works great when you have a bad config you are looking for. I've used this 4 or 5 times already which had great results. But I do not think it will help if there's a good config that makes the kernel work again. If we select that config on the first pass, then all new configs will contain this working config.

I'm confused, as I thought the working config was between the two broken configs he has. Maybe I just misunderstood.

-- Steve