Distribution: Hardware Environment: Dell PE400SC, same motherboard as Dimension 8000 Software Environment: Kernel 2.6-test4 Problem Description: Everytime I reboot with full ACPI the BIOS option "OS Install Mode" turns on. "OS Install Mode" limits memory to 256MB for NT compatibility. The machine has 1GB memory. I tried APCI HT enum only too. In this case shutdown does not poweroff the machine. Poweroff works with full ACP. Steps to reproduce: Turn on full ACPI under 2.6-test4, reboot on a Dell PE400SC.
Dell PE400SC is 875P based. BIOS version is A02. 2.8Ghz CPU with HT turned on.
I have investigated the poweroff issues, and found that: If you could catch dmesg through serial console, you can find something like: "apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16ac)" "apm: disabled - APM is not SMP safe." "Power down." "Error: pm_power_off =null" Since acpi_power_off is disabled, you have to turn to apm_power_off. But I think you are using SMP kenrel which could break APM. So this kind of poweroff issue is APM issue.It is nothing to do with ACPI. Could you please explian "Everytime I reboot with full ACPI the BIOS option "OS Install Mode" turns on". Could you please catch dmesg which can demonstrate the problem. Thanks a lot.
I am using a SMP kernel and APM is not compiled in. I believe it is defaulted off because of the not safe for SMP issue. In the Dell BIOS screen there is a BIOS option called "OS Install Mode". The help for this states that this is a special mode for installing NT 4.0 that limits RAM to 256MB even if there is more installed. I have this featured disabled. Now I boot a 2.6-test4 kernel with full APCI enabled. The next time I reboot, the "OS Install Mode" will be activated even though I never changed the BIOS settings. Something in the APCI code is turning this option on. If I boot RH9 with 2.4 this does not happen. It does not happen on Windows either.
Also, "OS install mode" does not get enabled on 2.6-test4 if APCI is not compiled it.
Can you confirm that you do not see the limited memory problem when you boot in the HT-only config? (say by using an HT-ONLY config, or booting full ACPI config with the acpi=ht cmdline option? [note, it is normal for ACPI to not poweroff your machine when limited to the HT-ONLY case] Can you confirm that if OS Install Mode is disabled in CMOS before you see the problem, that it is still disabled in CMOS after you see the problem? Can you confirm that you do not see the problem when the kernel has full ACPI configured in, but the cmdline "acpi=off" is used? Please attach the output of dmesg -s40000 for the failure and success cases.
Can you confirm that you do not see the limited memory problem when you boot in the HT-only config? (say by using an HT-ONLY config, or booting full ACPI config with the acpi=ht cmdline option? >> I am picking the HT-ONLY has a kernel build option. HT-ONLY does not trigger the problem. [note, it is normal for ACPI to not poweroff your machine when limited to the HT-ONLY case] Can you confirm that if OS Install Mode is disabled in CMOS before you see the problem, that it is still disabled in CMOS after you see the problem? >> Install Mode is disabled when I boot. On the next reboot it will be enabled. It shows as enable if I enter setup mode. I have to enter setup to disable it and get my RAM back. Can you confirm that you do not see the problem when the kernel has full ACPI configured in, but the cmdline "acpi=off" is used? >> I need to rebuild to do this. I will post when finished. Please attach the output of dmesg -s40000 for the failure and success cases.
Created attachment 786 [details] dmesg output dmesg from boot with HT-ONLY ACPI compiled in.
Created attachment 787 [details] full APCI dmesg, has problem full APCI compiled in. No kernel params. Has problem with 'os install mode'
Created attachment 788 [details] full APCI, acpi-ht, no problem Full APCI compiled in. apci=ht on kernel command line. Does not trigger problem.
I didn't find same problem on PE4400 using 2.6.0-test3. From the problem description, Some data in the CMOS seems to be overidden during reboot cycle. I'm curious how it could happen. Did you see same symptom before? Thanks for your input!
Here is another report of the same problem: http://sourceforge.net/mailarchive/forum.php?thread_id=2638363&forum_id=7803 Dimension 8300 and PE400SC have the same motherboard. I don't think a Dell PE4400 has anything in common with PE400SC. PE400SC is very new machine based on i875P chipset 800Mhz FSB, Dual channel RAM. ICH5 Ethernet, etc. With full ACPI enabled the problem happens on every reboot. It is trivial to reproduce. Link to Dell for machine: http://configure.us.dell.com/dellstore/config.aspx?cs=04&oc=PE400SC&m_1=432SC&m_8=40GB&m_27=MIDE&c=us&l=en&kc=6W463
ACPI seems to be just enabling interrupts, so lets see if skipping that avoids the problem. Can you boot full ACPI config with "pci=noacpi" and then with "noapic" and see if CMOS gets tubed or not? Also, Please attach the output from dmidecide, available in /usr/sbin/, or here: http://www.nongnu.org/dmidecode/ And Please attach the output from acpidmp, available in /usr/sbin/, or in here http://www.intel.com/technology/iapc/acpi/downloads/pmtools-20010730.tar.gz
I need dmesg of kernel reboot. Since the issue will happen right after kernel rebooting. So some clues could be shown there. Did you try poweroff instead of reboot. Does same symptom appears?
Created attachment 800 [details] acpidmp
Created attachment 801 [details] dmidecode I can do more this evening when I have more time
On kernel with full APCI compiled in: booted with pci=noacpi -- has problem booted with noapic -- has problem booted with no param, hit reset button -- has problem The BIOS is get changed during power on. The test with the reset button never let shutdown or reboot code run.
Thanks for running the tests Jon. Looks like something to do with booting ACPI updates your CMOS, but that something is not table parsing or interrupt configuration. Time to lop off functions to find the guilty party... To start, please config-out all of the optional ACPI drivers CONFIG_ACPI_FAN, BATTERY etc. go ahead and attach the resulting .config so I can confirm or if you're using all loadable modules, move /lib/modules/<version>/kernel/drivers/acpi away. If that has no effect, then we need to do some surgery on the acpi core. we'll cook up a patch for ACPI to first ignore your SSDT, and then you DSDT. If that has no effect, then we've eliminated all the AML, which leaves only the fixed function stuff in the FADT.
moved away ACPI modules and still have problem. none were getting loaded anyway.
Created attachment 810 [details] Dmesg with APCI debug compiled in, failure mode
Is there /proc/acpi/alarm? In drivers/acpi/sleep/proc.c, you can find many calls to CMOS_WRITE. If ACPI really causes problem, would you please try below patch : --- /usr/src/andy.2.5/drivers/acpi/sleep/proc.c 2003-09-02 15:03:04.000000000 +0800 +++ /usr/src/andy.2.5/drivers/acpi/sleep/proc.c.1 2003-09-04 14:04:51.000000000 +0800 @@ -205,6 +205,7 @@ size_t count, loff_t *ppos) { +#if 0 int result = 0; char alarm_string[30] = {'\0'}; char *p = alarm_string; @@ -359,6 +360,8 @@ result = 0; end: return_VALUE(result ? result : count); +#endif + return 0 } If the problem is still there, you have to find out the OS Install flag address in CMOS, and intercept call to CMOS_WRITE to verify if there are address conflicit with OS Install flag. thanks a lot.
Is there a program to dump the CMOS? I could dump it, trigger the problem, dump and diff. I do not have a /proc/acpi/alarm. [root@smirl acpi]# [root@smirl acpi]# ls debug_layer debug_level dsdt embedded_controller event fadt info power_resource [root@smirl acpi]# ls embedded_controller [root@smirl acpi]# ls power_resource [root@smirl acpi]# cat debug_layer 0xffff3fff [root@smirl acpi]# cat debug_level 0x0000000f [root@smirl acpi]# cat info version: 20030813 [root@smirl acpi]#
Dell just put PE400SC on special. $598 with 3.2Ghz P4, 800Mhz FSB, i875P, AGP 8x $398 with 2.8Ghz P4 How can you lose? You can't even buy the processors for what Dell is charging for this system. http://www.slickdeals.net/forums/showthread.php?s=&threadid=2071
I tried calling Dell to find out which bit in CMOS controls 'OS Install Mode'. I couldn't get through to anyone who knew what I was talking about. This may require someone with an OEM relation to Dell to call.
Would you please configure char/nvram into kernel, and do "cat /proc/driver/nvram and /proc/driver/rtc " to see what's unusual. I don't think "OS Install mode" flag can be found from /proc/driver/nvram, but some clues could be found there. At least we can judge whether standard nvram has been messed up. Another point is we could enlarge NVRAM_BYTE to access more CMOS flag . (including OS Install mode flag). Thanks a lot.
Created attachment 900 [details] cat /proc/driver/nvram
Created attachment 901 [details] cat /proc/driver/rtc
The motherboard in the PE400SC is an OEM product manufactured by Intel.
Created attachment 944 [details] patch for catching overlay port Would you please try this patch to see whether ACPI try to write ports belongs to CMOS. And please attach dmesg. thanks a lot.
Created attachment 948 [details] Dmesg trace with overlay patch installed, failure mode
try in acpi/osl.c 'acpi_os_read_port' add: > *value = 0; what did it happen? As I know, SBF may change CMOS, try mask off module of 'arch/i386/kernel/bootflag.c'.
I mean to add the line above the switch statement.
I'm in a no win situation with this bug. I just added SATA drives to my machine. The SATA interrupt will only get configured if full APCI is turned on. Of course turning on full ACPI causes the OS Install problem. Now everytime the machine is rebooted it needs manual intervention to reset OS Install mode. BTW, this is an OEM Intel motherboard. Would it be easier to get the BIOS info from them that trying to get it from Dell?
This problem has been fixed by Dell/Intel in the latest AO3 BIOS for the PE400SC