Bug 7913
Summary: | Default BIOS settings have been loaded due to BIOS CMOS update or checksum issue. - BIOS bug: Legacy-free FADT detected, but FADT size (129) is incorrect! | ||
---|---|---|---|
Product: | ACPI | Reporter: | Dave Gutz (davegutz) |
Component: | BIOS | Assignee: | acpi_bios |
Status: | REJECTED INVALID | ||
Severity: | low | CC: | acpi-bugzilla, hilrie |
Priority: | P2 | ||
Hardware: | i386 | ||
OS: | Linux | ||
Kernel Version: | kernel.2.6.9-42.0.2.EL | Subsystem: | |
Regression: | --- | Bisected commit-id: | |
Attachments: | output of dmesg on 020107 |
Description
Dave Gutz
2007-01-31 18:05:04 UTC
Please boot Linux with "acpi=off" and see if the issue goes away. If it doesn't, then by definition, this is not a bug in the Linux kernel ACPI support. > Well with kernel 2.6.9-34.0.2.EL some disk > - not sure which - is found to fail a test - see the dmesg output attached. Exactly what failure do you refer to? I don't see one. > The kernel attempts to correct this somehow, I think by writing to the boot > sector. Then on restart, ACPI detects a change and reloads default boot > order, booting on the Windows disk - eeeegaaaads. No, I don't think Linux is writing to the boot sector. Do you see a message from the BIOS on reset about an invalid CMOS checksum and resetting to defaults? > Won't fit here note that bugzilla accepts attachments -- which is a preferable way to put a dmesg in a bug report vs pasting it into the text. BTW. it appears you are running a uni-processor kernel on an SMP -- why? Created attachment 10250 [details]
output of dmesg on 020107
------- Additional Comments From len.brown@intel.com 2007-01-31 19:04 ------- >>Please boot Linux with "acpi=off" and see if the issue goes away. >>If it doesn't, then by definition, this is not a bug in >>the Linux kernel ACPI support. I don't know if ACPI is off the hook. The result of booting "acpi=off" is as follows: kernel panic. The workstation locks up and flashes codes on the keyboard. Repeating with an earlier kernel there is no effect of acpi=off. Recognizing that I'm a novice with BIOS issues, it still acts like the kernel is finding a problem in MBR and writing a correction. With acpi back on, it reboots ok with error message thrown in dmesg (search 'BIOS bug'). > > Well with kernel 2.6.9-34.0.2.EL some disk > > - not sure which - is found to fail a test - see the dmesg output attached. >Exactly what failure do you refer to? I don't see one. Please search for 'BIOS bug' in dmesg. > > The kernel attempts to correct this somehow, I think by writing to the boot > > sector. Then on restart, ACPI detects a change and reloads default boot > > order, booting on the Windows disk - eeeegaaaads. >No, I don't think Linux is writing to the boot sector. It acts like it to a casual observer. This doesn't mean it is. >Do you see a message from the BIOS on reset about an invalid CMOS >checksum and resetting to defaults? Yes I do. The exact words are: 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). I have a screen shot from digital camera if you need it. > > Won't fit here >note that bugzilla accepts attachments -- which is a preferable >way to put a dmesg in a bug report vs pasting it into the text. I attached it this time to make it easier for you to search for the message 'BIOS bug' >>BTW. it appears you are running a uni-processor kernel on an SMP -- why? When I installed, I asked for nearly everything to be installed. The machine is a uni-processor. I manually modified GRUB to only boot the single CPU kernel because it was trying to boot up on SMP by default. My impression was that, for some reason, having everything installed sets some switches to SMP mode. For example, irqbalance is on after this type of install even booting on the signel CPU kernel and I have to go 'uncheck' it to prevent an apparently harmless error message on shutdown. This same install thing happened on another pc I have - single CPU e-machine athlon. With kernel updates, the emachine does not have the BIOS activity that we're talking about. It also is not a dual boot setup. I could get some bootup info off that one if you're interested. > BIOS bug: Legacy-free FADT detected, but FADT size (129) is incorrect! This error message does not appear in Linux-2.6.9 and does not appear in the latest from kernel.org, Linux-2.6.19. If it bothers you, you need to take that up with bugzilla.redhat.com for you are running their kernel (2.6.9-42.0.2.EL) > Default BIOS settings have been loaded due to > BIOS update or checksum issue. It appears that something is corrupting the CMOS when you boot Linux. If this is reproducible with the latest upstream kernel from kernel.org, then please re-open this bug. |