Hide Forgot
Description of Problem: When I boot (or try to install) RH8.0 (as well as RH7.2, Suse 8.1, Suse 7.3), the system hangs after about one text page. The only remedy I found so far is adding pci=off or pci=conf2 to the boot options. Both of these result in pci-adapters like ethernet not being available (which is unacceptable). Version-Release number of selected component (if applicable): several 2.4 kernels How Reproducible: always Steps to Reproduce: 1. put RH-install CD into the drive 2. turn on, press enter to start installation Actual Results: complete crash (no C-A Del, no NumLock key, ...) Expected Results: start choosing what to install Additional Information: The system is a Gericom Masterpiece 2440 notebook (P4 2,4), with a DVD/CDRW-drive. lspci reports the pci-bridge to be intel 82801BAM (apparently, this belongs to the intel 860 chipset). A recent version of knoppix which I just tried boots ok, and afterwars "ifconfig eth0" knows about the ethernet card (which is a realtek 8139). I have found some (not very many) similar bugs here, but none that matched my case. PS: nousb-boot parameter doesn't help here.
I have found that if I install the RH7.1-kernel, everything works fine. Absolutely weird, since the 7.1-kernel is 2.4.2-2 ...
Could you collect the boot messages of both the 2.4.2-2 kernel and the 8.0 kernel off of a serial console attached to the machine? That might give us a clue where things are going wrong, and what workaround is possible.
Created attachment 88704 [details] the output of dmesg of 2.4.2-2 on RH7.1 I have attached the output of kernel 2.4.2-2 on RH7.1 (the system I am currently running). (sorry, don't know what you mean by attaching a serial console). The other kernels hang after printing the "ide1: BM-DMA ..."-line. To the best of my knowledge, the output before is the same. I will also attach the output of kernel 2.4.7 (RH7.1); however, it will be the output of the one booting with "pci=off"-option.
Created attachment 88705 [details] dmesg-output of kernel 2.4.7 (with "pci=off") this is the announced output of dmesg, after booting with kernel 2.4.7 with the "pci=off"-option. should I download the kernel 2.4.20, which RH released as a supplement to 8.0?
TYPO! I am running RH7.2, with the kernel of 7.1. sorry, it's getting late in Europe...
Try the 8.0 boot with ide=nodma
ide=nodma does not change anything. BTW, on the dead screen, I have the impression of more "IRQ10"'s showing up than on both running ones. Also, maybe I should mention that I have a Phoenix 4.0 (release 6) BIOS, which does not offer a lot of options. However, I have set "operating system" to "other" (the alternative was win 2k/xp), otherwise pretty much everything there is still at its standard values. I guess the operating system-setting is actually the PnP-question.
Any more ideas on this bug? I am still not happy with the situation... (also: maybe someone should change the status; or is this still a "new" bug?)
No more ideas currently, and no replication of it on other 860 based systems that I know about.
Actually, I just managed to get some new information: I downloaded kernel-2.4.20-2 (from rawhide) and installed it (at least tried to) on RH7.1 (because I had it on an old partition and didn't want to mess with the working system too much). Anyway, it shows the following behavior: crashes both with and without "pci=off" (but at different points) Not using "pci=off": Similar crash as before, but the last messages are different: looks somewhat normal, the last few lines are: PCI: Enabling device 00:1f.6 (0000 -> 0001) PCI: Found IRQ 10 for deevice 00:1f.3 PCI: Sharing IRQ 10 with 00:1f.5 Real Time Clock Driver v1.10e and that's it. If I add "pci=off" to the boot options: the last screen looks like: a bunch of acpi messages 2 init messages 1 kernel_thread_helper message Code: Bad EIP value <0> kernel panic: Attempted to kill init! (and that's it again). (maybe the "bad EIP" - thing has something to do with the fact that I had to install some more recent version of iptables than shipped with RH7.1 ?) (should I install RH8.0 on the spare partition and see what kernel 2.4.20-2 does with that?)
On some other mailinglist (suse-laptop), someone has found a solution: One has to disable "USB legacy support" in the BIOS, then everything works fine. He reports that USB works nevertheless (I can't test that since I don't have any USB devices)