Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 227202 - FADT corrupted by acpi-reset-mechanism patch beginning with 2.6.9-42.0.2.EL.
Summary: FADT corrupted by acpi-reset-mechanism patch beginning with 2.6.9-42.0.2.EL.
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel
Version: 4.4
Hardware: i686
OS: Linux
medium
low
Target Milestone: ---
: ---
Assignee: Eric Paris
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-02-03 13:47 UTC by Dave Gutz
Modified: 2007-11-17 01:14 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-02-14 16:40:09 UTC
Target Upstream Version:


Attachments (Terms of Use)
dmesg (deleted)
2007-02-03 13:47 UTC, Dave Gutz
no flags Details

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.


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