Description of problem:
gcc 3.4.6 (rhel 4.4) builds a functional 2.6.18-rc7. It boots and runs on x86_64
under a variety of motherboards.
gcc 4.1.1 builds a 2.6.18-rc7 kernel, modules_install and install,
but the kernel boots to memory config stage and hangs. No amount of proding gets
it past that. The 3.4.6 built kernel loads just fine and runs.
tyan 2885 8GB dual 248 opterons, adaptec U320 7902 scsi system disk.
Version-Release number of selected component (if applicable):
the default 2.6.17-2596 kernel does not support XFS. Bummer, use the current
2.6.18-rc7 which workes fine on ES 4.4. Nope, can't compile and boot it with
4.1.1. Dead in the water. No panic, nothing. just stops on the boot.
Steps to Reproduce:
1. Use attached 2.6.18-rc7 .config if you want. Same one was used for ES 4.4 build.
hang 1 second into boot
normal 2.6.18-rc7 build
Created attachment 136581 [details]
2.6.18-rc7 .config from build tree after "make oldconfig"
That's far more likely a bug on the XFS side, at least as past experience shows,
especially in the XFS code. For a gcc bugreport you'd have to
come with a self-contained small testcase.
I'm sorry, but what does XFS have to do with the kernel not compiling and
executing with gcc 4.1.1? That the default kernel does not have XFS is a
marketing thing, not a gcc thing. Using 2.6.18-rc7 compiled with 3.4.6 on EL5
works fine. Using 2.6.18-rc7 built with 4.1.1 does not. The kernel has not even
gotten to loading modules. It is still trying to do memory discovery.
You want a small test case? how small is the kernel :-) Come on! At least EL5
installed where as FC6 could not even do a GUI install on x86_64. Even in text
mode it failed to install initrd in /boot. EL5 actually worked, and you don't
want to hear about 2.6.18-rc7? I'm sorry I even bothered to report the problem.
Filed against rhel5-rc1, which doesn't exist. Moving to rhel5-beta1.
Berkley, perhaps you can try building the rhel5-beta1 sources with the stock
rhel5-beta1 config that shipped.
If that works, try building the rhel5-beta1 kernel sources with whatever config
you used with the vanilla kernel.
Don't worry about xfs in the config, since your kernel isn't even getting that far.
I wouldn't be surprised if it turns out that the bug ends up having something to
do with your config differences...
Created attachment 136756 [details]
Config file that does boot on a opteron
Try this config file.
The kernel is currently running on an operon box compiled
You might want to turn off some of the debug options although.
And I agree, I have never seen a problem where including XFS causes
a hard lock up at boot.
Panics yes, but not hard lockup's early in the boot.
that .config builds. Thank you. It even allows nvidia's kernel module to load.
WOW! dual heads again. I really missed my other head to talk to :-) Some
problems along the way - the other .config came from FC6. It I *TOUCH* the
.config you provided with a gcc 3.4.6 made "make oldconfig" even followed by a
"make clean" and another "make oldconfig", *NOTHING* builds. It blows up with a
message about please enable modules in your kernel. Really descriptive. A make
distclean and a fresh copy of the .config helps. Perhaps a release note (which I
never read) that says you MUST start with a stock .config for the new EL5. Now
what I need to do is figure out what option causes the kernel to lock up. Or
just give up and continue on down the road. And file more bug reports, like
thunderbird isn't on EL5, but is in FC6. go figure. or there are no MP3 players
in EL5 (Bummer!) DRM strikes again! or updatedb searches NFS mounts, takes 1.5
years to get 11 zillion access errors.....
So I'm happy (thanks again) and XFS does seem to work (but really should be
native). I'm almost afraid to take this .config back to 3.4.6 and EL4.
Closing this out, as appears the issue resolved itself with the stock config file.