Bug 227202

Summary: FADT corrupted by acpi-reset-mechanism patch beginning with 2.6.9-42.0.2.EL.
Product: Red Hat Enterprise Linux 4 Reporter: Dave Gutz <davegutz>
Component: kernelAssignee: Eric Paris <eparis>
Status: CLOSED NOTABUG QA Contact: Brian Brock <bbrock>
Severity: low Docs Contact:
Priority: medium    
Version: 4.4CC: jbaron, konradr
Target Milestone: ---Keywords: Regression
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-02-14 16:40:09 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Attachments:
Description Flags
dmesg none

Description Dave Gutz 2007-02-03 13:47:59 UTC
Description of problem:The patch 2.6.9-acpi-reset-mechanism.patch erroneously
writes over the FADT during startup causing the BIOS to reset itself on
subsequent hard boot.


Version-Release number of selected component (if applicable):
kernel.2.6.9-42.0.2.EL 


How reproducible:On my dual boot pc I set the BIOS boot order to begin on the
second hard drive.


Steps to Reproduce:
1.Change BIOS to boot on second hard drive.  Grub is installed on second drive.
2.Bootup on the kernel 9-42.0.2 and shutdown hard.  (won't happen soft)
3.Try to start up again the same way.  The BIOS program will self-correct a
checksum error and not make it to Grub on the second drive.
  
Actual results:
The BIOS program self-corrects a checksum error and boots up on first hard drive.

Expected results:
The BIOS should take no action and bootup on second drive as originally set.

Additional info:

On the first boot with the BIOS changed to second drive, the program tbconvrt.c
is throwing message "BIOS bug: Legacy-free FADT detected, but FADT size (129) is
incorrect!"

Comment 1 Dave Gutz 2007-02-03 13:47:59 UTC
Created attachment 147272 [details]
dmesg

Comment 2 Konrad Rzeszutek 2007-02-06 21:47:13 UTC
How did you come to the conclusion that the patch over-writes the ACPI FADT table?

What machine is this specifically? Are you running the latest BIOS version?

Comment 3 Dave Gutz 2007-02-08 00:15:16 UTC
I went looking for any file containing the text "BIOS bug: Legacy-free FADT
detected, but FADT size (129) is incorrect!" and came up with the patch file. 
This message is the only difference I could see between when the issue happens
and when it does not. 

Below is hardware info.  dmesg is attached.

>cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 3
model name      : Intel(R) Pentium(R) 4 CPU 3.20GHz
stepping        : 3
cpu MHz         : 3200.742
cache size      : 1024 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 5
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe pni monitor ds_cpl cid
bogomips        : 6403.91


The BIOS puts out a message "Default BIOS settings have been loaded due to BIOS
update or checksum issue." This message is put up by an American Megatrends
product (www.ami.com) Revision 3.21 (02/04/04).  There is something about Core
version 08.00.09 (AMIBIOS 8?).   There was nothing available on their website
that I could use to update BIOS.   In their documentation they say the error
message usually can be corrected by entering their setup program.  (?).  I'm
willing to try most anything to help.

The only time I get these messages and this behavior is when booting after
booting the kernel I identified or later.  No problems old kernel.  No problems
WinXP.

Let me know what else I can provide.  Thanks, I think you guys do great work.

Comment 4 Konrad Rzeszutek 2007-02-08 16:09:43 UTC
Let me build you a test kernel without that patch for that specific version and
see if the problem appear.

Comment 6 Dave Gutz 2007-02-09 00:00:50 UTC
I tried the new kernel.  At first it seemed to correct the problem.  Then I
tried a few more times with different way of powering off and now I can get the
problem to happen on any kernel even Windows.   (After powering off, I now press
the power button on the pc chassis to discharge any capacitors.)

I regret any of your time I may have wasted.   Life is too short.

It may be my motherboard battery...anyhow that's my problem...  :-(   Thank you
for the trial kernel.

Regards,  Dave

Comment 7 Eric Paris 2007-02-14 16:40:09 UTC
Closing, not a bug.

Comment 8 Konrad Rzeszutek 2007-02-14 19:27:49 UTC
Dave,

No problem. Thanks for working on this and getting to the bottom of the problem.

Comment 9 Dave Gutz 2007-02-17 02:44:49 UTC
Replacing the CMOS battery corrected the problem.