Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 227202 - FADT corrupted by acpi-reset-mechanism patch beginning with 2.6.9-42.0.2.EL.
FADT corrupted by acpi-reset-mechanism patch beginning with 2.6.9-42.0.2.EL.
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
i686 Linux
medium Severity low
: ---
: ---
Assigned To: Eric Paris
Brian Brock
: Regression
Depends On:
  Show dependency treegraph
Reported: 2007-02-03 08:47 EST by Dave Gutz
Modified: 2007-11-16 20:14 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-02-14 11:40:09 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
dmesg (15.94 KB, text/plain)
2007-02-03 08:47 EST, Dave Gutz
no flags Details

  None (edit)
Description Dave Gutz 2007-02-03 08:47:59 EST
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):

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
Comment 1 Dave Gutz 2007-02-03 08:47:59 EST
Created attachment 147272 [details]
Comment 2 Konrad Rzeszutek 2007-02-06 16:47:13 EST
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-07 19:15:16 EST
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

Let me know what else I can provide.  Thanks, I think you guys do great work.
Comment 4 Konrad Rzeszutek 2007-02-08 11:09:43 EST
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-08 19:00:50 EST
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 11:40:09 EST
Closing, not a bug.
Comment 8 Konrad Rzeszutek 2007-02-14 14:27:49 EST

No problem. Thanks for working on this and getting to the bottom of the problem.
Comment 9 Dave Gutz 2007-02-16 21:44:49 EST
Replacing the CMOS battery corrected the problem.

Note You need to log in before you can comment on or make changes to this bug.