I have a system with a BCM QS754 motherboard and AMD Athlon Tbird
(stepping 02) 700MHz with 128mb pc133 sdram, a 10gb IDE HD (hda), 25gb IDE
HD (hdc), 8x4x32 CD-RW (hdb), and a 52x cdrom (hdd). the system also has
a voodoo3 video card, sb pci64 sound, and a 3com 3c905b nic. The RedHat
6.2 install works perfectly fine on the sytem (installing as a GNOME
workstation). However, on reboot, the kernel panics with the following
CPU: AMD AMD Athlon(tm) Processor stepping 02
Enabling extended fast FPU save and restore...done.
Disabling CPUID Serial number...general protection fault: 0000
eax: 00000020 ebx: 07c3d1d0 ecx: 00000119 edx: 00000001
esi: 00098800 edi: c0106000 ebp: 000001de esp: c0233fc8
ds: 0018 es: 0018 ss: 0018
Process swapper (pid: 0, process nr: 0, stackpage=c0233000)
Stack: c0106000 c02344e2 c02143a0 c01d7d0b c02143a0 c0234c7b 07c3d1d0
07c3d1d0 c03b2e30 c7ff0000 00000000 c0214460 c0100175
Call Trace: [<c0106000>] [<c01d7d0b>] [<c0100175>]
Code: 0f 32 0d 00 00 20 00 0f 30 68 21 78 1d c0 e8 27 fd ed ff 83
Kernel panic: Attempted to kill the idle task!
In swapper task - not syncing
At this point, the system hangs. I've had the almost the identical system
running 6.2, albeit with an AMD K6-2/450 CPU and a BMC Super7 motherboard,
for a while without problem. After installing into the new system, I
installed 6.2 from scratch on the new system. Setup gave no hint of any
problem whatsoever, but upon first reboot, the above message came up. The
first time it happened, I suspected it to be a problem with the CPU, so I
replaced the CPU. The replacement CPU exhibits identical behavior. Any
help on this issue is greatly appreciated... Thanks!
Could you run the oops message through ksymoops on your machine
in order to show the symbol names?
Are you running apmd? If so, try turning it off; that sometimes helps
with broken apm bioses.
Doing anything useful on this machine in particular doesnt seem very likely--
even with a boot disk, the machine wont boot far enough to be able to do
anything. Because of this, I'd be relatively sure that apmd wasn't started
when the crash happened. Also, wouldn't I need access to this unworking
machine to be able to run ksymoops against the dump? Perhaps I am mistaken,
but I thought that basically it would need an identical kernel to the one that
actually produced the dump for its output to be worth anything. If this isn't
the case, I'll happily find another RedHat machine around here and run the dump
through ksymoops. Otherwise... any other ideas?
This is indeed an RH bug. It is fixed in the 2.2.16 errata kernel.
The following has been reported to work:
When Lilo says boot: type:
and it should boot up. Once it is booted, either build a new kernel that
doesn't try to disable the CPUID number or include the "x86_serial_nr=1" flag in
LILO. A longer description follows:
The LILO instructions:
add the following to lilo under the stanza for your kernel:
then run /sbin/lilo to save the change. When the system is rebooted the flag
will be used automatically.
(a more advanced answer is to use the rescue mode to access the installed
partitions, install the i386 kernel version off the cd, edit lilo for the new
version, and chroot and run lilo.)
Similar problem, need help
Installation complete Red Hat 7 on Tecra notebook Pentium I, 64Mb RAM
HD is 2 Gbwith one partition, 32 bit FAT
Deleted this partition then made three per the manual.
Try to run and everything seems to load until I get:
/ was not cleanly unmounted, check forced
Aiee killing interrupt handler
kernel panic attempt kill idle task
in interrupt handler not syncing
Anyone know what I did wrong?
i have redhat linux 7.0 and i ran into the same problem when i messed with
sbin/lilo. was trying to fix mmy memory. what do i do?
I am running Redhat 7.1 and it seems that the kernel still disables reading the
CPUID on boot-up. Even though I have it enabled it in the BIOS settings, still I
can't read the CPU ID. I took everyones advice and added 'append =
"x86_serial_nr=1"' in my lilo.conf file under 'Image = " section and then ran
'lilo -v -v', but that is not helping either.
In the append line, I now have "x86_serial_nr=1, hdb=ide-scsi" - Could that be
the source of the problem?