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):
This is with a SuperMicro P4DP6 Dual Xeon with one CPU, hyperthreading dusabled,
8 GB memory
Steps to Reproduce:
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. firstname.lastname@example.org.
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.
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
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.
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
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/