Red Hat Bugzilla – Bug 15532
General Protection Fault trying to dissable CPUID serial no on AMD Duron
Last modified: 2008-05-01 11:37:57 EDT
I have a Duron 650CPU running on an ASUS A7V with 384MB pc133 RAM,
AHA2940UW PCI SCSI, PCI NIC (runs ok in RH6.2) ATI RAGE FURY 128PRO
(causes crashes when auto probe during install) and Guillemot MAXI sound
PCI (Yamaha XG based).
I can install 6.2 (text mode due to ATI card) on my ID8 SCSI drive
perfectly ok. When the system reboots after LILO, it gives me a general
protection fault trying to disable the CPUID serial no (as if it was a
P3). It reports some registers and causes a kernel panic.
This is 100% CPU related and it also happens with the latest ATHLON
(socketA, aka Thunderbird).
A kernel fix should do, but you know better.
Obivously we cannot load linux so the problem is terminal and needs of
Thank you and keep up the good work.
I have exactly the same problem with Duron 600 and Gigabyte 7zx-1.
After some investigation I found a solution (see at the end).
It seems the problem has 2 origins
-bit 18 of EDX from CPUID 0x80000001 is set on Duron (with meaning ???), and
unfortunately this is "serial number ID capability" on PIII.
-the PIII patch used by redhat :
there is a test against bit 18 from CPUID, whereas in in the mainstream kernel
(I checked on 2.4.0-test5) the test is :
Vendor == INTEL (and transmeta also..) AND bit 18 is set.
Luckily :-) this patch authorize keeping serial number :
adding "x86_serial_nr=1" on lilo prompt worked like a charm...
Anyway checking for Vendor ID should be cool.
Note : there is also a minor problem with duron : L2 cache is reported as zero
(this is a duron bug, even if AMD changed the meaning of the registers).
Once you have booted with x86_serial_nr=1 upgrade to the latest kernel as this has been fixed (either intentionally or otherwise !!).
I would be interested in knowing if you are able to recompile the kernel as my Duron 600 / MSI 6340 motherboard combination hangs everytime. I've
changed out everything on my system (memory, motherboard, graphics card, hard drive, etc) except the processsor and still get the same result. I've
used a windows based CPU burn program for > 24 hours without ant problems and I am able to recompile other stuff. I have seen this raised as a bug
report but the response was less than helpful. I will raise this as a seperate report in the meantime.
The errata kernel solves this problem and the pinstripe beta kernel was also
tested and verified to solve this problem.