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
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 ?
On 1/17/07, Arjan van de Ven <[email protected]> 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?
On 1/17/07, Matheus Izvekov <[email protected]> wrote:
> On 1/17/07, Arjan van de Ven <[email protected]> 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..?
On 1/17/07, Luming Yu <[email protected]> wrote:
> On 1/17/07, Matheus Izvekov <[email protected]> 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.
I just tried the firmwarekit, and here are the results, attached.
TYVM, thats a very useful tool.
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);
On 1/17/07, Matheus Izvekov <[email protected]> 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
On 1/17/07, Sunil Naidu <[email protected]> wrote:
> On 1/17/07, Matheus Izvekov <[email protected]> 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
On 1/17/07, Len Brown <[email protected]> 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
On Wednesday 17 January 2007 16:10, Matheus Izvekov wrote:
> On 1/17/07, Len Brown <[email protected]> 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
On 1/19/07, Len Brown <[email protected]> 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.
On 1/19/07, Matheus Izvekov <[email protected]> wrote:
> On 1/19/07, Len Brown <[email protected]> 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
On 1/19/07, Len Brown <[email protected]> wrote:
> On Wednesday 17 January 2007 05:34, you wrote:
> > On 1/17/07, Matheus Izvekov <[email protected]> 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 [email protected] may be able to help.
>
> cheers,
> -Len
Thanks Len, am still investigating about this new MOBO. Shall post
more info here.
~Akula2