Bug 15532

Summary:	General Protection Fault trying to dissable CPUID serial no on AMD Duron
Product:	[Retired] Red Hat Linux	Reporter:	Need Real Name <otheos>
Component:	lilo	Assignee:	Michael K. Johnson <johnsonm>
Status:	CLOSED ERRATA	QA Contact:
Severity:	high	Docs Contact:
Priority:	medium
Version:	6.2	CC:	jducourt, kevin.smith
Target Milestone:	---
Target Release:	---
Hardware:	i686
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2000-09-01 07:43:24 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Need Real Name 2000-08-06 01:39:12 UTC

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 
immediate attention.

Thank you and keep up the good work.

Comment 1 jducourt 2000-08-08 15:38:27 UTC

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).

Comment 2 Kevin 2000-09-01 07:43:23 UTC

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.

Comment 3 Doug Ledford 2000-09-02 02:12:54 UTC

The errata kernel solves this problem and the pinstripe beta kernel was also
tested and verified to solve this problem.