I'm not sure which component this should be filed against. Probably at least the kernel, but because I haven't changed it very recently, it's more likely to be (also?) somewhere else. Please reassign to a suitable component if you can think of a better one. Today, when booting my FC3 box, I suddenly started receiving this: Initializing hardware... storage network audioKernel panic - not syncing: kernel/sched.c:2781: spin_is_locked on uninitialized spinlock e0a5c7a8 This is kernel 2.6.10-1.741_FC3 i686 on a P4 box. I have had no problems with this kernel earlier, and have not added any modules recently. The panic occurs in /etc/rc.sysinit somewhere. I tried booting with "nomodules", and got the same results (except that then, I saw the "done" and "ok" after "audio" above), so maybe it's not a problem with loading the modules. Recently installed updates include hal-0.4.6-1.FC3 and initscripts-7.93.6-1. Other maybe related things: I have erased the rhgb package a long time ago and removed rhgb from the command line in /etc/grub.conf. I got the above panic some 5 times in a row in subsequent reboots, then left the box alone for half an hour or so, came back and tried booting by adding rhgb to the boot command line in /etc/grub.conf. And... it booted just fine. Then, did a reboot without grub in the command line, and it booted flawlessly again. I'm not going to push my luck by rebooting any more for now unless I really have to... Suggestions? Time to memtest? This box has been running perfectly stable for a couple of years, and no fiddling with h/w has been done recently.
I got it too, but it happened only once until now. rhgb was enabled, and the subsequent reboot went fine. Same kernel and same CPU; so a hardware problem seems very unlikely. The box here is now fully up-to-date, running kernel-2.6.10-1.760_FC3, but has shown no sign of trouble yet -- though unfortunately, this doesn't seem to be easily reproducible.
Created attachment 111240 [details] lspci -v This still happens with 2.6.10-1.766_FC3, but I managed to narrow it down somewhat. When trying to boot having a USB device (tested with a X10 receiver for a ATI Remote Wonder remote controller and a USB keyboard) plugged into a hub that shares IRQ with a Sigma Designs Hollywood+ MPEG decoder card, the panic at boot happens _almost_ always. Not 100%, but I guesstimate something like 95%. If no USB devices are plugged in, there are no problems. Ditto, everything seems to be fine now that I've shuffled PCI cards so that the HW+ and USB stuff never share an IRQ. This setup with HW+ and USB sharing IRQ and USB devices plugged in has worked with no problems noticed before; the first kernel I witnessed problems with was 2.6.10-1.741_FC3. Will attach the output of lspci -v and lsusb -v. Additionally, the current /proc/interrupts is: CPU0 0: 65393843 XT-PIC timer 1: 7 XT-PIC i8042 2: 0 XT-PIC cascade 5: 4790742 XT-PIC saa7146 (0), ohci1394 8: 1 XT-PIC rtc 9: 0 XT-PIC acpi 10: 1580052 XT-PIC ide2, eth1 11: 314586 XT-PIC uhci_hcd, uhci_hcd, eth0 12: 6389228 XT-PIC EMU10K1, em8300 14: 587776 XT-PIC ide0 NMI: 0 ERR: 0 Note that this is with the "fixed" setup. The problems arose when em8300 and uhci_hcd were sharing IRQ's.
Created attachment 111241 [details] lsusb -v
This bug should be fixed by the RHEL4 0day errata's 4/4G split fix. Previously on 3:1 split kernels with the 4/4 split patch applied there was a bug that could leave the kernel page tables inconsistent between processes...
Note that if my guess is right, the bug only hits after X has been started and quit. If the bug is hit without ever starting X, my guess is wrong ;)
In that case, I'm afraid your guess is wrong :(. The panic occurred very early during boot, at the time rc.sysinit loads "other" modules. No X. And I don't have rhgb installed.
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which may contain a fix for your problem. Please update to this new kernel, and report whether or not it fixes your problem. If you have updated to Fedora Core 4 since this bug was opened, and the problem still occurs with the latest updates for that release, please change the version field of this bug to 'fc4'. Thank you.
I have moved on to FC4, and in the meantime, the possible culprit here (the out-of-tree em8300 driver) has got some changes that may have solved this problem. Anyway, I haven't seen this occur in a long time, nor on FC3 or FC4. Will close, and reopen later if I happen to run into it again.