Re: [2.6.25-rc1 regression] Suspend to RAM (bisected)
Applied.
thanks,
-Len
On Monday 11 February 2008 18:20, Venki Pallipadi wrote:
> On Mon, Feb 11, 2008 at 12:06:50PM -0800, Venki Pallipadi wrote:
> > On Mon, Feb 11, 2008 at 05:37:04PM -0200, Carlos R. Mafra wrote:
> > > Pallipadi, Venkatesh wrote:
> > > >
> > > > Can you send me the output of acpidump and full dmesg to me. Looks like
> > > > it is a platform issue due to which we cannot use C1 mwait idle during
> > > > suspend resume, something similar to issue we had with using C2/C3 state
> > > > during idle.
> > >
> > > Full dmesg and acpidump outputs are attached.
> >
> > Above acpidump doesnt have all info, as it is loading some SSDT at run time.
> > Can you get the output of
> >
> > # acpidump --addr 0x7F6D8709 --length 0x04B7
> > # acpidump --addr 0x7F6D8BC0 --length 0x0092
> >
>
> Thanks for sending the dumps Carlos.
>
> The patch below (on top of rc1) should fix the problem. Can you please
> check it.
>
> Thanks,
> Venki
>
>
> Earlier patch (bc71bec91f9875ef825d12104acf3bf4ca215fa4) broke
> suspend resume on many laptops. The problem was reported by
> Carlos R. Mafra and Calvin Walton, who bisected the issue to above patch.
>
> The problem was because, C2 and C3 code were calling acpi_idle_enter_c1
> directly, with C2 or C3 as state parameter, while suspend/resume was in
> progress. The patch bc71bec started making use of that state information,
> assuming that it would always be referring to C1 state. This caused the
> problem with suspend-resume as we ended up using C2/C3 state indirectly.
>
> Fix this by adding acpi_idle_suspend check in enter_c1.
>
> Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]>
>
> Index: linux-2.6.25-rc1/drivers/acpi/processor_idle.c
> ===
> --- linux-2.6.25-rc1.orig/drivers/acpi/processor_idle.c
> +++ linux-2.6.25-rc1/drivers/acpi/processor_idle.c
> @@ -1420,6 +1420,14 @@ static int acpi_idle_enter_c1(struct cpu
> return 0;
>
> local_irq_disable();
> +
> + /* Do not access any ACPI IO ports in suspend path */
> + if (acpi_idle_suspend) {
> + acpi_safe_halt();
> + local_irq_enable();
> + return 0;
> + }
> +
> if (pr->flags.bm_check)
> acpi_idle_update_bm_rld(pr, cx);
>
> --
> 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/
>
--
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: [2.6.25-rc1 regression] Suspend to RAM (bisected)
Applied.
thanks,
-Len
On Monday 11 February 2008 18:20, Venki Pallipadi wrote:
On Mon, Feb 11, 2008 at 12:06:50PM -0800, Venki Pallipadi wrote:
On Mon, Feb 11, 2008 at 05:37:04PM -0200, Carlos R. Mafra wrote:
Pallipadi, Venkatesh wrote:
Can you send me the output of acpidump and full dmesg to me. Looks like
it is a platform issue due to which we cannot use C1 mwait idle during
suspend resume, something similar to issue we had with using C2/C3 state
during idle.
Full dmesg and acpidump outputs are attached.
Above acpidump doesnt have all info, as it is loading some SSDT at run time.
Can you get the output of
# acpidump --addr 0x7F6D8709 --length 0x04B7
# acpidump --addr 0x7F6D8BC0 --length 0x0092
Thanks for sending the dumps Carlos.
The patch below (on top of rc1) should fix the problem. Can you please
check it.
Thanks,
Venki
Earlier patch (bc71bec91f9875ef825d12104acf3bf4ca215fa4) broke
suspend resume on many laptops. The problem was reported by
Carlos R. Mafra and Calvin Walton, who bisected the issue to above patch.
The problem was because, C2 and C3 code were calling acpi_idle_enter_c1
directly, with C2 or C3 as state parameter, while suspend/resume was in
progress. The patch bc71bec started making use of that state information,
assuming that it would always be referring to C1 state. This caused the
problem with suspend-resume as we ended up using C2/C3 state indirectly.
Fix this by adding acpi_idle_suspend check in enter_c1.
Signed-off-by: Venkatesh Pallipadi [EMAIL PROTECTED]
Index: linux-2.6.25-rc1/drivers/acpi/processor_idle.c
===
--- linux-2.6.25-rc1.orig/drivers/acpi/processor_idle.c
+++ linux-2.6.25-rc1/drivers/acpi/processor_idle.c
@@ -1420,6 +1420,14 @@ static int acpi_idle_enter_c1(struct cpu
return 0;
local_irq_disable();
+
+ /* Do not access any ACPI IO ports in suspend path */
+ if (acpi_idle_suspend) {
+ acpi_safe_halt();
+ local_irq_enable();
+ return 0;
+ }
+
if (pr-flags.bm_check)
acpi_idle_update_bm_rld(pr, cx);
--
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/
--
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: [2.6.25-rc1 regression] Suspend to RAM (bisected)
Venki Pallipadi wrote:
> On Mon, Feb 11, 2008 at 12:06:50PM -0800, Venki Pallipadi wrote:
>> On Mon, Feb 11, 2008 at 05:37:04PM -0200, Carlos R. Mafra wrote:
>>> Pallipadi, Venkatesh wrote:
Can you send me the output of acpidump and full dmesg to me. Looks like
it is a platform issue due to which we cannot use C1 mwait idle during
suspend resume, something similar to issue we had with using C2/C3 state
during idle.
>>> Full dmesg and acpidump outputs are attached.
>> Above acpidump doesnt have all info, as it is loading some SSDT at run time.
>> Can you get the output of
>>
>> # acpidump --addr 0x7F6D8709 --length 0x04B7
>> # acpidump --addr 0x7F6D8BC0 --length 0x0092
>>
>
> Thanks for sending the dumps Carlos.
>
> The patch below (on top of rc1) should fix the problem. Can you please
> check it.
I tested your patch and it fixes the problem here!
Thank you very much for your good work,
Carlos
> Thanks,
> Venki
>
>
> Earlier patch (bc71bec91f9875ef825d12104acf3bf4ca215fa4) broke
> suspend resume on many laptops. The problem was reported by
> Carlos R. Mafra and Calvin Walton, who bisected the issue to above patch.
>
> The problem was because, C2 and C3 code were calling acpi_idle_enter_c1
> directly, with C2 or C3 as state parameter, while suspend/resume was in
> progress. The patch bc71bec started making use of that state information,
> assuming that it would always be referring to C1 state. This caused the
> problem with suspend-resume as we ended up using C2/C3 state indirectly.
>
> Fix this by adding acpi_idle_suspend check in enter_c1.
>
> Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]>
>
> Index: linux-2.6.25-rc1/drivers/acpi/processor_idle.c
> ===
> --- linux-2.6.25-rc1.orig/drivers/acpi/processor_idle.c
> +++ linux-2.6.25-rc1/drivers/acpi/processor_idle.c
> @@ -1420,6 +1420,14 @@ static int acpi_idle_enter_c1(struct cpu
> return 0;
>
> local_irq_disable();
> +
> + /* Do not access any ACPI IO ports in suspend path */
> + if (acpi_idle_suspend) {
> + acpi_safe_halt();
> + local_irq_enable();
> + return 0;
> + }
> +
> if (pr->flags.bm_check)
> acpi_idle_update_bm_rld(pr, cx);
>
>
--
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: [2.6.25-rc1 regression] Suspend to RAM (bisected)
On Mon, Feb 11, 2008 at 12:06:50PM -0800, Venki Pallipadi wrote:
> On Mon, Feb 11, 2008 at 05:37:04PM -0200, Carlos R. Mafra wrote:
> > Pallipadi, Venkatesh wrote:
> > >
> > > Can you send me the output of acpidump and full dmesg to me. Looks like
> > > it is a platform issue due to which we cannot use C1 mwait idle during
> > > suspend resume, something similar to issue we had with using C2/C3 state
> > > during idle.
> >
> > Full dmesg and acpidump outputs are attached.
>
> Above acpidump doesnt have all info, as it is loading some SSDT at run time.
> Can you get the output of
>
> # acpidump --addr 0x7F6D8709 --length 0x04B7
> # acpidump --addr 0x7F6D8BC0 --length 0x0092
>
Thanks for sending the dumps Carlos.
The patch below (on top of rc1) should fix the problem. Can you please
check it.
Thanks,
Venki
Earlier patch (bc71bec91f9875ef825d12104acf3bf4ca215fa4) broke
suspend resume on many laptops. The problem was reported by
Carlos R. Mafra and Calvin Walton, who bisected the issue to above patch.
The problem was because, C2 and C3 code were calling acpi_idle_enter_c1
directly, with C2 or C3 as state parameter, while suspend/resume was in
progress. The patch bc71bec started making use of that state information,
assuming that it would always be referring to C1 state. This caused the
problem with suspend-resume as we ended up using C2/C3 state indirectly.
Fix this by adding acpi_idle_suspend check in enter_c1.
Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]>
Index: linux-2.6.25-rc1/drivers/acpi/processor_idle.c
===
--- linux-2.6.25-rc1.orig/drivers/acpi/processor_idle.c
+++ linux-2.6.25-rc1/drivers/acpi/processor_idle.c
@@ -1420,6 +1420,14 @@ static int acpi_idle_enter_c1(struct cpu
return 0;
local_irq_disable();
+
+ /* Do not access any ACPI IO ports in suspend path */
+ if (acpi_idle_suspend) {
+ acpi_safe_halt();
+ local_irq_enable();
+ return 0;
+ }
+
if (pr->flags.bm_check)
acpi_idle_update_bm_rld(pr, cx);
--
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: [2.6.25-rc1 regression] Suspend to RAM (bisected)
On Mon, Feb 11, 2008 at 05:37:04PM -0200, Carlos R. Mafra wrote: > Pallipadi, Venkatesh wrote: > > > > Can you send me the output of acpidump and full dmesg to me. Looks like > > it is a platform issue due to which we cannot use C1 mwait idle during > > suspend resume, something similar to issue we had with using C2/C3 state > > during idle. > > Full dmesg and acpidump outputs are attached. Above acpidump doesnt have all info, as it is loading some SSDT at run time. Can you get the output of # acpidump --addr 0x7F6D8709 --length 0x04B7 # acpidump --addr 0x7F6D8BC0 --length 0x0092 Thanks, Venki -- 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: [2.6.25-rc1 regression] Suspend to RAM (bisected)
>-Original Message- >From: Calvin Walton [mailto:[EMAIL PROTECTED] >Sent: Sunday, February 10, 2008 9:48 PM >To: Carlos R. Mafra >Cc: linux-kernel@vger.kernel.org; Pallipadi, Venkatesh >Subject: Re: [2.6.25-rc1 regression] Suspend to RAM (bisected) > >On Mon, 2008-02-11 at 03:25 -0200, Carlos R. Mafra wrote: >> Hi, >> >> I want to report that suspend to RAM stopped working on my Sony Vaio >> VGN-FZ240E in 2.6.25-rc1 and that I could bisect the problem down >> to: >> >> commit bc71bec91f9875ef825d12104acf3bf4ca215fa4 >> Author: [EMAIL PROTECTED] <[EMAIL PROTECTED]> >> Date: Thu Jan 31 17:35:04 2008 -0800 >> >> ACPI: enable MWAIT for C1 idle > >I normally hate to throw in a 'me-too', but I'm also seeing a >suspend-to-ram regression on my Thinkpad R61i that I've managed to >bisect down to the same patch series. > Carlos, Calvin, Can you send me the output of acpidump and full dmesg to me. Looks like it is a platform issue due to which we cannot use C1 mwait idle during suspend resume, something similar to issue we had with using C2/C3 state during idle. Thanks, Venki -- 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: [2.6.25-rc1 regression] Suspend to RAM (bisected)
On Mon, Feb 11, 2008 at 05:37:04PM -0200, Carlos R. Mafra wrote: Pallipadi, Venkatesh wrote: Can you send me the output of acpidump and full dmesg to me. Looks like it is a platform issue due to which we cannot use C1 mwait idle during suspend resume, something similar to issue we had with using C2/C3 state during idle. Full dmesg and acpidump outputs are attached. Above acpidump doesnt have all info, as it is loading some SSDT at run time. Can you get the output of # acpidump --addr 0x7F6D8709 --length 0x04B7 # acpidump --addr 0x7F6D8BC0 --length 0x0092 Thanks, Venki -- 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: [2.6.25-rc1 regression] Suspend to RAM (bisected)
-Original Message- From: Calvin Walton [mailto:[EMAIL PROTECTED] Sent: Sunday, February 10, 2008 9:48 PM To: Carlos R. Mafra Cc: linux-kernel@vger.kernel.org; Pallipadi, Venkatesh Subject: Re: [2.6.25-rc1 regression] Suspend to RAM (bisected) On Mon, 2008-02-11 at 03:25 -0200, Carlos R. Mafra wrote: Hi, I want to report that suspend to RAM stopped working on my Sony Vaio VGN-FZ240E in 2.6.25-rc1 and that I could bisect the problem down to: commit bc71bec91f9875ef825d12104acf3bf4ca215fa4 Author: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Thu Jan 31 17:35:04 2008 -0800 ACPI: enable MWAIT for C1 idle I normally hate to throw in a 'me-too', but I'm also seeing a suspend-to-ram regression on my Thinkpad R61i that I've managed to bisect down to the same patch series. Carlos, Calvin, Can you send me the output of acpidump and full dmesg to me. Looks like it is a platform issue due to which we cannot use C1 mwait idle during suspend resume, something similar to issue we had with using C2/C3 state during idle. Thanks, Venki -- 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: [2.6.25-rc1 regression] Suspend to RAM (bisected)
On Mon, Feb 11, 2008 at 12:06:50PM -0800, Venki Pallipadi wrote:
On Mon, Feb 11, 2008 at 05:37:04PM -0200, Carlos R. Mafra wrote:
Pallipadi, Venkatesh wrote:
Can you send me the output of acpidump and full dmesg to me. Looks like
it is a platform issue due to which we cannot use C1 mwait idle during
suspend resume, something similar to issue we had with using C2/C3 state
during idle.
Full dmesg and acpidump outputs are attached.
Above acpidump doesnt have all info, as it is loading some SSDT at run time.
Can you get the output of
# acpidump --addr 0x7F6D8709 --length 0x04B7
# acpidump --addr 0x7F6D8BC0 --length 0x0092
Thanks for sending the dumps Carlos.
The patch below (on top of rc1) should fix the problem. Can you please
check it.
Thanks,
Venki
Earlier patch (bc71bec91f9875ef825d12104acf3bf4ca215fa4) broke
suspend resume on many laptops. The problem was reported by
Carlos R. Mafra and Calvin Walton, who bisected the issue to above patch.
The problem was because, C2 and C3 code were calling acpi_idle_enter_c1
directly, with C2 or C3 as state parameter, while suspend/resume was in
progress. The patch bc71bec started making use of that state information,
assuming that it would always be referring to C1 state. This caused the
problem with suspend-resume as we ended up using C2/C3 state indirectly.
Fix this by adding acpi_idle_suspend check in enter_c1.
Signed-off-by: Venkatesh Pallipadi [EMAIL PROTECTED]
Index: linux-2.6.25-rc1/drivers/acpi/processor_idle.c
===
--- linux-2.6.25-rc1.orig/drivers/acpi/processor_idle.c
+++ linux-2.6.25-rc1/drivers/acpi/processor_idle.c
@@ -1420,6 +1420,14 @@ static int acpi_idle_enter_c1(struct cpu
return 0;
local_irq_disable();
+
+ /* Do not access any ACPI IO ports in suspend path */
+ if (acpi_idle_suspend) {
+ acpi_safe_halt();
+ local_irq_enable();
+ return 0;
+ }
+
if (pr-flags.bm_check)
acpi_idle_update_bm_rld(pr, cx);
--
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: [2.6.25-rc1 regression] Suspend to RAM (bisected)
Venki Pallipadi wrote:
On Mon, Feb 11, 2008 at 12:06:50PM -0800, Venki Pallipadi wrote:
On Mon, Feb 11, 2008 at 05:37:04PM -0200, Carlos R. Mafra wrote:
Pallipadi, Venkatesh wrote:
Can you send me the output of acpidump and full dmesg to me. Looks like
it is a platform issue due to which we cannot use C1 mwait idle during
suspend resume, something similar to issue we had with using C2/C3 state
during idle.
Full dmesg and acpidump outputs are attached.
Above acpidump doesnt have all info, as it is loading some SSDT at run time.
Can you get the output of
# acpidump --addr 0x7F6D8709 --length 0x04B7
# acpidump --addr 0x7F6D8BC0 --length 0x0092
Thanks for sending the dumps Carlos.
The patch below (on top of rc1) should fix the problem. Can you please
check it.
I tested your patch and it fixes the problem here!
Thank you very much for your good work,
Carlos
Thanks,
Venki
Earlier patch (bc71bec91f9875ef825d12104acf3bf4ca215fa4) broke
suspend resume on many laptops. The problem was reported by
Carlos R. Mafra and Calvin Walton, who bisected the issue to above patch.
The problem was because, C2 and C3 code were calling acpi_idle_enter_c1
directly, with C2 or C3 as state parameter, while suspend/resume was in
progress. The patch bc71bec started making use of that state information,
assuming that it would always be referring to C1 state. This caused the
problem with suspend-resume as we ended up using C2/C3 state indirectly.
Fix this by adding acpi_idle_suspend check in enter_c1.
Signed-off-by: Venkatesh Pallipadi [EMAIL PROTECTED]
Index: linux-2.6.25-rc1/drivers/acpi/processor_idle.c
===
--- linux-2.6.25-rc1.orig/drivers/acpi/processor_idle.c
+++ linux-2.6.25-rc1/drivers/acpi/processor_idle.c
@@ -1420,6 +1420,14 @@ static int acpi_idle_enter_c1(struct cpu
return 0;
local_irq_disable();
+
+ /* Do not access any ACPI IO ports in suspend path */
+ if (acpi_idle_suspend) {
+ acpi_safe_halt();
+ local_irq_enable();
+ return 0;
+ }
+
if (pr-flags.bm_check)
acpi_idle_update_bm_rld(pr, cx);
--
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: [2.6.25-rc1 regression] Suspend to RAM (bisected)
Arjan van de Ven wrote: > On Mon, 11 Feb 2008 03:25:33 -0200 > "Carlos R. Mafra" <[EMAIL PROTECTED]> wrote: > >> The problem with suspend to RAM is that right after typing (from >> inside X) 'echo mem > /sys/power/state' the screen becomes black and >> the laptop freezes. I have to use SysRq+b to reboot. >> >> I tried to revert the above commit (bc71bec) on top of 2.6.25-rc1, but >> the compilation fails. It turns out that I have to revert also >> 9a0b8415 and 9b12e18c to be able to compile without errors. >> >> After reverting the 3 commits mentioned above, the resulting >> 2.6.25-rc1 kernel can suspend to RAM again (and I must say that it is >> better that 2.6.24, because now it resumes directly into X and I >> don't need to use Crtl-Alt-F1 and Alt-F7 to go back to X as I used to >> do before). >> >> The laptop is a Core 2 Duo T7250 2.0 GHz, running Mandriva 2008.0 in >> 64-bit mode, with the following graphics card: >> VGA compatible controller: Intel Corporation Mobile GM965/GL960 >> Integrated Graphics Controller (rev 0c) (prog-if 00 [VGA]) >> >> If there is anything else I can do to help please let me know. > > > this may be a BIOS bug; I'll let Venki dig into this ... but can you send the > output of > the dmidecode program to the list? If we need to start blacklisting bioses > that information > is going to be needed ;( I am sending the dmidecode output attached (I erased the UUID). Thanks for the prompt answer! # dmidecode 2.9 SMBIOS 2.4 present. 17 structures occupying 710 bytes. Table at 0x000DC010. Handle 0x, DMI type 0, 24 bytes BIOS Information Vendor: Phoenix Technologies LTD Version: R1120J7 Release Date: 07/04/2007 Address: 0xE6C60 Runtime Size: 103328 bytes ROM Size: 1024 kB Characteristics: PCI is supported PNP is supported BIOS is upgradeable BIOS shadowing is allowed ESCD support is available Boot from CD is supported Selectable boot is supported EDD is supported 8042 keyboard services are supported (int 9h) CGA/mono video services are supported (int 10h) ACPI is supported USB legacy is supported AGP is supported Smart battery is supported BIOS boot specification is supported Function key-initiated network boot is supported Targeted content distribution is supported BIOS Revision: 12.0 Firmware Revision: 12.0 Handle 0x0001, DMI type 1, 27 bytes System Information Manufacturer: Sony Corporation Product Name: VGN-FZ240E Version: C60034YU Serial Number: 28209434-3041267 UUID: ----x Wake-up Type: Power Switch SKU Number: N/A Family: N/A Handle 0x0002, DMI type 2, 10 bytes Base Board Information Manufacturer: Sony Corporation Product Name: VAIO Version: N/A Serial Number: N/A Handle 0x0003, DMI type 3, 17 bytes Chassis Information Manufacturer: Sony Corporation Type: Notebook Lock: Not Present Version: N/A Serial Number: N/A Asset Tag: N/A Boot-up State: Safe Power Supply State: Safe Thermal State: Safe Security Status: None OEM Information: 0x Handle 0x0004, DMI type 4, 35 bytes Processor Information Socket Designation: N/A Type: Central Processor Family: Other Manufacturer: GenuineIntel ID: FD 06 00 00 FF FB EB BF Version: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz Voltage: 1.2 V External Clock: 200 MHz Max Speed: 2000 MHz Current Speed: 2000 MHz Status: Populated, Enabled Upgrade: None L1 Cache Handle: 0x0005 L2 Cache Handle: 0x0006 L3 Cache Handle: 0x0007 Serial Number: N/A Asset Tag: N/A Part Number: N/A Handle 0x0005, DMI type 7, 19 bytes Cache Information Socket Designation: L1 Cache Configuration: Enabled, Socketed, Level 1 Operational Mode: Write Back Location: Internal Installed Size: 64 KB Maximum Size: 64 KB Supported SRAM Types: Burst Pipeline Burst Asynchronous Installed SRAM Type: Other Speed: Unknown Error Correction Type: Single-bit ECC System Type: Data Associativity: 8-way Set-associative Handle 0x0006, DMI type 7, 19 bytes Cache Information Socket Designation: L2 Cache Configuration: Enabled, Socketed, Level 2 Operational Mode: Write Back Location: Internal Installed Size: 2048 KB Maximum Size: 2048 KB Supported SRAM Types: Burst
Re: [2.6.25-rc1 regression] Suspend to RAM (bisected)
On Mon, 2008-02-11 at 03:25 -0200, Carlos R. Mafra wrote: > Hi, > > I want to report that suspend to RAM stopped working on my Sony Vaio > VGN-FZ240E in 2.6.25-rc1 and that I could bisect the problem down > to: > > commit bc71bec91f9875ef825d12104acf3bf4ca215fa4 > Author: [EMAIL PROTECTED] <[EMAIL PROTECTED]> > Date: Thu Jan 31 17:35:04 2008 -0800 > > ACPI: enable MWAIT for C1 idle I normally hate to throw in a 'me-too', but I'm also seeing a suspend-to-ram regression on my Thinkpad R61i that I've managed to bisect down to the same patch series. You beat me emailing the issue to the list by a few minutes :) > The problem with suspend to RAM is that right after typing (from inside X) > 'echo mem > /sys/power/state' the screen becomes black and the laptop > freezes. I have to use SysRq+b to reboot. My symptoms in this case are slightly different - the suspend appears to work correctly, and is fast. However, when I resume, the screen lights up quickly, but the system hangs for nearly a minute with the suspend light still on solid before it actually resumes. No delay is visible in dmesg; this apparently happens before the "return to C". > I tried to revert the above commit (bc71bec) on top of 2.6.25-rc1, but > the compilation fails. It turns out that I have to revert also 9a0b8415 and > 9b12e18c to be able to compile without errors. > > After reverting the 3 commits mentioned above, the resulting 2.6.25-rc1 kernel > can suspend to RAM again (and I must say that it is better that 2.6.24, > because > now it resumes directly into X and I don't need to use Crtl-Alt-F1 and Alt-F7 > to > go back to X as I used to do before). I just tried reverting the above-mentioned 3 commits, doing so fixes the delay. > The laptop is a Core 2 Duo T7250 2.0 GHz, running Mandriva 2008.0 in 64-bit > mode, with the > following graphics card: > VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated > Graphics Controller (rev 0c) (prog-if 00 [VGA]) Rather similar system - I have a core 2 duo 1.5 running x86_64 gentoo, and a GM965 chip (using uvesafb) > > If there is anything else I can do to help please let me know. > > Carlos R. Mafra -- Calvin Walton <[EMAIL PROTECTED]> -- 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: [2.6.25-rc1 regression] Suspend to RAM (bisected)
On Mon, 11 Feb 2008 03:25:33 -0200 "Carlos R. Mafra" <[EMAIL PROTECTED]> wrote: > The problem with suspend to RAM is that right after typing (from > inside X) 'echo mem > /sys/power/state' the screen becomes black and > the laptop freezes. I have to use SysRq+b to reboot. > > I tried to revert the above commit (bc71bec) on top of 2.6.25-rc1, but > the compilation fails. It turns out that I have to revert also > 9a0b8415 and 9b12e18c to be able to compile without errors. > > After reverting the 3 commits mentioned above, the resulting > 2.6.25-rc1 kernel can suspend to RAM again (and I must say that it is > better that 2.6.24, because now it resumes directly into X and I > don't need to use Crtl-Alt-F1 and Alt-F7 to go back to X as I used to > do before). > > The laptop is a Core 2 Duo T7250 2.0 GHz, running Mandriva 2008.0 in > 64-bit mode, with the following graphics card: > VGA compatible controller: Intel Corporation Mobile GM965/GL960 > Integrated Graphics Controller (rev 0c) (prog-if 00 [VGA]) > > If there is anything else I can do to help please let me know. this may be a BIOS bug; I'll let Venki dig into this ... but can you send the output of the dmidecode program to the list? If we need to start blacklisting bioses that information is going to be needed ;( -- If you want to reach me at my work email, use [EMAIL PROTECTED] For development, discussion and tips for power savings, visit http://www.lesswatts.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/
[2.6.25-rc1 regression] Suspend to RAM (bisected)
Hi, I want to report that suspend to RAM stopped working on my Sony Vaio VGN-FZ240E in 2.6.25-rc1 and that I could bisect the problem down to: commit bc71bec91f9875ef825d12104acf3bf4ca215fa4 Author: [EMAIL PROTECTED] <[EMAIL PROTECTED]> Date: Thu Jan 31 17:35:04 2008 -0800 ACPI: enable MWAIT for C1 idle Add MWAIT idle for C1 state instead of halt, on platforms that support C1 state with MWAIT. Renames cx->space_id to something more appropriate. Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]> Signed-off-by: Len Brown <[EMAIL PROTECTED]> The problem with suspend to RAM is that right after typing (from inside X) 'echo mem > /sys/power/state' the screen becomes black and the laptop freezes. I have to use SysRq+b to reboot. I tried to revert the above commit (bc71bec) on top of 2.6.25-rc1, but the compilation fails. It turns out that I have to revert also 9a0b8415 and 9b12e18c to be able to compile without errors. After reverting the 3 commits mentioned above, the resulting 2.6.25-rc1 kernel can suspend to RAM again (and I must say that it is better that 2.6.24, because now it resumes directly into X and I don't need to use Crtl-Alt-F1 and Alt-F7 to go back to X as I used to do before). The laptop is a Core 2 Duo T7250 2.0 GHz, running Mandriva 2008.0 in 64-bit mode, with the following graphics card: VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c) (prog-if 00 [VGA]) If there is anything else I can do to help please let me know. Carlos R. Mafra -- 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/
[2.6.25-rc1 regression] Suspend to RAM (bisected)
Hi, I want to report that suspend to RAM stopped working on my Sony Vaio VGN-FZ240E in 2.6.25-rc1 and that I could bisect the problem down to: commit bc71bec91f9875ef825d12104acf3bf4ca215fa4 Author: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Thu Jan 31 17:35:04 2008 -0800 ACPI: enable MWAIT for C1 idle Add MWAIT idle for C1 state instead of halt, on platforms that support C1 state with MWAIT. Renames cx-space_id to something more appropriate. Signed-off-by: Venkatesh Pallipadi [EMAIL PROTECTED] Signed-off-by: Len Brown [EMAIL PROTECTED] The problem with suspend to RAM is that right after typing (from inside X) 'echo mem /sys/power/state' the screen becomes black and the laptop freezes. I have to use SysRq+b to reboot. I tried to revert the above commit (bc71bec) on top of 2.6.25-rc1, but the compilation fails. It turns out that I have to revert also 9a0b8415 and 9b12e18c to be able to compile without errors. After reverting the 3 commits mentioned above, the resulting 2.6.25-rc1 kernel can suspend to RAM again (and I must say that it is better that 2.6.24, because now it resumes directly into X and I don't need to use Crtl-Alt-F1 and Alt-F7 to go back to X as I used to do before). The laptop is a Core 2 Duo T7250 2.0 GHz, running Mandriva 2008.0 in 64-bit mode, with the following graphics card: VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c) (prog-if 00 [VGA]) If there is anything else I can do to help please let me know. Carlos R. Mafra -- 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: [2.6.25-rc1 regression] Suspend to RAM (bisected)
Arjan van de Ven wrote: On Mon, 11 Feb 2008 03:25:33 -0200 Carlos R. Mafra [EMAIL PROTECTED] wrote: The problem with suspend to RAM is that right after typing (from inside X) 'echo mem /sys/power/state' the screen becomes black and the laptop freezes. I have to use SysRq+b to reboot. I tried to revert the above commit (bc71bec) on top of 2.6.25-rc1, but the compilation fails. It turns out that I have to revert also 9a0b8415 and 9b12e18c to be able to compile without errors. After reverting the 3 commits mentioned above, the resulting 2.6.25-rc1 kernel can suspend to RAM again (and I must say that it is better that 2.6.24, because now it resumes directly into X and I don't need to use Crtl-Alt-F1 and Alt-F7 to go back to X as I used to do before). The laptop is a Core 2 Duo T7250 2.0 GHz, running Mandriva 2008.0 in 64-bit mode, with the following graphics card: VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c) (prog-if 00 [VGA]) If there is anything else I can do to help please let me know. this may be a BIOS bug; I'll let Venki dig into this ... but can you send the output of the dmidecode program to the list? If we need to start blacklisting bioses that information is going to be needed ;( I am sending the dmidecode output attached (I erased the UUID). Thanks for the prompt answer! # dmidecode 2.9 SMBIOS 2.4 present. 17 structures occupying 710 bytes. Table at 0x000DC010. Handle 0x, DMI type 0, 24 bytes BIOS Information Vendor: Phoenix Technologies LTD Version: R1120J7 Release Date: 07/04/2007 Address: 0xE6C60 Runtime Size: 103328 bytes ROM Size: 1024 kB Characteristics: PCI is supported PNP is supported BIOS is upgradeable BIOS shadowing is allowed ESCD support is available Boot from CD is supported Selectable boot is supported EDD is supported 8042 keyboard services are supported (int 9h) CGA/mono video services are supported (int 10h) ACPI is supported USB legacy is supported AGP is supported Smart battery is supported BIOS boot specification is supported Function key-initiated network boot is supported Targeted content distribution is supported BIOS Revision: 12.0 Firmware Revision: 12.0 Handle 0x0001, DMI type 1, 27 bytes System Information Manufacturer: Sony Corporation Product Name: VGN-FZ240E Version: C60034YU Serial Number: 28209434-3041267 UUID: ----x Wake-up Type: Power Switch SKU Number: N/A Family: N/A Handle 0x0002, DMI type 2, 10 bytes Base Board Information Manufacturer: Sony Corporation Product Name: VAIO Version: N/A Serial Number: N/A Handle 0x0003, DMI type 3, 17 bytes Chassis Information Manufacturer: Sony Corporation Type: Notebook Lock: Not Present Version: N/A Serial Number: N/A Asset Tag: N/A Boot-up State: Safe Power Supply State: Safe Thermal State: Safe Security Status: None OEM Information: 0x Handle 0x0004, DMI type 4, 35 bytes Processor Information Socket Designation: N/A Type: Central Processor Family: Other Manufacturer: GenuineIntel ID: FD 06 00 00 FF FB EB BF Version: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz Voltage: 1.2 V External Clock: 200 MHz Max Speed: 2000 MHz Current Speed: 2000 MHz Status: Populated, Enabled Upgrade: None L1 Cache Handle: 0x0005 L2 Cache Handle: 0x0006 L3 Cache Handle: 0x0007 Serial Number: N/A Asset Tag: N/A Part Number: N/A Handle 0x0005, DMI type 7, 19 bytes Cache Information Socket Designation: L1 Cache Configuration: Enabled, Socketed, Level 1 Operational Mode: Write Back Location: Internal Installed Size: 64 KB Maximum Size: 64 KB Supported SRAM Types: Burst Pipeline Burst Asynchronous Installed SRAM Type: Other Speed: Unknown Error Correction Type: Single-bit ECC System Type: Data Associativity: 8-way Set-associative Handle 0x0006, DMI type 7, 19 bytes Cache Information Socket Designation: L2 Cache Configuration: Enabled, Socketed, Level 2 Operational Mode: Write Back Location: Internal Installed Size: 2048 KB Maximum Size: 2048 KB Supported SRAM Types: Burst Pipeline Burst
Re: [2.6.25-rc1 regression] Suspend to RAM (bisected)
On Mon, 11 Feb 2008 03:25:33 -0200 Carlos R. Mafra [EMAIL PROTECTED] wrote: The problem with suspend to RAM is that right after typing (from inside X) 'echo mem /sys/power/state' the screen becomes black and the laptop freezes. I have to use SysRq+b to reboot. I tried to revert the above commit (bc71bec) on top of 2.6.25-rc1, but the compilation fails. It turns out that I have to revert also 9a0b8415 and 9b12e18c to be able to compile without errors. After reverting the 3 commits mentioned above, the resulting 2.6.25-rc1 kernel can suspend to RAM again (and I must say that it is better that 2.6.24, because now it resumes directly into X and I don't need to use Crtl-Alt-F1 and Alt-F7 to go back to X as I used to do before). The laptop is a Core 2 Duo T7250 2.0 GHz, running Mandriva 2008.0 in 64-bit mode, with the following graphics card: VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c) (prog-if 00 [VGA]) If there is anything else I can do to help please let me know. this may be a BIOS bug; I'll let Venki dig into this ... but can you send the output of the dmidecode program to the list? If we need to start blacklisting bioses that information is going to be needed ;( -- If you want to reach me at my work email, use [EMAIL PROTECTED] For development, discussion and tips for power savings, visit http://www.lesswatts.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: [2.6.25-rc1 regression] Suspend to RAM (bisected)
On Mon, 2008-02-11 at 03:25 -0200, Carlos R. Mafra wrote: Hi, I want to report that suspend to RAM stopped working on my Sony Vaio VGN-FZ240E in 2.6.25-rc1 and that I could bisect the problem down to: commit bc71bec91f9875ef825d12104acf3bf4ca215fa4 Author: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Thu Jan 31 17:35:04 2008 -0800 ACPI: enable MWAIT for C1 idle I normally hate to throw in a 'me-too', but I'm also seeing a suspend-to-ram regression on my Thinkpad R61i that I've managed to bisect down to the same patch series. You beat me emailing the issue to the list by a few minutes :) The problem with suspend to RAM is that right after typing (from inside X) 'echo mem /sys/power/state' the screen becomes black and the laptop freezes. I have to use SysRq+b to reboot. My symptoms in this case are slightly different - the suspend appears to work correctly, and is fast. However, when I resume, the screen lights up quickly, but the system hangs for nearly a minute with the suspend light still on solid before it actually resumes. No delay is visible in dmesg; this apparently happens before the return to C. I tried to revert the above commit (bc71bec) on top of 2.6.25-rc1, but the compilation fails. It turns out that I have to revert also 9a0b8415 and 9b12e18c to be able to compile without errors. After reverting the 3 commits mentioned above, the resulting 2.6.25-rc1 kernel can suspend to RAM again (and I must say that it is better that 2.6.24, because now it resumes directly into X and I don't need to use Crtl-Alt-F1 and Alt-F7 to go back to X as I used to do before). I just tried reverting the above-mentioned 3 commits, doing so fixes the delay. The laptop is a Core 2 Duo T7250 2.0 GHz, running Mandriva 2008.0 in 64-bit mode, with the following graphics card: VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c) (prog-if 00 [VGA]) Rather similar system - I have a core 2 duo 1.5 running x86_64 gentoo, and a GM965 chip (using uvesafb) If there is anything else I can do to help please let me know. Carlos R. Mafra -- Calvin Walton [EMAIL PROTECTED] -- 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/
