Bug 207024 - gcc 4.1.1 won't build a functional linux 2.6.18-rc7 kernel
gcc 4.1.1 won't build a functional linux 2.6.18-rc7 kernel
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
5.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Kernel Manager
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-09-18 16:12 EDT by Berkley Shands
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-09-20 23:11:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
2.6.18-rc7 .config from build tree after "make oldconfig" (53.36 KB, application/octet-stream)
2006-09-18 16:12 EDT, Berkley Shands
no flags Details
Config file that does boot on a opteron (45.50 KB, application/octet-stream)
2006-09-20 12:49 EDT, Russell Cattelan
no flags Details

  None (edit)
Description Berkley Shands 2006-09-18 16:12:58 EDT
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:
Comment 1 Berkley Shands 2006-09-18 16:12:59 EDT
Created attachment 136581 [details]
2.6.18-rc7 .config from build tree after "make oldconfig"
Comment 2 Jakub Jelinek 2006-09-19 02:36:21 EDT
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.
Comment 3 Berkley Shands 2006-09-19 07:57:14 EDT
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
Comment 4 Jeff Needle 2006-09-20 11:40:18 EDT
Filed against rhel5-rc1, which doesn't exist.  Moving to rhel5-beta1.
Comment 5 Eric Sandeen 2006-09-20 12:00:13 EDT
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...
Comment 6 Russell Cattelan 2006-09-20 12:49:08 EDT
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.
Comment 7 Berkley Shands 2006-09-20 14:17:20 EDT
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
Comment 8 Jay Turner 2006-09-20 23:11:55 EDT
Closing this out, as appears the issue resolved itself with the stock config file.

Note You need to log in before you can comment on or make changes to this bug.