Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 76551 - (440GX IRQ_ROUTING)2.4.18-17.7.xsmp kernel hangs with 440GX motherboard
(440GX IRQ_ROUTING)2.4.18-17.7.xsmp kernel hangs with 440GX motherboard
Status: CLOSED DUPLICATE of bug 79752
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Doug Ledford
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2002-10-23 06:21 EDT by Tim Evans
Modified: 2007-04-18 12:47 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-02-21 13:50:01 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Dmesg boot log 2.4.19-smp on 440BX (12.27 KB, text/plain)
2002-11-12 09:55 EST, Seth Mos
no flags Details

  None (edit)
Description Tim Evans 2002-10-23 06:21:11 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.6 (X11; Linux i686; U;) Gecko/20020913

Description of problem:
I have a dual processor motherboard (Intel Corp. 440GX) based machine with 1
processor installed. I am currently running RedHat 7.3 with the 2.4.18-4smp kernel.

I installed the 2.4.18-17.7.xsmp kernel, but the machine hangs when booting this
kernel, just at the point where it is about to probe the SCSI controllers (i.e.
it DOES NOT probe the controllers).

I have tried disabling all the external SCSI devices (leaving only the internal
hard-drive) but this does not make any difference.

I have also tried using the noapic flag on boot, and the 2.4.18-17.7.x (non-SMP)
kernel, but this results in the expected SCSI timeouts for this motherboard.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.boot using the 2.4.18-17.7.xsmp kernel 

Additional info:
Comment 1 Arjan van de Ven 2002-10-23 06:27:27 EDT
does it work if you make it use the aic7xxx_old driver instead?
Comment 2 Tim Evans 2002-10-23 07:54:11 EDT
I moved the aic7xxx_old.o module into place, but the result is the same.

They system hangs just at the point where it is reporting on:

Real Time Clock

Comment 3 Ryan Cleary 2002-10-23 14:16:43 EDT
I'm experiencing a similar problem with a Dell PowerEdge 2400 (dual CPU
motherboard) with only one CPU installed.  I have Red Hat 7.3 installed on a
RAID array attached to a Mylex eXtremeRAID 2000 card (DAC960, doesn't use SCSI
layer).  Only my CD-ROM is using the onboard Adaptec SCSI.

With 2.4.18-17.7.x, it boots fine, loading the the aic7xxx module.

With 2.4.18-17.7.xsmp, it hangs right after the line

pty: 2048 Unix98 ptys configured

This machine will be available for testing over the next few days if there's
anything you want me to try.
Comment 4 Need Real Name 2002-10-29 16:36:51 EST
I've been having similar problems with a system recently upgraded to RedHat 8.0
(as well as systems running 7.3) see bug #74937.  The problem has to do with a
long standing BIOS/firmware problem with the L440GX+ chipset.  Basically what I
have found is that the smp kernels work fine on L440GX+ mobo's that have two
processors but the smp kernel does NOT work on L440GX+ system with single
processors (which has worked on previous kernel releases).  NOTE: The
kernel-BOOT rpm will boot on these systems....

However, there is a way to get these systems running by building a custom kernel
and disabling SMP support and enabling local APIC and IO-APIC support for
uniprocessors in the processor type and features section under "make xconfig."

I will be uploading a kernel .config to bug #74937 with the fix in it later today.
Comment 5 Seth Mos 2002-11-12 09:53:37 EST
I have a Dell PowerEdge 1300 with a single processor that hangs on boot as well.
However this system is based on the Intel 440BX chipset and not the GLX.

This is very annoying since this is the first kernel in years that breaks for
this reason. I always used kernels with smp support and it never showed before.
The standard 2.4.18-17.7.xsmp i686 kernel hangs on boot after the "pty: 2048
Unix98 ptys configured" line.

This is a test box so I can try out any patches. I will provide a 2.4.19-xfs-smp
dmesg boot log as a an attachment.
Comment 6 Seth Mos 2002-11-12 09:55:47 EST
Created attachment 84624 [details]
Dmesg boot log 2.4.19-smp on 440BX
Comment 7 ipvcor 2002-11-25 20:30:53 EST
I have the exact same problem on a 440GX+ motherboard. When the kernel hangs on
boot, i either get a 'p' or 'pty:'. it's never able to spit out the full line.
Comment 8 Tim Evans 2002-12-03 11:06:46 EST
The latest 2.4.18-18.7-smp kernel is also hanging after the lines 

ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
Comment 9 Jan vandenBerg 2002-12-18 10:42:26 EST
Hi. It looks like I have the same problem on a Dell 530 workstation (i860 
chipset), configured with a single cpu. If I try to boot the newer 2.4.18-
18.7.xsmp or 2.4.18-17.7.xsmp kernels, the boot hangs at:

pty: 2048 Unix98 ptys configured
Serial driver version 5.05c

The UP versions of these newer kernels seem to work fine. Older SMP kernels up 
through 2.4.18-10smp worked fine, too.

It's nice to be able to just throw the smp kernels onto all of your machines, 
regardless of their actual up/smp configurations.

All of the aforementioned kernels are the i686 builds.
Comment 10 Bill Strossman 2002-12-19 16:43:25 EST
	My problem is very similar (Dell 530 Workstation, single CPU) and the latest
SMP kernel (2.4.18-18.7.x, 686 build) hangs at boot.  UP kernel boots fine. 
Stock Redhat 7.3 kernels (both UP and SMP) boot fine.  The difference is that
mine hangs after the following lines:

Dec 18 12:49:27 muon kernel: PIIX4: not 100%% native mode: will probe irqs later
Dec 18 12:49:27 muon kernel:     ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: h
da:DMA, hdb:DMA
Dec 18 12:49:27 muon kernel:     ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: h
dc:DMA, hdd:pio

Comment 11 tolga ceylan 2002-12-19 18:56:27 EST
I have the same problem on a single CPU Compaq DL360 G2, with
kernels 2.4.18-17.7smp and 2.4.18-18.7. It hangs at boot at 
"pty: 2048 Unix98 pyts configured" line. If I use the old
2.4.18-10smp kernel then it works. I don't have any 
problems with the new UP kernels.
Comment 12 Bill Strossman 2003-01-04 05:22:57 EST
UPDATE (see additional comment #10): The latest kernel on the updates site
(kernel-smp-2.4.18-19.7.x.i686.rpm) behaves exactly the same way as
2.4.18-18.7.x, so I just compiled kernel 2.4.20 from source using the redhat
config file kernel-2.4.18-i686-smp.config (make oldconfig).  I chose the default
answers for the new questions (they seem to be unrelated anyway) and this smp
kernel boots fine. 
Comment 13 Tim Evans 2003-02-13 05:04:23 EST
kernel-smp-2.4.18-24.7.x also has this problem
Comment 14 Tim Evans 2003-03-19 04:20:17 EST
kernel-smp-2.4.18-27.7.x continues to have the same problem.
Comment 15 David Campbell 2003-04-01 21:10:00 EST
Is this ever going to get fixed? The 2.4.18-3smp kernel works fine in regards 
to this bug, but there are other bugs present in that kernel that I'd like to 
patch such as the security holes and ext3 bugs by installing a newer kernel. 

Is there an ETA on when this bug will get fixed, or should I start building 
custom kernels for each of my servers that have the gx440 motherboard?

Does anyone know if the new redhat 9.0 still has this bug?
Comment 16 Tom Diehl 2003-04-02 01:00:54 EST
suggest reading the release notes. As I understand things they have a 
workaround in the shrike kernel that may or may not fix it for you. Remember 
this is NOT a Red Hat bug. It is an Intel BIOS bug. You can work around it by 
recmpiling the kernel. I know it is a PITA but it is better than not being 
able to use the hardware. along with everyone else I too hope for a permanent 
fix but I think Intel is to busy with other things to be interested and they 
only recently released hints on how to possibly fix this to the Linux Kernel 
developers. Time will tell. 
Comment 17 Alan Cox 2003-06-08 07:30:14 EDT

*** This bug has been marked as a duplicate of 79752 ***
Comment 18 Red Hat Bugzilla 2006-02-21 13:50:01 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

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