Bug 6888 - regression in resume from suspend to ram
Summary: regression in resume from suspend to ram
Status: CLOSED PATCH_ALREADY_AVAILABLE
Alias: None
Product: ACPI
Classification: Unclassified
Component: Power-Sleep-Wake (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: Shaohua
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-07-23 17:21 UTC by Karl Tomlinson
Modified: 2006-07-26 14:26 UTC (History)
1 user (show)

See Also:
Kernel Version: 2.6.17.6
Subsystem:
Regression: ---
Bisected commit-id:


Attachments
call stack screenshot (164.54 KB, image/jpeg)
2006-07-23 17:25 UTC, Karl Tomlinson
Details
config (39.83 KB, text/plain)
2006-07-23 17:26 UTC, Karl Tomlinson
Details

Description Karl Tomlinson 2006-07-23 17:21:32 UTC
Most recent kernel where this bug did not occur: 2.6.16.24
Distribution: vanilla kernel on Gentoo
Hardware Environment: Dell Inspiron 9100, Intel Pentium 4 with w/HT stepping 9
Software Environment: gcc (GCC) 3.4.6 (Gentoo 3.4.6-r1, ssp-3.4.5-1.0, 
pie-8.7.9)
Problem Description:
Failure to resume.
With radeonfb, "Linu" is displayed in probably 80x25 vga mode (as normal)
but the system then hangs.
With vgacon, a call stack is produced, as will be attached.

Steps to reproduce:
hibernate-ram, which performs echo mem > /sys/power/state.
press power button to resume.
(Both radeonfb and vgacon resumed fine without acpi_sleep= for 2.6.16.)
Comment 1 Karl Tomlinson 2006-07-23 17:25:08 UTC
Created attachment 8605 [details]
call stack screenshot

I don't know whether this is the first message displayed and I can't think how
to get previous messages.  By trying various vga= options I could only get
the previous 3 lines:

  divide error: 0000 [#1]
  PREEMPT SMP
  Modules linked in: usbcore ext2

(The patch in bug #6492 is applied, but the problem occurred without this
patch.)

gdb vmlinux

(gdb) l *0xc0222ee9
0xc0222ee9 is in acpi_pm_enter (main.c:109).
104
105		default:
106			return -EINVAL;
107		}
108		local_irq_restore(flags);
109		printk(KERN_DEBUG "Back to C!\n");
110
111		/* restore processor state
112		 * We should only be here if we're coming back from STR or STD.

113		 * And, in the case of the latter, the memory image should have
already
(gdb) x/100i acpi_pm_enter
...
0xc0222ebc <acpi_pm_enter+78>:	call   0xc0112150 <do_suspend_lowlevel>
0xc0222ec1 <acpi_pm_enter+83>:	jmp    0xc0222ee5 <acpi_pm_enter+119>
...
0xc0222ee5 <acpi_pm_enter+119>: pushl  0xfffffff0(%ebp)
0xc0222ee8 <acpi_pm_enter+122>: popf
0xc0222ee9 <acpi_pm_enter+123>: push   $0xc0314844
0xc0222eee <acpi_pm_enter+128>: call   0xc0122aac <printk>
0xc0222ef3 <acpi_pm_enter+133>: dec    %esi
0xc0222ef4 <acpi_pm_enter+134>: pop    %eax
0xc0222ef5 <acpi_pm_enter+135>: jle    0xc0222efc <acpi_pm_enter+142>
0xc0222ef7 <acpi_pm_enter+137>: call   0xc011027e <acpi_restore_state_mem>
Comment 2 Karl Tomlinson 2006-07-23 17:26:21 UTC
Created attachment 8606 [details]
config
Comment 3 Shaohua 2006-07-25 01:05:24 UTC
do you see similar issue without fb module?
Comment 4 Karl Tomlinson 2006-07-25 02:03:16 UTC
Yes, I saw the same issue without CONFIG_FB.

I added CONFIG_FB for FB_VESA in an unsuccessful attempt to get more text on 
the display.

The call stack attached here was produced with fbcon=map:1 and/or vga=ask 
command line options to revert to using vgacon, but the output is very similar 
to that without CONFIG_FB.
Comment 5 Shaohua 2006-07-25 02:14:33 UTC
Thanks! How about a UP kernel? And do you ever try a latest kernel like 2.6.18-
rc2?
Comment 6 Karl Tomlinson 2006-07-25 04:10:37 UTC
I don't usually try out the rc's, but no point trying to track down a bug if it 
has already been fixed.

suspend2 to ram seems to be working with 2.6.18-rc2 SMP (radeonfb and vgacon), 
but the kernel config I used is quite different and some other things are not 
working properly:  e.g. it is now 2032, but I haven't yet worked out whether 
this is related to suspend.

I suggest leaving this bug open until I do some comparisons with more similar 
configs, but it may be a couple of days before I get a chance to look at this.

Thanks for your help.
Comment 7 Karl Tomlinson 2006-07-26 14:26:44 UTC
2.6.18-rc2 works fine when configured very similarly to 2.6.17.6 which 
demonstrated this bug.  (And I should have read the documentation before 
enabling CONFIG_PM_TRACE.)

Marking this resolved.  Not sure if PATCH_ALREADY_AVAILABLE is quite right
as this large patch may not have been consciously designed to resolve this bug:

http://www.kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.18-rc2.bz2

Note You need to log in before you can comment on or make changes to this bug.