Red Hat Bugzilla – Bug 76551
(440GX IRQ_ROUTING)2.4.18-17.7.xsmp kernel hangs with 440GX motherboard
Last modified: 2007-04-18 12:47:53 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: Always Steps to Reproduce: 1.boot using the 2.4.18-17.7.xsmp kernel 2. 3. Additional info:
does it work if you make it use the aic7xxx_old driver instead?
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
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.
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.
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.
Created attachment 84624 [details] Dmesg boot log 2.4.19-smp on 440BX
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.
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
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.
Hi: 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
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.
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.
kernel-smp-2.4.18-24.7.x also has this problem
kernel-smp-2.4.18-27.7.x continues to have the same problem.
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?
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.
*** This bug has been marked as a duplicate of 79752 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.