BUG: linux 2.6.19 unable to enable acpi

BUG: linux 2.6.19 unable to enable acpi

[Matheus Izvekov]

Just tried linux for the first time on this old machine, and i got
this problem. dmesg below:

Linux version 2.6.19 (root@localhost) (gcc version 4.1.1 (Gentoo
4.1.1-r3)) #10 PREEMPT Sun Dec 10 17:35:24 BRST 2006
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000dc000 - 00000000000e0000 (reserved)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000000fdf0000 (usable)
 BIOS-e820: 000000000fdf0000 - 000000000fdf8000 (ACPI data)
 BIOS-e820: 000000000fdf8000 - 000000000fe00000 (ACPI NVS)
 BIOS-e820: 00000000ffef0000 - 00000000fff00000 (reserved)
 BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
253MB LOWMEM available.
Entering add_active_range(0, 0, 65008) 0 entries of 256 used
Zone PFN ranges:
  DMA             0 ->     4096
  Normal       4096 ->    65008
early_node_map[1] active PFN ranges
    0:        0 ->    65008
On node 0 totalpages: 65008
  DMA zone: 32 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 4064 pages, LIFO batch:0
  Normal zone: 475 pages used for memmap
  Normal zone: 60437 pages, LIFO batch:15
DMI 2.2 present.
ACPI: RSDP (v000 AMI                                   ) @ 0x000fb080
ACPI: RSDT (v001 AMIINT          0x00000000 MSFT 0x00000097) @ 0x0fdf0000
ACPI: FADT (v001 AMIINT          0x00000000 MSFT 0x00000097) @ 0x0fdf0030
ACPI: DSDT (v001    SiS      620 0x00001000 MSFT 0x0100000a) @ 0x00000000
ACPI: PM-Timer IO Port: 0x408
Allocating PCI resources starting at 10000000 (gap: 0fe00000:f00f0000)
Detected 300.701 MHz processor.
Built 1 zonelists.  Total pages: 64501
Kernel command line: root=/dev/sda3
Local APIC disabled by BIOS -- you can enable it with "lapic"
mapped APIC to ffffd000 (01201000)
Initializing CPU#0
CPU 0 irqstacks, hard=c039e000 soft=c039d000
PID hash table entries: 1024 (order: 10, 4096 bytes)
Console: colour VGA+ 80x25
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 254172k/260032k available (1868k kernel code, 5368k reserved,
603k data, 180k init, 0k highmem)
virtual kernel memory layout:
    fixmap  : 0xfffb7000 - 0xfffff000   ( 288 kB)
    vmalloc : 0xd0800000 - 0xfffb5000   ( 759 MB)
    lowmem  : 0xc0000000 - 0xcfdf0000   ( 253 MB)
      .init : 0xc036b000 - 0xc0398000   ( 180 kB)
      .data : 0xc02d3086 - 0xc0369fa8   ( 603 kB)
      .text : 0xc0100000 - 0xc02d3086   (1868 kB)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 601.79 BogoMIPS (lpj=300897)
Security Framework v1.0.0 initialized
Mount-cache hash table entries: 512
CPU: After generic identify, caps: 0080f9ff 00000000 00000000 00000000
00000000 00000000 00000000
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 512K
CPU: After all inits, caps: 0080f9ff 00000000 00000000 00000040
00000000 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: Intel Pentium II (Klamath) stepping 03
Checking 'hlt' instruction... OK.
ACPI: Core revision 20060707
ACPI: setting ELCR to 0200 (from 1c00)
ACPI Error (hwacpi-0179): Hardware did not change modes [20060707]
ACPI Error (evxfevnt-0084): Could not transition to ACPI mode [20060707]
ACPI Warning (utxface-0154): AcpiEnable failed [20060707]
ACPI: Unable to enable ACPI

Re: BUG: linux 2.6.19 unable to enable acpi

[Arjan van de Ven]

On Wed, 2007-01-17 at 02:01 -0200, Matheus Izvekov wrote:
> Just tried linux for the first time on this old machine, and i got
> this problem. dmesg below:


did this machine EVER support acpi ?

Re: BUG: linux 2.6.19 unable to enable acpi

[Matheus Izvekov]

On 1/17/07, Arjan van de Ven <arjan@infradead.org> wrote:
> On Wed, 2007-01-17 at 02:01 -0200, Matheus Izvekov wrote:
> > Just tried linux for the first time on this old machine, and i got
> > this problem. dmesg below:
>
>
> did this machine EVER support acpi ?
>
>

It used to support power button events, dont know what else. Is there
anything I can do to check how good the acpi support is?

Re: BUG: linux 2.6.19 unable to enable acpi

[Luming Yu]

On 1/17/07, Matheus Izvekov <mizvekov@gmail.com> wrote:
> On 1/17/07, Arjan van de Ven <arjan@infradead.org> wrote:
> > On Wed, 2007-01-17 at 02:01 -0200, Matheus Izvekov wrote:
> > > Just tried linux for the first time on this old machine, and i got
> > > this problem. dmesg below:
> >
> >
> > did this machine EVER support acpi ?
> >
> >
>
> It used to support power button events, dont know what else. Is there
> anything I can do to check how good the acpi support is?

Did you check BIOS setting? Is there any ACPI related menuitems?
Does MS windows work?
Have you ever tried other kernel  i.e. 2.6.18, 2.6.17, 2.6.16..?

Re: BUG: linux 2.6.19 unable to enable acpi

[Matheus Izvekov]

On 1/17/07, Luming Yu <luming.yu@gmail.com> wrote:
> On 1/17/07, Matheus Izvekov <mizvekov@gmail.com> wrote:
> > It used to support power button events, dont know what else. Is there
> > anything I can do to check how good the acpi support is?
>
> Did you check BIOS setting? Is there any ACPI related menuitems?
No ACPI related menuitems, just APM ones, which are disabled.
> Does MS windows work?

Yes, but i dont have it anymore to check how acpi was working there.
But that is yes for sure, i could turn it off with the power button.

> Have you ever tried other kernel  i.e. 2.6.18, 2.6.17, 2.6.16..?
>

No, but ill try if it proves to be necessary.

Re: BUG: linux 2.6.19 unable to enable acpi

[Matheus Izvekov]

[-- Attachment #1: Type: text/plain, Size: 98 bytes --]

I just tried the firmwarekit, and here are the results, attached.
TYVM, thats a very useful tool.

[-- Attachment #2: results.xml --]
[-- Type: text/xml, Size: 9719 bytes --]

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet href="results.css" type="text/css"?>
<results>
<test>
	<id>apicedge</id>
	<name>(experimental) APIC Edge/Level check</name>
	<result>4</result>
 
	<description>This test checks if legacy interrupts are edge and PCI interrupts are level</description>
	<detail>
		<summary>Non-Legacy interrupt 0 is incorrectly level triggered</summary>
		<result>4</result>
		<uri>interrupts://</uri>
				<data>  0:      22353    XT-PIC-XT        timer
</data>
	</detail>
	<detail>
		<summary>Non-Legacy interrupt 1 is incorrectly level triggered</summary>
		<result>4</result>
		<uri>interrupts://</uri>
				<data>  1:          9    XT-PIC-XT        i8042
</data>
	</detail>
	<detail>
		<summary>Non-Legacy interrupt 2 is incorrectly level triggered</summary>
		<result>4</result>
		<uri>interrupts://</uri>
				<data>  2:          0    XT-PIC-XT        cascade
</data>
	</detail>
	<detail>
		<summary>Non-Legacy interrupt 8 is incorrectly level triggered</summary>
		<result>4</result>
		<uri>interrupts://</uri>
				<data>  8:          0    XT-PIC-XT        rtc
</data>
	</detail>
	<detail>
		<summary>Non-Legacy interrupt 10 is incorrectly level triggered</summary>
		<result>4</result>
		<uri>interrupts://</uri>
				<data> 10:         51    XT-PIC-XT        ohci_hcd:usb1
</data>
	</detail>
</test>
<test>
	<id>microcode</id>
	<name>Processor microcode update</name>
	<result>4</result>
 
	<description>This test verifies if the firmware has put a recent version of the microcode into the processor at boot time. Recent microcode is important to have all the required features and errata updates for the processor.</description>
	<detail>
		<summary>Cpu cpu0 has outdated microcode (version 34 while version 36 is available)</summary>
		<result>4</result>
		<uri></uri>
			</detail>
</test>
<test>
	<id>FADT</id>
	<name>FADT test</name>
	<result>4</result>
 
	<description>verify FADT SCI_EN bit enabled or NOT.</description>
	<detail>
		<summary>E820: XSDT (0x2ed382e9) is not in reserved or ACPI memory!</summary>
		<result>4</result>
		<uri>e820://</uri>
			</detail>
	<detail>
		<summary>Legacy mode, SCI_EN bit in PM1a_Control register is incorrectly Disabled</summary>
		<result>4</result>
	</detail>
	<detail>
		<summary>E820: XSDT (0x2ed382e9) is not in reserved or ACPI memory!</summary>
		<result>4</result>
		<uri>e820://</uri>
			</detail>
</test>
<test>
	<id>mtrr</id>
	<name>MTRR validation</name>
	<result>4</result>
 
	<description>This test validates the MTRR setup against the memory map to detect any inconsistencies in cachability.</description>
	<detail>
		<summary>Memory range 0x100000 to 0xfdeffff (System RAM) has incorrect attribute default </summary>
		<result>4</result>
		<uri>mtrr://System RAM</uri>
				<data>Memory range 0x100000 to 0xfdeffff (System RAM) has incorrect attribute default </data>
	</detail>
</test>
<test>
	<id>mcfg</id>
	<name>MCFG PCI Express* memory mapped config space</name>
	<result>4</result>
 
	<description>This test tries to validate the MCFG table by comparing the first 16 bytes in the MMIO mapped config space with the 'traditional' config space of the first PCI device (root bridge). The MCFG data is only trusted if it is marked reserved in the E820 table.</description>
	<detail>
		<summary>E820: XSDT (0x2ed382e9) is not in reserved or ACPI memory!</summary>
		<result>4</result>
		<uri>e820://</uri>
			</detail>
	<detail>
		<summary>No MCFG ACPI table found. This table is required for PCI Express*.</summary>
		<result>2</result>
	</detail>
</test>
<test>
	<id>edd</id>
	<name>EDD Boot disk hinting</name>
	<result>4</result>
 
	<description>This test verifies if the BIOS directs the operating system on which storage device to use for booting (EDD information). This is important for systems that (can) have multiple disks. Linux distributions increasingly depend on this info to find out on which device to install the bootloader.</description>
	<detail>
		<summary>Boot device 0x80 does not support EDD
</summary>
		<result>4</result>
		<uri></uri>
			</detail>
</test>
<test>
	<id>pciresource</id>
	<name>Validate assigned PCI resources</name>
	<result>4</result>
 
	<description>This test is currently a placeholder and just checks the kernel log for complaints about PCI resource errors. In the future the idea is to actually perform a validation step on all PCI resources against a certain rule-set.</description>
	<detail>
		<summary>Device 0000:01:00.0 has incorrect resources</summary>
		<result>4</result>
		<uri>pci://0000:01:00.0</uri>
				<data>PCI: Ignore bogus resource 6 [0:0] of 0000:01:00.0</data>
	</detail>
</test>
<test>
	<id>thermal_trip</id>
	<name>ACPI passive thermal trip points</name>
	<result>2</result>
 
	<description>This test determines if the passive trip point works as expected.</description>
	<detail>
		<summary>Cannot test trip points without existing /proc/acpi/thermal_zone.</summary>
		<result>2</result>
		<uri></uri>
			</detail>
</test>
<test>
	<id>cpufreq</id>
	<name>CPU frequency scaling tests</name>
	<result>2</result>
 
	<description>For each processor in the system, this test steps through the various frequency states (P-states) that the BIOS advertises for the processor. For each processor/frequency combination, a quick performance value is measured. The test then validates that: 
  1) Each processor has the same number of frequency states
  2) Higher advertised frequencies have a higher performance
  3) No duplicate frequency values are reported by the BIOS
  4) Is BIOS wrongly doing Sw_All P-state coordination across cores
  5) Is BIOS wrongly doing Sw_Any P-state coordination across cores
</description>
	<detail>
		<summary>Frequency scaling not supported</summary>
		<result>2</result>
		<uri></uri>
			</detail>
</test>
<test>
	<id>virt</id>
	<name>VT/VMX Virtualization extensions</name>
	<result>1</result>
 
	<description>This test checks if VT/VMX is set up correctly</description>
	<detail>
		<summary>Processor does not support Virtualization extensions</summary>
		<result>1</result>
		<uri></uri>
			</detail>
</test>
<test>
	<id>acpiinfo</id>
	<name>General ACPI information</name>
	<result>1</result>
 
	<description>This test checks the output of the in-kernel ACPI CA against common error messages that indicate a bad interaction with the bios, including those that point at AML syntax errors.</description>
	<detail>
		<summary>DSDT was compiled by the Microsoft AML compiler</summary>
		<result>1</result>
		<data>ACPI: DSDT (v001    SiS      620 0x00001000 MSFT 0x0100000a) @ 0x00000000</data>
	</detail>
</test>
<test>
	<id>maxreadreq</id>
	<name>PCI Express MaxReadReq tuning</name>
	<result>0</result>
 
	<description>This test checks if the firmware has set MaxReadReq to a higher value on non-montherboard devices</description>
</test>
<test>
	<id>os2gap</id>
	<name>OS/2 memory hole test</name>
	<result>0</result>
 
	<description>This test checks if the OS/2 15Mb memory hole is absent</description>
</test>
<test>
	<id>dmi</id>
	<name>DMI information check</name>
	<result>0</result>
 
	<description>This test checks the DMI/SMBIOS tables for common errors.</description>
</test>
<test>
	<id>chk_hpet</id>
	<name>HPET configuration test</name>
	<result>0</result>
 
	<description>This test checks the HPET PCI BAR for each timer block in the timer.The base address is passed by the firmware via an ACPI table.IRQ routing and initialization is also verified by the test.
</description>
</test>
<test>
	<id>fan</id>
	<name>Fan tests</name>
	<result>0</result>
 
	<description>This test reports how many fans there are in the system. It also checks for the states of the fan.</description>
	<detail>
		<summary>No fan information present</summary>
		<result>1</result>
		<uri></uri>
			</detail>
</test>
<test>
	<id>battery</id>
	<name>Battery tests</name>
	<result>0</result>
 
	<description>This test reports which (if any) batteries there are in the system. In addition, for charging or discharging batteries, the test validates that the reported 'current capacity' properly increments/decrements in line with the charge/discharge state. 

This test also stresses the entire battery state reporting codepath in the ACPI BIOS, and any warnings given by the ACPI interpreter will be reported.</description>
	<detail>
		<summary>No battery information present</summary>
		<result>1</result>
		<uri></uri>
			</detail>
</test>
<test>
	<id>ethernet</id>
	<name>Ethernet functionality</name>
	<result>0</result>
 
	<description>This test is currently a placeholder for a more advanced ethernet test. Currently the only check performed is that a link is acquired within 45 seconds of enabling the interface. 45 seconds is close to the value most Linux distributions use as timeout value.

In the future the plan is to also perform actual data transfer tests as part of the ethernet test, to validate interrupt routing and other per-NIC behaviors.</description>
</test>
<test>
	<id>acpicompile</id>
	<name>DSDT AML verification</name>
	<result>0</result>
 
	<description>This test first disassembles the DSDT of the BIOS, and then uses the IASL compiler from Intel to recompile the code. The IASL copiler is much stricter in detecting deviations from the ACPI specification and can find numerous defects that other AML compilers cannot find. Fixing these defects increases the probability that the BIOS will operate well with a variety of operating systems.</description>
	<detail>
		<summary>Tested table DSDT.dsl</summary>
		<result>0</result>
		<uri></uri>
			</detail>
	<detail>
		<summary>Tested _SUN ids; successfully found no duplicates</summary>
		<result>0</result>
		<uri></uri>
			</detail>
</test>
</results>

Re: BUG: linux 2.6.19 unable to enable acpi

[Len Brown]

The code that enables ACPI mode hasn't really changed since before 2.6.12 -- 
unless udelay() has changed beneath us...
So if you are going to test an old version of Linux, you should start before then.

Perhaps you can try this debug patch on top of 2.6.19 and send along the dmesg?
(also, please include CONFIG_ACPI_DEBUG=y)

thanks,
-Len



diff --git a/drivers/acpi/hardware/hwacpi.c b/drivers/acpi/hardware/hwacpi.c
index de50fab..c782da3 100644
--- a/drivers/acpi/hardware/hwacpi.c
+++ b/drivers/acpi/hardware/hwacpi.c
@@ -119,6 +119,9 @@ acpi_status acpi_hw_set_mode(u32 mode)
 	 * we make sure both the numbers are zero to determine these
 	 * transitions are not supported.
 	 */
+printk("ACPI: FADT.acpi_enable %d\n", acpi_gbl_FADT->acpi_enable);
+printk("ACPI: FADT.acpi_disable %d\n", acpi_gbl_FADT->acpi_disable);
+
 	if (!acpi_gbl_FADT->acpi_enable && !acpi_gbl_FADT->acpi_disable) {
 		ACPI_ERROR((AE_INFO,
 			    "No ACPI mode transition supported in this system (enable/disable both zero)"));
@@ -130,6 +133,9 @@ acpi_status acpi_hw_set_mode(u32 mode)
 
 		/* BIOS should have disabled ALL fixed and GP events */
 
+printk("ACPI: smi_cmd 0x%x, acpi_enable 0x%x\n",
+	acpi_gbl_FADT->smi_cmd, (u32) acpi_gbl_FADT->acpi_enable);
+
 		status = acpi_os_write_port(acpi_gbl_FADT->smi_cmd,
 					    (u32) acpi_gbl_FADT->acpi_enable,
 					    8);
@@ -164,7 +170,7 @@ acpi_status acpi_hw_set_mode(u32 mode)
 	 * Some hardware takes a LONG time to switch modes. Give them 3 sec to
 	 * do so, but allow faster systems to proceed more quickly.
 	 */
-	retry = 3000;
+	retry = 3000 * 100;
 	while (retry) {
 		if (acpi_hw_get_mode() == mode) {
 			ACPI_DEBUG_PRINT((ACPI_DB_INFO,
@@ -175,6 +181,7 @@ acpi_status acpi_hw_set_mode(u32 mode)
 		acpi_os_stall(1000);
 		retry--;
 	}
+printk("ACPI: retry %d\n");
 
 	ACPI_ERROR((AE_INFO, "Hardware did not change modes"));
 	return_ACPI_STATUS(AE_NO_HARDWARE_RESPONSE);

Re: BUG: linux 2.6.19 unable to enable acpi

[Matheus Izvekov]

On 1/17/07, Len Brown <lenb@kernel.org> wrote:
> The code that enables ACPI mode hasn't really changed since before 2.6.12 --
> unless udelay() has changed beneath us...
> So if you are going to test an old version of Linux, you should start before then.
>
> Perhaps you can try this debug patch on top of 2.6.19 and send along the dmesg?
> (also, please include CONFIG_ACPI_DEBUG=y)
>
> thanks,
> -Len

Tried that, dmesg output below:

DMI 2.2 present.
ACPI: RSDP (v000 AMI                                   ) @ 0x000fb080
ACPI: RSDT (v001 AMIINT          0x00000000 MSFT 0x00000097) @ 0x0fdf0000
ACPI: FADT (v001 AMIINT          0x00000000 MSFT 0x00000097) @ 0x0fdf0030
ACPI: DSDT (v001    SiS      620 0x00001000 MSFT 0x0100000a) @ 0x00000000
ACPI: PM-Timer IO Port: 0x408
Allocating PCI resources starting at 10000000 (gap: 0fe00000:f00f0000)
Detected 300.683 MHz processor.
Built 1 zonelists.  Total pages: 64501
Kernel command line: root=/dev/sda3
Initializing CPU#0
CPU 0 irqstacks, hard=c038f000 soft=c038e000
PID hash table entries: 1024 (order: 10, 4096 bytes)
Console: colour VGA+ 80x25
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 254268k/260032k available (1818k kernel code, 5268k reserved,
611k data, 160k init, 0k highmem)
virtual kernel memory layout:
    fixmap  : 0xffff8000 - 0xfffff000   (  28 kB)
    vmalloc : 0xd0800000 - 0xffff6000   ( 759 MB)
    lowmem  : 0xc0000000 - 0xcfdf0000   ( 253 MB)
      .init : 0xc0361000 - 0xc0389000   ( 160 kB)
      .data : 0xc02c6be6 - 0xc035fa28   ( 611 kB)
      .text : 0xc0100000 - 0xc02c6be6   (1818 kB)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 602.00 BogoMIPS (lpj=3010033)
Security Framework v1.0.0 initialized
Mount-cache hash table entries: 512
CPU: After generic identify, caps: 0080f9ff 00000000 00000000 00000000
00000000 00000000 00000000
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 512K
CPU: After all inits, caps: 0080f9ff 00000000 00000000 00000040
00000000 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: Intel Pentium II (Klamath) stepping 03
Checking 'hlt' instruction... OK.
ACPI: Core revision 20060707
 tbxface-0107 [01] load_tables           : ACPI Tables successfully acquired
Parsing all Control Methods:
Table [DSDT](id 0005) - 259 Objects with 25 Devices 99 Methods 13 Regions
ACPI Namespace successfully loaded at root c03a49f0
ACPI: setting ELCR to 8000 (from 1c00)
ACPI: FADT.acpi_enable 225
ACPI: FADT.acpi_disable 30
ACPI: smi_cmd 0x435, acpi_enable 0xe1
ACPI: retry 142
ACPI Error (hwacpi-0185): Hardware did not change modes [20060707]
ACPI Error (evxfevnt-0084): Could not transition to ACPI mode [20060707]
ACPI Warning (utxface-0154): AcpiEnable failed [20060707]
ACPI: Unable to enable ACPI

Re: BUG: linux 2.6.19 unable to enable acpi

[Len Brown]

On Wednesday 17 January 2007 16:10, Matheus Izvekov wrote:
> On 1/17/07, Len Brown <lenb@kernel.org> wrote:
> > The code that enables ACPI mode hasn't really changed since before 2.6.12 --
> > unless udelay() has changed beneath us...
> > So if you are going to test an old version of Linux, you should start before then.
> >
> > Perhaps you can try this debug patch on top of 2.6.19 and send along the dmesg?
> > (also, please include CONFIG_ACPI_DEBUG=y)
> >
> > thanks,
> > -Len
> 
> Tried that, dmesg output below:
> 
> DMI 2.2 present.
> ACPI: RSDP (v000 AMI                                   ) @ 0x000fb080
> ACPI: RSDT (v001 AMIINT          0x00000000 MSFT 0x00000097) @ 0x0fdf0000
> ACPI: FADT (v001 AMIINT          0x00000000 MSFT 0x00000097) @ 0x0fdf0030
> ACPI: DSDT (v001    SiS      620 0x00001000 MSFT 0x0100000a) @ 0x00000000
> ACPI: PM-Timer IO Port: 0x408
> Allocating PCI resources starting at 10000000 (gap: 0fe00000:f00f0000)
> Detected 300.683 MHz processor.
> Built 1 zonelists.  Total pages: 64501
> Kernel command line: root=/dev/sda3
> Initializing CPU#0
> CPU 0 irqstacks, hard=c038f000 soft=c038e000
> PID hash table entries: 1024 (order: 10, 4096 bytes)
> Console: colour VGA+ 80x25
> Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
> Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
> Memory: 254268k/260032k available (1818k kernel code, 5268k reserved,
> 611k data, 160k init, 0k highmem)
> virtual kernel memory layout:
>     fixmap  : 0xffff8000 - 0xfffff000   (  28 kB)
>     vmalloc : 0xd0800000 - 0xffff6000   ( 759 MB)
>     lowmem  : 0xc0000000 - 0xcfdf0000   ( 253 MB)
>       .init : 0xc0361000 - 0xc0389000   ( 160 kB)
>       .data : 0xc02c6be6 - 0xc035fa28   ( 611 kB)
>       .text : 0xc0100000 - 0xc02c6be6   (1818 kB)
> Checking if this processor honours the WP bit even in supervisor mode... Ok.
> Calibrating delay using timer specific routine.. 602.00 BogoMIPS (lpj=3010033)
> Security Framework v1.0.0 initialized
> Mount-cache hash table entries: 512
> CPU: After generic identify, caps: 0080f9ff 00000000 00000000 00000000
> 00000000 00000000 00000000
> CPU: L1 I cache: 16K, L1 D cache: 16K
> CPU: L2 cache: 512K
> CPU: After all inits, caps: 0080f9ff 00000000 00000000 00000040
> 00000000 00000000 00000000
> Intel machine check architecture supported.
> Intel machine check reporting enabled on CPU#0.
> CPU: Intel Pentium II (Klamath) stepping 03
> Checking 'hlt' instruction... OK.
> ACPI: Core revision 20060707
>  tbxface-0107 [01] load_tables           : ACPI Tables successfully acquired
> Parsing all Control Methods:
> Table [DSDT](id 0005) - 259 Objects with 25 Devices 99 Methods 13 Regions
> ACPI Namespace successfully loaded at root c03a49f0
> ACPI: setting ELCR to 8000 (from 1c00)
> ACPI: FADT.acpi_enable 225
> ACPI: FADT.acpi_disable 30
> ACPI: smi_cmd 0x435, acpi_enable 0xe1
> ACPI: retry 142

I guess I'm losing my mind, because when I read this code,
there are only two ways out of the while(retry) loop.
Either return with success, or retry is 0.
So how the heck is retry printed as 142?!

did you notice any delay between the last two lines of printout above?

please boot with "acpi_dbg_layer=2" "acpi_dbg_level=0xffffffff"
so that we can see each read and write of the hardware look like.
Success is measured here by looking for SCI_EN being set
to indicate that we successfully entered ACPI mode.

I guess we should see about 142 reads looking for SCI_EN...

It would be interesting if you could boot a windows disk on this box
to see if they are able to get into ACPI mode.  You'd be able to
tell by dumping the interrupt list, looking at the device tree,
or observing if the power button gives immediate poweroff
or does an OS shutdown.

thanks,
-Len

> ACPI Error (hwacpi-0185): Hardware did not change modes [20060707]
> ACPI Error (evxfevnt-0084): Could not transition to ACPI mode [20060707]
> ACPI Warning (utxface-0154): AcpiEnable failed [20060707]
> ACPI: Unable to enable ACPI

Re: BUG: linux 2.6.19 unable to enable acpi

[Matheus Izvekov]

On 1/19/07, Len Brown <lenb@kernel.org> wrote:
> I guess I'm losing my mind, because when I read this code,
> there are only two ways out of the while(retry) loop.
> Either return with success, or retry is 0.
> So how the heck is retry printed as 142?!
>
> did you notice any delay between the last two lines of printout above?
>
> please boot with "acpi_dbg_layer=2" "acpi_dbg_level=0xffffffff"
> so that we can see each read and write of the hardware look like.
> Success is measured here by looking for SCI_EN being set
> to indicate that we successfully entered ACPI mode.
>
> I guess we should see about 142 reads looking for SCI_EN...
>
> It would be interesting if you could boot a windows disk on this box
> to see if they are able to get into ACPI mode.  You'd be able to
> tell by dumping the interrupt list, looking at the device tree,
> or observing if the power button gives immediate poweroff
> or does an OS shutdown.
>
> thanks,
> -Len

printk("ACPI: retry %d\n") -> printk("ACPI: retry %d\n", retry)
;)
ill try this again soon.

Re: BUG: linux 2.6.19 unable to enable acpi

[Matheus Izvekov]

On 1/19/07, Matheus Izvekov <mizvekov@gmail.com> wrote:
> On 1/19/07, Len Brown <lenb@kernel.org> wrote:
> > I guess I'm losing my mind, because when I read this code,
> > there are only two ways out of the while(retry) loop.
> > Either return with success, or retry is 0.
> > So how the heck is retry printed as 142?!
> >
> > did you notice any delay between the last two lines of printout above?
> >
> > please boot with "acpi_dbg_layer=2" "acpi_dbg_level=0xffffffff"
> > so that we can see each read and write of the hardware look like.
> > Success is measured here by looking for SCI_EN being set
> > to indicate that we successfully entered ACPI mode.
> >
> > I guess we should see about 142 reads looking for SCI_EN...
> >
> > It would be interesting if you could boot a windows disk on this box
> > to see if they are able to get into ACPI mode.  You'd be able to
> > tell by dumping the interrupt list, looking at the device tree,
> > or observing if the power button gives immediate poweroff
> > or does an OS shutdown.
> >
> > thanks,
> > -Len
>
> printk("ACPI: retry %d\n") -> printk("ACPI: retry %d\n", retry)
> ;)
> ill try this again soon.
>

Ok, here is what i got:

  hwacpi-0207 [C031D380] [04] hw_get_mode           : ----Entry
  hwregs-0273 [C031D380] [05] get_register          : ----Entry
  hwregs-0487 [C031D380] [06] hw_register_read      : ----Entry
  hwregs-0810 [C031D380] [06] hw_low_level_read     : Read:  00000000
width 16 from 0000000000000404 (SystemIO)
  hwregs-0575 [C031D380] [06] hw_register_read      : ----Exit- AE_OK
  hwregs-0300 [C031D380] [05] get_register          : Read value
00000000 register 3
  hwregs-0303 [C031D380] [05] get_register          : ----Exit- AE_OK
  hwacpi-0226 [C031D380] [04] hw_get_mode           : ----Exit- 0000000000000002
ACPI: retry 0
ACPI Error (hwacpi-0185): Hardware did not change modes [20060707]
  hwacpi-0186 [C031D380] [03] hw_set_mode           : ----Exit-
****Exception****: AE_NO_HARDWARE_RESPONSE
ACPI Error (evxfevnt-0084): Could not transition to ACPI mode [20060707]
ACPI Warning (utxface-0154): AcpiEnable failed [20060707]
ACPI: Unable to enable ACPI

Re: BUG: linux 2.6.19 unable to enable acpi

[Sunil Naidu]

On 1/17/07, Matheus Izvekov <mizvekov@gmail.com> wrote:
> I just tried the firmwarekit, and here are the results, attached.
> TYVM, thats a very useful tool.

I do suspect ACPI issues on my new DG965WH MOBO:-

http://www.intel.com/products/motherboard/DG965WH/index.htm

Tried with Linux-2.6.19.2. Anyone tested this MOBO?

And, from where to download the firmwarekit?

~Akula2

Re: BUG: linux 2.6.19 unable to enable acpi

[Matheus Izvekov]

On 1/17/07, Sunil Naidu <akula2.shark@gmail.com> wrote:
> On 1/17/07, Matheus Izvekov <mizvekov@gmail.com> wrote:
> > I just tried the firmwarekit, and here are the results, attached.
> > TYVM, thats a very useful tool.
>
> I do suspect ACPI issues on my new DG965WH MOBO:-
>
> http://www.intel.com/products/motherboard/DG965WH/index.htm
>
> Tried with Linux-2.6.19.2. Anyone tested this MOBO?
>
> And, from where to download the firmwarekit?
>
> ~Akula2
>

Its in Arjan's sig: http://www.linuxfirmwarekit.org

Re: BUG: linux 2.6.19 unable to enable acpi

[Sunil Naidu]

On 1/19/07, Len Brown <lenb@kernel.org> wrote:
> On Wednesday 17 January 2007 05:34, you wrote:
> > On 1/17/07, Matheus Izvekov <mizvekov@gmail.com> wrote:
> > > I just tried the firmwarekit, and here are the results, attached.
> > > TYVM, thats a very useful tool.
> >
> > I do suspect ACPI issues on my new DG965WH MOBO:-
> >
> > http://www.intel.com/products/motherboard/DG965WH/index.htm
>
> What acpi issues do you suspect?
>
> note that linux-acpi@vger.kernel.org may be able to help.
>
> cheers,
> -Len

Thanks Len, am still investigating about this new MOBO. Shall post
more info here.

~Akula2