RE: Re: Samsung P35 and S3 suspend

RE: Re: Samsung P35 and S3 suspend

[Li, Shaohua]

>The background is that any write access to the pci config registers of
some
>devices(sound card, usb 2.0 controler, and modem) cause a system lockup
if
>they are called before acpi_leave_sleep_state and
>acpi_disable_wakeup_device
>were called. This is on an Acer Travelmate 803 Notebook, and it seems
to be
>the same on other systems.
>
>I sent the patch to the list, but it seems that nobody noticed it and I
>forgot
>to send it again. Here is an updated patch against 2.6.10. I can't
promise
>that it doesn't break other systems. Someone should make sure that
>pm_ops->leave is set to NULL for apm. I haven't found this in the apm
code
>yet.
This patch is quite interesting. If you just move '
acpi_leave_sleep_state(acpi_state)' to acpi_pm_leave, what's the result?
And please send me a copy of your acpidmp, I'd like look at it.

Thanks,
Shaohua


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/

Re: Re: Samsung P35 and S3 suspend

[Stefan Dösinger]

> This patch is quite interesting. If you just move '
> acpi_leave_sleep_state(acpi_state)' to acpi_pm_leave, what's the result?
> And please send me a copy of your acpidmp, I'd like look at it.
Works too with 2.6.10. Strange, AFAIK this didn't work with 2.6.7.
I sent the output of acpidump in a private mail(File fize)

stefan


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Re: Samsung P35 and S3 suspend

[Li Shaohua]

On Mon, 2004-12-27 at 20:18, stefandoesinger-RbZlAiThDcE@public.gmane.org wrote:
> > This patch is quite interesting. If you just move '
> > acpi_leave_sleep_state(acpi_state)' to acpi_pm_leave, what's the
> result?
> > And please send me a copy of your acpidmp, I'd like look at it.
> Works too with 2.6.10. Strange, AFAIK this didn't work with 2.6.7.
> I sent the output of acpidump in a private mail(File fize)
Your original patch (move 'acpi_leave_sleep_state' and
'acpi_disable_wakeup_device' to 'acpi_pm_leave') seems safer (in case
resumed devices generate unexpected wakeup interrupts), please submit a
patch to Len.

Though I wonder if 'acpi_pm_leave' should be called before
'device_power_up' (ACPI spec said _WAK should be called before device
resume, which possibly includes system devices). There isn't a
straightforward fix for this, acpi_leave_sleep_state is designed being
called with interrupt enabled. But anyway, we can fix it till we
actually find one real bug.

Thanks,
Shaohua



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Re: Samsung P35 and S3 suspend

[Stefan Dösinger]

> And also please try this one (in kernel/power/main.c):
> static void suspend_finish(suspend_state_t state)
> {
> - device_resume();
>  if (pm_ops && pm_ops->finish)
>   pm_ops->finish(state);
> + device_resume();
>  thaw_processes();
>  pm_restore_console();
> }
> According to ACPI spec, device resume should be after _WAK method (in
> acpi_leave_sleep_state)
This is the first thing I've done, it also works(See the archives), but 
Luca<kronos@pe...> told me that it's not correct:

>  Well, it may work but it"s not correct. ->finish is meant to be called
> to finalize the wakeup procedure *after* devices are waked up.
 
> ACPI finish calls acpi_leave_sleep_state() and restore the waking
> vectore. I"m not an ACPI guru but my guess is that what you need is
> in acpi_leave_sleep_state().
 
> If that"s the case we may want to split the finish callback (say
> prepare_wake and finish_wake).
This is what I did.

Stefan


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

RE: Re: Samsung P35 and S3 suspend

[Li, Shaohua]

>I think this is the patch I sent to this list a few months ago. Here
the
>archive linksfor reference:
>
>http://sourceforge.net/mailarchive/message.php?msg_id=9091506
>
>The background is that any write access to the pci config registers of
some
>devices(sound card, usb 2.0 controler, and modem) cause a system lockup
if
>they are called before acpi_leave_sleep_state and
>acpi_disable_wakeup_device
>were called. This is on an Acer Travelmate 803 Notebook, and it seems
to be
>the same on other systems.
>
>I sent the patch to the list, but it seems that nobody noticed it and I
>forgot
>to send it again. Here is an updated patch against 2.6.10. I can't
promise
>that it doesn't break other systems. Someone should make sure that
>pm_ops->leave is set to NULL for apm. I haven't found this in the apm
code
>yet.
>
And also please try this one (in kernel/power/main.c):
static void suspend_finish(suspend_state_t state)
{
-	device_resume();
	if (pm_ops && pm_ops->finish)
		pm_ops->finish(state);
+	device_resume();
	thaw_processes();
	pm_restore_console();
}
According to ACPI spec, device resume should be after _WAK method (in
acpi_leave_sleep_state)

Thanks,
Shaohua


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/

Re: Re: Samsung P35 and S3 suspend

[Stefan Dösinger]

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


> > >>- pci-resume-2.6.10.patch and resume-finish-split-2.6.10.patch
> > >>  are applied
> > >
> > > Excuse my ignorance, but where can I get these patches?
> > >
> > >From my local harddisk ;-)
> >
> > Actually, you only need resume-finish-split-2.6.10.patch, the other
> > patch did not have any effect in my testing. Patch attached.
>
> The patch actually looks good, are you going to submit it?
>         Pavel

I think this is the patch I sent to this list a few months ago. Here the 
archive linksfor reference: 

http://sourceforge.net/mailarchive/message.php?msg_id=9091506

The background is that any write access to the pci config registers of some 
devices(sound card, usb 2.0 controler, and modem) cause a system lockup if 
they are called before acpi_leave_sleep_state and acpi_disable_wakeup_device 
were called. This is on an Acer Travelmate 803 Notebook, and it seems to be 
the same on other systems.

I sent the patch to the list, but it seems that nobody noticed it and I forgot 
to send it again. Here is an updated patch against 2.6.10. I can't promise 
that it doesn't break other systems. Someone should make sure that 
pm_ops->leave is set to NULL for apm. I haven't found this in the apm code 
yet.

Stefan Dösinger

[-- Attachment #2: resume-finish-split.patch --]
[-- Type: text/x-diff, Size: 1855 bytes --]

--- linux-2.6.10/include/linux/pm.h	2004-12-26 15:25:39.639998872 +0100
+++ include/linux/pm.h	2004-12-26 15:27:10.885127504 +0100
@@ -208,6 +208,7 @@
 	suspend_disk_method_t pm_disk_mode;
 	int (*prepare)(suspend_state_t state);
 	int (*enter)(suspend_state_t state);
+	int (*leave)(suspend_state_t state);
 	int (*finish)(suspend_state_t state);
 };
 
--- linux-2.6.10/kernel/power/main.c	2004-12-26 15:25:54.377758392 +0100
+++ kernel/power/main.c	2004-12-26 15:26:31.472119192 +0100
@@ -104,6 +104,8 @@
 
 static void suspend_finish(suspend_state_t state)
 {
+	if (pm_ops && pm_ops->leave)
+		pm_ops->leave(state);
 	device_resume();
 	if (pm_ops && pm_ops->finish)
 		pm_ops->finish(state);
--- linux-2.6.10/drivers/acpi/sleep/main.c	2004-12-26 15:25:20.314936728 +0100
+++ drivers/acpi/sleep/main.c	2004-12-26 15:28:49.253173288 +0100
@@ -130,7 +130,23 @@
 	return ACPI_SUCCESS(status) ? 0 : -EFAULT;
 }
 
+/**
+ *	acpi_pm_leave - Make system ready to resume devices.
+ *	@pm_state:		State we're coming out of.
+ *
+ *	This is called after we wake back up and before device
+ *	resume methods are called.
+ */
+
+static int acpi_pm_leave(suspend_state_t pm_state)
+{
+	u32 acpi_state = acpi_suspend_states[pm_state];
 
+	acpi_leave_sleep_state(acpi_state);
+	acpi_disable_wakeup_device(acpi_state);
+	
+	return 0;
+}
 /**
  *	acpi_pm_finish - Finish up suspend sequence.
  *	@pm_state:		State we're coming out of.
@@ -143,9 +159,6 @@
 {
 	u32 acpi_state = acpi_suspend_states[pm_state];
 
-	acpi_leave_sleep_state(acpi_state);
-	acpi_disable_wakeup_device(acpi_state);
-
 	/* reset firmware waking vector */
 	acpi_set_firmware_waking_vector((acpi_physical_address) 0);
 
@@ -173,6 +186,7 @@
 static struct pm_ops acpi_pm_ops = {
 	.prepare	= acpi_pm_prepare,
 	.enter		= acpi_pm_enter,
+	.leave		= acpi_pm_leave,
 	.finish		= acpi_pm_finish,
 };
 

Re: Re: Samsung P35 and S3 suspend

[Pavel Machek]

Hi!

> >>- pci-resume-2.6.10.patch and resume-finish-split-2.6.10.patch
> >>  are applied
> > 
> > 
> > Excuse my ignorance, but where can I get these patches?
> 
> >From my local harddisk ;-)
> Actually, you only need resume-finish-split-2.6.10.patch, the other
> patch did not have any effect in my testing. Patch attached.

The patch actually looks good, are you going to submit it?
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Re: Samsung P35 and S3 suspend

[Carl-Daniel Hailfinger]

Carl-Daniel Hailfinger wrote:

> OK, I got S3 working with all kernels since 2.6.9 (well, your
> patches had to be modified slightly). Right now I'm running on the
> latest Linus -bk tree.
>
> I will now try other configurations and a full bootup.
>
> OK, it is working perfectly with the latest Linus -bk tree and
> everything configured in (SuSE .config, comparable to allmodconfig).

It turns out that (at least for 2.6.10-rc3 and later) the kernel
resumes from S3 perfectly regardless of .config as long as
- no framebuffer console is activated (kernel param video=vesa:off )
- pci-resume-2.6.10.patch and resume-finish-split-2.6.10.patch
  are applied
- suspend and resume happen with an active TEXT console (chvt 2)
- VESA registers are saved before suspend
- the radeon card is POSTed after resume
- the VESA registers are restored after that
- now you are free to change back to X if you want.

You do NOT need
- a patched X server
- a special kernel .config
- sacrifices of any kind.

See my other mail to acpi-devel for details about how to save/restore
the VESA registers and POST the card.

Question for the framebuffer experts: Is it possible to forbid access
to the video card after resume until the card has been POSTed and all
registers are restored? Any access to the card before that will freeze
the machine.

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Re: Samsung P35 and S3 suspend

[Carl-Daniel Hailfinger]

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

PROBLEM SOLVED COMPLETELY! Read on for details (and excuse the yelling)
;-)

Search engine hint: Samsung P30 P35 S3 suspend resume

Carl-Daniel Hailfinger schrieb:
> Matthew Garrett schrieb:
> 
>>On Thu, 2004-12-16 at 19:41 +0100, Matthias Hentges wrote:
>>
>>
>>
>>>1: VGA POST
>>>2. VESA reset
>>
>>
>>Can you try the vm86_video_post and vbestate programs from
>>http://www.srcf.ucam.org/~mjg59/laptops/ ? You want to do something like
>>this:
>>
>>1) chvt away from X on suspend
>>2) vbestate save >/tmp/state
>>3) suspend
>>4) resume
>>5) vm86_video_post
>>6) vbestate restore </tmp/state
>>7) chvt back to X
>>
>>This sequence (possibly with a dpms on in there somewhere) seems to work
>>on a fairly large number of machines.
> 
> 
> It sort of works. Before step 7, the (text mode) display contains garbage.

OK, I have a patch for vbestate which allows resume back to a text console
(no X server involved at all) and you should have clean fonts and usable
text console afterwards. The screen needs to be redrawn and Unicode fonts
have to be reloaded, but that can be handled, too.

The following script makes S3 from text console and/or X a breeze:

#!/bin/bash
statedir=/root/s3/state
curcons=`fgconsole`
fuser /dev/tty$curcons 2>/dev/null|xargs ps -o comm= -p|grep -q X && chvt 2
cat /dev/vcsa >$statedir/vcsa
sync
echo 3 >/proc/acpi/sleep
sync
vm86_video_post
vbestate restore <$statedir/vbe.5
cat $statedir/vcsa >/dev/vcsa
rckbd restart
chvt $[curcons%6+1]
chvt $curcons

IMPORTANT NOTES:
$statedir/vbe should be saved directly after bootup before entering X. It
only has to be saved once, you can use it for every situation afterwards.
That includes new boots, having switched from X to console, etc.
vbestate has to be patched with my patch to work correctly.
The script assumes that no harmful modules are loaded.
The kernel was 2.6.10-rc3 or later and had to be patched with
pci-resume-2.6.10.patch and resume-finish-split.patch.
.config available on request (see earlier in this thread for details).
You don't need a patched X for this to work.

With the above script my machine survived 32 iterations of S3 suspend
without any visible problems (no screen corruption, no freezes, even
umlauts are preserved). Sometimes I was in X, sometimes working on the
text console and it came back every time to the console I had used,
screen contents exactly the same as before.

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

[-- Attachment #2: vbestate-s3.diff --]
[-- Type: text/plain, Size: 778 bytes --]

diff -urN vbestate-0.1/vbestate.c vbestate-0.1-s3/vbestate.c
--- vbestate-0.1/vbestate.c	2004-12-09 00:42:51.000000000 +0100
+++ vbestate-0.1-s3/vbestate.c	2004-12-21 01:37:06.132044112 +0100
@@ -119,6 +119,9 @@
 		short tmpbuffer[524288];
 		size_t i,length=0;
 		
+		/* The loop below doesn't make any sense unless we think our
+		input data contains length/sizeof(tmpbuffer)*sizeof(tmpbuffer)
+		bytes of leading garbage */
 		while (i=read(0, tmpbuffer, sizeof(tmpbuffer))) {
 			length+=i;
 		}
@@ -127,6 +130,12 @@
 		memcpy(data,tmpbuffer,length);
 
 		restore_state(data);
+		text_mode();
+
+		data = LRMI_alloc_real(length);
+		memcpy(data,tmpbuffer,length);
+
+		restore_state(data);
 	} else {
 		fprintf(stderr,"%s: Usage %s [save|restore]\n",
 			argv[0],argv[0]);

Re: Re: Samsung P35 and S3 suspend

[Carl-Daniel Hailfinger]

Matthew Garrett schrieb:
> On Thu, 2004-12-16 at 19:41 +0100, Matthias Hentges wrote:
> 
> 
>>1: VGA POST
>>2. VESA reset
> 
> 
> Can you try the vm86_video_post and vbestate programs from
> http://www.srcf.ucam.org/~mjg59/laptops/ ? You want to do something like
> this:
> 
> 1) chvt away from X on suspend
> 2) vbestate save >/tmp/state
> 3) suspend
> 4) resume
> 5) vm86_video_post
> 6) vbestate restore </tmp/state
> 7) chvt back to X
> 
> This sequence (possibly with a dpms on in there somewhere) seems to work
> on a fairly large number of machines.

It sort of works. Before step 7, the (text mode) display contains garbage.
But it is much more comfortable than starting a second X server.
Any chance to get the functionality into
- the X.Org Radeon server and
- the kernel to make suspend work with framebuffer console?

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Re: Samsung P35 and S3 suspend

[Carl-Daniel Hailfinger]

Stefan Dösinger schrieb:
>>That patch has been merged into the 6.8.x tree at X.Org three minutes ago,
>>so it will be in the 6.8.2 release.
>>
>>Did I understand correctly that with this patch should make POSTing the
>>card with boot-radeon unnecessary? Current 6_8_BRANCH X.Org is building
>>here at the moment, will report back when it is installed.

(I built X.Org CVS HEAD, but it has the same patch.)


> Yes, that's correct.
> 
> It was AFAIK the first way to wake up the radeon card. boot-radeon was written 
> based on the X11 patch.

Unfortunately, that fails on my Samsung P35. (Well, at least the display
backlight comes back and the machine doesn't crash.)

Messages by the X server after resume:

(WW) RADEON(0): zero MEMSIZE, probably at D3cold. Re-POSTing via int10.
(II) RADEON(0): Primary V_BIOS segment is: 0xc000
(EE) RADEON(0): unknown reason for exception
(II) RADEON(0): EAX=0x00004e08, EBX=0x00000106, ECX=0x00000000, EDX=0x000030fa
(II) RADEON(0): ESP=0x00000fb2, EBP=0x00000fba, ESI=0x00003d17, EDI=0x00000000
(II) RADEON(0): CS=0x5110, SS=0x0100, DS=0x0040, ES=0x0000, FS=0x0000, GS=0x0000
(II) RADEON(0): EIP=0x0000ffff, EFLAGS=0x00033206
(II) stack at 0x00001fb2:
 aa 3d 00 f0 52 3d 18 f9 00 c0 00 00 00 00 f9 01
 00 00 ce 0f 06 01 fa 30 00 00 08 4e f9 95 00 c0
 46 32 ad 08 56 08 00 00 00 00 00 00 00 00 00 00
 00 00 f8 0f 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 01 00 00 00 00 40 00 00 06 00 00
(II) RADEON(0): code at 0x000610ff:
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
(EE) RADEON(0): cannot continue
(II) RADEON(0): BIOS HotKeys Disabled
(II) Mouse[1]: ps2EnableDataReporting: succeeded

Especially CS:EIP looks suspicious.

So what step would be next? IIRC on the P35 needed a crashing VESA server
in addition to boot-radeon. Can that step be added somehow to the Radeon
X server?


Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Re: Samsung P35 and S3 suspend

[Stefan Dösinger]

> That patch has been merged into the 6.8.x tree at X.Org three minutes ago,
> so it will be in the 6.8.2 release.
>
> Did I understand correctly that with this patch should make POSTing the
> card with boot-radeon unnecessary? Current 6_8_BRANCH X.Org is building
> here at the moment, will report back when it is installed.
Yes, that's correct.

It was AFAIK the first way to wake up the radeon card. boot-radeon was written 
based on the X11 patch.

Stefan


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Re: Samsung P35 and S3 suspend

[Carl-Daniel Hailfinger]

Stefan Dösinger schrieb:
> Attached is a patch against Xorg-6.8.0 which makes the radeon X11 driver call 
> the reset routine if it notices that the system was in S3. This patch is 
> quite uncomfortable because it's necessary to recompile X11. It is from 
> Gentoo where it is compiled by default.

That patch has been merged into the 6.8.x tree at X.Org three minutes ago,
so it will be in the 6.8.2 release.

Did I understand correctly that with this patch should make POSTing the card
with boot-radeon unnecessary? Current 6_8_BRANCH X.Org is building here at
the moment, will report back when it is installed.

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Re: Samsung P35 and S3 suspend

[Matthew Garrett]

On Thu, 2004-12-16 at 22:26 +0100, Stefan Dösinger wrote:

> This is partially true for my system. The instruction at c000:0003 is a JMP. 
> But the code seems to remain in the area around 0xc0000. A jump somewhere 
> else is a good explanation for the crashes on some machines.
> 
> Is this code used by the system bios to boot the VGA card when powering on the 
> machine?

Yup. However, bear in mind that a typical laptop BIOS is about 512K.
There's a lot of code that's used during boot, but then unmapped again
because it shouldn't be needed by any user application. Depending on
your machine, this may include stuff that's used for video POSTing.

> > POSTing will help in some cases (it seems to work well on Thinkpads),
> > but it's not a universal cure. I've had more joy with saving and
> > restoring the VBE state.
> Is this the vbestate utility? I'll have a look at it. What does 
> vm86_video_post do? It looks like another lrmi based "call c000:0003 
> utility". Can only saving and restoring the VBE state bring the card back to 
> live or do I need to call the reset routine in any case?

vm86_video_post is just an lrmi-based POST tool, yeah - I hacked it
together after speaking to some of the X.org people and discovering that
they don't have too much faith in the correctness of the x86emu code.
One advantage it does have over most of the POST tools is that it puts
the device it's initialising in ax, which seems to make a difference in
some hardware. On the Dell X300, just calling the POST code results in
nasty screen effects. Having the PCI ID in ax seems to avoid this.

I'm not sure whether saving and restoring VBE state is sufficient. It
seems quite effective in combination with POSTing.
-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/

Re: Re: Samsung P35 and S3 suspend

[Stefan Dösinger]

> It turns out that this works badly. A large number of machines have code
> at c000:0003 that jumps to somewhere else in the video ROM - this
> executes a small amount of code (normally turning off the screen) and
> then jumps elsewhere. In laptop hardware, this second jump is often to
> code that is no longer mapped into address space. I've seen several
> machines where trying to run POST code under XFree's x86 emulator fails
> because it suddenly hits a pile of binary that looks nothing like the
> x86 instruction set.
This is partially true for my system. The instruction at c000:0003 is a JMP. 
But the code seems to remain in the area around 0xc0000. A jump somewhere 
else is a good explanation for the crashes on some machines.

Is this code used by the system bios to boot the VGA card when powering on the 
machine?

> POSTing will help in some cases (it seems to work well on Thinkpads),
> but it's not a universal cure. I've had more joy with saving and
> restoring the VBE state.
Is this the vbestate utility? I'll have a look at it. What does 
vm86_video_post do? It looks like another lrmi based "call c000:0003 
utility". Can only saving and restoring the VBE state bring the card back to 
live or do I need to call the reset routine in any case?

Stefan


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Re: Samsung P35 and S3 suspend

[Matthew Garrett]

On Thu, 2004-12-16 at 21:57 +0100, Stefan Dösinger wrote:

> In the ideal case the frame buffer driver would run the VGA Rom post 
> routine($0xc000:$3) in an X86 emulator(or in vm86 mode if it works), set up 
> the frame buffer and at the end of the resume function the device is in the 
> same state where it was before suspend and user mode programs like the 
> X-Server won't recognise that the system was suspended.
> That's at least my opinion.

It turns out that this works badly. A large number of machines have code
at c000:0003 that jumps to somewhere else in the video ROM - this
executes a small amount of code (normally turning off the screen) and
then jumps elsewhere. In laptop hardware, this second jump is often to
code that is no longer mapped into address space. I've seen several
machines where trying to run POST code under XFree's x86 emulator fails
because it suddenly hits a pile of binary that looks nothing like the
x86 instruction set.

(This is fairly easy to test, by the way - you can generally dump the
video rom by dding out of /dev/kmem. Disassemble it and work out where
it jumps to, and then disassemble that. Keep following it and you may
well end up discovering that it jumps out to code that you're not able
to get hold of)

POSTing will help in some cases (it seems to work well on Thinkpads),
but it's not a universal cure. I've had more joy with saving and
restoring the VBE state.

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



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/

Re: Re: Samsung P35 and S3 suspend

[Stefan Dösinger]

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


> > Just a note about 2.6.10-rc2/3 kernels: I also had some Problems with
> > them. snd-Intel8x0 needs an update concerning PCI config save/restore and
> > ehci-hcd causes problems after resume. uhci-hcd suspend/resume works for
> > me, except that I must not plug or unplug usb devices while the system is
> > supended.
>
> Could you go into more detail? Changing the hardware config while suspended
> is obviously not recommended, but what are the exact problems occuring
> besides that?
I get a kernel panic at resume if I plugged in a device while suspended 
(Capslock led blinking, screen stays black)
The system locks during resume up if I unplug a device while in S3(capslock 
led not blinking, screen stays black too.)

> > No, I think it's the kernels problem. The various framebuffer drivers 
should 
> > know how to wake up the card.
> > There were some discussions on the linux-fbdev-devel list about writing a 
> > lightwhight(20-30k) 8086 emulator for the kernel to avoid real mode hacks.
> > As far as I know, this should be based on the 8086 emulator XFree/X.org 
uses.

> Yes, but for that to work we should have a procedure in place which allows
> us to get the card working again without having to crash a secondary vesa
> xserver. If boot-radeon could be extended to do the things the crashing
> vesa xserver does, we would be much better off. That could be folded
> a) into the kernel framebuffer drivers
> b) into the radeon xserver.
In the ideal case the frame buffer driver would run the VGA Rom post 
routine($0xc000:$3) in an X86 emulator(or in vm86 mode if it works), set up 
the frame buffer and at the end of the resume function the device is in the 
same state where it was before suspend and user mode programs like the 
X-Server won't recognise that the system was suspended.
That's at least my opinion.

Boot-radeon and the others are supposed to do that(in User mode), but the 
80x86 environment they set up seems to be incorrect in some way so they crash 
before they finish their task on some systems. If it works, the display comes 
back without any Vesa X11 server.

Attached is a patch against Xorg-6.8.0 which makes the radeon X11 driver call 
the reset routine if it notices that the system was in S3. This patch is 
quite uncomfortable because it's necessary to recompile X11. It is from 
Gentoo where it is compiled by default.

Stefan

[-- Attachment #2: 9375_all_6.7.0-radeon-resume-from-S3-suspend.patch --]
[-- Type: text/x-diff, Size: 1508 bytes --]

This enables resume from suspend level S3 by asking the Radeon chip if it
thinks it has no memory.  If so, the card is re-POSTed via the int10
interface.  Reportedly enables the driver to work for this type of
suspend/resume cycle on Dell D600 laptops (Dell D800s as well, if the video
BIOS is patched to 4.28.20.31.C1 or later). See Gentoo bug #48095 or Debian bug
#234575. This patch by Emmanuel Thome and Ole Rohne, and this info borrowed from
Debian.

--- xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c	2003-10-25 00:10:20.000000000 +0200
+++ xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c.new	2003-11-22 17:20:14.000000000 +0100
@@ -345,6 +345,7 @@
     "xf86InitInt10",
     "xf86FreeInt10",
     "xf86int10Addr",
+    "xf86ExecX86int10",
     NULL
 };
 
@@ -6409,9 +6410,22 @@
 {
     ScrnInfoPtr    pScrn = xf86Screens[scrnIndex];
     RADEONInfoPtr  info  = RADEONPTR(pScrn);
+    unsigned char * RADEONMMIO = info->MMIO;
 
     RADEONTRACE(("RADEONEnterVT\n"));
 
+    if (INREG(RADEON_CONFIG_MEMSIZE) == 0) { /* Softboot V_BIOS */
+      xf86Int10InfoPtr pInt;
+	xf86DrvMsg(pScrn->scrnIndex, X_WARNING,
+	       "zero MEMSIZE, probably at D3cold. Re-POSTing via int10.\n");
+      pInt = xf86InitInt10 (info->pEnt->index);
+      if (pInt) {
+        pInt->num = 0xe6;
+        xf86ExecX86int10 (pInt);
+        xf86FreeInt10 (pInt);
+      }
+    }
+
     if (info->FBDev) {
 	unsigned char *RADEONMMIO = info->MMIO;
 	if (!fbdevHWEnterVT(scrnIndex,flags)) return FALSE;

Re: Re: Samsung P35 and S3 suspend

[Matthew Garrett]

On Thu, 2004-12-16 at 19:41 +0100, Matthias Hentges wrote:

> 1: VGA POST
> 2. VESA reset

Can you try the vm86_video_post and vbestate programs from
http://www.srcf.ucam.org/~mjg59/laptops/ ? You want to do something like
this:

1) chvt away from X on suspend
2) vbestate save >/tmp/state
3) suspend
4) resume
5) vm86_video_post
6) vbestate restore </tmp/state
7) chvt back to X

This sequence (possibly with a dpms on in there somewhere) seems to work
on a fairly large number of machines.

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



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Re: Samsung P35 and S3 suspend

[Matthias Hentges]

Am Donnerstag, den 16.12.2004, 19:10 +0100 schrieb Carl-Daniel
Hailfinger:
> Carl-Daniel Hailfinger schrieb:

[...]

> OK, it is working perfectly with the latest Linus -bk tree and
> everything configured in (SuSE .config, comparable to allmodconfig).
> The only things which are NOT enabled are:
> -CONFIG_REGPARM
> -CONFIG_HIGHMEM
> -CONFIG_EFI
> -CONFIG_FB
> -CONFIG_VIDEO_SELECT

I'll try that, thanks :)

> Before suspending, I start both X-Servers (like you) and then
> chvt 1
> modprobe -r uhci_hcd ehci_hcd ohci1394 snd_intel8x0
> sleep 5
> echo 3 >/proc/acpi/sleep

Basically the same here.

> Resume procedure is the same as yours.
> 
> I'm still trying to figure out what the Vesa X-Server does what
> can't be done with vbetest or similar.

Here's my theory:

All that is needed to bring back our card is:
1: VGA POST
2. VESA reset

The kernel parameter "acpi_sleep=s3_bios,s3_mode" would do just that.
But for some retarded reason, any kernel access to the card freezes the
machine.

Find the reason, and the kernel parameter should work perfectly.
Maybe even framebuffer could be used (and hence, bootsplash).


-- 
Matthias Hentges 
Cologne / Germany

[www.hentges.net] -> PGP welcome, HTML tolerated
ICQ: 97 26 97 4   -> No files, no URL's

My OS: Debian SID. Geek by Nature, Linux by Choice



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Re: Samsung P35 and S3 suspend

[Carl-Daniel Hailfinger]

Stefan Dösinger schrieb:
>>OK, I got S3 working with all kernels since 2.6.9 (well, your patches
>>had to be modified slightly). Right now I'm running on the latest
>>Linus -bk tree.
>>
>>I will now try other configurations and a full bootup.
> 
> Just a note about 2.6.10-rc2/3 kernels: I also had some Problems with them. 
> snd-Intel8x0 needs an update concerning PCI config save/restore and ehci-hcd 
> causes problems after resume. uhci-hcd suspend/resume works for me, except 
> that I must not plug or unplug usb devices while the system is supended.

Could you go into more detail? Changing the hardware config while suspended
is obviously not recommended, but what are the exact problems occuring
besides that?


>>Besides that, I think we could convince the X.Org developers that
>>the "get display working" bug is their problem ;-)
>>It seems they have merged some suspend/resume bugfixes for Radeon and
>>will merge at least one more bugfix in the next few days. Basically,
>>it should be possible that the normal Radeon Xserver rePOSTs the card
>>itself once it detects a resume event. If that is done properly, we
>>could get rid of the hack completely and would only have to live with
>>the text console.
> 
> No, I think it's the kernels problem. The various framebuffer drivers should 
> know how to wake up the card.
> There were some discussions on the linux-fbdev-devel list about writing a 
> lightwhight(20-30k) 8086 emulator for the kernel to avoid real mode hacks.
> As far as I know, this should be based on the 8086 emulator XFree/X.org uses.

Yes, but for that to work we should have a procedure in place which allows
us to get the card working again without having to crash a secondary vesa
xserver. If boot-radeon could be extended to do the things the crashing
vesa xserver does, we would be much better off. That could be folded
a) into the kernel framebuffer drivers
b) into the radeon xserver.


Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Re: Samsung P35 and S3 suspend

[Carl-Daniel Hailfinger]

Carl-Daniel Hailfinger schrieb:
> Carl-Daniel Hailfinger schrieb:
> 
>>Matthias Hentges schrieb:
>>
>>
>>>Am Mittwoch, den 15.12.2004, 18:59 +0100 schrieb Carl-Daniel Hailfinger:
>>>
>>>
>>>>Oh, and once I get S3 working with 2.6.9 I'll do a binary search
>>>>to find the changeset that is causing the problems after 2.6.9
>>>>and report back.
>>>
>>>That would be most appreciated. I still haven't fully recovered from
>>>trying 30+ kernels / configurations to find the borked patch ;)
>>
>>A first hint: CONFIG_REGPARM killed swsusp in some kernels before
>>2.6.10-rc3, it could also be the culprit for S3.
> 
> OK, I got S3 working with all kernels since 2.6.9 (well, your patches
> had to be modified slightly). Right now I'm running on the latest
> Linus -bk tree.
> 
> I will now try other configurations and a full bootup.

OK, it is working perfectly with the latest Linus -bk tree and
everything configured in (SuSE .config, comparable to allmodconfig).
The only things which are NOT enabled are:
-CONFIG_REGPARM
-CONFIG_HIGHMEM
-CONFIG_EFI
-CONFIG_FB
-CONFIG_VIDEO_SELECT

Before suspending, I start both X-Servers (like you) and then
chvt 1
modprobe -r uhci_hcd ehci_hcd ohci1394 snd_intel8x0
sleep 5
echo 3 >/proc/acpi/sleep

Resume procedure is the same as yours.

I'm still trying to figure out what the Vesa X-Server does what
can't be done with vbetest or similar.

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Re: Samsung P35 and S3 suspend

[Stefan Dösinger]

> OK, I got S3 working with all kernels since 2.6.9 (well, your patches
> had to be modified slightly). Right now I'm running on the latest
> Linus -bk tree.
>
> I will now try other configurations and a full bootup.
Just a note about 2.6.10-rc2/3 kernels: I also had some Problems with them. 
snd-Intel8x0 needs an update concerning PCI config save/restore and ehci-hcd 
causes problems after resume. uhci-hcd suspend/resume works for me, except 
that I must not plug or unplug usb devices while the system is supended.

> Besides that, I think we could convince the X.Org developers that
> the "get display working" bug is their problem ;-)
> It seems they have merged some suspend/resume bugfixes for Radeon and
> will merge at least one more bugfix in the next few days. Basically,
> it should be possible that the normal Radeon Xserver rePOSTs the card
> itself once it detects a resume event. If that is done properly, we
> could get rid of the hack completely and would only have to live with
> the text console.
No, I think it's the kernels problem. The various framebuffer drivers should 
know how to wake up the card.
There were some discussions on the linux-fbdev-devel list about writing a 
lightwhight(20-30k) 8086 emulator for the kernel to avoid real mode hacks.
As far as I know, this should be based on the 8086 emulator XFree/X.org uses.

Cheers,
Stefan


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Re: Samsung P35 and S3 suspend

[Carl-Daniel Hailfinger]

Carl-Daniel Hailfinger schrieb:
> Matthias Hentges schrieb:
> 
>>Am Mittwoch, den 15.12.2004, 18:59 +0100 schrieb Carl-Daniel Hailfinger:
>>
>>>Oh, and once I get S3 working with 2.6.9 I'll do a binary search
>>>to find the changeset that is causing the problems after 2.6.9
>>>and report back.
>>
>>That would be most appreciated. I still haven't fully recovered from
>>trying 30+ kernels / configurations to find the borked patch ;)
> 
> A first hint: CONFIG_REGPARM killed swsusp in some kernels before
> 2.6.10-rc3, it could also be the culprit for S3.

OK, I got S3 working with all kernels since 2.6.9 (well, your patches
had to be modified slightly). Right now I'm running on the latest
Linus -bk tree.

I will now try other configurations and a full bootup.

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Re: Samsung P35 and S3 suspend

[Carl-Daniel Hailfinger]

Matthias Hentges schrieb:
> 
>> Matthias Hentges schrieb:
>> 
>>>I haven't had any luck with resume on any kernel > 2.6.9 so far.
>>>So, I suggest you try 2.6.9 and apply the patches from here:
>>>http://www.hentges.net/misc/howtos/samsung_p30_s3.shtml

> Am Mittwoch, den 15.12.2004, 18:59 +0100 schrieb Carl-Daniel Hailfinger:
> 
>>Do you have any hints what to exclude in the .config? The .config
>>which was once available in your forum is marked as "deleted
>>attachment" and cannot be downloaded.
> 
> Do not use any framebuffer, be it radeonfb or vesafb, it will freeze
> your machine on resume. USB drivers should be built as modules and need
> to be unloaded before suspending or USB might become FUBAR after a
> resume. Besides that, I don't remember anything which I haven't noted on
> my page (see above).
> [...]
> 
> I've attached my current kernel .config for 2.6.9 and the suspend script
> I'm using. 
> It looks like an ugly hack but it is working very well for me

Thanks! While you wrote your mail, I got S3 working here, but your suspend
script is very appreciated.


>>Oh, and once I get S3 working with 2.6.9 I'll do a binary search
>>to find the changeset that is causing the problems after 2.6.9
>>and report back.
> 
> That would be most appreciated. I still haven't fully recovered from
> trying 30+ kernels / configurations to find the borked patch ;)

A first hint: CONFIG_REGPARM killed swsusp in some kernels before
2.6.10-rc3, it could also be the culprit for S3.

Besides that, I think we could convince the X.Org developers that
the "get display working" bug is their problem ;-)
It seems they have merged some suspend/resume bugfixes for Radeon and
will merge at least one more bugfix in the next few days. Basically,
it should be possible that the normal Radeon Xserver rePOSTs the card
itself once it detects a resume event. If that is done properly, we
could get rid of the hack completely and would only have to live with
the text console.

Once these patches are merged completely, I'll try a current X.Org
build and open a bug with X.Org if the situation isn't better.


Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/