ACPI S3 resume only reboots

DISCUSSION Alberto 6 participants 16 messages Oct 4, 2004 – Oct 22, 2004 10 messages not in the archive ACPI

lore

Share & tools

lore

Alberto

author

2004-10-04 11:33 UTC #0 lore raw

Hi list,

I'm using kernel 2.6.9-rc3-bk2 + latest acpi + swsusp2

When i do
cat -n "mem" > /sys/power/state
the system seems to go down fine in S3 state...
when i hit the power button it looks like trying to resume (fan starts again, noises from harddisk and cdrom) then it just reboots....

# lspci
0000:00:00.0 Host bridge: VIA Technologies, Inc. VT8377 [KT400/KT600 AGP] Host Bridge (rev 80)
0000:00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge
0000:00:09.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 80)
0000:00:0b.0 CardBus bridge: O2 Micro, Inc. OZ6912 Cardbus Controller (rev 20)
0000:00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80)
0000:00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80)
0000:00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80)
0000:00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82)
0000:00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge
0000:00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
0000:00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 50)
0000:00:11.6 Communication controller: VIA Technologies, Inc. Intel 537 [AC97 Modem] (rev 80)
0000:00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 74)
0000:01:00.0 VGA compatible controller: ATI Technologies Inc Radeon R250 Lf [Radeon Mobility 9000 M9] (rev 01)

I removed all the modules and tryed from runlevel 1, all the usb devices where unplugged as well...

I googled about it and i found other people with the same KT400/KT600 chipset reporting the same problem.

How could i try to debug this to give you more info?

Thanks,

Alberto Piai

-------------------------------------------------------
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

A message that is not in the archive (sent off-list or not yet received): [email protected]

Matthew Garrett

2004-10-04 16:38 UTC #2 lore raw

Quoted 4 lines · Alberto

When i do
cat -n "mem" > /sys/power/state
the system seems to go down fine in S3 state...
when i hit the power button it looks like trying to resume (fan starts again, noises from harddisk and cdrom) then it just reboots....

Do you have a /proc/acpi/wakeup_devices ? If so, what's in it?

Signature · 9 lines

Matthew Garrett | [email protected]



-------------------------------------------------------
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

A message that is not in the archive (sent off-list or not yet received): 1096907923.11326.15.camel-Xmbc1Sz64/5pghhO6/9/[email protected]

Alberto

author

2004-10-04 19:12 UTC #4 lore raw

Quoted 8 lines · On Mon, 04 Oct 2004 17:38:43 +0100 Matthew Garrett…

Quoted 4 lines · Alberto
When i do
cat -n "mem" > /sys/power/state
the system seems to go down fine in S3 state...
when i hit the power button it looks like trying to resume (fan starts again, noises from harddisk and cdrom) then it just reboots....
Do you have a /proc/acpi/wakeup_devices ? If so, what's in it?

Yes i have a /proc/acpi/wakeup

$ cat /proc/acpi/wakeup
Device  Sleep state     Status
PCI0       4            disabled
USB1       0            disabled
USB2       0            disabled
USB3       0            disabled
EHCI       0            disabled
 EC0       4            disabled
 LID       4            *enabled
 AC9       4            disabled
 MC9       4            disabled
ILAN       4            disabled
SLPB       4            *enabled

Pressing the lid button to simulate lid opening happens the same as above...

A message that is not in the archive (sent off-list or not yet received): [email protected]

Alberto

author

2004-10-08 13:21 UTC #6 lore raw

Hi everybody,

i really need to fix this issue... i found in the archives and out in the net some references to this problem, that seems to be related to the VIA KT400 chipset, but no interesting follow-up was in the archive. I'm trying to suspento to ram from init 1, with all external devices unplugged and all modules unloaded. Seems to suspend fine, but wakeup generates a reboot.
Again, how could i try to understand what's going on if the machine just reboots?

Thanks,
Alberto

# lspci
0000:00:00.0 Host bridge: VIA Technologies, Inc. VT8377 [KT400/KT600 AGP] Host Bridge (rev 80)
0000:00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge
0000:00:09.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 80)
0000:00:0b.0 CardBus bridge: O2 Micro, Inc. OZ6912 Cardbus Controller (rev 20)
0000:00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80)
0000:00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80)
0000:00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80)
0000:00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82)
0000:00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge
0000:00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
0000:00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 50)
0000:00:11.6 Communication controller: VIA Technologies, Inc. Intel 537 [AC97 Modem] (rev 80)
0000:00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 74)
0000:01:00.0 VGA compatible controller: ATI Technologies Inc Radeon R250 Lf [Radeon Mobility 9000 M9] (rev 01)

Quoted 23 lines

Quoted 6 lines
Quoted 4 lines
When i do
cat -n "mem" > /sys/power/state
the system seems to go down fine in S3 state...
when i hit the power button it looks like trying to resume (fan starts again, noises from harddisk and cdrom) then it just reboots....
Do you have a /proc/acpi/wakeup_devices ? If so, what's in it?
Yes i have a /proc/acpi/wakeup
$ cat /proc/acpi/wakeup
Device  Sleep state     Status
PCI0       4            disabled
USB1       0            disabled
USB2       0            disabled
USB3       0            disabled
EHCI       0            disabled
 EC0       4            disabled
 LID       4            *enabled
 AC9       4            disabled
 MC9       4            disabled
ILAN       4            disabled
SLPB       4            *enabled

Quoted 1 line

Pressing the lid button to simulate lid opening happens the same as above...

Pavel Machek

2004-10-09 13:06 UTC #7 lore raw

In reply to a message not in the archive

Hi!

Quoted 23 lines

I'm using kernel 2.6.9-rc3-bk2 + latest acpi + swsusp2

# lspci
0000:00:00.0 Host bridge: VIA Technologies, Inc. VT8377 [KT400/KT600 AGP] Host Bridge (rev 80)
0000:00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge
0000:00:09.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 80)
0000:00:0b.0 CardBus bridge: O2 Micro, Inc. OZ6912 Cardbus Controller (rev 20)
0000:00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80)
0000:00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80)
0000:00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80)
0000:00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82)
0000:00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge
0000:00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
0000:00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 50)
0000:00:11.6 Communication controller: VIA Technologies, Inc. Intel 537 [AC97 Modem] (rev 80)
0000:00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 74)
0000:01:00.0 VGA compatible controller: ATI Technologies Inc Radeon R250 Lf [Radeon Mobility 9000 M9] (rev 01)

Quoted 5 lines

I removed all the modules and tryed from runlevel 1, all the usb devices where unplugged as well...
I googled about it and i found other people with the same KT400/KT600 chipset reporting the same problem.
How could i try to debug this to give you more info?

You basically need to fix this yourself. Add infinite loops to wakeup.S to see where it breaks.
Pavel

Signature · 9 lines

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

A message that is not in the archive (sent off-list or not yet received): 20041009130628.GA21781-I/[email protected]

[email protected]

2004-10-10 10:56 UTC #9 lore raw

Quoted 5 lines · Pavel Machek

Quoted 1 line
How could i try to debug this to give you more info?
You basically need to fix this yourself. Add infinite loops to wakeup.S to see where it breaks.
Pavel

I have a similar problem. I did try adding infinite loops into wakeup.S, right at the start, but the machine rebooted nevertheless. I suspect that my infinite loop was never executed and that the problem was that the computer didn't jump to the wake-up address on resume. Please do have a go yourself and see if you can narrow things down at all.

Here is my lspci, if it helps:

00:00.0 Host bridge: VIA Technologies, Inc. VT8377 [KT400 AGP] Host Bridge
00:01.0 PCI bridge: VIA Technologies, Inc. VT8235 PCI Bridge
00:08.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
00:0c.0 Multimedia audio controller: C-Media Electronics Inc CM8738 (rev 10)
00:0f.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5702 Gigabit Ethernet (rev 02) 00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge
00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT8233/A/C/VT8235 PIPC Bus Master IDE (rev 06) 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon R250 If [Radeon 9000] (rev 01) 01:00.1 Display controller: ATI Technologies Inc Radeon R250 [Radeon 9000] (Secondary) (rev 01)

If anybody has had any success with the KT400 chipset, please can you post your lspci as well, so that we can try and spot the hardware differences if any.

Thanks

John

A message that is not in the archive (sent off-list or not yet received): [email protected]

Alberto

author

2004-10-12 15:58 UTC #11 lore raw

Quoted 6 lines · Pavel Machek

Quoted 5 lines
Quoted 1 line
How could i try to debug this to give you more info?
You basically need to fix this yourself. Add infinite loops to wakeup.S to see where it breaks.
Pavel

I isolated the line were it breaks and reboots.

Code from arch/i386/kernel/acpi/wakeup.S

[...]

	# setup data segment
	movw	%cs, %ax
	movw	%ax, %ds					# Make ds:0 point to wakeup_start
	movw	%ax, %ss
	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

movl real_magic - wakeup_code, %eax
cmpl $0x12345678, %eax
jne bogus_real_magic
[...]

placing a statement like
hole: jmp hole
before pushl $0 (line 37) makes it loop, while immediatly after it reboots.

I don't have skills to fix it myself, but i can test patches... how can i help?

Thanks,
Alberto Piai

A message that is not in the archive (sent off-list or not yet received): [email protected]

Nate Lawson

2004-10-12 17:06 UTC #13 lore raw

Quoted 19 lines · Alberto

Quoted 6 lines · Pavel Machek
Quoted 5 lines
Quoted 2 lines
How could i try to debug this to give you more info?
You basically need to fix this yourself. Add infinite loops to wakeup.S to see where it breaks.
I isolated the line were it breaks and reboots.
Code from arch/i386/kernel/acpi/wakeup.S
[...]
	# setup data segment
	movw	%cs, %ax
	movw	%ax, %ds					# Make ds:0 point to wakeup_start
	movw	%ax, %ss
	mov	$(wakeup_stack - wakeup_code), %sp		# Private stack is needed for ASUS board
	movw	$0x0e00 + 'S', %fs:(0x12)

Quoted 2 lines

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

Hehe. Look up above where the stack pointer is changed to point to the wakeup stack and then 0 is pushed on it. It's likely there is some problem with the config or location of the wakeup stack.

Signature · 8 lines

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

A message that is not in the archive (sent off-list or not yet received): [email protected]

Alberto

author

2004-10-12 21:17 UTC #15 lore raw

Quoted 10 lines · On Tue, 12 Oct 2004 10:06:28 -0700 Nate Lawson…

Quoted 10 lines

Code from arch/i386/kernel/acpi/wakeup.S

[...]

	# setup data segment
	movw	%cs, %ax
	movw	%ax, %ds					# Make ds:0 point to wakeup_start
	movw	%ax, %ss
	mov	$(wakeup_stack - wakeup_code), %sp		# Private stack is needed for ASUS board
	movw	$0x0e00 + 'S', %fs:(0x12)

Quoted 6 lines

Quoted 2 lines
pushl $0 ###THIS LINE CAUSES REBOOT### # Kill any dangerous flags
popfl
Hehe. Look up above where the stack pointer is changed to point to the wakeup stack and then 0 is pushed on it. It's likely there is some problem with the config or location of the wakeup stack.

Ok, so the question is: where should %sp point to?

from wakeup.S :

[...]
.org 0x800
wakeup_stack_begin: # Stack grows down

.org 0xff0 # Just below end of page
wakeup_stack:
ENTRY(wakeup_end)

.org 0x1000
[...]

I noticed that dmesg shows the following lines:

# dmesg | grep BIOS
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000d2000 - 00000000000d8000 (reserved)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000001fff0000 (usable)
 BIOS-e820: 000000001fff0000 - 000000001fff8000 (ACPI data)
 BIOS-e820: 000000001fff8000 - 0000000020000000 (ACPI NVS)
 BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
 BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
 BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved)

maybe i'm just saying nonsense, but could this be useful?

A message that is not in the archive (sent off-list or not yet received): [email protected]

Nate Lawson

2004-10-12 21:54 UTC #17 lore raw

Quoted 14 lines · Alberto

Quoted 10 lines · On Tue, 12 Oct 2004 10:06:28 -0700 Nate Lawson…
Quoted 10 lines
Code from arch/i386/kernel/acpi/wakeup.S
[...]
	# setup data segment
	movw	%cs, %ax
	movw	%ax, %ds					# Make ds:0 point to wakeup_start
	movw	%ax, %ss
	mov	$(wakeup_stack - wakeup_code), %sp		# Private stack is needed for ASUS board
	movw	$0x0e00 + 'S', %fs:(0x12)

Quoted 7 lines

Quoted 4 lines
Quoted 2 lines
pushl $0 ###THIS LINE CAUSES REBOOT### # Kill any dangerous flags
popfl
Hehe. Look up above where the stack pointer is changed to point to the wakeup stack and then 0 is pushed on it. It's likely there is some problem with the config or location of the wakeup stack.
Ok, so the question is: where should %sp point to?

Dunno, we don't use a stack for the wake code.

-Nate

A message that is not in the archive (sent off-list or not yet received): [email protected]

Alberto

author

2004-10-13 07:46 UTC #19 lore raw

Quoted 18 lines · On Tue, 12 Oct 2004 14:54:03 -0700 Nate Lawson…

Quoted 17 lines · Alberto
Quoted 13 lines · On Tue, 12 Oct 2004 10:06:28 -0700 Nate Lawson…
Quoted 12 lines
Code from arch/i386/kernel/acpi/wakeup.S
[...]
	# setup data segment
	movw	%cs, %ax
	movw	%ax, %ds					# Make ds:0 point to wakeup_start
	movw	%ax, %ss
	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

Quoted 8 lines

Quoted 6 lines
Quoted 3 lines
Hehe. Look up above where the stack pointer is changed to point to the wakeup stack and then 0 is pushed on it. It's likely there is some problem with the config or location of the wakeup stack.
Ok, so the question is: where should %sp point to?
Dunno, we don't use a stack for the wake code.

...mmmh, the problem is that i'm not a programmer, i have no chance to work this out alone. Anybody can help? :)

Thanks,
Alberto

Pavel Machek

2004-10-17 19:43 UTC #20 lore raw

In reply to a message not in the archive

Hi!

Quoted 19 lines

Quoted 19 lines
Quoted 4 lines
Quoted 4 lines
Quoted 1 line
How could i try to debug this to give you more info?
You basically need to fix this yourself. Add infinite loops to wakeup.S to see where it breaks.
I isolated the line were it breaks and reboots.
Code from arch/i386/kernel/acpi/wakeup.S
[...]
	# setup data segment
	movw	%cs, %ax
	movw	%ax, %ds					# Make ds:0 
	point to wakeup_start
	movw	%ax, %ss
	mov	$(wakeup_stack - wakeup_code), %sp		# Private 
	stack is needed for ASUS board
	movw	$0x0e00 + 'S', %fs:(0x12)

Quoted 7 lines

Quoted 3 lines
	pushl	$0		###THIS LINE CAUSES REBOOT###		 # 
	Kill any dangerous flags
	popfl
Hehe. Look up above where the stack pointer is changed to point to the wakeup stack and then 0 is pushed on it. It's likely there is some problem with the config or location of the wakeup stack.

Is it possible that %cs:%ip is 1:2345 instead of 1234:5 at beggining of this?

	movw	%ip, %ax
	testw	%ax, $0xff00
	jnz	some_horrible_death

....

some_horrible_death:
BEEP
jmp some_horrible_death

Hmm, that does not work, %ip can't be accessed like that. Any ideas?

Pavel

Signature · 9 lines

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

Pavel Machek

2004-10-17 19:36 UTC #21 lore raw

In reply to a message not in the archive

Hi!

Quoted 4 lines

Quoted 4 lines
Quoted 4 lines
Quoted 1 line
How could i try to debug this to give you more info?
You basically need to fix this yourself. Add infinite loops to wakeup.S to see where it breaks.

[BTW good. I expected you to just forget it at this point.]

Quoted 20 lines

I isolated the line were it breaks and reboots.
Code from arch/i386/kernel/acpi/wakeup.S
[...]
	# setup data segment
	movw	%cs, %ax
	movw	%ax, %ds					# Make ds:0 point to wakeup_start
	movw	%ax, %ss
	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
movl real_magic - wakeup_code, %eax
cmpl $0x12345678, %eax
jne bogus_real_magic
[...]

Quoted 5 lines

placing a statement like
hole: jmp hole
before pushl $0 (line 37) makes it loop, while immediatly after it reboots.
I don't have skills to fix it myself, but i can test patches... how can i help?

Well, you'll have the skills when we are done with this. Try this one (with some suitable loop). Can you hear the tone?

We can make several variants of these to produce different tones (changing -74 and -119 to some other numbers should do the trick). That should speed your testing a tiny bit.

Pavel

arch/i386/kernel/acpi/wakeup.S +17 -1

@@ -11,8 +11,23 @@
 #
 # If physical address of wakeup_code is 0x12345, BIOS should call us with
 # cs = 0x1234, eip = 0x05
-# 
+#
 
+#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; 
+	
 ALIGN
 	.align	4096
 ENTRY(wakeup_start)

@@ -20,6 +35,7 @@
 	wakeup_code_start = .
 	.code16
 
+	BEEP
  	movw	$0xb800, %ax
 	movw	%ax,%fs
 	movw	$0x0e00 + 'L', %fs:(0x10)

Signature · 9 lines

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

A message that is not in the archive (sent off-list or not yet received): 20041017193623.GB7476-I/[email protected]

Matthew Garrett

2004-10-18 20:42 UTC #23 lore raw

Re: nc4010 resume failure (was: ACPI S3 resume only reboots)

arch/i386/kernel/acpi/wakeup.S line 41

Quoted 9 lines · Pavel Machek

ENTRY(wakeup_start)

arch/i386/kernel/acpi/wakeup.S +1 -0

@@ -20,6 +35,7 @@
 	wakeup_code_start = .
 	.code16
 
+	BEEP
  	movw	$0xb800, %ax
 	movw	%ax,%fs
 	movw	$0x0e00 + 'L', %fs:(0x10)

I've been trying this on an HP nc4010. As far as I can tell, the code never even gets this far. The machine appears to suspend correctly - the sleep light flashes. Pressing the power button then causes the fan to switch on, but no beep is produced. This is with the gdt and virt_to_phys patches applied. What's the best way to proceed with debugging this?

Signature · 9 lines

Matthew Garrett <[email protected]>



-------------------------------------------------------
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

Hiroshi 2 Itoh

2004-10-18 21:52 UTC #24 lore raw

Re: nc4010 resume failure (was: ACPI S3 resume only reboots)

Quoted 5 lines · Matthew

Quoted 5 lines
ENTRY(wakeup_start)
arch/i386/kernel/acpi/wakeup.S +0 -0
@@ -20,6 +35,7 @@
          wakeup_code_start = .
          .code16
 

Quoted 11 lines

arch/i386/kernel/acpi/wakeup.S line 41
Quoted 4 lines
arch/i386/kernel/acpi/wakeup.S +1 -0
+         BEEP
          movw        $0xb800, %ax
          movw        %ax,%fs
          movw        $0x0e00 + 'L', %fs:(0x10)
I've been trying this on an HP nc4010. As far as I can tell, the code never even gets this far. The machine appears to suspend correctly - the sleep light flashes. Pressing the power button then causes the fan to switch on, but no beep is produced. This is with the gdt and virt_to_phys patches applied. What's the best way to proceed with debugging this?

It is reported that some machines cannot use its stack due to unknown reason. In that case you must create a beep sound without any stack use (push, call etc.) especially before your own ss:sp setting.

The best way to debug is to write a code to switch from protected mode to real mode and jump directly to wakeup_start from do_suspend_lowlevel. If the control comes back to C routine again via the short-cut code, BIOS shall be something wrong.

I will start writing the code soon to verify whether BIOS wakeup routine misbehave to system hardware registers or not.

Regards, Hiro.

Pavel Machek

2004-10-22 10:51 UTC #25 lore raw

Re: nc4010 resume failure (was: ACPI S3 resume only reboots)

In reply to Matthew Garrett

Hi!

Quoted 5 lines

Quoted 5 lines
ENTRY(wakeup_start)
arch/i386/kernel/acpi/wakeup.S +0 -0
@@ -20,6 +35,7 @@
 	wakeup_code_start = .
 	.code16
 

Quoted 11 lines

arch/i386/kernel/acpi/wakeup.S line 41
Quoted 4 lines
arch/i386/kernel/acpi/wakeup.S +1 -0
+	BEEP
  	movw	$0xb800, %ax
 	movw	%ax,%fs
 	movw	$0x0e00 + 'L', %fs:(0x10)
I've been trying this on an HP nc4010. As far as I can tell, the code never even gets this far. The machine appears to suspend correctly - the sleep light flashes. Pressing the power button then causes the fan to switch on, but no beep is produced. This is with the gdt and virt_to_phys patches applied. What's the best way to proceed with debugging this?

Add infinite loop just after BEEP... if it crashed too fast after BEEP you might not hear anything.
Pavel

Signature · 9 lines

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