From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98; Win 9x 4.90) During boot process, kernel hangs while probing IRQ devices Reproducible: Always Steps to Reproduce: 1. Boot 2. 3. HARDWARE: AMD Athalon Thunderbird 1.1Ghz CPU 512MB PC133 RAM ASUS A7V Socket A Motherboard ATI Radeon VIVO 64MB RAM (2) IBM UltraATA/100 Desktar Drives 30GB Pioneer DVD 105S Sony Espressa CD/RW Soundblaster Live 5.1 Platinum All latest BIOS patches applied. Unfortunately, it's impossible to get a screen dump as the system never actaully boots. However, if needed I can summarize the boot messages. It appears to hang after deteting the DVD drive (sucessfully). This is the first Red Hat release that looks to support all the above hardware components without patching the kernel.
The following setting caused the conflict/hang: Both hard drives (master/slave) on primary ATA100 controller (Promise) DVD drive (master) on secondary ATA100 controller CD/RW (master) on primary IDE controller Work around: Both hard drives (master/slave) on primary ATA100 controller (Promise) DVD & CD/RW drive (master/slave) on secondary ATA100 controller I'm assuming this is a bug as the original setting worked under Windows ME.
Are you sure there isn't a "panic: cannot mount root-fs" message somewhere ? And did the original configuration work with your own kernels ? (if so, could you please include the output of "cat /proc/ide/pdc202xx" and "cat /proc/ide/via" in the working case).
Nope. No messages. Simply hung during the boot process during the IRQ assignment. This was the first red hat release that I got working with my hardware, so no other configuration worked. I did re-arrange the perhipherals so that everything is running off the UltraATA100 controllers; as I mentioned this seemed to eliminate the conflicts and everything appears to be fine. I didn't go a good job summarizing above (apologies, it was early), but the conflict was three devices on ATA100 and one device on Ultra 66/33.
I've re-arranged the peripherals again and am getting a similar error. The A7V motherboard has 2 Ultra ATA/100 controllers and 2 IDE controllers. I've placed a hard drive on each ATA controller (both master). I've placed the DVD drive on the primary IDE and the Sony CD/RW on the secondary IDE controller (again both master). So, basically, I'm utilizing all four controllers, each device being the only (thus master) device on the controller. I re-loaded fisher onto the hard drive on the secondary UltraATA controller (primary houses Windows ME). Installation was flawless and all devices appeared to be recoginzed. Now, when booting, LILO fails to start. I get an "LI" after the BIOS screens then the system simply hangs. However, if I boot of the linux boot floppy (created during install), the system seems to come up fine. I've installed/uninstalled LILO a few times with similar results. During the load process, LILO was placed onto the Windows ME drive, as it's occupying the primary ATA100 controller.
I'm seeing the same hang at LILO after *fresh* (/home was not reformatted) fisher install Setup ABIT VP6 which similarly has 2 regular IDE and 2 ATA100 controllers. hda (master primary IDE) CDRW hdc (master secondary IDE) hard drive hde (master primary ATA) IBM UltraATA/100 Desktar Drives 30GB /boot is /hde1 i.e. on the ATA100 controller. I had had previous problems on same system doing upgrade from RH 7.0. lilo.conf was correctly edited by installer to reflect fisher changes hower /sbin/lilo did not seem to have been run.
This is actually a lilo issue.
I found the exact same thing on a ABIT KT7-RAID. Uses the Highpoint 370 IDE chip. Same amount of memory, same CPU. I was running two IBM 45GB Ultra-100 IDE drives in RAID-0 mode. It seems everything works fine if I boot with the floppy. But when I boot from hard disk with lilo it hangs with "LI" in the bottom left of the display. I did run "lilo -v -v" to ensure it being up to date. As a side note, a friend has the same KT7-RAID but only one drive running Ultra- 100 and he too had the same problem.
These are lilo.conf issues. Basically, even though linux thinks the drives are in some particular order, the BIOS has them in a different order. In order to get things working properly, you've got to find the order that the BIOS has the drives listed in, compare that to the order that linux finds the drives in, then modify your lilo.conf file to reflect drive locations. For example: boot=/dev/hdc /* if the BIOS finds /dev/hdc first, then put lilo on it */ disk=/dev/hdc /* start a disk configuration block in the lilo.conf */ bios=0x80 /* tell lilo that the BIOS sees /dev/hdc as /dev/hda */ disk=/dev/hda bios=0x81 /* tell lilo that the BIOS sees /dev/hda as /dev/hdb */ image=/boot/vmlinuz /* /boot is on /dev/hda so we need the disk=/dev/hda */ read-only /* section above */ other-options.... Thats typically enough to get the system booting properly. Fixing the problem any other way is beyond the scope of lilo changes because we can't read the BIOS to tell what order it places the drives in once we have booted into 32 bit protected mode.