Red Hat Bugzilla – Bug 81575
kernel 2.4.18-19.7.x (bigmem) hangs at boot
Last modified: 2007-04-18 12:49:41 EDT
Description of problem: Upgrading a 7.2 computer to kernel-bigmem-2.4.18-19.7.x caused hard hang at boot. Version-Release number of selected component (if applicable): kernel-bigmem-2.4.18-19.7.x (i686) This is with a SuperMicro P4DP6 Dual Xeon with one CPU, hyperthreading dusabled, 8 GB memory How reproducible: Always. Steps to Reproduce: 1. Boot. 2. 3. Actual results: Expected results: Additional info: See attached boot log.
Created attachment 89288 [details] kernel output preceeding hang This gives all the output the kernel produces. After this, all I can do is press the reset button (CTRL-ALT-DEL is innefective, but also disabled in our inittab). The timestamps are from our serial console server program. Sometimes the hang occurs a line or two earlier or later than this.
I get a hang at the same exact point with 2.4.18-19.7.xsmp on a Dell PowerEdge 1550 (dual PIII with only a single 866 MHz CPU installed, 256MB RAM). I did try the non-SMP 2.4.18-19.7.x, and it does boot, however interrupt routing is suboptimal, with the aic7xxx controller running on IRQ 3 (after complaining about an interrupt conflict). For now I've reverted to 2.4.9-34enterprise.
This sounds like the same hang as in Bug 76829. The hang there is in the same place, only displaying the first 'p' in the last line below: VFS: Diskquotas version dquot_6.5.0 initialized Detected PS/2 Mouse Port. pty: 2048 Unix98 ptys configured
I have the same problem on an IBM x345, single XEON with HT enabled, 4GB memory, kernel 2.4.18-26.8.0 from RH8.0 errata. donald_bodle@reyrey.com. Hangs either at the ptys: statement, or once I got "serial driver version 5.05c (2001-07-08) wit" as the incomplete next line. The UP kernel boots fine.
Yeah, I restested this with a slightly re-spun 2.4.18-26.7.x bigmem kernel. The problem only appears with a single CPU. With 2 CPUs, all is fine. Apparently, there is something in the bigmem code path that fails if multiple CPUs are not present. Dave
I did discover that HT had been disabled on the x345 I was testing on. With HT enabled on a single CPU box, the 2.4.18-26.8.0 smp and bigmem kernels both booted okay. Don Bodle
You may want to cross-check also with bug 78559 - I just posted a comment there. I am *not* using bigmem, but get the hang at the "pty" on a number of UP systems when booting 2.4.18-26.7.x SMP - 2.4.18-26.7.x UP works fine, as does 2.4.18-10 SMP. Since you too seem to have the problem with the SMP kernel on UP systems, perhaps the bigmem is not the critical factor - also the mod I did (which fixes / works around the problem for me) wasn't related to bigmem. --Per Hedeland
I haven't been back to this in a while, but wanted to note that if you look at the Redhat configs used to generate the smp and bigmem kernels, both have SMP enabled. So the problem with the bigmem kernel is likely still an SMP issue.
Thanks for the bug report. However, Red Hat no longer maintains this version of the product. Please upgrade to the latest version and open a new bug if the problem persists. The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, and if you believe this bug is interesting to them, please report the problem in the bug tracker at: http://bugzilla.fedora.us/