[PATCH] GDT table patch for resume only reboots problem

[PATCH] GDT table patch for resume only reboots problem

[Hiroshi 2 Itoh]

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





Hi,

Using 2.6.9 RC4 kernel + Shaohua-san's wakeup patch, my test machine
resumes just before
ljmpl $__KERNEL_CS,$wakeup_pmode_return in wakeup.S.
(This is confirmed by parallel port(0x3bc) out like BIOS steping number.)

The code would not come back to wakeup_pmode_return entry and goes to
reboot. After fairly tough debugging, it is found that the original GDT
pointed by GDTR cannot be accessed from real mode. (This may occurr
especially when CR4 PSE bit is on.)

The following patch will partially copy the GDT into low memory to be
addressable.
(See attached file: wakeup_gdt.patch)

I hope most of machines can resume with;

Kernel 2.6.9 RC4
+wakeup_addr.patch
+wakeup_gdt.patch

If you cannot see the screen normally after resume, "acpi_sleep=s3_bios"
boot option is available to reset the video mode.
(My ThinkPad is still in trouble with HDD access after resume because of
unknown reason. :-)

Regards, Hiro.

[-- Attachment #2: wakeup_gdt.patch --]
[-- Type: application/octet-stream, Size: 1142 bytes --]

--- a/arch/i386/kernel/acpi/wakeup.S	2004-08-14 14:36:31.000000000 +0900
+++ b/arch/i386/kernel/acpi/wakeup.S	2004-10-18 04:30:53.684987016 +0900
@@ -67,6 +67,13 @@
 	movw	$0x0e00 + 'i', %fs:(0x12)
 	
 	# need a gdt
+	# use the gdt copied in this low mem
+	lea     temp_gdt_table - wakeup_code, %eax
+	xor     %ebx, %ebx
+	movw    %ds, %bx
+	shll    $4, %ebx
+	addl    %ebx, %eax
+	movl    %eax, real_save_gdt + 2 - wakeup_code
 	lgdt	real_save_gdt - wakeup_code
 
 	movl	real_save_cr0 - wakeup_code, %eax
@@ -89,6 +96,7 @@
 real_magic:	.long 0
 video_mode:	.long 0
 video_flags:	.long 0
+temp_gdt_table: .fill GDT_ENTRIES, 8, 0
 
 bogus_real_magic:
 	movw	$0x0e00 + 'B', %fs:(0x12)
@@ -231,6 +239,14 @@
 	movl	%edx, real_save_cr0 - wakeup_start (%eax)
 	sgdt    real_save_gdt - wakeup_start (%eax)
 
+	# gdt body must be addressable from real mode by
+	# partially copying it to the lower mem
+	xor     %ecx, %ecx
+	movw    saved_gdt, %cx
+	movl    saved_gdt + 2, %esi
+	lea     temp_gdt_table - wakeup_start (%eax), %edi
+	rep movsb
+
 	movl	saved_videomode, %edx
 	movl	%edx, video_mode - wakeup_start (%eax)
 	movl	acpi_video_flags, %edx

Re: [PATCH] GDT table patch for resume only reboots problem

[Pavel Machek]

Hi!

> Using 2.6.9 RC4 kernel + Shaohua-san's wakeup patch, my test machine
> resumes just before
> ljmpl $__KERNEL_CS,$wakeup_pmode_return in wakeup.S.
> (This is confirmed by parallel port(0x3bc) out like BIOS steping number.)
> 
> The code would not come back to wakeup_pmode_return entry and goes to
> reboot. After fairly tough debugging, it is found that the original GDT
> pointed by GDTR cannot be accessed from real mode. (This may occurr
> especially when CR4 PSE bit is on.)
> 
> The following patch will partially copy the GDT into low memory to be
> addressable.
> (See attached file: wakeup_gdt.patch)
> 
> I hope most of machines can resume with;
> 
> Kernel 2.6.9 RC4
> +wakeup_addr.patch
> +wakeup_gdt.patch
> 
> If you cannot see the screen normally after resume, "acpi_sleep=s3_bios"
> boot option is available to reset the video mode.
> (My ThinkPad is still in trouble with HDD access after resume because of
> unknown reason. :-)

(Please inline patches to make commenting on them easier)

--- a/arch/i386/kernel/acpi/wakeup.S    2004-08-14 14:36:31.000000000
+0900
+++ b/arch/i386/kernel/acpi/wakeup.S    2004-10-18 04:30:53.684987016
+0900
@@ -67,6 +67,13 @@
        movw    $0x0e00 + 'i', %fs:(0x12)

        # need a gdt
+       # use the gdt copied in this low mem
+       lea     temp_gdt_table - wakeup_code, %eax
+       xor     %ebx, %ebx
+       movw    %ds, %bx
+       shll    $4, %ebx
+       addl    %ebx, %eax
+       movl    %eax, real_save_gdt + 2 - wakeup_code
        lgdt    real_save_gdt - wakeup_code

        movl    real_save_cr0 - wakeup_code, %eax

It is ugly to do this kind of computation during resume time (where it
is impossible to debug). It could be done in suspend time and resume
path could stay the same, right?
								Pavel

-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: [PATCH] GDT table patch for resume only reboots problem

[Hiroshi 2 Itoh]

>Hi!


>--- a/arch/i386/kernel/acpi/wakeup.S    2004-08-14 14:36:31.000000000
>+0900
>+++ b/arch/i386/kernel/acpi/wakeup.S    2004-10-18 04:30:53.684987016
>+0900
>@@ -67,6 +67,13 @@
>        movw    $0x0e00 + 'i', %fs:(0x12)>
>
>        # need a gdt
>+       # use the gdt copied in this low mem
>+       lea     temp_gdt_table - wakeup_code, %eax
>+       xor     %ebx, %ebx
>+       movw    %ds, %bx
>+       shll    $4, %ebx
>+       addl    %ebx, %eax
>+       movl    %eax, real_save_gdt + 2 - wakeup_code
>        lgdt    real_save_gdt - wakeup_code
>
>        movl    real_save_cr0 - wakeup_code, %eax
>
>It is ugly to do this kind of computation during resume time (where it
>is impossible to debug). It could be done in suspend time and resume
>path could stay the same, right?

As for in suspend time, it can be more beautifully written in C routine.
But in resume time, unfortunately the code should be relocatable and the
usable stack area is small.

Hiro



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: [PATCH] GDT table patch for resume only reboots problem

[Pavel Machek]

Hi!

> >--- a/arch/i386/kernel/acpi/wakeup.S    2004-08-14 14:36:31.000000000
> >+0900
> >+++ b/arch/i386/kernel/acpi/wakeup.S    2004-10-18 04:30:53.684987016
> >+0900
> >@@ -67,6 +67,13 @@
> >        movw    $0x0e00 + 'i', %fs:(0x12)>
> >
> >        # need a gdt
> >+       # use the gdt copied in this low mem
> >+       lea     temp_gdt_table - wakeup_code, %eax
> >+       xor     %ebx, %ebx
> >+       movw    %ds, %bx
> >+       shll    $4, %ebx
> >+       addl    %ebx, %eax
> >+       movl    %eax, real_save_gdt + 2 - wakeup_code
> >        lgdt    real_save_gdt - wakeup_code
> >
> >        movl    real_save_cr0 - wakeup_code, %eax
> >
> >It is ugly to do this kind of computation during resume time (where it
> >is impossible to debug). It could be done in suspend time and resume
> >path could stay the same, right?
> 
> As for in suspend time, it can be more beautifully written in C routine.
> But in resume time, unfortunately the code should be relocatable and the
> usable stack area is small.

What you do at resume time is some computation based on %ds. You can
do it during suspend time as well, %ds is same as %cs during resume,
and that should be known during suspend... its the address you set to
wakeup_vector >> 4.
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: [PATCH] GDT table patch for resume only reboots problem

[Alberto Piai]

On Mon, 18 Oct 2004 05:17:21 +0900
Hiroshi 2 Itoh <HIROIT-JE5g2YyFxFHQT0dZR+AlfA@public.gmane.org> wrote:

> I hope most of machines can resume with;
> 
> Kernel 2.6.9 RC4
> +wakeup_addr.patch
> +wakeup_gdt.patch

Sorry, it doesn't work on my system :(
It still reboots on
		mov	$(wakeup_stack - wakeup_code), %sp		# Private stack is needed for ASUS board
		movw	$0x0e00 + 'S', %fs:(0x12)

		pushl	$0			#THIS LINE CAUSES REBOOT			# Kill any dangerous flags
		popfl

If I uncomment pushl and popfl it hangs(but not reboot, like going in an infinite loop) later, on
	wakeup_pmode_return:
		movw	$__KERNEL_DS, %ax
		movw	%ax, %ss           #HANGS HERE
		movw	%ax, %ds

Thanks,
Alberto


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: [PATCH] GDT table patch for resume only reboots problem

[Pavel Machek]

Hi!

> > I hope most of machines can resume with;
> > 
> > Kernel 2.6.9 RC4
> > +wakeup_addr.patch
> > +wakeup_gdt.patch
> 
> Sorry, it doesn't work on my system :(
> It still reboots on
> 		mov	$(wakeup_stack - wakeup_code), %sp		# Private stack is needed for ASUS board
> 		movw	$0x0e00 + 'S', %fs:(0x12)
> 
> 		pushl	$0			#THIS LINE CAUSES REBOOT			# Kill any dangerous flags
> 		popfl
> 
> If I uncomment pushl and popfl it hangs(but not reboot, like going in an infinite loop) later, on
> 	wakeup_pmode_return:
> 		movw	$__KERNEL_DS, %ax
> 		movw	%ax, %ss           #HANGS HERE
> 		movw	%ax, %ds

Are you sure it hangs there? Your pushl $0 method to force reboot is
unlikely to be effective after %ss is set up properly... Which is this
point. [That beeping code might be handy here.]

Next thing you can try is replacing

        movw    %ax, %ss
        mov     $(wakeup_stack - wakeup_code), %sp              # Private stack is needed for ASUS board

with
	movw	$0x00, %ss		# Warning, will corrupt page #0 if you resume correctly
	movw	%ax, %ss
	movw	$2048, %ax
	movw	%ax, %sp

								Pavel

-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: [PATCH] GDT table patch for resume only reboots problem

[Alberto Piai]

On Mon, 18 Oct 2004 01:38:19 +0200
Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org> wrote:

> > If I uncomment pushl and popfl it hangs(but not reboot, like going in an infinite loop) later, on
> > 	wakeup_pmode_return:
> > 		movw	$__KERNEL_DS, %ax
> > 		movw	%ax, %ss           #HANGS HERE
> > 		movw	%ax, %ds
> 
> Are you sure it hangs there? Your pushl $0 method to force reboot is
> unlikely to be effective after %ss is set up properly... Which is this
> point. [That beeping code might be handy here.]

I'm trying to use the beeping code but i get strange behavior..
if use just a BEEP it hangs beeping forever
if i use a  beeping loop like
	die:
		BEEP
		jmp die
i don't get any sound, but it just hangs.

Alberto


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: [PATCH] GDT table patch for resume only reboots problem

[Pavel Machek]

Hi!

> > > If I uncomment pushl and popfl it hangs(but not reboot, like going in an infinite loop) later, on
> > > 	wakeup_pmode_return:
> > > 		movw	$__KERNEL_DS, %ax
> > > 		movw	%ax, %ss           #HANGS HERE
> > > 		movw	%ax, %ds
> > 
> > Are you sure it hangs there? Your pushl $0 method to force reboot is
> > unlikely to be effective after %ss is set up properly... Which is this
> > point. [That beeping code might be handy here.]
> 
> I'm trying to use the beeping code but i get strange behavior..
> if use just a BEEP it hangs beeping forever
> if i use a  beeping loop like
> 	die:
> 		BEEP
> 		jmp die
> i don't get any sound, but it just hangs.

Hmm, I should probably not reprogram beep timer over and over and
over.

	die:
		BEEP
	die2:
		jmp die2

should do the trick.
								Pavel

-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: [PATCH] GDT table patch for resume only reboots problem

[Hiroshi 2 Itoh]

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





Pavel,

You wrote.

>What you do at resume time is some computation based on %ds. You can
>do it during suspend time as well, %ds is same as %cs during resume,
>and that should be known during suspend... its the address you set to
>wakeup_vector >> 4.

You are right and I agree gdtr save area can be modified via
acpi_copy_wakeup_routine() with its FASTCALL argument added. This is the
second version of gdt table patch. Also I changed temp_gdt... to
real_gdt... because temp_gdt... looks like temporary fix.

Thanks, Hiro.

=================================================================================================
diff -Nru a/arch/i386/kernel/acpi/sleep.c b/arch/i386/kernel/acpi/sleep.c
--- a/arch/i386/kernel/acpi/sleep.c 2004-10-15 11:29:15.000000000 +0900
+++ b/arch/i386/kernel/acpi/sleep.c 2004-10-19 00:59:32.000000000 +0900
@@ -17,7 +17,7 @@

 extern void zap_low_mappings(void);

-extern unsigned long FASTCALL(acpi_copy_wakeup_routine(unsigned long));
+extern unsigned long FASTCALL(acpi_copy_wakeup_routine(unsigned
long,unsigned long));

 static void init_low_mapping(pgd_t *pgd, int pgd_limit)
 {
@@ -41,7 +41,8 @@
            return 1;
      init_low_mapping(swapper_pg_dir, USER_PTRS_PER_PGD);
      memcpy((void *) acpi_wakeup_address, &wakeup_start, &wakeup_end -
&wakeup_start);
-     acpi_copy_wakeup_routine(acpi_wakeup_address);
+     acpi_copy_wakeup_routine(acpi_wakeup_address,
+                        virt_to_phys((void *)acpi_wakeup_address));

      return 0;
 }
diff -Nru a/arch/i386/kernel/acpi/wakeup.S b/arch/i386/kernel/acpi/wakeup.S
--- a/arch/i386/kernel/acpi/wakeup.S      2004-08-14 14:36:31.000000000
+0900
+++ b/arch/i386/kernel/acpi/wakeup.S      2004-10-19 05:24:42.000000000
+0900
@@ -89,6 +89,7 @@
 real_magic:      .long 0
 video_mode:      .long 0
 video_flags:     .long 0
+real_gdt_table: .fill GDT_ENTRIES, 8, 0

 bogus_real_magic:
      movw  $0x0e00 + 'B', %fs:(0x12)
@@ -213,6 +214,7 @@
 #
 # Parameters:
 # %eax:    place to copy wakeup routine to
+# %edx: the second argument (physical address)
 #
 # Returned address is location of code in low memory (past data and stack)
 #
@@ -223,6 +225,9 @@
      sldt  saved_ldt
      str   saved_tss

+     # save wakeup_start physical address in ecx
+     movl  %edx, %ecx
+
      movl    %cr3, %edx
      movl    %edx, real_save_cr3 - wakeup_start (%eax)
      movl    %cr4, %edx
@@ -231,6 +236,16 @@
      movl  %edx, real_save_cr0 - wakeup_start (%eax)
      sgdt    real_save_gdt - wakeup_start (%eax)

+     # gdt body must be addressable from real mode by
+     # copying it to the lower mem
+     lea     real_gdt_table - wakeup_start (%ecx), %ecx
+     movl    %ecx, real_save_gdt + 2 - wakeup_start (%eax)
+     xor     %ecx, %ecx
+     movw    saved_gdt, %cx
+     movl    saved_gdt + 2, %esi
+     lea     real_gdt_table - wakeup_start (%eax), %edi
+     rep movsb
+
      movl  saved_videomode, %edx
      movl  %edx, video_mode - wakeup_start (%eax)
      movl  acpi_video_flags, %edx
=================================================================================================
(See attached file: wakeup_gdt2.patch)

[-- Attachment #2: wakeup_gdt2.patch --]
[-- Type: application/octet-stream, Size: 2214 bytes --]

diff -Nru a/arch/i386/kernel/acpi/sleep.c b/arch/i386/kernel/acpi/sleep.c
--- a/arch/i386/kernel/acpi/sleep.c	2004-10-15 11:29:15.000000000 +0900
+++ b/arch/i386/kernel/acpi/sleep.c	2004-10-19 00:59:32.000000000 +0900
@@ -17,7 +17,7 @@
 
 extern void zap_low_mappings(void);
 
-extern unsigned long FASTCALL(acpi_copy_wakeup_routine(unsigned long));
+extern unsigned long FASTCALL(acpi_copy_wakeup_routine(unsigned long,unsigned long));
 
 static void init_low_mapping(pgd_t *pgd, int pgd_limit)
 {
@@ -41,7 +41,8 @@
 		return 1;
 	init_low_mapping(swapper_pg_dir, USER_PTRS_PER_PGD);
 	memcpy((void *) acpi_wakeup_address, &wakeup_start, &wakeup_end - &wakeup_start);
-	acpi_copy_wakeup_routine(acpi_wakeup_address);
+	acpi_copy_wakeup_routine(acpi_wakeup_address,
+				 virt_to_phys((void *)acpi_wakeup_address));
 
 	return 0;
 }
diff -Nru a/arch/i386/kernel/acpi/wakeup.S b/arch/i386/kernel/acpi/wakeup.S
--- a/arch/i386/kernel/acpi/wakeup.S	2004-08-14 14:36:31.000000000 +0900
+++ b/arch/i386/kernel/acpi/wakeup.S	2004-10-19 05:24:42.000000000 +0900
@@ -89,6 +89,7 @@
 real_magic:	.long 0
 video_mode:	.long 0
 video_flags:	.long 0
+real_gdt_table: .fill GDT_ENTRIES, 8, 0
 
 bogus_real_magic:
 	movw	$0x0e00 + 'B', %fs:(0x12)
@@ -213,6 +214,7 @@
 #
 # Parameters:
 # %eax:	place to copy wakeup routine to
+# %edx: the second argument (physical address)
 #
 # Returned address is location of code in low memory (past data and stack)
 #
@@ -223,6 +225,9 @@
 	sldt	saved_ldt
 	str	saved_tss
 
+	# save wakeup_start physical address in ecx
+	movl	%edx, %ecx
+
 	movl    %cr3, %edx
 	movl    %edx, real_save_cr3 - wakeup_start (%eax)
 	movl    %cr4, %edx
@@ -231,6 +236,16 @@
 	movl	%edx, real_save_cr0 - wakeup_start (%eax)
 	sgdt    real_save_gdt - wakeup_start (%eax)
 
+	# gdt body must be addressable from real mode by
+	# copying it to the lower mem
+	lea     real_gdt_table - wakeup_start (%ecx), %ecx
+	movl    %ecx, real_save_gdt + 2 - wakeup_start (%eax)
+	xor     %ecx, %ecx
+	movw    saved_gdt, %cx
+	movl    saved_gdt + 2, %esi
+	lea     real_gdt_table - wakeup_start (%eax), %edi
+	rep movsb
+
 	movl	saved_videomode, %edx
 	movl	%edx, video_mode - wakeup_start (%eax)
 	movl	acpi_video_flags, %edx

Re: [PATCH] GDT table patch for resume only reboots problem

[Pavel Machek]

Hi!

> You wrote.
> 
> >What you do at resume time is some computation based on %ds. You can
> >do it during suspend time as well, %ds is same as %cs during resume,
> >and that should be known during suspend... its the address you set to
> >wakeup_vector >> 4.
> 
> You are right and I agree gdtr save area can be modified via
> acpi_copy_wakeup_routine() with its FASTCALL argument added. This is the
> second version of gdt table patch. Also I changed temp_gdt... to
> real_gdt... because temp_gdt... looks like temporary fix.

Yes, this si better, thanks!
								Pavel


-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: [PATCH] GDT table patch for resume only reboots problem

[Matthew Garrett]

On Tue, 2004-10-19 at 05:38 +0900, Hiroshi 2 Itoh wrote:

> You are right and I agree gdtr save area can be modified via
> acpi_copy_wakeup_routine() with its FASTCALL argument added. This is the
> second version of gdt table patch. Also I changed temp_gdt... to
> real_gdt... because temp_gdt... looks like temporary fix.

I'm testing this patch plus the wakeup address one on an EiSystem 3001
(some random cheap VIA-based system). Suspend appears to work correctly
- if I use Pavel's BEEP code in do_suspend_lowevel I get a tone
immediately before the machine shuts down. The sleep light then comes
on. Hitting the power button results in the machine rebooting
immediately - putting a BEEP at the start of wakeup_start doesn't result
in any tone. Are there any further useful details I can send?

(This machine is of sufficiently poor quality that its DMI table claims
it's a desktop, but it suspends correctly under Windows XP...)
-- 
Matthew Garrett <mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org>



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: [PATCH] GDT table patch for resume only reboots problem

[Hiroshi 2 Itoh]

>I'm testing this patch plus the wakeup address one on an EiSystem 3001
>(some random cheap VIA-based system). Suspend appears to work correctly
>- if I use Pavel's BEEP code in do_suspend_lowevel I get a tone
>immediately before the machine shuts down. The sleep light then comes
>on. Hitting the power button results in the machine rebooting
>immediately - putting a BEEP at the start of wakeup_start doesn't result
>in any tone. Are there any further useful details I can send?

>(This machine is of sufficiently poor quality that its DMI table claims
>it's a desktop, but it suspends correctly under Windows XP...)

Beep is not always audible. The timer registers should be initialized to
get a certain clock and the output of the beep may be controlled via
buttons,
sliders, or other software controllable registers. We cannot assume that
all of BIOS can do this kind of minimum POST setup from wakeup. It is not
a significant problem when the resume code can come back under OS control
to
re-initialize.

Instead, I test my machine to write a byte value on I/O port 0x3bc. This
is the parallel port's output register to be latched and observable if you
have a simple hardware decoder with 7 segment LEDs. <- do it yourself work
is required. :-)

The port write is very simple one instruction using dx and al registers
without any stack help. So It's nice for our suspend/resume debug.

- Hiro



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: [PATCH] GDT table patch for resume only reboots problem

[Hiroshi 2 Itoh]

>Instead, I test my machine to write a byte value on I/O port 0x3bc. This
>is the parallel port's output register to be latched and observable if you
>have a simple hardware decoder with 7 segment LEDs. <- do it yourself work
>is required. :-)

Matthew,

My diagnostic tool consists of one 74LN373 chip and two 7-segment LEDs with
Dsub 25 pin + PS2
mouse cable to get +5V only from the mouse connecter.

It seems that there is a company to sell such a POST card.
http://tech.parvus.com/item_info.asp?Item=PRV-0867X-01

- Hiro



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: [PATCH] GDT table patch for resume only reboots problem

[Pavel Machek]

Hi!

> >I'm testing this patch plus the wakeup address one on an EiSystem 3001
> >(some random cheap VIA-based system). Suspend appears to work correctly
> >- if I use Pavel's BEEP code in do_suspend_lowevel I get a tone
> >immediately before the machine shuts down. The sleep light then comes
> >on. Hitting the power button results in the machine rebooting
> >immediately - putting a BEEP at the start of wakeup_start doesn't result
> >in any tone. Are there any further useful details I can send?
> 
> >(This machine is of sufficiently poor quality that its DMI table claims
> >it's a desktop, but it suspends correctly under Windows XP...)
> 
> Beep is not always audible. The timer registers should be initialized to
> get a certain clock and the output of the beep may be controlled via
> buttons,

Right...

> Instead, I test my machine to write a byte value on I/O port 0x3bc. This
> is the parallel port's output register to be latched and observable if you
> have a simple hardware decoder with 7 segment LEDs. <- do it yourself work
> is required. :-)

Is it guaranteed that southbridge is initialized enough for parport to
work? Anyway you can do simpler debugging dongle with 8 leds and 8
resistors, right to the port, no ps/2 power needed (ok, its a hack).

								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: [PATCH] GDT table patch for resume only reboots problem

[Matthew Garrett]

On Thu, 2004-10-21 at 03:36 +0900, Hiroshi 2 Itoh wrote:

> Instead, I test my machine to write a byte value on I/O port 0x3bc. This
> is the parallel port's output register to be latched and observable if you
> have a simple hardware decoder with 7 segment LEDs. <- do it yourself work
> is required. :-)

I've tried this now - again, there's no sign whatsoever of anything in
wakeup_code being run. I'm going to start looking into where it's being
located, and see if that seems to make any difference.

What reasons could there be for wakeup_code never being run?
-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: [PATCH] GDT table patch for resume only reboots problem

[Matthew Garrett]

On Sat, 2004-10-23 at 01:34 +0100, Matthew Garrett wrote:

> I've tried this now - again, there's no sign whatsoever of anything in
> wakeup_code being run. I'm going to start looking into where it's being
> located, and see if that seems to make any difference.
> 
> What reasons could there be for wakeup_code never being run?

I've done some further digging - it seems that the wakeup_vector is
generally set to 0x1000, and that that's its value at the start of
acpi_pm_enter - that is, it doesn't appear to be overwritten by anything
during sleep preparation.

-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: [PATCH] GDT table patch for resume only reboots problem

[Hiroshi 2 Itoh]

Hi!

acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org wrote on 2004/10/22 19:53:40:

> > Instead, I test my machine to write a byte value on I/O port 0x3bc.
This
> > is the parallel port's output register to be latched and observable if
you
> > have a simple hardware decoder with 7 segment LEDs. <- do it yourself
work
> > is required. :-)
>
> Is it guaranteed that southbridge is initialized enough for parport to
> work? Anyway you can do simpler debugging dongle with 8 leds and 8
> resistors, right to the port, no ps/2 power needed (ok, its a hack).
>

Yes, BIOS people always enable it for their own debug.

- Hiro.



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: [PATCH] GDT table patch for resume only reboots problem

[Hiroshi 2 Itoh]

Hi!

> On Sat, 2004-10-23 at 01:34 +0100, Matthew Garrett wrote:
>
> I've done some further digging - it seems that the wakeup_vector is
> generally set to 0x1000, and that that's its value at the start of
> acpi_pm_enter - that is, it doesn't appear to be overwritten by anything
> during sleep preparation.

The vector means a physical address, not the offset of any kernel entry
points.
You confirmed virt_to_phys((void *)acpi_wakeup_address) was equal to
0x1000?

- Hiro.



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: [PATCH] GDT table patch for resume only reboots problem

[Matthew Garrett]

On Sat, 2004-10-23 at 20:01 +0900, Hiroshi 2 Itoh wrote:
> On Sat, 2004-10-23 at 01:34 +0100, Matthew Garrett wrote:
> >
> > I've done some further digging - it seems that the wakeup_vector is
> > generally set to 0x1000, and that that's its value at the start of
> > acpi_pm_enter - that is, it doesn't appear to be overwritten by anything
> > during sleep preparation.
> 
> The vector means a physical address, not the offset of any kernel entry
> points.
> You confirmed virt_to_phys((void *)acpi_wakeup_address) was equal to
> 0x1000?

Sorry, yes - the virtual address is 0xc0001000, and after it's been
through virt_to_phys it's 0x00001000. This is the value that gets
written into the FACS, and reading it back immediately before the final
suspend call shows that it's still the value there.

Further digging - the machine claims that the FACS revision is 0, the
table length is 64 and that xfirmware_waking_vector is set to 0, As a
result of the first and last of these things, firmware_waking_vector is
used instead of xfirmware_waking_vector. This shouldn't be an issue,
right? 
-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: [PATCH] GDT table patch for resume only reboots problem

[Hiroshi 2 Itoh]

>
> Further digging - the machine claims that the FACS revision is 0, the
> table length is 64 and that xfirmware_waking_vector is set to 0, As a
> result of the first and last of these things, firmware_waking_vector is
> used instead of xfirmware_waking_vector. This shouldn't be an issue,
> right?
> --

Yes, nothing is bad. Try to write the value in both etc...

- Hiro.



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: [PATCH] GDT table patch for resume only reboots problem

[Matthew Garrett]

On Sat, 2004-10-23 at 21:05 +0900, Hiroshi 2 Itoh wrote:

> Yes, nothing is bad. Try to write the value in both etc...

Writing the value into both makes no difference. I also tried pushing
the wakeup address higher up into lowmem (around 256K), but that makes
no difference either.

-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: [PATCH] GDT table patch for resume only reboots problem

[Nate Lawson]

Matthew Garrett wrote:
> On Sat, 2004-10-23 at 20:01 +0900, Hiroshi 2 Itoh wrote:
> 
>>On Sat, 2004-10-23 at 01:34 +0100, Matthew Garrett wrote:
>>
>>>I've done some further digging - it seems that the wakeup_vector is
>>>generally set to 0x1000, and that that's its value at the start of
>>>acpi_pm_enter - that is, it doesn't appear to be overwritten by anything
>>>during sleep preparation.
>>
>>The vector means a physical address, not the offset of any kernel entry
>>points.
>>You confirmed virt_to_phys((void *)acpi_wakeup_address) was equal to
>>0x1000?
> 
> 
> Sorry, yes - the virtual address is 0xc0001000, and after it's been
> through virt_to_phys it's 0x00001000. This is the value that gets
> written into the FACS, and reading it back immediately before the final
> suspend call shows that it's still the value there.
> 
> Further digging - the machine claims that the FACS revision is 0, the
> table length is 64 and that xfirmware_waking_vector is set to 0, As a
> result of the first and last of these things, firmware_waking_vector is
> used instead of xfirmware_waking_vector. This shouldn't be an issue,
> right? 

Doesn't acpi require an identity mapping (virtual == physical)?  I'm not 
sure what you're entering for the PTE.

-- 
Nate


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: [PATCH] GDT table patch for resume only reboots problem

[Matthew Garrett]

On Sat, 2004-10-23 at 13:44 +0100, Matthew Garrett wrote:
> On Sat, 2004-10-23 at 21:05 +0900, Hiroshi 2 Itoh wrote:
> 
> > Yes, nothing is bad. Try to write the value in both etc...
> 
> Writing the value into both makes no difference. I also tried pushing
> the wakeup address higher up into lowmem (around 256K), but that makes
> no difference either.

Further playing:

Setting the wakeup vector to other values makes no difference - the
machine behaves identically regardless of whether it's pointing at the
wakeup code or at empty space (ie, it always reboots). The only two
things that spring to mind are:

1) Something is still going wrong in the suspend pathway, and some
machines are not being properly configured for suspend. Given that the
machine reboots without running any code when attempting to wake from
S3, is there any way to test this?

2) (This is somewhat far-fetched, but...) Could the machine be ignoring
the contents of the wakeup vector and always attempting to run code from
the same address? Does Windows put the wakeup code in a predictable
location?

Looking a bit more closely, the DSDT claims to be for a VIA Apollo-P.
The machine was made by Elite Computer Systems (www.ecs.com.tw ) and is
a rebadged G320. It's a very, very horrible piece of hardware, but S3
works under Windows.
-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org



-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click