Since there are plans to unmask gcc-4.3, I was asked on linux.gentoo.dev to file this as a bug: When compiled on x86 with gcc-4.3, the hardened-sources-2.6.24 kernel dies immediately at boot, even before printing any message (so debugging is hard). When the kernel parameter acpi=off is passed, it boots without problems. The problem does not occur on amd64 or when gcc-4.2.1 is used for compilation. I deselected all acpi features in the configuration (except for the general acpi support, of course), and had the same behaviour. I have not tried (and have no time to try these days) whether the problem arises also on gentoo-sources or whether it is hardened specific.
Created attachment 149473 [details] One kernel configuration which does not boot The attached .config does not have all acpi deselected, but as mentioned, this makes no difference. It has PAX disabled, so this can be excluded as a cause.
(In reply to comment #1) > Created an attachment (id=149473) [edit] > One kernel configuration which does not boot > > The attached .config does not have all acpi deselected, but as mentioned, > this makes no difference. > > It has PAX disabled, so this can be excluded as a cause. > I don't know what roll this machine plays in your operations but if it is not too much trouble, would you mind trying gcc 4.3 compiled gentoo-sources-2.6.24-r4 on it with this config?
As far as I'm aware, 2.6.24 with gcc-4.3.0 is not a supported combination from an upstream perspective. In fact, I would strongly recommend against it with respect to bug 213811. If you're going to try, then at least apply the following patch: http://tinyurl.com/2obf6t I'm not sure whether that has a direct bearing on the reporter's problem though. I too would like to know if the same problem occurs when using gentoo-sources. Gordon, while I think of it, you should add the above patch to your 2.6.23-r10 queue as the kernel herd will almost certainly address it solely in the current genpatches branch.
Now I found a bit time to try also with gentoo-sources-2.6.24-r4: The same result, i.e. (as expected) the problem is not hardened specific. [To be precise: I used "make oldconfig" with the above config and answered the three new points KALLSYMS_EXTRA_PASS FB_CON_DECOR PROC_KCORE all with "N"] @Kerin Millar: Originally, I had also conjectured that the problem is the well-known cause that gcc-4.3 does not clear the DF flag (that's why I did not want to post the bug first), but I was told at gentoo-dev mailinglist that this problem occurs only much later in userspace. Moreover, it seems to me that the patch you posted was already applied in gentoo-sources-2.6.24-r4 (and then probably also in hardened-sources-2.6.24, since they both are based on the same patchset). I don't know know whether it is helpful: If I pass the kernel parameter vga=0x31A, the vga-mode is changed, before the kernel dies...
> that this problem occurs only much later in userspace. Moreover, it seems to > me that the patch you posted was already applied in gentoo-sources-2.6.24-r4 > (and then probably also in hardened-sources-2.6.24, since they both are based > on the same patchset). Sorry Martin, you are quite right. Before going gold, the final iteration of the 2.6.24 patchset was adjusted by Gordon. That's the point at which genpatches-2.6.24-5 was pulled in and I hadn't noticed that the patch was included. Well, I suppose that's one less thing to worry about. Re-assigning to the kernel herd.
linux-2.6.25 has been released ... please test that version to see if the issue remains
The problem has vanished with 2.6.25 (tested: gentoo-sources-2.6.25-r1). I am not sure whether I should close this bug now or wait until hardened-sources-2.6.25 gets released.
will close when 2.6.25 goes stable, or earlier if we can identify and backport the fix to 2.6.24
(In reply to comment #8) > will close when 2.6.25 goes stable, or earlier if we can identify and backport > the fix to 2.6.24 > In the case that a backported fix is not found and {gentoo,vanilla}-sources-2.6.25 goes stable, please re-assign to hardened@gentoo.org instead of closing as we will want to keep note of this bug. Thanks dsd. :)
Just for the records (although it is not very surprising): Also after the latest gcc update (4.3.0->4.3.1) the kernel (I tried hardened-sources-2.6.24-r2) does not work.
Since hardened-sources-2.6.25 is now in the tree, I should mention that they work fine with gcc-4.3.1.
Closing as this is fixed in 2.6.25, which we'll hopefully have headed towards stable soon.