From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 Description of problem: During the Red Hat 9 installation bootup, the kernel properly detects that the machine has a DAC960 RAID controller. However, when the kernel module is loaded, the install simply hangs. The main install screen shows that it's loading the module, and one of the debug screens had the first two lines from the kernel module. The machine will reboot on a Control-Alt-Delete and will switch between screens, though. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Boot from install CD Actual Results: Install hangs loading DAC960 module. Expected Results: Install should have not hung. Additional info: Also attempted using noapic and loading the module manually after booting with noprobe, to no effect. This exact machine DOES boot fine with Red Hat 7.X and Red Hat 8.0 . The machine is a NEC Express 5800 MC2400R with a Mylex DAC960PTL1 RAID controller.
I have also have this problem although on different hardware (Intel Nightshade 440BX Motherboard with Mylex DAC960PTL1 RAID controller. The same thing happens, except the onboard controllers are located first but the module aborts loading because it detects that the raid controller is handling the onboard ports (this is normal and works fine on 7.3 and 8.0) then the DAC 960 module loads, displays the first 2 lines of output and then does nothing. You can switch between terminal sessions as noted in the original post.
I think I may have found the problem here. The NEC Express 5800 MC2400R has a Symbios 53C876E SCSI controller on-board. The Mylex DAC960PTL1 RAID controller has a 53C895 SCSI controller also. Could the kernel be confused as to which one to talk to when initializing the DAC960 driver? (When insmod tries to load the DAC960 driver, it deadlocks, hanging. Modprobe shows the driver "initializing".) Does the Intel Nightshade have an on-board Symbios controller as well?
I have checked the Nightshade board and yes it is the same as the NEC by the sounds of it. There is a 53C895 Chip on the Raid Controller and there IS a symbios 53C876E chip on the Nightshade board. I know the Raid controller with the nightshade has to be in a particular slot so that the raid controller can control the onboard scsi channels. Here is the output from Console screen 3 Durning the boot (copied and typed) * loaded sym53c8xx from /modules/modules.cgz * loaded DAC960 from /modules/modules.cgz .. .. .. /tmp/sym53c8xx.o init_module: Hint insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters You may find more information in syslog or the output from dmesg * failed to insert /tmp/sym53c8xx.o I consider the above normal when i have used the RAID controller in the past. output from ALT + F4 shows: (relavent lines only included) <6>sym53c8xx: at PCI bus 0, device 13, function 0 <4>sym53x8xx: not initalizing, driven by SISL RAID Controller <6>sym53c8xx: at PCI bus 0, device 13, function 1 <4>sym53x8xx: not initalizing, driven by SISL RAID Controller <5>DAC960: ***** DAC960 RAID Driver Version 2.4.11 of 11 October 2001 ***** <5>DAC960: Copyright 1998-2001 by Leonard N. Zubkoff <lnz> At this point the machine proceeds no further althou does still allow console switching. I have not included lines regarding PCI IRQ assignments in the above output.
This problem is not a DAC960 driver issue. After hours of testing and debugging, we finally tried an Intel SRCU42L RAID controller. The results were identical to the Mylex DAC960. The boot process freezes while tring to insmod the RAID module. Further investigation has revealed the following problem: The BOOT and single processor 2.4.20 kernels for RedHat 9 (including the kernel on the boot disks and CD) have been compiled with the following two options off: (All of the SMP kernels have these options enabled.) # CONFIG_X86_UP_APIC is not set # CONFIG_X86_UP_IOAPIC is not set Turning the above kernel options on and recompiling allows the machine to boot. What's odd is that previous versions of the RedHat kernel have these options enabled. The following two lines came from the last 2.4.18 kernel released! CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y If this is an APIC problem, is it related to bug #30980? Also important to note in bug #30980, entering "linux apic" at the boot prompt allowed the machine to boot. This does not seem to be the case here. Any chance RedHat will release a new set of boot images with this problem fixed? This makes loading a machine difficult to say the least unless your saavy with building updated boot disks. :) Darcy
Seems same kind of problem with ES Enterprise 3 Update 1 as on Linux 9 linux apic linux noapic linux expert noprobe (almost gets there, says loading driver at least, still hung) Definitely with Intel440GX dual proc Nightshade chipset problem, even with updated bios / firmware Hope there could be update boot.imgs for this one
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/