Skip to contentSkip to conversation

Suspend-to-RAM on Sony Vaios

DISCUSSION Jon Valvatne 9 participants 26 messages Oct 18, 2004 – Nov 3, 2004 19 messages not in the archive ACPI

lore
Share & tools
lore

Jon Valvatne

author
#0 lore raw

Hello list,

I'd very much like to get suspend-to-RAM working on my Vaio X505; any pointers would be very welcome. Trying with the latest RPM-kernel for FC2, I can get it suspended just fine (after removing the ehci_hcd module), but it doesn't come back up.

Specifically: Once it's suspended, it seems dead except for a slowly blinking red power LED. When I press any button or key, it goes completely dead, requiring the battery to be taken out and reinserted before it'll even respond to the power button. Between those two states (blinking LED and completely dead) there is no indication whatsoever that it even tries to wake up - the LED simply stops blinking the moment I touch a key.

I haven't heard of anyone else installing Linux on this specific model of Vaio yet, and all I see of other Linux-on-Vaio-experiences only tell of similar problems, with no solutions. All the suspends-but-doesn't-resume stories I've seen here on this list tell of systems that make signs of starting up before they crash, as opposed to mine which doesn't. That makes me think my case is different, and it makes me doubt that it's the VGA issue again... I could be wrong though, I don't pretend to know the details of this stuff.

Any pointers on how to debug this problem at all? The syslog is obviously useless; the hard drive isn't even spinning when the problem occurs.

Thanks in advance,

Jon Valvatne
Barcelona, Spain

-------------------------------------------------------
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): 20041018020816.48673359-bi+AKbBUZKY6gyzm1THtWbp2dZbC/[email protected]

#2 lore raw
Quoted 7 lines · Jon Valvatne

Hello list,

I'd very much like to get suspend-to-RAM working on my Vaio X505; any pointers would be very welcome. Trying with the latest RPM-kernel for FC2, I can get it suspended just fine (after removing the ehci_hcd module), but it doesn't come back up.

What kernel version are you using? Are you using the latest versoin of ACPI?

I had exactly the same problem with ACPI before acpi-20040816-26. At which point I then had the video mode problem.

Signature · 9 lines
Ivor Hewitt.
http://www.ivor.it - tech | http://www.ivor.org - hedge


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

author
#4 lore raw
Quoted 10 lines · On Mon, 18 Oct 2004 04:15:59 +0000 Ivor Hewitt…
Quoted 7 lines · Jon Valvatne

Hello list,

I'd very much like to get suspend-to-RAM working on my Vaio X505; any pointers would be very welcome. Trying with the latest RPM-kernel for FC2, I can get it suspended just fine (after removing the ehci_hcd module), but it doesn't come back up.

What kernel version are you using? Are you using the latest versoin of ACPI?

I'm using 2.6.8-1.521 from FC2, so no, I am not. I suppose I'll try 2.6.9 when it comes.

Quoted 3 lines

I had exactly the same problem with ACPI before acpi-20040816-26. At which point I then had the video mode problem.

Thanks, that's actually very good to hear; at least the video mode problem is a known one :) Can I ask what your hardware is?

Jon

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

#5 lore raw
In reply to a message not in the archive

Hi!

Please wrap your messages at column 72

Quoted 2 lines

Specifically: Once it's suspended, it seems dead except for a slowly blinking red power LED. When I press any button or key, it goes completely dead, requiring the battery to be taken out and reinserted before it'll even respond to the power button. Between those two states (blinking LED and completely dead) there is no indication whatsoever that it even tries to wake up - the LED simply stops blinking the moment I touch a key.

If battery needs to be reinserted, complain to sony. They have hw bug in there.

For debugging techniques... There's beeping patch from me floating around.

Signature · 9 lines
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         



-------------------------------------------------------
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): 20041018112632.GB4400-u08AdweFZfgxtPtxi4kahqVXKuFTiq87@public.gmane.org

author
#7 lore raw

Hey,

Quoted 4 lines · On Mon, 18 Oct 2004 13:26:33 +0200 Pavel Machek…

Hi!

Please wrap your messages at column 72

Yeah, sorry about that. My newly installed sylpheed seems to have had wrapping off by default; weird but true.

Quoted 7 lines

If battery needs to be reinserted, complain to sony. They have hw bug in there.

For debugging techniques... There's beeping patch from me floating around.

Thanks, but with 2.6.9-final it actually does resume, so luckily I won't have to suffer the beeping :)

I do hit the video problem though. I've tried the stuff in power/video.txt, but mine doesn't seem to be among the few systems with a solution at the moment. I don't have a Radeon, so I haven't tried the radeonfb-patch that's been floating around
(http://www.loria.fr/~thome/d600/), but the part that mentions "you may insert a similar call from the vesa frame buffer driver to obtain similar results for a wide range of cards" intrigues me. Could this be something to try? Or is this already what acpi_sleep=s3_bios does?

I'm on an Intel 855GM by the way.

Jon

-------------------------------------------------------
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): 20041021001331.69c6c965-bi+AKbBUZKY6gyzm1THtWbp2dZbC/[email protected]

#9 lore raw

Hi!

Quoted 5 lines
Quoted 2 lines

For debugging techniques... There's beeping patch from me floating around.

Thanks, but with 2.6.9-final it actually does resume, so luckily I won't have to suffer the beeping :)

Good.

Quoted 8 lines

I do hit the video problem though. I've tried the stuff in power/video.txt, but mine doesn't seem to be among the few systems with a solution at the moment. I don't have a Radeon, so I haven't tried the radeonfb-patch that's been floating around
(http://www.loria.fr/~thome/d600/), but the part that mentions "you may insert a similar call from the vesa frame buffer driver to obtain similar results for a wide range of cards" intrigues me. Could this be something to try? Or is this already what acpi_sleep=s3_bios does?

No, its something different. Take Ole's patch and port it to whatever framebuffer you use... and good luck with that.
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): 20041020225334.GC29863-I/[email protected]

#11 lore raw

Hi all,

The attached patch provides acpi_sleep=s3_late_bios boot option. This is just a trivial wrap-up of Ole's patch. It hooks into pci_default_resume (on X86 only and even then only when the flag is given), so you actually can resume the video without a framebuffer driver (and if you do have one, well, it should do what it takes to handle resume).

Ole, do you mind having your code wrapped up this way ?

I'd be curious to know whether other machines than my Dell D600 (with a radeon 9000) and Ole's Fujitsu P2120 (with a radeon 7000) work with this hack.

A few annoying bits, still:

When the machine resumes (using s3_late_bios), hitting a key seems to be necessary to finish the wakeup. Weird.

At present, I can resume with video=radeonfb:off acpi_sleep=s3_late_bios , but not from a VESA mode: the machine hangs in the VGA bios lcall. I'm having difficulties issuing good beeps during the late real mode step:
beep starts, but never ends. So perhaps something is wrong with the real mode setup, forbidding I/Os, or something like this (which could explain that resuming from anything less trivial than basic 80x25 crashes). The beep code I use is from pcspkr.c :

#define BEEP(X)                 \
        inb     $0x61, %al;     \
        orb     $3,%al;         \
        outb    %al, $0x61;     \
        movb    $0xb6, %al;     \
        outb    %al, $0x43;     \
        movb    $0, %al;        \
        outb    %al, $0x42;     \
        movb    X, %al;         \
        outb    %al, $0x42;     \
        movw    $0x3FF, %bx;    \
20:                             \
        movw    $0, %ax;        \
21:                             \
        decw    %ax;            \
        jnz     21b;            \
        decw    %bx;            \
        jnz     20b;            \
        inb     $0x61, %al;     \
        and     $0xfc, %al;     \
        outb    %al, $0x61
#define DEBUG_TONE      \
        BEEP($0x20);    \
        BEEP($0x04)

E.

Quoted 22 lines · Pavel Machek

Hi!

Quoted 5 lines
Quoted 2 lines

For debugging techniques... There's beeping patch from me floating around.

Thanks, but with 2.6.9-final it actually does resume, so luckily I won't have to suffer the beeping :)

Good.

Quoted 8 lines

I do hit the video problem though. I've tried the stuff in power/video.txt, but mine doesn't seem to be among the few systems with a solution at the moment. I don't have a Radeon, so I haven't tried the radeonfb-patch that's been floating around
(http://www.loria.fr/~thome/d600/), but the part that mentions "you may insert a similar call from the vesa frame buffer driver to obtain similar results for a wide range of cards" intrigues me. Could this be something to try? Or is this already what acpi_sleep=s3_bios does?

No, its something different. Take Ole's patch and port it to whatever framebuffer you use... and good luck with that.
Pavel

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

#13 lore raw

Emmanuel> Ole, do you mind having your code wrapped up this way ?

Not the least! Thank you very much for picking it up! - it has become clear that I wouldn't ever have the capacity of bringing it beyond the "works for me" stage:-)

Emmanuel> I'd be curious to know whether other machines than my Dell Emmanuel> D600 (with a radeon 9000) and Ole's Fujitsu P2120 (with a Emmanuel> radeon 7000) work with this hack.

And I'm even more curious about why it doesn't work on some machines...

Emmanuel> A few annoying bits, still:

Emmanuel> When the machine resumes (using s3_late_bios), hitting a key Emmanuel> seems to be necessary to finish the wakeup. Weird.

On the P2120, this rarely happens, and I think only if the machine was under heavy load when suspended. I'm guessing it is a missing interrupt. Linux reenables interrupts early, and some of the drivers' resume code could depend on getting at least one event to complete.

Emmanuel> At present, I can resume with video=radeonfb:off Emmanuel> acpi_sleep=s3_late_bios , but not from a VESA mode:

On the P2120, resuming from the hires framebuffer console works, I haven't even tested the 80x25:-)

Ole

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

#14 lore raw
In reply to a message not in the archive

Hi!

Quoted 5 lines

The attached patch provides acpi_sleep=s3_late_bios boot option. This is just a trivial wrap-up of Ole's patch. It hooks into pci_default_resume (on X86 only and even then only when the flag is given), so you actually can resume the video without a framebuffer driver (and if you do have one, well, it should do what it takes to handle resume).

Patch looks good to me...

Review

Quoted 6 lines
(quoted diff) +6 -0
+	# Fixup 16-bit CS descriptor
+	movl	%ecx, %edx
+	movw	%dx, go_real_cseg - wakeup_start + 2 (%eax)
+	shrl	$16, %edx
+	movb	%dl, go_real_cseg - wakeup_start + 4 (%eax)
+	movb	%dh, go_real_cseg - wakeup_start + 7 (%eax)

Uff, this looks pretty ugly. But I guess it is i386 being ugly...

drivers/pci/pci-driver.c line 340

Quoted 8 lines
drivers/pci/pci-driver.c +2 -0
@@ -336,6 +336,20 @@
 	/* if the device was busmaster before the suspend, make it busmaster again */
 	if (pci_dev->is_busmaster)
 		pci_set_master(pci_dev);
+#if	defined(CONFIG_X86) && defined(CONFIG_ACPI_SLEEP)
+	if (((pci_dev->class ^ (PCI_CLASS_DISPLAY_VGA << 8)) & 0xffff00)==0)

The use of xor here is certainly interesting. Is it possible to say

	pci_dev->class & 0xffff00 == PCI_CLASS_DISPLAY_VGA << 8

?

drivers/pci/pci-driver.c line 350

Quoted 10 lines
drivers/pci/pci-driver.c +10 -0
+	{
+		/* This is a no-op, and returns -1, in case s3_bios_late
+		 * hasn't been specified on the kernel command line
+		 */
+		int rc;
+		rc=acpi_vgapost (pci_dev->bus->number << 8 | pci_dev->devfn);
+		if (rc==0) {
+			printk(KERN_INFO "resumed pci graphics adapter %s\n",
+				pci_name(pci_dev));
+		}

Please do it without the variable, and use

	foo = bar(baz, xyzzy);

style of formatting.

include/asm-i386/acpi.h line 191

Quoted 8 lines
include/asm-i386/acpi.h +2 -0
@@ -187,6 +187,9 @@
 /* early initialization routine */
 extern void acpi_reserve_bootmem(void);
 
+/* real mode excursion to post code from vga rom ; must come once pci is up. */
+extern int acpi_vgapost (unsigned long);

~--
\ kill this space.

Quoted 9 lines
arch/i386/kernel/acpi/sleep_hacks.h +6 -0
@@ -0,0 +1,16 @@
+#ifndef ACPI_SLEEP_HACKS_H_
+#define ACPI_SLEEP_HACKS_H_
+
+#ifdef	CONFIG_ACPI_SLEEP
+
+#define	ACPI_SLEEP_S3_BIOS	1

arch/i386/kernel/acpi/sleep_hacks.h line 16

Quoted 10 lines
arch/i386/kernel/acpi/sleep_hacks.h +10 -0
+#define	ACPI_SLEEP_S3_MODE	2
+#define	ACPI_SLEEP_S3_LATE_BIOS	4
+#define	ACPI_SLEEP_S3_LATE_MODE	8
+#define	ACPI_SLEEP_S3_LATE_MASK	12
+#define ACPI_SLEEP_S3_LATE_BITS(X)	(((X)&12)>>2)
+
+#endif
+
+
+#endif	/* ACPI_SLEEP_HACKS_H_ */

Does it really deserve its own header file? Hmm and it should probably be common between x86-64 and i386, as we might need 64-bit version in future...

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

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

#16 lore raw
Quoted 1 line · Pavel Machek

Patch looks good to me...

Great. Here's an updated version.

Quoted 1 line

Uff, this looks pretty ugly. But I guess it is i386 being ugly...

The present version does the indirection once and for all, it's more readable. I've documented a bit the segment descriptor stuff, so that it's not so mystifying. I can do most of it in C, using asm/processor.h and asm/desc.h if you prefer.

Ole, while digging up what happens with your real mode / pmode switch, I discovered that it turns out you're _not_ initializing the segment descriptor for the data segment. It does not matter too much, since the wakeup code (once in real mode) hooks ds to the same place as cs anyway, and sets up the stack accordingly, but is there a reason for doing so ? I've initialized the descriptor, to make things more clear.

In fact, I hoped that this was a key explaining vgabios crashes: the es segment point into nowhere (the wakeup code does not touch it), but maybe the ROM code uses it (who knows). Unfortunately, movw %ax, %es does not improve things.

I would say, still, that adding movw %ax, %es on top of wakeup_start would make sense, perhaps some machine where s3_{,late_}{bios,mode} almost work would benefit from it. Do you agree ?

Quoted 3 lines

Review

Quoted 1 line
(quoted diff) +1 -0
+	if (((pci_dev->class ^ (PCI_CLASS_DISPLAY_VGA << 8)) & 0xffff00)==0)

The use of xor here is certainly interesting. Is it possible to say

	pci_dev->class & 0xffff00 == PCI_CLASS_DISPLAY_VGA << 8

;-) This one got me laughing as well. I do prefer the (a & b) == c idiom (now used), but I was amused by this xor in pci_match_one_device.

Quoted 4 lines
Quoted 1 line

[ sleep_hacks.h ]

Does it really deserve its own header file? Hmm and it should probably be common between x86-64 and i386, as we might need 64-bit version in future...

Well, the problem is that this stuff has to be included from the .S file as well.

I've moved it into asm/acpi.h instead, which was the place where I intended to put it at first. This implies protecting most of asm/acpi.h with #ifndef __ASSEMBLY__ , but this makes sense for asm/ includes, doesn't it ? Do you prefer this location ?

Attached are three files.

s3_late_bios.patch.gz is the current, working patch for i386.

s3_late_bios_radeon.patch.gz puts an acpi_vgapost call into the radeonfb driver, just to illustrate how it can be inserted into custom pci resume functions (oh, this will change in 2.6.10 with the removal of pci_restore_state's second arg...).

s3_late_bios-x86_64-draft.patch.gz is untested. It lays the ground for doing the same for x86_64 , but currently I don't have access to amd64 boxes where I can play with acpi (you wouldn't play such games on a department level server, would you ?).

I've read on this ml that this stuff crashes S4 resume, understandably. So now, calls to acpi_vgapost are protected by (pci_dev->dev.power_state != 4) checks, as seen elsewhere. Is .power_state==4 effectively used for marking S4 sleep ?

Hoping this version is OK for you,

E.

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

#18 lore raw

Hi!

Quoted 6 lines
Quoted 1 line

Uff, this looks pretty ugly. But I guess it is i386 being ugly...

The present version does the indirection once and for all, it's more readable. I've documented a bit the segment descriptor stuff, so that it's not so mystifying. I can do most of it in C, using asm/processor.h and asm/desc.h if you prefer.

Yes, that would be nice.

Quoted 6 lines
Quoted 3 lines

Review

Quoted 1 line
(quoted diff) +1 -0
+	if (((pci_dev->class ^ (PCI_CLASS_DISPLAY_VGA << 8)) & 0xffff00)==0)

The use of xor here is certainly interesting. Is it possible to say

	pci_dev->class & 0xffff00 == PCI_CLASS_DISPLAY_VGA << 8

;-) This one got me laughing as well. I do prefer the (a & b) == c idiom (now used), but I was amused by this xor in pci_match_one_device.

Good.

Quoted 4 lines

I've moved it into asm/acpi.h instead, which was the place where I intended to put it at first. This implies protecting most of asm/acpi.h with #ifndef __ASSEMBLY__ , but this makes sense for asm/ includes, doesn't it ? Do you prefer this location ?

I think that's better.

Quoted 4 lines

s3_late_bios-x86_64-draft.patch.gz is untested. It lays the ground for doing the same for x86_64 , but currently I don't have access to amd64 boxes where I can play with acpi (you wouldn't play such games on a department level server, would you ?).

Well, it depends if you want to keep your work, I guess :-). Okay, x86-64 can wait.

Thanks,
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:
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

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

#20 lore raw
Quoted 2 lines

Well, it depends if you want to keep your work, I guess :-). Okay, x86-64 can wait.

Or rather not apply this. I have no plans to support switch back to real mode on x86-64. It is just far too hackish and fragile.

Either do it before switching to protected/long mode or later in a emulator.

-Andi

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

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

#22 lore raw

Hi!

Quoted 8 lines
Quoted 2 lines

Well, it depends if you want to keep your work, I guess :-). Okay, x86-64 can wait.

Or rather not apply this. I have no plans to support switch back to real mode on x86-64. It is just far too hackish and fragile.

Either do it before switching to protected/long mode or later in a emulator.

It can not be done before switching to long mode... because video bios needs initialized PCI. As of emulator.... yes that could be way to go.

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

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

#24 lore raw
Quoted 5 lines · Pavel Machek

Hi!

Quoted 3 lines
Quoted 2 lines

Well, it depends if you want to keep your work, I guess :-). Okay, x86-64 can wait.

Quoted 8 lines
Quoted 5 lines

Or rather not apply this. I have no plans to support switch back to real mode on x86-64. It is just far too hackish and fragile.

Either do it before switching to protected/long mode or later in a emulator.

It can not be done before switching to long mode... because video bios needs initialized PCI. As of emulator.... yes that could be way to go.

Initialized in what way? If it's very simple you could do it in assembler or alternatively call the PCI BIOS to do it.

-Andi

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

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

#26 lore raw

Hi!

Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 2 lines

Well, it depends if you want to keep your work, I guess :-). Okay, x86-64 can wait.

Or rather not apply this. I have no plans to support switch back to real mode on x86-64. It is just far too hackish and fragile.

Quoted 8 lines
Quoted 5 lines
Quoted 2 lines

Either do it before switching to protected/long mode or later in a emulator.

It can not be done before switching to long mode... because video bios needs initialized PCI. As of emulator.... yes that could be way to go.

Initialized in what way? If it's very simple you could do it in assembler or alternatively call the PCI BIOS to do it.

I guess agp bridge has to be initialized etc... It does not look like task one would like to write in assembly. Okay, lets do this on i386, first, then see how it can be done in better way on x86-64.

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

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

#28 lore raw
Quoted 14 lines · Pavel Machek

Hi!

Quoted 12 lines
Quoted 11 lines
Quoted 8 lines
Quoted 2 lines

Well, it depends if you want to keep your work, I guess :-). Okay, x86-64 can wait.

Or rather not apply this. I have no plans to support switch back to real mode on x86-64. It is just far too hackish and fragile.

Either do it before switching to protected/long mode or later in a emulator.

It can not be done before switching to long mode... because video bios needs initialized PCI. As of emulator.... yes that could be way to go.

Quoted 6 lines
Quoted 2 lines

Initialized in what way? If it's very simple you could do it in assembler or alternatively call the PCI BIOS to do it.

I guess agp bridge has to be initialized etc... It does not look like task one would like to write in assembly. Okay, lets do this on i386, first, then see how it can be done in better way on x86-64.

That sounds like the wrong way round - i would first create a clean way instead of spending much time in perfecting a hack.

-Andi

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

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

#30 lore raw

Hi!

Quoted 6 lines
Quoted 3 lines

I guess agp bridge has to be initialized etc... It does not look like task one would like to write in assembly. Okay, lets do this on i386, first, then see how it can be done in better way on x86-64.

That sounds like the wrong way round - i would first create a clean way instead of spending much time in perfecting a hack.

Rewriting half of kernel into asm/wakeup.S is not called "clean way"... And look at code, going back to real mode is actually pretty easy and we have to do it in other places, too...
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:
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

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

#32 lore raw
Quoted 11 lines · Pavel Machek

Hi!

Quoted 6 lines
Quoted 3 lines

I guess agp bridge has to be initialized etc... It does not look like task one would like to write in assembly. Okay, lets do this on i386, first, then see how it can be done in better way on x86-64.

That sounds like the wrong way round - i would first create a clean way instead of spending much time in perfecting a hack.

Rewriting half of kernel into asm/wakeup.S is not called "clean way"... And look at code, going back to real mode is actually pretty

Calling the PCI BIOS for initialization is not exactly "rewriting half of kernel into asm/wakeup.S"

-Andi

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

#33 lore raw
In reply to a message not in the archive

Andi> Or rather not apply this. I have no plans to support switch back Andi> to real mode on x86-64. It is just far too hackish and fragile.

I agree that return to real mode is kind of *hackish* - but I do not agree that it has to be *fragile*. I'd like to repeat my general comments on the alternatives, not particularly connected to x86-64:

Andi> Either do it before switching to protected/long mode or later Andi> in a emulator.

Properly supporting the "POST before switching to PM" would require a full real-mode bus/device resume. The ACPI specs doesn't even guarantee a working southbridge at real mode resume.

"Later in an emulator" is arguably safer than real mode. But the emulation needs to be done from kernel at the proper point in the resume sequence. Leaving it to the user-mode suspend/resume script is not an option.

Ole

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

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

#35 lore raw
Quoted 6 lines · On Wed, Nov 03, 2004 at 12:31:46PM +0100…

Andi> Or rather not apply this. I have no plans to support switch back Andi> to real mode on x86-64. It is just far too hackish and fragile.

I agree that return to real mode is kind of *hackish* - but I do not agree that it has to be *fragile*. I'd like to repeat my general comments on the alternatives, not particularly connected to x86-64:

I very much doubt it you can get it reliable because it's such an extremly intrusive operation.

Quoted 7 lines

Andi> Either do it before switching to protected/long mode or later Andi> in a emulator.

Properly supporting the "POST before switching to PM" would require a full real-mode bus/device resume. The ACPI specs doesn't even guarantee a working southbridge at real mode resume.

Not sure what you mean with "working southbridge". If you need PCI why not call the PCI BIOS to initialize it first?

Quoted 4 lines

"Later in an emulator" is arguably safer than real mode. But the emulation needs to be done from kernel at the proper point in the resume sequence. Leaving it to the user-mode suspend/resume script is not an option.

Why not?

-Andi

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

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

#37 lore raw

Andi> On Wed, Nov 03, 2004 at 12:31:46PM +0100, [email protected] wrote:
Andi> Or rather not apply this. I have no plans to support switch back
Andi> to real mode on x86-64. It is just far too hackish and fragile.

Quoted 4 lines
Quoted 4 lines

I agree that return to real mode is kind of *hackish* - but I do not agree that it has to be *fragile*. I'd like to repeat my general comments on the alternatives, not particularly connected to x86-64:

Andi> I very much doubt it you can get it reliable because it's such an Andi> extremly intrusive operation.

Why do you say so? As we're resuming from S3 sleep, we've just come out of real mode anyway, and we're just relying on the same mechanism to work twice. We need of course to be careful setting up the real mode environment and make sure it happens before SMP etc. Apart from that, there is nothing particularly "intrusive" about running known real-mode code.

Andi> Either do it before switching to protected/long mode or later Andi> in a emulator.

Quoted 3 lines
Quoted 3 lines

Properly supporting the "POST before switching to PM" would require a full real-mode bus/device resume. The ACPI specs doesn't even guarantee a working southbridge at real mode resume.

Andi> Not sure what you mean with "working southbridge".

I'm not really sure myself... I'm just trying to understand why the original s3_bios just plainly doesn't work on some machines. The ACPI specs only guarantee memory mapping

Andi> If you need PCI why not call the PCI BIOS to initialize it Andi> first?

I'm sure that could be tried... I'd guess this is the way Windows does it, initializing everything and the kitchen sink before even returning to PM.

Quoted 4 lines
Quoted 4 lines

"Later in an emulator" is arguably safer than real mode. But the emulation needs to be done from kernel at the proper point in the resume sequence. Leaving it to the user-mode suspend/resume script is not an option.

Andi> Why not?

There is just too much stuff even in kernel space that depends on the graphics hardware behaving sanely. IMU, thrashing across a non-initialized adapter can and will hang a system. For everyone's sanity, it is just better to leave resuming hardware with the kernel.

Ole

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

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

#39 lore raw
Quoted 8 lines · On Wed, Nov 03, 2004 at 02:52:04PM +0100…

Andi> On Wed, Nov 03, 2004 at 12:31:46PM +0100, [email protected] wrote:
Andi> Or rather not apply this. I have no plans to support switch back
Andi> to real mode on x86-64. It is just far too hackish and fragile.

Quoted 4 lines
Quoted 4 lines

I agree that return to real mode is kind of *hackish* - but I do not agree that it has to be *fragile*. I'd like to repeat my general comments on the alternatives, not particularly connected to x86-64:

Quoted 6 lines

Andi> I very much doubt it you can get it reliable because it's such an Andi> extremly intrusive operation.

Why do you say so? As we're resuming from S3 sleep, we've just come out of real mode anyway, and we're just relying on the same mechanism to work twice. We need of course to be careful setting up the real

The big difference is that the kernel does all kind of complicated things to shut itself up first. What you're trying is to do the same thing halfway through the initialization sequence when a lot of hardware is already running again. Especially on x86-64 going back out of long mode is a really intrusive operation, killing all interrupt state etc.

Quoted 13 lines

Andi> Either do it before switching to protected/long mode or later Andi> in a emulator.

Quoted 3 lines
Quoted 3 lines

Properly supporting the "POST before switching to PM" would require a full real-mode bus/device resume. The ACPI specs doesn't even guarantee a working southbridge at real mode resume.

Andi> Not sure what you mean with "working southbridge".

I'm not really sure myself... I'm just trying to understand why the original s3_bios just plainly doesn't work on some machines. The ACPI specs only guarantee memory mapping

Quoted 6 lines

Andi> If you need PCI why not call the PCI BIOS to initialize it Andi> first?

I'm sure that could be tried... I'd guess this is the way Windows does it, initializing everything and the kitchen sink before even returning to PM.

You just need to initialize the same things the boot BIOS does before calling the video POST after power up. That would be probably AGP and PCI.

I hope the PCI BIOS has a function for this though. I don't have a spec for it unfortunately.

Quoted 1 line

There is just too much stuff even in kernel space that depends on the

The only code in the kernel that should care about video mode state is the fbcon console driver. Possibly DRI too, but those are firmly under user control and can be handled by the X server.

-Andi

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

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

#41 lore raw

Andi> The big difference is that the kernel does all kind of complicated Andi> things to shut itself up first. What you're trying is to do the Andi> same thing halfway through the initialization sequence when Andi> a lot of hardware is already running again. Especially on x86-64 Andi> going back out of long mode is a really intrusive operation, Andi> killing all interrupt state etc.

There shouldn't be any state to kill at this point. IMO, hardware resume should happen *before* interrupts, bus mastering and SMP, and I think the ACPI spec support that view. The "lot of hardware is already running again" should only include stuff that appears before the graphics in bus-enumeration order. It's a pity though the two-phase resume model was abandoned.

Quoted 3 lines
Quoted 3 lines

I'm sure that could be tried... I'd guess this is the way Windows does it, initializing everything and the kitchen sink before even returning to PM.

Andi> You just need to initialize the same things the boot BIOS does Andi> before calling the video POST after power up. That would be Andi> probably AGP and PCI.

Sorry, my reference to Windows wasn't meant to imply this way is difficult or wrong. Rather, I'm just frustrated by the lack of spec and we don't plainly *know* what the "reference" implementation does.

Andi> I hope the PCI BIOS has a function for this though. I don't have Andi> a spec for it unfortunately.

You might be lucky here, I think PCI BIOS is documented.

Quoted 1 line
Quoted 1 line

There is just too much stuff even in kernel space that depends on the

Andi> The only code in the kernel that should care about video mode Andi> state is the fbcon console driver. Possibly DRI too, but those Andi> are firmly under user control and can be handled by the X server.

What about the random console printing that goes on during suspend/resume?

Ole

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

#42 lore raw
In reply to a message not in the archive
Quoted 1 line
Quoted 1 line

Uff, this looks pretty ugly. But I guess it is i386 being ugly...

E.> The present version does the indirection once and for all, it's E.> more readable. I've documented a bit the segment descriptor stuff, E.> so that it's not so mystifying. I can do most of it in C, using E.> asm/processor.h and asm/desc.h if you prefer.

As it is a one-off, I'd vote for keeping it in assembly. And your documentation has made it a lot clearer what is going on.

E.> Ole, while digging up what happens with your real mode / pmode E.> switch, I discovered that it turns out you're _not_ initializing E.> the segment descriptor for the data segment. It does not matter E.> too much, since the wakeup code (once in real mode) hooks ds to E.> the same place as cs anyway, and sets up the stack accordingly, E.> but is there a reason for doing so ? I've initialized the E.> descriptor, to make things more clear.

I must have thought it was not necessary to touch the data segment, or I might just have missed it. What you have now seems complete and correct.

E.> In fact, I hoped that this was a key explaining vgabios crashes:
E.> the es segment point into nowhere (the wakeup code does not touch E.> it), but maybe the ROM code uses it (who knows). Unfortunately, E.> movw %ax, %es does not improve things.

So it doesn't help on machines that haven't been able to use the real-mode POST?

I guess there could still be things about how the segments are set up that are carried over to real mode. IIRC, the pm segment limit determines the meaning of real mode 32-bit offsets. Someone might want to play with this...

Ole

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

#43 lore raw
In reply to a message not in the archive
Quoted 8 lines

I do hit the video problem though. I've tried the stuff in power/video.txt, but mine doesn't seem to be among the few systems with a solution at the moment. I don't have a Radeon, so I haven't tried the radeonfb-patch that's been floating around
(http://www.loria.fr/~thome/d600/), but the part that mentions "you may insert a similar call from the vesa frame buffer driver to obtain similar results for a wide range of cards" intrigues me. Could this be something to try? Or is this already what acpi_sleep=s3_bios does?

Did you try passing "acpi_sleep=s3_bios acpi_sleep=s3_mode" as the kernel boot parameters? The ability of passing both at the same time isn't mentioned in the video.txt but it did the trick or me. (vaio fx505)

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

#44 lore raw
In reply to a message not in the archive
Quoted 7 lines · Jon Valvatne

Hello list,

I'd very much like to get suspend-to-RAM working on my Vaio X505; any pointers would be very welcome. Trying with the latest RPM-kernel for FC2, I can get it suspended just fine (after removing the ehci_hcd module), but it doesn't come back up.

For the first time, with a vanilla 2.6.9-rc4, S3 works on my laptop. It's a Sony PCG-Z1RMP. If I echo 3 > /proc/acpi/sleep while i'm in console, resume doesn't light on the screen (radeontool has the same problem). I can reboot, send command on my shell, but if I start X, my laptop freeze.
If I'm under X, suspend and resume works but if i go to console text screen is black of bad video resolution.

I've also a problem with kmalloc(GFP_KERNEL) and resume while interrupt is disabled.

PM: Preparing system for suspend
Stopping tasks: ===================|
PM: Entering state.
Back to C!
Debug: sleeping function called from invalid context at mm/slab.c:2052 in_atomic():0, irqs_disabled():1
[__might_sleep+182/224] __might_sleep+0xb6/0xe0 [__kmalloc+138/160] __kmalloc+0x8a/0xa0 [acpi_os_allocate+10/11] acpi_os_allocate+0xa/0xb [acpi_ut_allocate+52/87] acpi_ut_allocate+0x34/0x57 [acpi_ut_initialize_buffer+66/125] acpi_ut_initialize_buffer+0x42/0x7 [acpi_rs_create_byte_stream+35/57] acpi_rs_create_byte_stream+0x23/0x [acpi_rs_set_srs_method_data+27/157] acpi_rs_set_srs_method_data+0x1b [recalc_task_prio+151/400] recalc_task_prio+0x97/0x190 [acpi_pci_link_set+222/341] acpi_pci_link_set+0xde/0x155 [irqrouter_resume+28/48] irqrouter_resume+0x1c/0x30 [sysdev_resume+247/252] sysdev_resume+0xf7/0xfc [device_power_up+5/10] device_power_up+0x5/0xa [suspend_enter+48/80] suspend_enter+0x30/0x50 [enter_state+101/160] enter_state+0x65/0xa0 [acpi_suspend+59/73] acpi_suspend+0x3b/0x49 [copy_from_user+84/144] copy_from_user+0x54/0x90 [acpi_system_write_sleep+93/110] acpi_system_write_sleep+0x5d/0x6e [vfs_write+176/272] vfs_write+0xb0/0x110 [sys_write+71/128] sys_write+0x47/0x80
[syscall_call+7/11] syscall_call+0x7/0xb
sonypi: unknown event port1=0x0e,port2=0x05
PM: Finishing up.

Luc

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