Re: BUG: linux 2.6.19 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 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: linux 2.6.19 unable to enable acpi
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=0x"
> 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:
width 16 from 0404 (SystemIO)
hwregs-0575 [C031D380] [06] hw_register_read : Exit- AE_OK
hwregs-0300 [C031D380] [05] get_register : Read value
register 3
hwregs-0303 [C031D380] [05] get_register : Exit- AE_OK
hwacpi-0226 [C031D380] [04] hw_get_mode : Exit- 0002
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: linux 2.6.19 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=0x"
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: linux 2.6.19 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 0x MSFT 0x0097) @ 0x0fdf > ACPI: FADT (v001 AMIINT 0x MSFT 0x0097) @ 0x0fdf0030 > ACPI: DSDT (v001SiS 620 0x1000 MSFT 0x010a) @ 0x > ACPI: PM-Timer IO Port: 0x408 > Allocating PCI resources starting at 1000 (gap: 0fe0:f00f) > 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 : 0x8000 - 0xf000 ( 28 kB) > vmalloc : 0xd080 - 0x6000 ( 759 MB) > lowmem : 0xc000 - 0xcfdf ( 253 MB) > .init : 0xc0361000 - 0xc0389000 ( 160 kB) > .data : 0xc02c6be6 - 0xc035fa28 ( 611 kB) > .text : 0xc010 - 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 > > CPU: L1 I cache: 16K, L1 D cache: 16K > CPU: L2 cache: 512K > CPU: After all inits, caps: 0080f9ff 0040 > > 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=0x" 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: linux 2.6.19 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 0x MSFT 0x0097) @ 0x0fdf ACPI: FADT (v001 AMIINT 0x MSFT 0x0097) @ 0x0fdf0030 ACPI: DSDT (v001SiS 620 0x1000 MSFT 0x010a) @ 0x ACPI: PM-Timer IO Port: 0x408 Allocating PCI resources starting at 1000 (gap: 0fe0:f00f) 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 : 0x8000 - 0xf000 ( 28 kB) vmalloc : 0xd080 - 0x6000 ( 759 MB) lowmem : 0xc000 - 0xcfdf ( 253 MB) .init : 0xc0361000 - 0xc0389000 ( 160 kB) .data : 0xc02c6be6 - 0xc035fa28 ( 611 kB) .text : 0xc010 - 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 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 512K CPU: After all inits, caps: 0080f9ff 0040 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=0x 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: linux 2.6.19 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=0x 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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: linux 2.6.19 unable to enable acpi
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=0x 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: width 16 from 0404 (SystemIO) hwregs-0575 [C031D380] [06] hw_register_read : Exit- AE_OK hwregs-0300 [C031D380] [05] get_register : Read value register 3 hwregs-0303 [C031D380] [05] get_register : Exit- AE_OK hwacpi-0226 [C031D380] [04] hw_get_mode : Exit- 0002 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: linux 2.6.19 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 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: linux 2.6.19 unable to enable acpi
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 0x MSFT 0x0097) @ 0x0fdf ACPI: FADT (v001 AMIINT 0x MSFT 0x0097) @ 0x0fdf0030 ACPI: DSDT (v001SiS 620 0x1000 MSFT 0x010a) @ 0x ACPI: PM-Timer IO Port: 0x408 Allocating PCI resources starting at 1000 (gap: 0fe0:f00f) 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 : 0x8000 - 0xf000 ( 28 kB) vmalloc : 0xd080 - 0x6000 ( 759 MB) lowmem : 0xc000 - 0xcfdf ( 253 MB) .init : 0xc0361000 - 0xc0389000 ( 160 kB) .data : 0xc02c6be6 - 0xc035fa28 ( 611 kB) .text : 0xc010 - 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 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 512K CPU: After all inits, caps: 0080f9ff 0040 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: linux 2.6.19 unable to enable acpi
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: linux 2.6.19 unable to enable acpi
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: linux 2.6.19 unable to enable acpi
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);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: linux 2.6.19 unable to enable acpi
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);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: linux 2.6.19 unable to enable acpi
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: linux 2.6.19 unable to enable acpi
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: linux 2.6.19 unable to enable acpi
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 0x MSFT 0x0097) @ 0x0fdf ACPI: FADT (v001 AMIINT 0x MSFT 0x0097) @ 0x0fdf0030 ACPI: DSDT (v001SiS 620 0x1000 MSFT 0x010a) @ 0x ACPI: PM-Timer IO Port: 0x408 Allocating PCI resources starting at 1000 (gap: 0fe0:f00f) 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 : 0x8000 - 0xf000 ( 28 kB) vmalloc : 0xd080 - 0x6000 ( 759 MB) lowmem : 0xc000 - 0xcfdf ( 253 MB) .init : 0xc0361000 - 0xc0389000 ( 160 kB) .data : 0xc02c6be6 - 0xc035fa28 ( 611 kB) .text : 0xc010 - 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 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 512K CPU: After all inits, caps: 0080f9ff 0040 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: linux 2.6.19 unable to enable acpi
I just tried the firmwarekit, and here are the results, attached. TYVM, thats a very useful tool. apicedge (experimental) APIC Edge/Level check 4 This test checks if legacy interrupts are edge and PCI interrupts are level Non-Legacy interrupt 0 is incorrectly level triggered 4 interrupts:// 0: 22353XT-PIC-XTtimer Non-Legacy interrupt 1 is incorrectly level triggered 4 interrupts:// 1: 9XT-PIC-XTi8042 Non-Legacy interrupt 2 is incorrectly level triggered 4 interrupts:// 2: 0XT-PIC-XTcascade Non-Legacy interrupt 8 is incorrectly level triggered 4 interrupts:// 8: 0XT-PIC-XTrtc Non-Legacy interrupt 10 is incorrectly level triggered 4 interrupts:// 10: 51XT-PIC-XTohci_hcd:usb1 microcode Processor microcode update 4 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. Cpu cpu0 has outdated microcode (version 34 while version 36 is available) 4 FADT FADT test 4 verify FADT SCI_EN bit enabled or NOT. E820: XSDT (0x2ed382e9) is not in reserved or ACPI memory! 4 e820:// Legacy mode, SCI_EN bit in PM1a_Control register is incorrectly Disabled 4 E820: XSDT (0x2ed382e9) is not in reserved or ACPI memory! 4 e820:// mtrr MTRR validation 4 This test validates the MTRR setup against the memory map to detect any inconsistencies in cachability. Memory range 0x10 to 0xfde (System RAM) has incorrect attribute default 4 mtrr://System RAM Memory range 0x10 to 0xfde (System RAM) has incorrect attribute default mcfg MCFG PCI Express* memory mapped config space 4 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. E820: XSDT (0x2ed382e9) is not in reserved or ACPI memory! 4 e820:// No MCFG ACPI table found. This table is required for PCI Express*. 2 edd EDD Boot disk hinting 4 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. Boot device 0x80 does not support EDD 4 pciresource Validate assigned PCI resources 4 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. Device :01:00.0 has incorrect resources 4 pci://:01:00.0 PCI: Ignore bogus resource 6 [0:0] of :01:00.0 thermal_trip ACPI passive thermal trip points 2 This test determines if the passive trip point works as expected. Cannot test trip points without existing /proc/acpi/thermal_zone. 2 cpufreq CPU frequency scaling tests 2 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 Frequency scaling not supported 2 virt VT/VMX Virtualization extensions 1 This test checks if VT/VMX is set up correctly Processor does not support Virtualization extensions 1 acpiinfo General ACPI information 1 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. DSDT was compiled by the Microsoft AML compiler 1 ACPI: DSDT (v001SiS 620 0x1000 MSFT 0x010a) @ 0x maxreadreq PCI Express MaxReadReq tuning 0 This test checks if the firmware has set MaxReadReq to a higher value on non-montherboard devices os2gap OS/2 memory hole test 0 This test checks if the OS/2 15Mb memory hole is absent dmi DMI information check 0 This test checks the DMI/SMBIOS tables for common errors. chk_hpet HPET configuration test 0 This test checks the HPET PCI BAR for each timer block in the timer.The base address is passed by
Re: BUG: linux 2.6.19 unable to enable acpi
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: linux 2.6.19 unable to enable acpi
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..? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: linux 2.6.19 unable to enable 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? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: linux 2.6.19 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 ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
BUG: linux 2.6.19 unable to enable acpi
Just tried linux for the first time on this old machine, and i got this problem. dmesg below: Linux version 2.6.19 ([EMAIL PROTECTED]) (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: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000dc000 - 000e (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 0fdf (usable) BIOS-e820: 0fdf - 0fdf8000 (ACPI data) BIOS-e820: 0fdf8000 - 0fe0 (ACPI NVS) BIOS-e820: ffef - fff0 (reserved) BIOS-e820: - 0001 (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 0x MSFT 0x0097) @ 0x0fdf ACPI: FADT (v001 AMIINT 0x MSFT 0x0097) @ 0x0fdf0030 ACPI: DSDT (v001SiS 620 0x1000 MSFT 0x010a) @ 0x ACPI: PM-Timer IO Port: 0x408 Allocating PCI resources starting at 1000 (gap: 0fe0:f00f) 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 d000 (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 - 0xf000 ( 288 kB) vmalloc : 0xd080 - 0xfffb5000 ( 759 MB) lowmem : 0xc000 - 0xcfdf ( 253 MB) .init : 0xc036b000 - 0xc0398000 ( 180 kB) .data : 0xc02d3086 - 0xc0369fa8 ( 603 kB) .text : 0xc010 - 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 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 512K CPU: After all inits, caps: 0080f9ff 0040 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
BUG: linux 2.6.19 unable to enable acpi
Just tried linux for the first time on this old machine, and i got this problem. dmesg below: Linux version 2.6.19 ([EMAIL PROTECTED]) (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: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000dc000 - 000e (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 0fdf (usable) BIOS-e820: 0fdf - 0fdf8000 (ACPI data) BIOS-e820: 0fdf8000 - 0fe0 (ACPI NVS) BIOS-e820: ffef - fff0 (reserved) BIOS-e820: - 0001 (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 0x MSFT 0x0097) @ 0x0fdf ACPI: FADT (v001 AMIINT 0x MSFT 0x0097) @ 0x0fdf0030 ACPI: DSDT (v001SiS 620 0x1000 MSFT 0x010a) @ 0x ACPI: PM-Timer IO Port: 0x408 Allocating PCI resources starting at 1000 (gap: 0fe0:f00f) 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 d000 (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 - 0xf000 ( 288 kB) vmalloc : 0xd080 - 0xfffb5000 ( 759 MB) lowmem : 0xc000 - 0xcfdf ( 253 MB) .init : 0xc036b000 - 0xc0398000 ( 180 kB) .data : 0xc02d3086 - 0xc0369fa8 ( 603 kB) .text : 0xc010 - 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 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 512K CPU: After all inits, caps: 0080f9ff 0040 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: linux 2.6.19 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 ? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: linux 2.6.19 unable to enable 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? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: linux 2.6.19 unable to enable acpi
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..? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: linux 2.6.19 unable to enable acpi
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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: linux 2.6.19 unable to enable acpi
I just tried the firmwarekit, and here are the results, attached. TYVM, thats a very useful tool. ?xml version=1.0 encoding=UTF-8? ?xml-stylesheet href=results.css type=text/css? results test idapicedge/id name(experimental) APIC Edge/Level check/name result4/result descriptionThis test checks if legacy interrupts are edge and PCI interrupts are level/description detail summaryNon-Legacy interrupt 0 is incorrectly level triggered/summary result4/result uriinterrupts:///uri data 0: 22353XT-PIC-XTtimer /data /detail detail summaryNon-Legacy interrupt 1 is incorrectly level triggered/summary result4/result uriinterrupts:///uri data 1: 9XT-PIC-XTi8042 /data /detail detail summaryNon-Legacy interrupt 2 is incorrectly level triggered/summary result4/result uriinterrupts:///uri data 2: 0XT-PIC-XTcascade /data /detail detail summaryNon-Legacy interrupt 8 is incorrectly level triggered/summary result4/result uriinterrupts:///uri data 8: 0XT-PIC-XTrtc /data /detail detail summaryNon-Legacy interrupt 10 is incorrectly level triggered/summary result4/result uriinterrupts:///uri data 10: 51XT-PIC-XTohci_hcd:usb1 /data /detail /test test idmicrocode/id nameProcessor microcode update/name result4/result descriptionThis 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 summaryCpu cpu0 has outdated microcode (version 34 while version 36 is available)/summary result4/result uri/uri /detail /test test idFADT/id nameFADT test/name result4/result descriptionverify FADT SCI_EN bit enabled or NOT./description detail summaryE820: XSDT (0x2ed382e9) is not in reserved or ACPI memory!/summary result4/result urie820:///uri /detail detail summaryLegacy mode, SCI_EN bit in PM1a_Control register is incorrectly Disabled/summary result4/result /detail detail summaryE820: XSDT (0x2ed382e9) is not in reserved or ACPI memory!/summary result4/result urie820:///uri /detail /test test idmtrr/id nameMTRR validation/name result4/result descriptionThis test validates the MTRR setup against the memory map to detect any inconsistencies in cachability./description detail summaryMemory range 0x10 to 0xfde (System RAM) has incorrect attribute default /summary result4/result urimtrr://System RAM/uri dataMemory range 0x10 to 0xfde (System RAM) has incorrect attribute default /data /detail /test test idmcfg/id nameMCFG PCI Express* memory mapped config space/name result4/result descriptionThis 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 summaryE820: XSDT (0x2ed382e9) is not in reserved or ACPI memory!/summary result4/result urie820:///uri /detail detail summaryNo MCFG ACPI table found. This table is required for PCI Express*./summary result2/result /detail /test test idedd/id nameEDD Boot disk hinting/name result4/result descriptionThis 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 summaryBoot device 0x80 does not support EDD /summary result4/result uri/uri /detail /test test idpciresource/id nameValidate assigned PCI resources/name result4/result descriptionThis 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 summaryDevice :01:00.0 has incorrect resources/summary result4/result uripci://:01:00.0/uri dataPCI: Ignore bogus resource 6 [0:0] of :01:00.0/data /detail /test test idthermal_trip/id nameACPI passive thermal trip points/name result2/result descriptionThis test determines if the passive trip point works as expected./description detail summaryCannot test trip points without existing /proc/acpi/thermal_zone./summary result2/result uri/uri /detail /test test idcpufreq/id nameCPU frequency scaling tests/name result2/result descriptionFor 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
