suspend to ram problem

suspend to ram problem

[(अमेय) Ameya (पाळंदे) Palande]

Hi,

When we can expect suspend to ram will work ?
Kernel I am using is : 2.6.20-16-generic
Kvm - 26
Intel VT T2300 on dell inspiron e1505 / 6400 laptop.

Regards,
Ameya.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

Re: suspend to ram problem

[Avi Kivity]

(अमेय) Ameya (पाळंदे) Palande wrote:
> Hi,
>
> When we can expect suspend to ram will work ?
> Kernel I am using is : 2.6.20-16-generic
> Kvm - 26
> Intel VT T2300 on dell inspiron e1505 / 6400 laptop.
>   

Suspend to ram works on at least one laptop.  If it doesn't work for 
you, try the patch in http://lkml.org/lkml/2007/5/29/129 (use the 'Get 
diff' link).

I suggest upgrading to 2.6.22-rc3 before applying the patch.

-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

suspend to ram problem

[matthieu castet]

Hi,

I am trying to make work suspend to ram on a MSI MS-6380E with a 2.6.23 
kernel.

Standby mode works.
S2ram suspend seems to work : the computer turn off and I can wake up it 
with the keyboard.

But when the computer wakeup, I see the video card POST on the screen, 
but after that the computer hangs : black screen, no working numlock.

I tried to compile PM_TRACE, but it give no result. So this means the 
resume hang very early.

What can I do to debug this ?


Thanks

Matthieu

Re: suspend to ram problem

[matthieu castet]

matthieu castet wrote:
> Hi,
> 
> I am trying to make work suspend to ram on a MSI MS-6380E with a 2.6.23 
> kernel.
> 
> Standby mode works.
> S2ram suspend seems to work : the computer turn off and I can wake up it 
> with the keyboard.
> 
> But when the computer wakeup, I see the video card POST on the screen, 
> but after that the computer hangs : black screen, no working numlock.
> 
> I tried to compile PM_TRACE, but it give no result. So this means the 
> resume hang very early.
> 
> What can I do to debug this ?
>
I play with the s2_beep feature and :
- echo 4 > /proc/sys/kernel/acpi_video_flags make the computer beep
- echo 4 > /proc/sys/kernel/acpi_video_flags make the computer not beep
- adding a beep in bogus_real_magic, make the computer not beep

So the hang seems located in wakeup_start.


Matthieu

Re: suspend to ram problem

[Rafael J. Wysocki]

On Sunday, 3 of February 2008, matthieu castet wrote:
> matthieu castet wrote:
> > Hi,
> > 
> > I am trying to make work suspend to ram on a MSI MS-6380E with a 2.6.23 
> > kernel.
> > 
> > Standby mode works.
> > S2ram suspend seems to work : the computer turn off and I can wake up it 
> > with the keyboard.
> > 
> > But when the computer wakeup, I see the video card POST on the screen, 
> > but after that the computer hangs : black screen, no working numlock.
> > 
> > I tried to compile PM_TRACE, but it give no result. So this means the 
> > resume hang very early.
> > 
> > What can I do to debug this ?
> >
> I play with the s2_beep feature and :
> - echo 4 > /proc/sys/kernel/acpi_video_flags make the computer beep
> - echo 4 > /proc/sys/kernel/acpi_video_flags make the computer not beep
> - adding a beep in bogus_real_magic, make the computer not beep
> 
> So the hang seems located in wakeup_start.

Hm.  Can you add unconditional BEEP after "jne bogus_real_magic" in
arch/x86/kernel/acpi/wakeup.S and see if it beeps?

Rafael

Re: suspend to ram problem

[Pavel Machek]

On Sun 2008-02-03 18:39:01, Rafael J. Wysocki wrote:
> On Sunday, 3 of February 2008, matthieu castet wrote:
> > matthieu castet wrote:
> > > Hi,
> > > 
> > > I am trying to make work suspend to ram on a MSI MS-6380E with a 2.6.23 
> > > kernel.
> > > 
> > > Standby mode works.
> > > S2ram suspend seems to work : the computer turn off and I can wake up it 
> > > with the keyboard.
> > > 
> > > But when the computer wakeup, I see the video card POST on the screen, 
> > > but after that the computer hangs : black screen, no working numlock.
> > > 
> > > I tried to compile PM_TRACE, but it give no result. So this means the 
> > > resume hang very early.
> > > 
> > > What can I do to debug this ?
> > >
> > I play with the s2_beep feature and :
> > - echo 4 > /proc/sys/kernel/acpi_video_flags make the computer beep
> > - echo 4 > /proc/sys/kernel/acpi_video_flags make the computer not beep
> > - adding a beep in bogus_real_magic, make the computer not beep
> > 
> > So the hang seems located in wakeup_start.
> 
> Hm.  Can you add unconditional BEEP after "jne bogus_real_magic" in
> arch/x86/kernel/acpi/wakeup.S and see if it beeps?

Hmm, maybe I know where problem could be. Try

        movl     $(wakeup_stack - wakeup_code), %esp              # Private stack is needed for ASUS bo\

instead of existing stack setup. That helped on one of my test-boxes
-- I uncovered that during rewrite.

Otherwise use BEEP and infinite loops to find out where it hangs...

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: suspend to ram problem

[Rafael J. Wysocki]

On Sunday, 3 of February 2008, Pavel Machek wrote:
> On Sun 2008-02-03 18:39:01, Rafael J. Wysocki wrote:
> > On Sunday, 3 of February 2008, matthieu castet wrote:
> > > matthieu castet wrote:
> > > > Hi,
> > > > 
> > > > I am trying to make work suspend to ram on a MSI MS-6380E with a 2.6.23 
> > > > kernel.
> > > > 
> > > > Standby mode works.
> > > > S2ram suspend seems to work : the computer turn off and I can wake up it 
> > > > with the keyboard.
> > > > 
> > > > But when the computer wakeup, I see the video card POST on the screen, 
> > > > but after that the computer hangs : black screen, no working numlock.
> > > > 
> > > > I tried to compile PM_TRACE, but it give no result. So this means the 
> > > > resume hang very early.
> > > > 
> > > > What can I do to debug this ?
> > > >
> > > I play with the s2_beep feature and :
> > > - echo 4 > /proc/sys/kernel/acpi_video_flags make the computer beep
> > > - echo 4 > /proc/sys/kernel/acpi_video_flags make the computer not beep
> > > - adding a beep in bogus_real_magic, make the computer not beep
> > > 
> > > So the hang seems located in wakeup_start.
> > 
> > Hm.  Can you add unconditional BEEP after "jne bogus_real_magic" in
> > arch/x86/kernel/acpi/wakeup.S and see if it beeps?
> 
> Hmm, maybe I know where problem could be. Try
> 
>         movl     $(wakeup_stack - wakeup_code), %esp              # Private stack is needed for ASUS bo\
> 
> instead of existing stack setup. That helped on one of my test-boxes
> -- I uncovered that during rewrite.

Well, that could explain some mysterious failures reported from time to time by
ASUS users.

Rafael

Re: suspend to ram problem

[Rafael J. Wysocki]

On Sunday, 3 of February 2008, Pavel Machek wrote:
> On Sun 2008-02-03 18:39:01, Rafael J. Wysocki wrote:
> > On Sunday, 3 of February 2008, matthieu castet wrote:
> > > matthieu castet wrote:
> > > > Hi,
> > > > 
> > > > I am trying to make work suspend to ram on a MSI MS-6380E with a 2.6.23 
> > > > kernel.
> > > > 
> > > > Standby mode works.
> > > > S2ram suspend seems to work : the computer turn off and I can wake up it 
> > > > with the keyboard.
> > > > 
> > > > But when the computer wakeup, I see the video card POST on the screen, 
> > > > but after that the computer hangs : black screen, no working numlock.
> > > > 
> > > > I tried to compile PM_TRACE, but it give no result. So this means the 
> > > > resume hang very early.
> > > > 
> > > > What can I do to debug this ?
> > > >
> > > I play with the s2_beep feature and :
> > > - echo 4 > /proc/sys/kernel/acpi_video_flags make the computer beep
> > > - echo 4 > /proc/sys/kernel/acpi_video_flags make the computer not beep
> > > - adding a beep in bogus_real_magic, make the computer not beep
> > > 
> > > So the hang seems located in wakeup_start.
> > 
> > Hm.  Can you add unconditional BEEP after "jne bogus_real_magic" in
> > arch/x86/kernel/acpi/wakeup.S and see if it beeps?
> 
> Hmm, maybe I know where problem could be. Try
> 
>         movl     $(wakeup_stack - wakeup_code), %esp              # Private stack is needed for ASUS bo\
> 
> instead of existing stack setup. That helped on one of my test-boxes
> -- I uncovered that during rewrite.

Well, that could explain some mysterious failures reported from time to time by
ASUS users.

Rafael

Re: suspend to ram problem

[matthieu castet]

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

Pavel Machek wrote:
> On Sun 2008-02-03 18:39:01, Rafael J. Wysocki wrote:

>>> So the hang seems located in wakeup_start.
>> Hm.  Can you add unconditional BEEP after "jne bogus_real_magic" in
>> arch/x86/kernel/acpi/wakeup.S and see if it beeps?
I rewrite the beep tracer to generate small beep (I should clean the 
patch and try to submit it), and I only hear 2 beep.

So it crash when clearing the flags.

> 
> Hmm, maybe I know where problem could be. Try
> 
>         movl     $(wakeup_stack - wakeup_code), %esp              # Private stack is needed for ASUS bo\
> 
> instead of existing stack setup. That helped on one of my test-boxes
Thanks, I will try that.
Because clearing the flags imply pop/push in the stack it could be the 
problem

Matthieu

[-- Attachment #2: beep_tracer.diff --]
[-- Type: text/x-patch, Size: 3430 bytes --]

--- /home/mat/tmp/wakeup.S	2008-02-03 19:20:26.000000000 +0100
+++ arch/i386/kernel/acpi/wakeup.S	2008-02-03 19:30:20.000000000 +0100
@@ -13,20 +13,47 @@
 # cs = 0x1234, eip = 0x05
 # 
 
+/* one ISA cycle @8Mhz */
+#define PAUSE outb %al, $0x80
+#define WAIT_100MS \
+	movl $800000, %eax; \
+	2: \
+	PAUSE; \
+	dec %eax; \
+	jne 2b
+
+/* What's the PIT rate */
+#define COUNT 0xf89
 #define BEEP \
-	inb	$97, %al; 	\
-	outb	%al, $0x80; 	\
-	movb	$3, %al; 	\
-	outb	%al, $97; 	\
-	outb	%al, $0x80; 	\
-	movb	$-74, %al; 	\
-	outb	%al, $67; 	\
-	outb	%al, $0x80; 	\
-	movb	$-119, %al; 	\
-	outb	%al, $66; 	\
-	outb	%al, $0x80; 	\
-	movb	$15, %al; 	\
-	outb	%al, $66;
+	/* enable counter 2 */ \
+	inb		$0x61, %al; 	\
+	PAUSE; 	\
+	orb	$3, %al; \
+	outb	%al, $0x61; 	\
+	PAUSE; 	\
+	/* set command for counter 2, 2 byte write */ \
+	movb	$0xB6, %al; 	\
+	outb	%al, $0x43; 	\
+	PAUSE; 	\
+	/* select desired HZ */ \
+	movb	$(COUNT & 0xff), %al; \
+	outb	%al, $0x42; 	\
+	PAUSE; 	\
+	movb	$(COUNT >> 8), %al; 	\
+	outb	%al, $0x42; \
+	WAIT_100MS; \
+	/* disable counter 2 */ \
+	inb		$0x61, %al; 	\
+	PAUSE; 	\
+	andb	$0xFC, %al; \
+	outb	%al, $0x61; \
+	WAIT_100MS
+
+#define CBEEP \
+	testl   $4, realmode_flags - wakeup_code; \
+	jz      1f; \
+	BEEP; \
+1:
 
 ALIGN
 	.align	4096
@@ -37,7 +64,8 @@
 
  	movw	$0xb800, %ax
 	movw	%ax,%fs
-	movw	$0x0e00 + 'L', %fs:(0x10)
+	#movw	$0x0e00 + 'L', %fs:(0x10)
+	CBEEP
 
 	cli
 	cld
@@ -47,19 +75,18 @@
 	movw	%ax, %ds					# Make ds:0 point to wakeup_start
 	movw	%ax, %ss
 
-	testl   $4, realmode_flags - wakeup_code
-	jz      1f
-	BEEP
-1:
 	mov	$(wakeup_stack - wakeup_code), %sp		# Private stack is needed for ASUS board
-	movw	$0x0e00 + 'S', %fs:(0x12)
+	#movw	$0x0e00 + 'S', %fs:(0x12)
+	CBEEP
 
 	pushl	$0						# Kill any dangerous flags
 	popfl
+	CBEEP
 
 	movl	real_magic - wakeup_code, %eax
 	cmpl	$0x12345678, %eax
 	jne	bogus_real_magic
+	CBEEP
 
 	testl	$1, realmode_flags - wakeup_code
 	jz	1f
@@ -79,6 +106,7 @@
 	movl	$swsusp_pg_dir-__PAGE_OFFSET, %eax
 	movl	%eax, %cr3
 
+	CBEEP
 	testl	$1, real_efer_save_restore - wakeup_code
 	jz	4f
 	# restore efer setting
@@ -87,12 +115,14 @@
 	mov     $0xc0000080, %ecx
 	wrmsr
 4:
+	CBEEP
 	# make sure %cr4 is set correctly (features, etc)
 	movl	real_save_cr4 - wakeup_code, %eax
 	movl	%eax, %cr4
 	movw	$0xb800, %ax
 	movw	%ax,%fs
-	movw	$0x0e00 + 'i', %fs:(0x12)
+	#movw	$0x0e00 + 'i', %fs:(0x12)
+	CBEEP
 	
 	# need a gdt -- use lgdtl to force 32-bit operands, in case
 	# the GDT is located past 16 megabytes.
@@ -102,15 +132,14 @@
 	movl	%eax, %cr0
 	jmp 1f
 1:
-	movw	$0x0e00 + 'n', %fs:(0x14)
+	#movw	$0x0e00 + 'n', %fs:(0x14)
+	CBEEP
 
 	movl	real_magic - wakeup_code, %eax
 	cmpl	$0x12345678, %eax
 	jne	bogus_real_magic
 
-	testl   $8, realmode_flags - wakeup_code
-	jz      1f
-	BEEP
+	CBEEP
 1:
 	ljmpl	$__KERNEL_CS, $wakeup_pmode_return
 
@@ -128,7 +157,8 @@
 real_save_efer_eax: 	.long 0
 
 bogus_real_magic:
-	movw	$0x0e00 + 'B', %fs:(0x12)
+	BEEP
+	#movw	$0x0e00 + 'B', %fs:(0x12)
 	jmp bogus_real_magic
 
 /* This code uses an extended set of video mode numbers. These include:
@@ -194,7 +224,7 @@
 	movw	%ax, %es
 	movw	%ax, %fs
 	movw	%ax, %gs
-	movw	$0x0e00 + 'u', 0xb8016
+	#movw	$0x0e00 + 'u', 0xb8016
 
 	# reload the gdt, as we need the full 32 bit address
 	lgdt	saved_gdt
@@ -218,7 +248,7 @@
 	jmp	*%eax
 
 bogus_magic:
-	movw	$0x0e00 + 'B', 0xb8018
+	#movw	$0x0e00 + 'B', 0xb8018
 	jmp	bogus_magic
 
 

Re: suspend to ram problem

[matthieu castet]

matthieu castet wrote:
> Pavel Machek wrote:

>> Hmm, maybe I know where problem could be. Try
>>
>>         movl     $(wakeup_stack - wakeup_code), %esp              # 
>> Private stack is needed for ASUS bo\
>>
>> instead of existing stack setup. That helped on one of my test-boxes
> Thanks, I will try that.
> Because clearing the flags imply pop/push in the stack it could be the 
> problem
That doesn't help : it still crash in pushl $0.

Matthieu

Re: suspend to ram problem

[matthieu castet]

Hi,

matthieu castet wrote:
> matthieu castet wrote:
>> Pavel Machek wrote:
> 
>>> Hmm, maybe I know where problem could be. Try
>>>
>>>         movl     $(wakeup_stack - wakeup_code), %esp              # 
>>> Private stack is needed for ASUS bo\
>>>
>>> instead of existing stack setup. That helped on one of my test-boxes
>> Thanks, I will try that.
>> Because clearing the flags imply pop/push in the stack it could be the 
>> problem
> That doesn't help : it still crash in pushl $0.
> 
All stack stuff in wakeup_code crash for me.
I tried to change the stack position, make sure upper bit of %esp are 
clear, ... nothing work.
What's are strange is that according to my x86 manual, in real mode the 
failure can only happen if the stack wrap which is not the case here.
Any x86 guru advice ?

If I remove stack access (remove clearing flag stuff, not call to video 
stuff) the resume works.


Matthieu

Re: suspend to ram problem

[Rafael J. Wysocki]

On Wednesday, 6 of February 2008, matthieu castet wrote:
> Hi,
> 
> matthieu castet wrote:
> > matthieu castet wrote:
> >> Pavel Machek wrote:
> > 
> >>> Hmm, maybe I know where problem could be. Try
> >>>
> >>>         movl     $(wakeup_stack - wakeup_code), %esp              # 
> >>> Private stack is needed for ASUS bo\
> >>>
> >>> instead of existing stack setup. That helped on one of my test-boxes
> >> Thanks, I will try that.
> >> Because clearing the flags imply pop/push in the stack it could be the 
> >> problem
> > That doesn't help : it still crash in pushl $0.
> > 
> All stack stuff in wakeup_code crash for me.
> I tried to change the stack position, make sure upper bit of %esp are 
> clear, ... nothing work.
> What's are strange is that according to my x86 manual, in real mode the 
> failure can only happen if the stack wrap which is not the case here.
> Any x86 guru advice ?
> 
> If I remove stack access (remove clearing flag stuff, not call to video 
> stuff) the resume works.

Hm, can you place a "pushl %eax; popl %eax;" in place of the removed code and
see if that breaks?

Rafael

Re: suspend to ram problem

[Rafael J. Wysocki]

On Wednesday, 6 of February 2008, matthieu castet wrote:
> Hi,
> 
> matthieu castet wrote:
> > matthieu castet wrote:
> >> Pavel Machek wrote:
> > 
> >>> Hmm, maybe I know where problem could be. Try
> >>>
> >>>         movl     $(wakeup_stack - wakeup_code), %esp              # 
> >>> Private stack is needed for ASUS bo\
> >>>
> >>> instead of existing stack setup. That helped on one of my test-boxes
> >> Thanks, I will try that.
> >> Because clearing the flags imply pop/push in the stack it could be the 
> >> problem
> > That doesn't help : it still crash in pushl $0.
> > 
> All stack stuff in wakeup_code crash for me.
> I tried to change the stack position, make sure upper bit of %esp are 
> clear, ... nothing work.
> What's are strange is that according to my x86 manual, in real mode the 
> failure can only happen if the stack wrap which is not the case here.
> Any x86 guru advice ?
> 
> If I remove stack access (remove clearing flag stuff, not call to video 
> stuff) the resume works.

Hm, can you place a "pushl %eax; popl %eax;" in place of the removed code and
see if that breaks?

Rafael

Re: suspend to ram problem

[matthieu castet]

Rafael J. Wysocki wrote:
> On Wednesday, 6 of February 2008, matthieu castet wrote:
>> Hi,
>>
>> matthieu castet wrote:
>>> matthieu castet wrote:
>>>> Pavel Machek wrote:
>>>>> Hmm, maybe I know where problem could be. Try
>>>>>
>>>>>         movl     $(wakeup_stack - wakeup_code), %esp              # 
>>>>> Private stack is needed for ASUS bo\
>>>>>
>>>>> instead of existing stack setup. That helped on one of my test-boxes
>>>> Thanks, I will try that.
>>>> Because clearing the flags imply pop/push in the stack it could be the 
>>>> problem
>>> That doesn't help : it still crash in pushl $0.
>>>
>> All stack stuff in wakeup_code crash for me.
>> I tried to change the stack position, make sure upper bit of %esp are 
>> clear, ... nothing work.
>> What's are strange is that according to my x86 manual, in real mode the 
>> failure can only happen if the stack wrap which is not the case here.
>> Any x86 guru advice ?
>>
>> If I remove stack access (remove clearing flag stuff, not call to video 
>> stuff) the resume works.
> 
> Hm, can you place a "pushl %eax; popl %eax;" in place of the removed code and
> see if that breaks?
Yes that also break.

Matthieu

Re: suspend to ram problem

[matthieu castet]

Rafael J. Wysocki wrote:
> On Wednesday, 6 of February 2008, matthieu castet wrote:
>> Hi,
>>
>> matthieu castet wrote:
>>> matthieu castet wrote:
>>>> Pavel Machek wrote:
>>>>> Hmm, maybe I know where problem could be. Try
>>>>>
>>>>>         movl     $(wakeup_stack - wakeup_code), %esp              # 
>>>>> Private stack is needed for ASUS bo\
>>>>>
>>>>> instead of existing stack setup. That helped on one of my test-boxes
>>>> Thanks, I will try that.
>>>> Because clearing the flags imply pop/push in the stack it could be the 
>>>> problem
>>> That doesn't help : it still crash in pushl $0.
>>>
>> All stack stuff in wakeup_code crash for me.
>> I tried to change the stack position, make sure upper bit of %esp are 
>> clear, ... nothing work.
>> What's are strange is that according to my x86 manual, in real mode the 
>> failure can only happen if the stack wrap which is not the case here.
>> Any x86 guru advice ?
>>
>> If I remove stack access (remove clearing flag stuff, not call to video 
>> stuff) the resume works.
> 
> Hm, can you place a "pushl %eax; popl %eax;" in place of the removed code and
> see if that breaks?
Yes that also break.

Matthieu

Re: suspend to ram problem

[Pavel Machek]

Hi!

>>>>>> instead of existing stack setup. That helped on one of my test-boxes
>>>>> Thanks, I will try that.
>>>>> Because clearing the flags imply pop/push in the stack it could be the 
>>>>> problem
>>>> That doesn't help : it still crash in pushl $0.
>>>>
>>> All stack stuff in wakeup_code crash for me.
>>> I tried to change the stack position, make sure upper bit of %esp are 
>>> clear, ... nothing work.
>>> What's are strange is that according to my x86 manual, in real mode the 
>>> failure can only happen if the stack wrap which is not the case here.
>>> Any x86 guru advice ?
>>>
>>> If I remove stack access (remove clearing flag stuff, not call to video 
>>> stuff) the resume works.
>>
>> Hm, can you place a "pushl %eax; popl %eax;" in place of the removed code and
>> see if that breaks?
> Yes that also break.

Not sure what is going on... but if you remove all the stack
references, does it go up to 32-bit mode?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: suspend to ram problem

[Pavel Machek]

Hi!

>>>>>> instead of existing stack setup. That helped on one of my test-boxes
>>>>> Thanks, I will try that.
>>>>> Because clearing the flags imply pop/push in the stack it could be the 
>>>>> problem
>>>> That doesn't help : it still crash in pushl $0.
>>>>
>>> All stack stuff in wakeup_code crash for me.
>>> I tried to change the stack position, make sure upper bit of %esp are 
>>> clear, ... nothing work.
>>> What's are strange is that according to my x86 manual, in real mode the 
>>> failure can only happen if the stack wrap which is not the case here.
>>> Any x86 guru advice ?
>>>
>>> If I remove stack access (remove clearing flag stuff, not call to video 
>>> stuff) the resume works.
>>
>> Hm, can you place a "pushl %eax; popl %eax;" in place of the removed code and
>> see if that breaks?
> Yes that also break.

Not sure what is going on... but if you remove all the stack
references, does it go up to 32-bit mode?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: suspend to ram problem

[Rafael J. Wysocki]

On Wednesday, 6 of February 2008, Pavel Machek wrote:
> Hi!
> 
> >>>>>> instead of existing stack setup. That helped on one of my test-boxes
> >>>>> Thanks, I will try that.
> >>>>> Because clearing the flags imply pop/push in the stack it could be the 
> >>>>> problem
> >>>> That doesn't help : it still crash in pushl $0.
> >>>>
> >>> All stack stuff in wakeup_code crash for me.
> >>> I tried to change the stack position, make sure upper bit of %esp are 
> >>> clear, ... nothing work.
> >>> What's are strange is that according to my x86 manual, in real mode the 
> >>> failure can only happen if the stack wrap which is not the case here.
> >>> Any x86 guru advice ?
> >>>
> >>> If I remove stack access (remove clearing flag stuff, not call to video 
> >>> stuff) the resume works.
> >>
> >> Hm, can you place a "pushl %eax; popl %eax;" in place of the removed code and
> >> see if that breaks?
> > Yes that also break.

Interesting.

> Not sure what is going on...

Looks like ss goes bonkers or the 32-bit opcodes are invalid in real mode.

Matthieu, can you try "pushw %ax; popw %ax;", please?

Rafael

Re: suspend to ram problem

[Rafael J. Wysocki]

On Wednesday, 6 of February 2008, Pavel Machek wrote:
> Hi!
> 
> >>>>>> instead of existing stack setup. That helped on one of my test-boxes
> >>>>> Thanks, I will try that.
> >>>>> Because clearing the flags imply pop/push in the stack it could be the 
> >>>>> problem
> >>>> That doesn't help : it still crash in pushl $0.
> >>>>
> >>> All stack stuff in wakeup_code crash for me.
> >>> I tried to change the stack position, make sure upper bit of %esp are 
> >>> clear, ... nothing work.
> >>> What's are strange is that according to my x86 manual, in real mode the 
> >>> failure can only happen if the stack wrap which is not the case here.
> >>> Any x86 guru advice ?
> >>>
> >>> If I remove stack access (remove clearing flag stuff, not call to video 
> >>> stuff) the resume works.
> >>
> >> Hm, can you place a "pushl %eax; popl %eax;" in place of the removed code and
> >> see if that breaks?
> > Yes that also break.

Interesting.

> Not sure what is going on...

Looks like ss goes bonkers or the 32-bit opcodes are invalid in real mode.

Matthieu, can you try "pushw %ax; popw %ax;", please?

Rafael

Re: suspend to ram problem

[Cacy Rodney]

I have read somewhere that the problem appeared at the beginning of 
2.6.24 development. I'm using pure 2.6.23 (sony vaio laptop) and I have 
experienced the problem of returning from suspend to ram as well. It 
always occurs when the battery is present in the slot and never without 
it. I did not have such problem with 2.6.19-rc3. I tried the 2.6.23-12 
and 2.6.24 but without any better.
If you need any details about my configuration write me please.
regards
cacy

Re: suspend to ram problem

[Pavel Machek]

On Wed 2008-02-06 23:40:35, matthieu castet wrote:
> Rafael J. Wysocki wrote:
>> On Wednesday, 6 of February 2008, matthieu castet wrote:
>>> Hi,
>>>
>>> matthieu castet wrote:
>>>> matthieu castet wrote:
>>>>> Pavel Machek wrote:
>>>>>> Hmm, maybe I know where problem could be. Try
>>>>>>
>>>>>>         movl     $(wakeup_stack - wakeup_code), %esp              # 
>>>>>> Private stack is needed for ASUS bo\
>>>>>>
>>>>>> instead of existing stack setup. That helped on one of my test-boxes
>>>>> Thanks, I will try that.
>>>>> Because clearing the flags imply pop/push in the stack it could be the 
>>>>> problem
>>>> That doesn't help : it still crash in pushl $0.
>>>>
>>> All stack stuff in wakeup_code crash for me.
>>> I tried to change the stack position, make sure upper bit of %esp are 
>>> clear, ... nothing work.
>>> What's are strange is that according to my x86 manual, in real mode the 
>>> failure can only happen if the stack wrap which is not the case here.
>>> Any x86 guru advice ?
>>>
>>> If I remove stack access (remove clearing flag stuff, not call to video 
>>> stuff) the resume works.
>>
>> Hm, can you place a "pushl %eax; popl %eax;" in place of the removed code and
>> see if that breaks?
> Yes that also break.

Hmm, and what kind of machine is that?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: suspend to ram problem

[matthieu castet]

Pavel Machek wrote:
> On Wed 2008-02-06 23:40:35, matthieu castet wrote:
>>>> If I remove stack access (remove clearing flag stuff, not call to video 
>>>> stuff) the resume works.
>>> Hm, can you place a "pushl %eax; popl %eax;" in place of the removed code and
>>> see if that breaks?
>> Yes that also break.
> 
> Hmm, and what kind of machine is that?
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 6
model           : 6
model name      : AMD Athlon(tm) XP 1800+
stepping        : 2
cpu MHz         : 1533.490
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge 
mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow ts
bogomips        : 3070.84
clflush size    : 32

Re: suspend to ram problem

[matthieu castet]

Pavel Machek wrote:
> On Wed 2008-02-06 23:40:35, matthieu castet wrote:
>>>> If I remove stack access (remove clearing flag stuff, not call to video 
>>>> stuff) the resume works.
>>> Hm, can you place a "pushl %eax; popl %eax;" in place of the removed code and
>>> see if that breaks?
>> Yes that also break.
> 
> Hmm, and what kind of machine is that?
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 6
model           : 6
model name      : AMD Athlon(tm) XP 1800+
stepping        : 2
cpu MHz         : 1533.490
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge 
mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow ts
bogomips        : 3070.84
clflush size    : 32

Re: suspend to ram problem

[Pavel Machek]

Hi!

>>>>> If I remove stack access (remove clearing flag stuff, not call to video 
>>>>> stuff) the resume works.
>>>> Hm, can you place a "pushl %eax; popl %eax;" in place of the removed code and
>>>> see if that breaks?
>>> Yes that also break.
>>
>> Hmm, and what kind of machine is that?
> processor       : 0
> vendor_id       : AuthenticAMD
> cpu family      : 6
> model           : 6
> model name      : AMD Athlon(tm) XP 1800+
> stepping        : 2
> cpu MHz         : 1533.490
> cache size      : 256 KB
> fdiv_bug        : no
> hlt_bug         : no
> f00f_bug        : no
> coma_bug        : no
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 1
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
> cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow ts
> bogomips        : 3070.84
> clflush size    : 32

So I assume it is some kind of desktop?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: suspend to ram problem

[matthieu castet]

Hi,


Pavel Machek wrote:
> Hi!
> So I assume it is some kind of desktop?
Yes.

>>
>> ...if someone calls start as 0x1234:0, we are okay. But if some broken
>> bios calls us as 0x1:0x234, we've got a problem.
>
> Well, in that case the signature/end_signature tests below would 
 >trigger, no?

Yes, and for example the beep flag won't work.

>
> Not sure what is going on... but if you remove all the stack
> references, does it go up to 32-bit mode?
Yes, but I end up with a kernel panic after console resume and some 
resume stuff.

 > Looks like ss goes bonkers or the 32-bit opcodes are invalid in real 
mode.
 > Matthieu, can you try "pushw %ax; popw %ax;", please?
I still crash.
I also try to set ss to 0, and hardcode the stack (knowing we are loaded 
at 0x1000). And it crash.


I wonder if there a way to check that we are realy in real mode ?


Matthieu

Re: suspend to ram problem

[matthieu castet]

Hi,


Pavel Machek wrote:
> Hi!
> So I assume it is some kind of desktop?
Yes.

>>
>> ...if someone calls start as 0x1234:0, we are okay. But if some broken
>> bios calls us as 0x1:0x234, we've got a problem.
>
> Well, in that case the signature/end_signature tests below would 
 >trigger, no?

Yes, and for example the beep flag won't work.

>
> Not sure what is going on... but if you remove all the stack
> references, does it go up to 32-bit mode?
Yes, but I end up with a kernel panic after console resume and some 
resume stuff.

 > Looks like ss goes bonkers or the 32-bit opcodes are invalid in real 
mode.
 > Matthieu, can you try "pushw %ax; popw %ax;", please?
I still crash.
I also try to set ss to 0, and hardcode the stack (knowing we are loaded 
at 0x1000). And it crash.


I wonder if there a way to check that we are realy in real mode ?


Matthieu

Re: suspend to ram problem

[Rafael J. Wysocki]

On Thursday, 7 of February 2008, matthieu castet wrote:
> Hi,
> 
> 
> Pavel Machek wrote:
> > Hi!
> > So I assume it is some kind of desktop?
> Yes.
> 
> >>
> >> ...if someone calls start as 0x1234:0, we are okay. But if some broken
> >> bios calls us as 0x1:0x234, we've got a problem.
> >
> > Well, in that case the signature/end_signature tests below would 
>  >trigger, no?
> 
> Yes, and for example the beep flag won't work.
> 
> >
> > Not sure what is going on... but if you remove all the stack
> > references, does it go up to 32-bit mode?
> Yes, but I end up with a kernel panic after console resume and some 
> resume stuff.
> 
>  > Looks like ss goes bonkers or the 32-bit opcodes are invalid in real 
> mode.
>  > Matthieu, can you try "pushw %ax; popw %ax;", please?
> I still crash.
> I also try to set ss to 0, and hardcode the stack (knowing we are loaded 
> at 0x1000). And it crash.
> 
> 
> I wonder if there a way to check that we are realy in real mode ?

Yes.  In real mode bit 0 of the cr0 register should be 0.

Thanks,
Rafael

Re: suspend to ram problem

[Rafael J. Wysocki]

On Thursday, 7 of February 2008, matthieu castet wrote:
> Hi,
> 
> 
> Pavel Machek wrote:
> > Hi!
> > So I assume it is some kind of desktop?
> Yes.
> 
> >>
> >> ...if someone calls start as 0x1234:0, we are okay. But if some broken
> >> bios calls us as 0x1:0x234, we've got a problem.
> >
> > Well, in that case the signature/end_signature tests below would 
>  >trigger, no?
> 
> Yes, and for example the beep flag won't work.
> 
> >
> > Not sure what is going on... but if you remove all the stack
> > references, does it go up to 32-bit mode?
> Yes, but I end up with a kernel panic after console resume and some 
> resume stuff.
> 
>  > Looks like ss goes bonkers or the 32-bit opcodes are invalid in real 
> mode.
>  > Matthieu, can you try "pushw %ax; popw %ax;", please?
> I still crash.
> I also try to set ss to 0, and hardcode the stack (knowing we are loaded 
> at 0x1000). And it crash.
> 
> 
> I wonder if there a way to check that we are realy in real mode ?

Yes.  In real mode bit 0 of the cr0 register should be 0.

Thanks,
Rafael

Re: suspend to ram problem

[Pavel Machek]

> > I wonder if there a way to check that we are realy in real mode ?
> 
> Yes.  In real mode bit 0 of the cr0 register should be 0.

It is not as simple. There's stuff like "unreal" mode... real mode
with 4GB descriptor limits... and similar crazyness.
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: suspend to ram problem

[Pavel Machek]

> > I wonder if there a way to check that we are realy in real mode ?
> 
> Yes.  In real mode bit 0 of the cr0 register should be 0.

It is not as simple. There's stuff like "unreal" mode... real mode
with 4GB descriptor limits... and similar crazyness.
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: suspend to ram problem

[Pavel Machek]

Hi!

>>>>> If I remove stack access (remove clearing flag stuff, not call to video 
>>>>> stuff) the resume works.
>>>> Hm, can you place a "pushl %eax; popl %eax;" in place of the removed code and
>>>> see if that breaks?
>>> Yes that also break.
>>
>> Hmm, and what kind of machine is that?
> processor       : 0
> vendor_id       : AuthenticAMD
> cpu family      : 6
> model           : 6
> model name      : AMD Athlon(tm) XP 1800+
> stepping        : 2
> cpu MHz         : 1533.490
> cache size      : 256 KB
> fdiv_bug        : no
> hlt_bug         : no
> f00f_bug        : no
> coma_bug        : no
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 1
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
> cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow ts
> bogomips        : 3070.84
> clflush size    : 32

So I assume it is some kind of desktop?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: suspend to ram problem

[Pavel Machek]

On Wed 2008-02-06 23:40:35, matthieu castet wrote:
> Rafael J. Wysocki wrote:
>> On Wednesday, 6 of February 2008, matthieu castet wrote:
>>> Hi,
>>>
>>> matthieu castet wrote:
>>>> matthieu castet wrote:
>>>>> Pavel Machek wrote:
>>>>>> Hmm, maybe I know where problem could be. Try
>>>>>>
>>>>>>         movl     $(wakeup_stack - wakeup_code), %esp              # 
>>>>>> Private stack is needed for ASUS bo\
>>>>>>
>>>>>> instead of existing stack setup. That helped on one of my test-boxes
>>>>> Thanks, I will try that.
>>>>> Because clearing the flags imply pop/push in the stack it could be the 
>>>>> problem
>>>> That doesn't help : it still crash in pushl $0.
>>>>
>>> All stack stuff in wakeup_code crash for me.
>>> I tried to change the stack position, make sure upper bit of %esp are 
>>> clear, ... nothing work.
>>> What's are strange is that according to my x86 manual, in real mode the 
>>> failure can only happen if the stack wrap which is not the case here.
>>> Any x86 guru advice ?
>>>
>>> If I remove stack access (remove clearing flag stuff, not call to video 
>>> stuff) the resume works.
>>
>> Hm, can you place a "pushl %eax; popl %eax;" in place of the removed code and
>> see if that breaks?
> Yes that also break.

Hmm, and what kind of machine is that?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: suspend to ram problem

[Pavel Machek]

Hi!

>>>> Hmm, maybe I know where problem could be. Try
>>>>
>>>>         movl     $(wakeup_stack - wakeup_code), %esp              # 
>>>> Private stack is needed for ASUS bo\
>>>>
>>>> instead of existing stack setup. That helped on one of my test-boxes
>>> Thanks, I will try that.
>>> Because clearing the flags imply pop/push in the stack it could be the 
>>> problem
>> That doesn't help : it still crash in pushl $0.
>>
> All stack stuff in wakeup_code crash for me.
> I tried to change the stack position, make sure upper bit of %esp are 
> clear, ... nothing work.
> What's are strange is that according to my x86 manual, in real mode the 
> failure can only happen if the stack wrap which is not the case here.
> Any x86 guru advice ?

Could you try the .c wakeup? I changed it a bit, perhaps that's enough.

> If I remove stack access (remove clearing flag stuff, not call to video 
> stuff) the resume works.

Actually, I see a possible problem:

_start:
        cli
        cld

        /* Set up segments */
        movw    %cs,%ax
        movw    %ax,%ds
        movw    %ax,%es
        movw    %ax,%ss

        movl    $wakeup_stack_end, %esp

        /* Clear the EFLAGS */
        pushl   $0
        popfl

...if someone calls start as 0x1234:0, we are okay. But if some broken
bios calls us as 0x1:0x234, we've got a problem.

One possible hack would be to movl 0, %esp. That should put the stack
at _start, corrupting memory but hopefully helping you diagnose it.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: suspend to ram problem

[Rafael J. Wysocki]

On Thursday, 7 of February 2008, Pavel Machek wrote:
> Hi!

Hi,

> >>>> Hmm, maybe I know where problem could be. Try
> >>>>
> >>>>         movl     $(wakeup_stack - wakeup_code), %esp              # 
> >>>> Private stack is needed for ASUS bo\
> >>>>
> >>>> instead of existing stack setup. That helped on one of my test-boxes
> >>> Thanks, I will try that.
> >>> Because clearing the flags imply pop/push in the stack it could be the 
> >>> problem
> >> That doesn't help : it still crash in pushl $0.
> >>
> > All stack stuff in wakeup_code crash for me.
> > I tried to change the stack position, make sure upper bit of %esp are 
> > clear, ... nothing work.
> > What's are strange is that according to my x86 manual, in real mode the 
> > failure can only happen if the stack wrap which is not the case here.
> > Any x86 guru advice ?
> 
> Could you try the .c wakeup? I changed it a bit, perhaps that's enough.
> 
> > If I remove stack access (remove clearing flag stuff, not call to video 
> > stuff) the resume works.
> 
> Actually, I see a possible problem:
> 
> _start:
>         cli
>         cld
> 
>         /* Set up segments */
>         movw    %cs,%ax
>         movw    %ax,%ds
>         movw    %ax,%es
>         movw    %ax,%ss
> 
>         movl    $wakeup_stack_end, %esp
> 
>         /* Clear the EFLAGS */
>         pushl   $0
>         popfl
> 
> ...if someone calls start as 0x1234:0, we are okay. But if some broken
> bios calls us as 0x1:0x234, we've got a problem.

Well, in that case the signature/end_signature tests below would trigger, no?

Rafael

Re: suspend to ram problem

[Rafael J. Wysocki]

On Thursday, 7 of February 2008, Pavel Machek wrote:
> Hi!

Hi,

> >>>> Hmm, maybe I know where problem could be. Try
> >>>>
> >>>>         movl     $(wakeup_stack - wakeup_code), %esp              # 
> >>>> Private stack is needed for ASUS bo\
> >>>>
> >>>> instead of existing stack setup. That helped on one of my test-boxes
> >>> Thanks, I will try that.
> >>> Because clearing the flags imply pop/push in the stack it could be the 
> >>> problem
> >> That doesn't help : it still crash in pushl $0.
> >>
> > All stack stuff in wakeup_code crash for me.
> > I tried to change the stack position, make sure upper bit of %esp are 
> > clear, ... nothing work.
> > What's are strange is that according to my x86 manual, in real mode the 
> > failure can only happen if the stack wrap which is not the case here.
> > Any x86 guru advice ?
> 
> Could you try the .c wakeup? I changed it a bit, perhaps that's enough.
> 
> > If I remove stack access (remove clearing flag stuff, not call to video 
> > stuff) the resume works.
> 
> Actually, I see a possible problem:
> 
> _start:
>         cli
>         cld
> 
>         /* Set up segments */
>         movw    %cs,%ax
>         movw    %ax,%ds
>         movw    %ax,%es
>         movw    %ax,%ss
> 
>         movl    $wakeup_stack_end, %esp
> 
>         /* Clear the EFLAGS */
>         pushl   $0
>         popfl
> 
> ...if someone calls start as 0x1234:0, we are okay. But if some broken
> bios calls us as 0x1:0x234, we've got a problem.

Well, in that case the signature/end_signature tests below would trigger, no?

Rafael

Re: suspend to ram problem

[Pavel Machek]

Hi!

>>>> Hmm, maybe I know where problem could be. Try
>>>>
>>>>         movl     $(wakeup_stack - wakeup_code), %esp              # 
>>>> Private stack is needed for ASUS bo\
>>>>
>>>> instead of existing stack setup. That helped on one of my test-boxes
>>> Thanks, I will try that.
>>> Because clearing the flags imply pop/push in the stack it could be the 
>>> problem
>> That doesn't help : it still crash in pushl $0.
>>
> All stack stuff in wakeup_code crash for me.
> I tried to change the stack position, make sure upper bit of %esp are 
> clear, ... nothing work.
> What's are strange is that according to my x86 manual, in real mode the 
> failure can only happen if the stack wrap which is not the case here.
> Any x86 guru advice ?

Could you try the .c wakeup? I changed it a bit, perhaps that's enough.

> If I remove stack access (remove clearing flag stuff, not call to video 
> stuff) the resume works.

Actually, I see a possible problem:

_start:
        cli
        cld

        /* Set up segments */
        movw    %cs,%ax
        movw    %ax,%ds
        movw    %ax,%es
        movw    %ax,%ss

        movl    $wakeup_stack_end, %esp

        /* Clear the EFLAGS */
        pushl   $0
        popfl

...if someone calls start as 0x1234:0, we are okay. But if some broken
bios calls us as 0x1:0x234, we've got a problem.

One possible hack would be to movl 0, %esp. That should put the stack
at _start, corrupting memory but hopefully helping you diagnose it.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: suspend to ram problem

[matthieu castet]

Hi,

matthieu castet wrote:
> matthieu castet wrote:
>> Pavel Machek wrote:
> 
>>> Hmm, maybe I know where problem could be. Try
>>>
>>>         movl     $(wakeup_stack - wakeup_code), %esp              # 
>>> Private stack is needed for ASUS bo\
>>>
>>> instead of existing stack setup. That helped on one of my test-boxes
>> Thanks, I will try that.
>> Because clearing the flags imply pop/push in the stack it could be the 
>> problem
> That doesn't help : it still crash in pushl $0.
> 
All stack stuff in wakeup_code crash for me.
I tried to change the stack position, make sure upper bit of %esp are 
clear, ... nothing work.
What's are strange is that according to my x86 manual, in real mode the 
failure can only happen if the stack wrap which is not the case here.
Any x86 guru advice ?

If I remove stack access (remove clearing flag stuff, not call to video 
stuff) the resume works.


Matthieu

Re: suspend to ram problem

[matthieu castet]

matthieu castet wrote:
> Pavel Machek wrote:

>> Hmm, maybe I know where problem could be. Try
>>
>>         movl     $(wakeup_stack - wakeup_code), %esp              # 
>> Private stack is needed for ASUS bo\
>>
>> instead of existing stack setup. That helped on one of my test-boxes
> Thanks, I will try that.
> Because clearing the flags imply pop/push in the stack it could be the 
> problem
That doesn't help : it still crash in pushl $0.

Matthieu

Re: suspend to ram problem

[matthieu castet]

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

Pavel Machek wrote:
> On Sun 2008-02-03 18:39:01, Rafael J. Wysocki wrote:

>>> So the hang seems located in wakeup_start.
>> Hm.  Can you add unconditional BEEP after "jne bogus_real_magic" in
>> arch/x86/kernel/acpi/wakeup.S and see if it beeps?
I rewrite the beep tracer to generate small beep (I should clean the 
patch and try to submit it), and I only hear 2 beep.

So it crash when clearing the flags.

> 
> Hmm, maybe I know where problem could be. Try
> 
>         movl     $(wakeup_stack - wakeup_code), %esp              # Private stack is needed for ASUS bo\
> 
> instead of existing stack setup. That helped on one of my test-boxes
Thanks, I will try that.
Because clearing the flags imply pop/push in the stack it could be the 
problem

Matthieu

[-- Attachment #2: beep_tracer.diff --]
[-- Type: text/x-patch, Size: 3430 bytes --]

--- /home/mat/tmp/wakeup.S	2008-02-03 19:20:26.000000000 +0100
+++ arch/i386/kernel/acpi/wakeup.S	2008-02-03 19:30:20.000000000 +0100
@@ -13,20 +13,47 @@
 # cs = 0x1234, eip = 0x05
 # 
 
+/* one ISA cycle @8Mhz */
+#define PAUSE outb %al, $0x80
+#define WAIT_100MS \
+	movl $800000, %eax; \
+	2: \
+	PAUSE; \
+	dec %eax; \
+	jne 2b
+
+/* What's the PIT rate */
+#define COUNT 0xf89
 #define BEEP \
-	inb	$97, %al; 	\
-	outb	%al, $0x80; 	\
-	movb	$3, %al; 	\
-	outb	%al, $97; 	\
-	outb	%al, $0x80; 	\
-	movb	$-74, %al; 	\
-	outb	%al, $67; 	\
-	outb	%al, $0x80; 	\
-	movb	$-119, %al; 	\
-	outb	%al, $66; 	\
-	outb	%al, $0x80; 	\
-	movb	$15, %al; 	\
-	outb	%al, $66;
+	/* enable counter 2 */ \
+	inb		$0x61, %al; 	\
+	PAUSE; 	\
+	orb	$3, %al; \
+	outb	%al, $0x61; 	\
+	PAUSE; 	\
+	/* set command for counter 2, 2 byte write */ \
+	movb	$0xB6, %al; 	\
+	outb	%al, $0x43; 	\
+	PAUSE; 	\
+	/* select desired HZ */ \
+	movb	$(COUNT & 0xff), %al; \
+	outb	%al, $0x42; 	\
+	PAUSE; 	\
+	movb	$(COUNT >> 8), %al; 	\
+	outb	%al, $0x42; \
+	WAIT_100MS; \
+	/* disable counter 2 */ \
+	inb		$0x61, %al; 	\
+	PAUSE; 	\
+	andb	$0xFC, %al; \
+	outb	%al, $0x61; \
+	WAIT_100MS
+
+#define CBEEP \
+	testl   $4, realmode_flags - wakeup_code; \
+	jz      1f; \
+	BEEP; \
+1:
 
 ALIGN
 	.align	4096
@@ -37,7 +64,8 @@
 
  	movw	$0xb800, %ax
 	movw	%ax,%fs
-	movw	$0x0e00 + 'L', %fs:(0x10)
+	#movw	$0x0e00 + 'L', %fs:(0x10)
+	CBEEP
 
 	cli
 	cld
@@ -47,19 +75,18 @@
 	movw	%ax, %ds					# Make ds:0 point to wakeup_start
 	movw	%ax, %ss
 
-	testl   $4, realmode_flags - wakeup_code
-	jz      1f
-	BEEP
-1:
 	mov	$(wakeup_stack - wakeup_code), %sp		# Private stack is needed for ASUS board
-	movw	$0x0e00 + 'S', %fs:(0x12)
+	#movw	$0x0e00 + 'S', %fs:(0x12)
+	CBEEP
 
 	pushl	$0						# Kill any dangerous flags
 	popfl
+	CBEEP
 
 	movl	real_magic - wakeup_code, %eax
 	cmpl	$0x12345678, %eax
 	jne	bogus_real_magic
+	CBEEP
 
 	testl	$1, realmode_flags - wakeup_code
 	jz	1f
@@ -79,6 +106,7 @@
 	movl	$swsusp_pg_dir-__PAGE_OFFSET, %eax
 	movl	%eax, %cr3
 
+	CBEEP
 	testl	$1, real_efer_save_restore - wakeup_code
 	jz	4f
 	# restore efer setting
@@ -87,12 +115,14 @@
 	mov     $0xc0000080, %ecx
 	wrmsr
 4:
+	CBEEP
 	# make sure %cr4 is set correctly (features, etc)
 	movl	real_save_cr4 - wakeup_code, %eax
 	movl	%eax, %cr4
 	movw	$0xb800, %ax
 	movw	%ax,%fs
-	movw	$0x0e00 + 'i', %fs:(0x12)
+	#movw	$0x0e00 + 'i', %fs:(0x12)
+	CBEEP
 	
 	# need a gdt -- use lgdtl to force 32-bit operands, in case
 	# the GDT is located past 16 megabytes.
@@ -102,15 +132,14 @@
 	movl	%eax, %cr0
 	jmp 1f
 1:
-	movw	$0x0e00 + 'n', %fs:(0x14)
+	#movw	$0x0e00 + 'n', %fs:(0x14)
+	CBEEP
 
 	movl	real_magic - wakeup_code, %eax
 	cmpl	$0x12345678, %eax
 	jne	bogus_real_magic
 
-	testl   $8, realmode_flags - wakeup_code
-	jz      1f
-	BEEP
+	CBEEP
 1:
 	ljmpl	$__KERNEL_CS, $wakeup_pmode_return
 
@@ -128,7 +157,8 @@
 real_save_efer_eax: 	.long 0
 
 bogus_real_magic:
-	movw	$0x0e00 + 'B', %fs:(0x12)
+	BEEP
+	#movw	$0x0e00 + 'B', %fs:(0x12)
 	jmp bogus_real_magic
 
 /* This code uses an extended set of video mode numbers. These include:
@@ -194,7 +224,7 @@
 	movw	%ax, %es
 	movw	%ax, %fs
 	movw	%ax, %gs
-	movw	$0x0e00 + 'u', 0xb8016
+	#movw	$0x0e00 + 'u', 0xb8016
 
 	# reload the gdt, as we need the full 32 bit address
 	lgdt	saved_gdt
@@ -218,7 +248,7 @@
 	jmp	*%eax
 
 bogus_magic:
-	movw	$0x0e00 + 'B', 0xb8018
+	#movw	$0x0e00 + 'B', 0xb8018
 	jmp	bogus_magic
 
 

[-- Attachment #3: Type: text/plain, Size: 0 bytes --]

Re: suspend to ram problem

[Pavel Machek]

On Sun 2008-02-03 18:39:01, Rafael J. Wysocki wrote:
> On Sunday, 3 of February 2008, matthieu castet wrote:
> > matthieu castet wrote:
> > > Hi,
> > > 
> > > I am trying to make work suspend to ram on a MSI MS-6380E with a 2.6.23 
> > > kernel.
> > > 
> > > Standby mode works.
> > > S2ram suspend seems to work : the computer turn off and I can wake up it 
> > > with the keyboard.
> > > 
> > > But when the computer wakeup, I see the video card POST on the screen, 
> > > but after that the computer hangs : black screen, no working numlock.
> > > 
> > > I tried to compile PM_TRACE, but it give no result. So this means the 
> > > resume hang very early.
> > > 
> > > What can I do to debug this ?
> > >
> > I play with the s2_beep feature and :
> > - echo 4 > /proc/sys/kernel/acpi_video_flags make the computer beep
> > - echo 4 > /proc/sys/kernel/acpi_video_flags make the computer not beep
> > - adding a beep in bogus_real_magic, make the computer not beep
> > 
> > So the hang seems located in wakeup_start.
> 
> Hm.  Can you add unconditional BEEP after "jne bogus_real_magic" in
> arch/x86/kernel/acpi/wakeup.S and see if it beeps?

Hmm, maybe I know where problem could be. Try

        movl     $(wakeup_stack - wakeup_code), %esp              # Private stack is needed for ASUS bo\

instead of existing stack setup. That helped on one of my test-boxes
-- I uncovered that during rewrite.

Otherwise use BEEP and infinite loops to find out where it hangs...

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: suspend to ram problem

[Rafael J. Wysocki]

On Sunday, 3 of February 2008, matthieu castet wrote:
> matthieu castet wrote:
> > Hi,
> > 
> > I am trying to make work suspend to ram on a MSI MS-6380E with a 2.6.23 
> > kernel.
> > 
> > Standby mode works.
> > S2ram suspend seems to work : the computer turn off and I can wake up it 
> > with the keyboard.
> > 
> > But when the computer wakeup, I see the video card POST on the screen, 
> > but after that the computer hangs : black screen, no working numlock.
> > 
> > I tried to compile PM_TRACE, but it give no result. So this means the 
> > resume hang very early.
> > 
> > What can I do to debug this ?
> >
> I play with the s2_beep feature and :
> - echo 4 > /proc/sys/kernel/acpi_video_flags make the computer beep
> - echo 4 > /proc/sys/kernel/acpi_video_flags make the computer not beep
> - adding a beep in bogus_real_magic, make the computer not beep
> 
> So the hang seems located in wakeup_start.

Hm.  Can you add unconditional BEEP after "jne bogus_real_magic" in
arch/x86/kernel/acpi/wakeup.S and see if it beeps?

Rafael