I keep getting the following error on Pentium4 machines: Kernel panic: Aiee, killing interrupt handler! To be more specific, I have used the new Pentium 4 ISO as downloaded from a Gentoo mirror. I used the GRP installation, but I did compile my own kernel (did it a number of times before). I do compile with ACPI and APIC enabled, and this used to work with RC4; I can provide all the parameters if necessary. After changing BIOS parameters (APIC, PnP off) I even tried appending pci=biosirq to the kernel command line, but to no avail. The precise error messages are: Partition check: /dev/ide/host0/bus0/target0/lun0: p1 p2 p3 p4 <kernel BUG at sched:1102 (note: this number varies, e.g. 1146)! invalid operand: 0000 followed by a CPU/register dump and a call trace which I won't repeat and ending in <0> Kernel panic: Aiee, killing interrupt handler! In interrupt handler - not syncing At this point the system halts.
A) What kernel version are you using? [ I assume you are using gentoo-sources-rcX ] B) After looking through the source, try disabling the pre-emptive kernel. Also, unless you're using SMP < which I don't think you are > remove the SMP support which is on by default... C) This looks like an IRQ based problem, try removing APM and ACPI and APIC [ not disabling it in the BIOS, actually don't compile it ] D) A register dump would be very nice, and if you could 'ksymoops' that register dump we could see call trace output, hopefully allowing for a faster bug resolution... If a call trace is actually given, can you give the call trace [ and forget doing the 'ksymoops' ] E) Please attach your kernel .config
Ok I will recompile the kernel with the suggestions you've made. I'm not a Linux veteran so could you advise on how to copy a call trace or a register dump to a file when the kernel halts? Unfortunately I will not be able to do this before Saturday... I'll come back ASAP.
Ok I've found the bug. As you suggested, the problem is the pre-emptive kernel option. Once I disabled that and recompiled, I could boot normally. BTW, before that, I upgraded from gentoo-sources-r5 to -r6, but I suppose that is irrelevant here?! However, I may want to re-enable it later, so I still think it's a bug. Also, I should add that all of my Pentium4 systems live on an SiS5513 chipset (of course I did enable support for that!) Further, the bug did not appear with a Celeron 1.7GHz; when I installed using the same Pentium4 LiveCD, I encountered no problems there.
Could you do me a favor and try gentoo-test-sources when you get a chance. That will be making it's way to gentoo-sources soon, and I'd like to see if it's still got this problem
OK here's what I have done. I emerged the test-sources you mentioned, with ACCEPT_KEYWORDS="~x86". I then saved my current kernel configuration to a temporary file, changed the /usr/src/linux symlink to point to the new sources, loaded the old config file and changed only the pre-emptive kernel option. I recomplied the kernel in my usual way and rebooted. Unfortunately this was a failure. I first had to disable framebuffer because I saw a black screen only initially. Then it turned out that the kernel boot-up just stopped somewhere in the middle. The last few messages were: "Using local APIC timer interrupts. calibrating APIC timer ... ... CPU clock speed is 2399.xxxx MHz. ... cpu:0, clocks: 0, slice:0" or equivalent.
Next, I tried disabling the pre-emptive kernel option again, but this produced a compilation error, something about an undefined reference to 'atomic_dec_and_lock' I believe...
You should make distclean (which will erase your .config, so back it up) before rebuilding. Can you try disabling apic and acpi in the .config to see if that fixes the freeze at boot.
OK, I had some time available, so I was able to test this immediately. This was much better, but now I have framebuffer problems. Here's what I have done: 1. recreate the /usr/src/linux symlink 2. make distclean 3. reload the old kernel config file from the previous test 4. enable pre-emptive kernel, disable all power managment (both APM & ACPI), disable APIC 5. make dep && make clean bzImage modules modules_install 6. grub boot line: kernel (hd0,11)/boot/bzImage root=/dev/hda13 vga=0x31A video=vesa:ywrap,mtrr hdd=ide-scsi Everything is working now, including nVidia driver & ALSA sound, with one exception. Part of the text that gets written to the console, from no matter which application, is now completely unreadable. I need to press Enter 20 or more times to get the console back. I will try and reboot without the vesa & video options to see what happens, but I don't want to give framebuffer up!
Have you had any more time to test this? If you are still having problems with framebuffer, can you give some more info on what hardware you have, what exactly you are doing to get the described behavior, etc.?
I've had a lot of trouble trying to test it again. Here's what happened. I found out that there was an update to gentoo-test-sources available, so I decided to first emerge that. While doing that I noticed that a lot of dependencies were updated as well. Upon closer examination, my whole base system got updated, including gcc and base-layout, etc. I used "ACCEPT_KEYWORDS="~x86" emerge -uv gentoo-test-sources" I believe. I noticed some peculiarities when loading the old kernel config into "make menuconfig" for the new kernel (the Processor-family, which was Pentium-4, suddenly became something else, can't remember right now which). This was fixed, and after several attempts I again disabled ACPI and APIC (also APM, for that matter). The strange result was that my ethernet would no longer come up. It kept complaining about "disconnected or carrier signal not present" or equivalent. Also, at some point I discovered that the framebuffer problem still existed. Finally, I decided to try and return everything to a stable state, by downgrading packages with "emerge -uv world". However, I can now no longer boot into this particular implementation because of USB detection hanging ("usb bulk control timeout" or something). So I'm writing this from another system. Also, I lost much time because I stumbled upon a bug in the latest "wget" which is reported in Bugzilla now. Finally, my system is built from an ASUS P4S8X Motherboard, Pentium 4 2.4 GHZ, 1GB RAM and an nVidia GeForce TI4200 videocard, which works flawlessly under the latest 2.6 kernel, except that I have disabled pre-emptive kernel there as well (it's a multi-boot sytem).
Created attachment 21020 [details] System config 1 (output from "lscpi -v" under 2.6 kernel)
Created attachment 21021 [details] System config 2: 2.6 Kernel configuration file
Well, I'm back to business again. As a hopefully thorough measure, I decided to do "emerge world --emptytree". This took some 3 hours and now I can boot again. So what would you like me to do next?
Created attachment 21146 [details] Output from "dmesg"
Ok I decided to give it another try, after returning my system to a stable state, as described above. I first emerged the latest test sources with 'ACCEPT_KEYWORDS="~x86" emerge gentoo-test-sources' This gave me r1, this time without updating anything else. So I first changed the /usr/src/linux symlink with "cd /usr/src rm linux ln -s linux-2.4.22-gentoo-r1 linux" Following your earlier suggestion, after "cd linux" I first did a "make distclean" although I don't know whether it was needed. I decided to not use the old kernel config file, so I did a "make menuconfig" from scratch, enabling pre-emptive kernel, disabling all power management (both APM & ACPI), but enabling APIC. Then I compiled a new kernel with "make dep && make clean bzImage modules modules_install", recompiled nVidia & ALSA drivers with "emerge nvidia-kernel emerge nvidia-glx emerge alsa-driver"
is the new kernel working or not? you didn't really say what happened
Yes, the kernel is working, but no, I still have the framebuffer problem.
Open a new bug for the framebuffer issue please
Moving these so we can remove the "Install CD" component from "Gentoo Linux". I apologize to everyone for this spam, but according to the bugzilla developers, this is the only reasonable way to do this.
