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): gcc 4.1.1 How reproducible: 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. 2. 3. Actual results: hang 1 second into boot Expected results: normal 2.6.18-rc7 build Additional info:
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. berkley
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 with gcc-4.1.1. 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. berkley
Closing this out, as appears the issue resolved itself with the stock config file.