RE: Suspend-to-RAM on Sony Vaios

RE: Suspend-to-RAM on Sony Vaios

[Pallipadi, Venkatesh]

>-----Original Message-----
>From: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org 
>[mailto:acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of 
>ole.rohne-vJEk5272eHo@public.gmane.org
>Sent: Wednesday, November 03, 2004 3:32 AM
>To: Andi Kleen
>Cc: Pavel Machek; Emmanuel Thom??; Jon Valvatne; 
>acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>Subject: Re: [ACPI] Suspend-to-RAM on Sony Vaios
>
>"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.
>

Other options here are:
- to have the usermode emulator and call it from 
Proper point in kernel using call_usermodehelper().
- or have the emulator in the kernel itself.

-Venki


-------------------------------------------------------
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_idU88&alloc_id\x12065&op=click

Re: Suspend-to-RAM on Sony Vaios

[Andi Kleen]

On Wed, Nov 03, 2004 at 06:45:53AM -0800, Pallipadi, Venkatesh wrote:
> Other options here are:
> - to have the usermode emulator and call it from 
> Proper point in kernel using call_usermodehelper().

I don't think proper point is a big issue anyways. The 
only kernel user that really cares about video state is the
console.

But you would need to be careful to not schedule
the X server or a DRI client before it has run.
You would need a kind of "single process" mode.

I suspect doing it in assembly early would be cleaner.

-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

Re: Suspend-to-RAM on Sony Vaios

[ole.rohne-vJEk5272eHo]

Andi> I don't think proper point is a big issue anyways. The only
Andi> kernel user that really cares about video state is the console.

And as most modern graphics adapters are bus master capable, how do
you make sure it is not hanging on the bus request at the moment you
re-enable BM arbitration?

Speaking as someone who's tried extensively to get the "usermode,
anytime"-approach to work, what really turned me off was not being
able to get the console working.

Andi> But you would need to be careful to not schedule
Andi> the X server or a DRI client before it has run.
Andi> You would need a kind of "single process" mode.

Andi> I suspect doing it in assembly early would be cleaner.

:-)

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

Re: Suspend-to-RAM on Sony Vaios

[Andi Kleen]

On Wed, Nov 03, 2004 at 06:13:09PM +0100, ole.rohne-vJEk5272eHo@public.gmane.org wrote:
> Andi> I don't think proper point is a big issue anyways. The only
> Andi> kernel user that really cares about video state is the console.
> 
> And as most modern graphics adapters are bus master capable, how do
> you make sure it is not hanging on the bus request at the moment you
> re-enable BM arbitration?

The machine is comming fresh out of suspend. Nobody should be doing
bus mastering. 
> 
> Speaking as someone who's tried extensively to get the "usermode,
> anytime"-approach to work, what really turned me off was not being
> able to get the console working.

When you want to restore a graphics mode in the X server you don't
have a console anyways, so I don't see the problem here.

earlyprintk to serial or vga if you're in text mode should always work.

-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

Re: Suspend-to-RAM on Sony Vaios

[Matthew Garrett]

On Wed, 2004-11-03 at 18:21 +0100, Andi Kleen wrote:

> earlyprintk to serial or vga if you're in text mode should always work.

On most machines, vga textmode won't work until the card is POSTed
again.

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



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

Re: Suspend-to-RAM on Sony Vaios

[Andi Kleen]

On Wed, Nov 03, 2004 at 06:01:38PM +0000, Matthew Garrett wrote:
> On Wed, 2004-11-03 at 18:21 +0100, Andi Kleen wrote:
> 
> > earlyprintk to serial or vga if you're in text mode should always work.
> 
> On most machines, vga textmode won't work until the card is POSTed
> again.

But serial does.  

-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

Re: Suspend-to-RAM on Sony Vaios

[Matthew Garrett]

On Thu, 2004-11-04 at 05:15 +0100, Andi Kleen wrote:
> On Wed, Nov 03, 2004 at 06:01:38PM +0000, Matthew Garrett wrote:
> > On Wed, 2004-11-03 at 18:21 +0100, Andi Kleen wrote:
> > 
> > > earlyprintk to serial or vga if you're in text mode should always work.
> > 
> > On most machines, vga textmode won't work until the card is POSTed
> > again.
> 
> But serial does.  

Few modern laptops have serial ports. 

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



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

Re: Suspend-to-RAM on Sony Vaios

[Andi Kleen]

On Thu, Nov 04, 2004 at 10:39:14AM +0000, Matthew Garrett wrote:
> On Thu, 2004-11-04 at 05:15 +0100, Andi Kleen wrote:
> > On Wed, Nov 03, 2004 at 06:01:38PM +0000, Matthew Garrett wrote:
> > > On Wed, 2004-11-03 at 18:21 +0100, Andi Kleen wrote:
> > > 
> > > > earlyprintk to serial or vga if you're in text mode should always work.
> > > 
> > > On most machines, vga textmode won't work until the card is POSTed
> > > again.
> > 
> > But serial does.  
> 
> Few modern laptops have serial ports. 

Yes, that's an issue. USB EHCI has a special polled debug port mode
for this, but so far nobody has written a nice driver for it.

But anyways, as said VGA doesn't help you to debug VGA POST.
You always need some other debug channel.

I heard other people use LED on parport hacks, which probably works.

Anyways, this thread doesn't seem to serve any useful purpose
anymore so I won't post to it anymore.

-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

Re: Suspend-to-RAM on Sony Vaios

[ole.rohne-vJEk5272eHo]

Andi> I heard other people use LED on parport hacks, which probably works.

Modern laptops don't have parports either...

Anyway, my real objections to purely userspace POSTing are:

(1) it is hard to get it to work reliably (some method work with X11
    but not with text mode console, other methods work without DRM etc)
(2) the previous point goes to show that hardware sourcery belongs in
    kernel space (or before), as this is the only way to ensure proper
    ordering, bus mastering disable etc

Andi> Anyways, this thread doesn't seem to serve any useful purpose
Andi> anymore so I won't post to it anymore.

???

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

Re: Re: Suspend-to-RAM on Sony Vaios

[Oisín Mac Fhearaí]

On Thursday 04 November 2004 13:49, ole.rohne-vJEk5272eHo@public.gmane.org wrote:
> Andi> I heard other people use LED on parport hacks, which probably works.
>
> Modern laptops don't have parports either...

What about the PS/2 port? I don't think I've seen any machines without one of 
these.

Oisín


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

Re: Re: Suspend-to-RAM on Sony Vaios

[Matthew Garrett]

On Thu, 2004-11-04 at 22:16 +0000, Oisín Mac Fhearaí wrote:
> On Thursday 04 November 2004 13:49, ole.rohne-vJEk5272eHo@public.gmane.org wrote:
> > Andi> I heard other people use LED on parport hacks, which probably works.
> >
> > Modern laptops don't have parports either...
> 
> What about the PS/2 port? I don't think I've seen any machines without one of 
> these.

My current laptop has 2 USB sockets, VGA, modem, ethernet and sound.

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



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

Re: Suspend-to-RAM on Sony Vaios

[ole.rohne-vJEk5272eHo]

>> earlyprintk to serial or vga if you're in text mode should always work.

Matthew> On most machines, vga textmode won't work until the card is
Matthew> POSTed again.

And if the POSTing is left to X, it never works again. This is because
the X console switching code restores what it thinks is the proper PCI
config for text mode.

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

Re: Suspend-to-RAM on Sony Vaios

[ole.rohne-vJEk5272eHo]

Andi> On Wed, Nov 03, 2004 at 06:13:09PM +0100, ole.rohne-vJEk5272eHo@public.gmane.org wrote:
Andi> I don't think proper point is a big issue anyways. The only
Andi> kernel user that really cares about video state is the console.

>> And as most modern graphics adapters are bus master capable, how do
>> you make sure it is not hanging on the bus request at the moment you
>> re-enable BM arbitration?

Andi> The machine is comming fresh out of suspend. Nobody should be doing
Andi> bus mastering. 

There is absolutely no guarantee that the machine comes "fresh out of
suspend"! Here is my recollection of what the ACPI specs says: The
machine resumes with interrupts and BM disabled, it is the
responsibility of the OS to make sure all devices are "quiescent"
before reenabling interrupts and BM.

Once again I'd lament the fact that most of the device suspend/resume
code is not done from specs, but rather empirically based on overly
forgiving firmware implementations. Specifically, the code seems to
assume the hardware as it comes out of a boot, but there is no such
guarantee.

>> Speaking as someone who's tried extensively to get the "usermode,
>> anytime"-approach to work, what really turned me off was not being
>> able to get the console working.

Andi> When you want to restore a graphics mode in the X server you
Andi> don't have a console anyways, so I don't see the problem here.

If you decide you don't care about the console there is no
problem. But please don't advertise that as fully working S3
suspend/resume.

Andi> early printk to serial or vga if you're in text mode should
Andi> always work.

You mean "should always work" as in "not hanging the machine"?
Maybe...  It certainly doesn't "work" in the sense of displaying text
on the screen.

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

Re: Suspend-to-RAM on Sony Vaios

[Andi Kleen]

On Thu, Nov 04, 2004 at 09:24:29AM +0100, ole.rohne-vJEk5272eHo@public.gmane.org wrote:
> There is absolutely no guarantee that the machine comes "fresh out of
> suspend"! Here is my recollection of what the ACPI specs says: The

I don't see who should cause busmaster in flight operations
before suspend wakeup.

> code is not done from specs, but rather empirically based on overly
> forgiving firmware implementations. Specifically, the code seems to
> assume the hardware as it comes out of a boot, but there is no such
> guarantee.

Yes, that is the big bug of the ACPI specification. They should
have required the BIOS to post all hardware at least to the 
same state as it happens after initial power on. But Windows
chose to do it differently and now it is too late.

I think the best we can do is to use the BIOS infrastructure to
do this BIOS POST manually while still in real mode.

> 
> Andi> early printk to serial or vga if you're in text mode should
> Andi> always work.
> 
> You mean "should always work" as in "not hanging the machine"?
> Maybe...  It certainly doesn't "work" in the sense of displaying text
> on the screen.

Of course you cannot display anything on the screen when the video
card is not posted yet. I feel you're intentionally trying to misundertand
me.  If you want to debug the POST process you need some other debug
channel, like serial output or the usb debug console.

-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

Re: Suspend-to-RAM on Sony Vaios

[Pavel Machek]

Hi!

> > Andi> early printk to serial or vga if you're in text mode should
> > Andi> always work.
> > 
> > You mean "should always work" as in "not hanging the machine"?
> > Maybe...  It certainly doesn't "work" in the sense of displaying text
> > on the screen.
> 
> Of course you cannot display anything on the screen when the video
> card is not posted yet. I feel you're intentionally trying to misundertand
> me.  If you want to debug the POST process you need some other debug
> channel, like serial output or the usb debug console.

This is quite hard to do. Bios does not init video card, and it does
initialize other hardware, either. Serials are not available on many
machines, and initializing usb from real mode would be way too
hard....
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!


-------------------------------------------------------
This SF.Net email is sponsored by:
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

Re: Suspend-to-RAM on Sony Vaios

[ole.rohne-vJEk5272eHo]

>> There is absolutely no guarantee that the machine comes "fresh out of
>> suspend"! Here is my recollection of what the ACPI specs says: The

Andi> I don't see who should cause busmaster in flight operations
Andi> before suspend wakeup.

I'm supposing non-initialized hardware could physically hang on the
bus master request line.

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

RE: Suspend-to-RAM on Sony Vaios

[Li, Shaohua]

>
>On Tue, Oct 19, 2004 at 07:45:46PM +0800, Li, Shaohua wrote:
> >
>> >I apply your changes, but it doesn't change. You say, that we need
to
>> >enable interrupt, but
>> >>
>> >> +       local_save_flags(flag);
>> >> +       local_irq_disable();
>> >
>> Oh, I'm sorry. It's a typo. should be enable irq.
>
>With local_irq_enable, no more warning. Thanks very much.
>
>Is it normal just after a resume to have ?
>MCE: The hardware reports a non fatal, correctable incident occurred on
CPU
>0.
>Bank 1: f200000000000181
Thanks you verified the workaround works, but it's not a final solution.
For the MCE: it's not normal, but isn't harmful some times.

Thanks,
Shaohua


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

RE: Suspend-to-RAM on Sony Vaios

[Pallipadi, Venkatesh]

 

>-----Original Message-----
>From: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org 
>[mailto:acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of 
>Luc Saillard
>Sent: Tuesday, October 19, 2004 1:11 AM
>To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>Subject: Re: [ACPI] Suspend-to-RAM on Sony Vaios
>
>On Mon, Oct 18, 2004 at 02:08:16AM +0200, Jon Valvatne wrote:
>> 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). 

Which graphics controller do you have?
Are you using framebuffer with text console or simple VGA?
Can you try acpi_sleep boot options (refer
Documentation/power/video.txt) for text console suspend-resume.

Thanks,
-Venki


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

Re: Suspend-to-RAM on Sony Vaios

[Luc Saillard]

On Tue, Oct 19, 2004 at 09:32:56AM -0700, Pallipadi, Venkatesh wrote:
 
> Which graphics controller do you have?
Radeon Mobility M6
> Are you using framebuffer with text console or simple VGA?
no framebuffer, pure text console, and radeon graphics driver with xfree86.
> Can you try acpi_sleep boot options (refer
> Documentation/power/video.txt) for text console suspend-resume.
Ok i'll try to call vga bios...

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

Re: Suspend-to-RAM on Sony Vaios

[Proinnsias Breathnach]

On Tue, Oct 19, 2004 at 06:47:02PM +0200, Luc Saillard wrote:
> On Tue, Oct 19, 2004 at 09:32:56AM -0700, Pallipadi, Venkatesh wrote:
>  
> > Which graphics controller do you have?
> Radeon Mobility M6
> > Are you using framebuffer with text console or simple VGA?
> no framebuffer, pure text console, and radeon graphics driver with xfree86.
> > Can you try acpi_sleep boot options (refer
> > Documentation/power/video.txt) for text console suspend-resume.
> Ok i'll try to call vga bios...
> 
Not sure this'll be much help - but something I was referred to on a
site about getting S3 working on a Dell D600 might be useful:

http://www.loria.fr/~thome/d600/

There's a patch there for the radeonFB that may solve your problem

-------------8<--------------
"The radeonfb patch does a real-mode call to the video bios, so that the
radeon performs the necesssary resume code when returning from sleep.
This is done from within the kernel, but has to be done at the proper
point, namely after PCI is reinitialized (which happens in protected
mode, so another pmode/rmode switch happens). There is nothing
radeon-specific in this code, but it's triggered from the radeon frame
buffer driver. You may insert a similar call from the vesa frame buffer
driver to obtain similar results for a wide range of cards (unless I'm
mistaken, this has pretty good chances of working). The radeon frame
buffer driver must be built into the kernel, and not built as a module,
since it must take over the console as early as possible."
-------------8<--------------

Might be useful to some ...

P


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

RE: Suspend-to-RAM on Sony Vaios

[Li, Shaohua]

>
>On Tue, Oct 19, 2004 at 05:25:30PM +0800, Li, Shaohua wrote:
>> Yes, this is a known issue - link device resume must be with irq
>> enabled. Could you please try if below workaround makes any
difference
>> in your system.
>
>I apply your changes, but it doesn't change. You say, that we need to
>enable
>interrupt, but
>>
>> +       local_save_flags(flag);
>> +       local_irq_disable();
>
Oh, I'm sorry. It's a typo. should be enable irq.

Thanks,
Shaohua


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

Re: Suspend-to-RAM on Sony Vaios

[Luc Saillard]

On Tue, Oct 19, 2004 at 07:45:46PM +0800, Li, Shaohua wrote:
 >
> >I apply your changes, but it doesn't change. You say, that we need to
> >enable interrupt, but
> >>
> >> +       local_save_flags(flag);
> >> +       local_irq_disable();
> >
> Oh, I'm sorry. It's a typo. should be enable irq.
 
With local_irq_enable, no more warning. Thanks very much.

Is it normal just after a resume to have ?
MCE: The hardware reports a non fatal, correctable incident occurred on CPU 0.
Bank 1: f200000000000181

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

Re: Suspend-to-RAM on Sony Vaios

[Matthew Garrett]

On Tue, 2004-10-19 at 14:39 +0200, Luc Saillard wrote:

> Is it normal just after a resume to have ?
> MCE: The hardware reports a non fatal, correctable incident occurred on CPU 0.
> Bank 1: f200000000000181

I get that behaviour. It seems harmless.

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



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

RE: Suspend-to-RAM on Sony Vaios

[Li, Shaohua]

Yes, this is a known issue - link device resume must be with irq
enabled. Could you please try if below workaround makes any difference
in your system.

Thanks,
Shaohua



===== drivers/acpi/pci_link.c 1.32 vs edited =====
--- 1.32/drivers/acpi/pci_link.c        2004-08-19 07:26:48 +08:00
+++ edited/drivers/acpi/pci_link.c      2004-10-19 17:15:09 +08:00
@@ -714,7 +714,10 @@ irqrouter_resume(
 {
        struct list_head        *node = NULL;
        struct acpi_pci_link    *link = NULL;
+       unsigned long flag;

+       local_save_flags(flag);
+       local_irq_disable();
        ACPI_FUNCTION_TRACE("irqrouter_resume");

        list_for_each(node, &acpi_link.entries) {
@@ -727,6 +730,7 @@ irqrouter_resume(

                acpi_pci_link_resume(link);
        }
+       local_irq_restore(flag);
        return_VALUE(0);
 }

@@ -851,7 +855,7 @@ static int __init irqrouter_init_sysfs(v
        return_VALUE(error);
 }

-device_initcall(irqrouter_init_sysfs);
+fs_initcall(irqrouter_init_sysfs);


 static int __init acpi_pci_link_init (void)

>-----Original Message-----
>From: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org [mailto:acpi-devel-
>admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of Luc Saillard
>Sent: Tuesday, October 19, 2004 4:11 PM
>To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>Subject: Re: [ACPI] Suspend-to-RAM on Sony Vaios
>
>On Mon, Oct 18, 2004 at 02:08:16AM +0200, Jon Valvatne wrote:
>> 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
>_______________________________________________
>Acpi-devel mailing list
>Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>https://lists.sourceforge.net/lists/listinfo/acpi-devel


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

Re: Suspend-to-RAM on Sony Vaios

[Luc Saillard]

On Tue, Oct 19, 2004 at 05:25:30PM +0800, Li, Shaohua wrote:
> Yes, this is a known issue - link device resume must be with irq
> enabled. Could you please try if below workaround makes any difference
> in your system.

I apply your changes, but it doesn't change. You say, that we need to enable
interrupt, but
> 
> +       local_save_flags(flag);
> +       local_irq_disable();

you disable irq on this cpu ?

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

Suspend-to-RAM on Sony Vaios

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

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

Re: Suspend-to-RAM on Sony Vaios

[Ivor Hewitt]

On Monday 18 Oct 2004 00:08, Jon Valvatne wrote:
> 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.


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

Re: Suspend-to-RAM on Sony Vaios

[Jon Valvatne]

On Mon, 18 Oct 2004 04:15:59 +0000
Ivor Hewitt <ivor-rtBon1mkn18@public.gmane.org> wrote:

> On Monday 18 Oct 2004 00:08, Jon Valvatne wrote:
> > 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.

> 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

Re: Suspend-to-RAM on Sony Vaios

[Pavel Machek]

Hi!

Please wrap your messages at column 72

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


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

Re: Suspend-to-RAM on Sony Vaios

[Jon Valvatne]

Hey,

On Mon, 18 Oct 2004 13:26:33 +0200
Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org> wrote:

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

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

Re: Suspend-to-RAM on Sony Vaios

[Pavel Machek]

Hi!

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

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


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

Re: Suspend-to-RAM on Sony Vaios

[Emmanuel Thomé]

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


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.

On Thu, Oct 21, 2004 at 12:53:34AM +0200, Pavel Machek wrote:
> Hi!
> 
> > > 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.
> 
> > 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

[-- Attachment #2: s3_late_bios.patch.gz --]
[-- Type: application/x-gzip, Size: 3259 bytes --]

[-- Attachment #3: s3_late_bios_radeon.patch.gz --]
[-- Type: application/x-gzip, Size: 308 bytes --]

Re: Suspend-to-RAM on Sony Vaios

[ole.rohne-vJEk5272eHo]

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

Re: Suspend-to-RAM on Sony Vaios

[Pavel Machek]

Hi!

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

> +	# 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...

> --- linux.orig/drivers/pci/pci-driver.c	2004-10-26 10:19:42.000000000 +0200
> +++ linux/drivers/pci/pci-driver.c	2004-11-01 01:33:04.000000000 +0100
> @@ -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

?

> +	{
> +		/* 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.

> --- linux.orig/include/asm-i386/acpi.h	2004-10-26 10:19:50.000000000 +0200
> +++ linux/include/asm-i386/acpi.h	2004-11-01 02:15:12.000000000 +0100
> @@ -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.

> --- linux.orig/arch/i386/kernel/acpi/sleep_hacks.h	1970-01-01 01:00:00.000000000 +0100
> +++ linux/arch/i386/kernel/acpi/sleep_hacks.h	2004-11-01 02:53:47.000000000 +0100
> @@ -0,0 +1,16 @@
> +#ifndef ACPI_SLEEP_HACKS_H_
> +#define ACPI_SLEEP_HACKS_H_
> +
> +#ifdef	CONFIG_ACPI_SLEEP
> +
> +#define	ACPI_SLEEP_S3_BIOS	1
> +#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

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

Re: Suspend-to-RAM on Sony Vaios

[Emmanuel Thomé]

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


On Mon, Nov 01, 2004 at 04:41:28PM +0100, Pavel Machek wrote:
> Patch looks good to me...

Great. Here's an updated version.

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

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

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

[-- Attachment #2: s3_late_bios.patch.gz --]
[-- Type: application/x-gzip, Size: 3633 bytes --]

[-- Attachment #3: s3_late_bios_radeon.patch.gz --]
[-- Type: application/x-gzip, Size: 342 bytes --]

[-- Attachment #4: s3_late_bios-x86_64-draft.patch.gz --]
[-- Type: application/x-gzip, Size: 987 bytes --]

Re: Suspend-to-RAM on Sony Vaios

[Pavel Machek]

Hi!

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

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

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

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

Re: Suspend-to-RAM on Sony Vaios

[Andi Kleen]

> 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

Re: Suspend-to-RAM on Sony Vaios

[Pavel Machek]

Hi!

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

Re: Suspend-to-RAM on Sony Vaios

[Andi Kleen]

On Wed, Nov 03, 2004 at 12:13:06PM +0100, Pavel Machek wrote:
> Hi!
> 
> > > 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.

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

Re: Suspend-to-RAM on Sony Vaios

[Pavel Machek]

Hi!

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

Re: Suspend-to-RAM on Sony Vaios

[Andi Kleen]

On Wed, Nov 03, 2004 at 01:38:30PM +0100, Pavel Machek wrote:
> Hi!
> 
> > > > > 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.
> > 
> > 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

Re: Suspend-to-RAM on Sony Vaios

[Pavel Machek]

Hi!

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

Re: Suspend-to-RAM on Sony Vaios

[Andi Kleen]

On Wed, Nov 03, 2004 at 01:50:47PM +0100, Pavel Machek wrote:
> Hi!
> 
> > > 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

Re: Suspend-to-RAM on Sony Vaios

[ole.rohne-vJEk5272eHo]

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

Re: Suspend-to-RAM on Sony Vaios

[Andi Kleen]

On Wed, Nov 03, 2004 at 12:31:46PM +0100, ole.rohne-vJEk5272eHo@public.gmane.org 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.
> 
> 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. 

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

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

Re: Suspend-to-RAM on Sony Vaios

[ole.rohne-vJEk5272eHo]

Andi> On Wed, Nov 03, 2004 at 12:31:46PM +0100, ole.rohne-vJEk5272eHo@public.gmane.org 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.
>> 
>> 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.

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

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

Re: Suspend-to-RAM on Sony Vaios

[Andi Kleen]

On Wed, Nov 03, 2004 at 02:52:04PM +0100, ole.rohne-vJEk5272eHo@public.gmane.org wrote:
> Andi> On Wed, Nov 03, 2004 at 12:31:46PM +0100, ole.rohne-vJEk5272eHo@public.gmane.org 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.
> >> 
> >> 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

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.

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

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.

> 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

Re: Suspend-to-RAM on Sony Vaios

[ole.rohne-vJEk5272eHo]

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.

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

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

Re: Suspend-to-RAM on Sony Vaios

[ole.rohne-vJEk5272eHo]

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

Re: Suspend-to-RAM on Sony Vaios

[Florian Hühn]

> 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

Re: Suspend-to-RAM on Sony Vaios

[Luc Saillard]

On Mon, Oct 18, 2004 at 02:08:16AM +0200, Jon Valvatne wrote:
> 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