Still problems with ACPI sleep state

Still problems with ACPI sleep state

[Lars Amsel]

Hi,

I wrote some questions some week ago and since then I tried several things. I 
have a Fujitsu-Siemens Amilo L6820 with Fedora Core 2.

First I tried to repair my DSDT but I had no success with that.

Then I updated to kernel 2.6.7-1.441. Since that the ac_adapter reports its 
state correct und S3 seems to work better but not right. I start the machine 
into runlevel 3 (no X11) an log in as root. Then I do a 

[root-uXme+rPq5IdZ5tFPsFZChg@public.gmane.org lars]# echo 3 > /proc/acpi/sleep

and the notebook goes into sleep mode (the red 'sleep-LED' is blinking). After 
that I can push the power button and the notebook comes back but the screen 
stays blank. I can log in via ssh from the outside.

Any hints what I can do to get a working display after restart (relevant parts 
of /var/log/messages and dmesg appended)? 

cheers

Lars

/var/log/message:
Jun 25 15:32:52 desperados kernel: Stopping tasks: 
===============================|
Jun 25 15:32:52 desperados kernel: eth0: remaining active for wake-on-lan
Jun 25 15:32:52 desperados kernel: zapping low mappings.
Jun 25 15:32:52 desperados kernel: ACPI: PCI interrupt 0000:00:1f.1[A] -> GSI 
9 (level, low) -> IRQ 9
Jun 25 15:32:52 desperados kernel: ACPI: PCI interrupt 0000:00:1f.5[B] -> GSI 
3 (level, low) -> IRQ 3
Jun 25 15:32:52 desperados kernel: ACPI: PCI interrupt 0000:01:0a.0[A] -> GSI 
9 (level, low) -> IRQ 9
Jun 25 15:32:52 desperados kernel: ACPI: PCI interrupt 0000:01:0c.0[A] -> GSI 
3 (level, low) -> IRQ 3
Jun 25 15:32:52 desperados kernel: eth0: Setting full-duplex based on 
negotiated link capability.
Jun 25 15:32:52 desperados kernel: Restarting tasks... done

dmesg | grep ACPI:
 BIOS-e820: 000000000f7d0000 - 000000000f7df000 (ACPI data)
 BIOS-e820: 000000000f7df000 - 000000000f800000 (ACPI NVS)
ACPI: RSDP (v000 ACPIAM                                    ) @ 0x000f5540
ACPI: RSDT (v001 A M I  OEMRSDT  0x10000309 MSFT 0x00000097) @ 0x0f7d0000
ACPI: FADT (v002 A M I  OEMFACP  0x10000309 MSFT 0x00000097) @ 0x0f7d0200
ACPI: MADT (v001 A M I  OEMAPIC  0x10000309 MSFT 0x00000097) @ 0x0f7d0390
ACPI: OEMB (v001 A M I  AMI_OEM  0x10000309 MSFT 0x00000097) @ 0x0f7df040
ACPI: DSDT (v001 UW____ 755II5__ 0x00000016 INTL 0x02002026) @ 0x00000000
ACPI: PM-Timer IO Port: 0x408
ACPI: Subsystem revision 20040326
ACPI: IRQ9 SCI: Level Trigger.
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (00:00)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P2._PRT]
ACPI: Power Resource [URP1] (off)
ACPI: Power Resource [URP2] (off)
ACPI: Power Resource [FDDP] (off)
ACPI: Power Resource [LPTP] (off)
ACPI: Embedded Controller [EC0] (gpe 28)
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs *3 4 5 6 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 *5 6 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, 
disabled.
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, 
disabled.
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, 
disabled.
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 *10 11 12 14 15)
PCI: Using ACPI for IRQ routing
ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11
ACPI: PCI interrupt 0000:00:02.0[A] -> GSI 11 (level, low) -> IRQ 11
ACPI: PCI interrupt 0000:00:1d.0[A] -> GSI 11 (level, low) -> IRQ 11
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 5
ACPI: PCI interrupt 0000:00:1d.1[B] -> GSI 5 (level, low) -> IRQ 5
ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 9
ACPI: PCI interrupt 0000:00:1d.2[C] -> GSI 9 (level, low) -> IRQ 9
ACPI: PCI Interrupt Link [LNKH] enabled at IRQ 10
ACPI: PCI interrupt 0000:00:1d.7[D] -> GSI 10 (level, low) -> IRQ 10
ACPI: PCI interrupt 0000:00:1f.1[A] -> GSI 9 (level, low) -> IRQ 9
ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 3
ACPI: PCI interrupt 0000:00:1f.3[B] -> GSI 3 (level, low) -> IRQ 3
ACPI: PCI interrupt 0000:00:1f.5[B] -> GSI 3 (level, low) -> IRQ 3
ACPI: PCI interrupt 0000:00:1f.6[B] -> GSI 3 (level, low) -> IRQ 3
ACPI: PCI interrupt 0000:01:03.0[A] -> GSI 3 (level, low) -> IRQ 3
ACPI: PCI interrupt 0000:01:0a.0[A] -> GSI 9 (level, low) -> IRQ 9
ACPI: PCI interrupt 0000:01:0c.0[A] -> GSI 3 (level, low) -> IRQ 3
ACPI: Processor [CPU1] (supports C1, 8 throttling states)
ACPI: Thermal Zone [THRM] (75 C)
ACPI: PCI interrupt 0000:00:1f.6[B] -> GSI 3 (level, low) -> IRQ 3
ACPI: PCI interrupt 0000:00:1f.1[A] -> GSI 9 (level, low) -> IRQ 9
ACPI: (supports S0 S3 S4 S5)
ACPI: AC Adapter [AC0] (on-line)
ACPI: Battery Slot [BAT0] (battery present)
ACPI: Power Button (FF) [PWRF]
ACPI: Lid Switch [LID]
ACPI: Sleep Button (CM) [SLPB]
ACPI: PCI interrupt 0000:01:0a.0[A] -> GSI 9 (level, low) -> IRQ 9
ACPI: PCI interrupt 0000:01:0c.0[A] -> GSI 3 (level, low) -> IRQ 3
ACPI: PCI interrupt 0000:01:0c.0[A] -> GSI 3 (level, low) -> IRQ 3
ACPI: PCI interrupt 0000:01:03.0[A] -> GSI 3 (level, low) -> IRQ 3
ACPI: PCI interrupt 0000:00:1d.0[A] -> GSI 11 (level, low) -> IRQ 11
ACPI: PCI interrupt 0000:00:1d.1[B] -> GSI 5 (level, low) -> IRQ 5
ACPI: PCI interrupt 0000:00:1d.2[C] -> GSI 9 (level, low) -> IRQ 9
ACPI: PCI interrupt 0000:00:1f.5[B] -> GSI 3 (level, low) -> IRQ 3



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: Still problems with ACPI sleep state

[Herman Sheremetyev]

Hi Lars,

Try booting with acpi_sleep=s3_bios, I had the same problem on my Asus
M6N and that made the LCD come back on after an S3 resume.

-Herman

On Fri, 2004-06-25 at 09:47, Lars Amsel wrote:
> Hi,
> 
> I wrote some questions some week ago and since then I tried several things. I 
> have a Fujitsu-Siemens Amilo L6820 with Fedora Core 2.
> 
> First I tried to repair my DSDT but I had no success with that.
> 
> Then I updated to kernel 2.6.7-1.441. Since that the ac_adapter reports its 
> state correct und S3 seems to work better but not right. I start the machine 
> into runlevel 3 (no X11) an log in as root. Then I do a 
> 
> [root-uXme+rPq5IdZ5tFPsFZChg@public.gmane.org lars]# echo 3 > /proc/acpi/sleep
> 
> and the notebook goes into sleep mode (the red 'sleep-LED' is blinking). After 
> that I can push the power button and the notebook comes back but the screen 
> stays blank. I can log in via ssh from the outside.
> 
> Any hints what I can do to get a working display after restart (relevant parts 
> of /var/log/messages and dmesg appended)? 
> 
> cheers
> 
> Lars
> 
> /var/log/message:
> Jun 25 15:32:52 desperados kernel: Stopping tasks: 
> ===============================|
> Jun 25 15:32:52 desperados kernel: eth0: remaining active for wake-on-lan
> Jun 25 15:32:52 desperados kernel: zapping low mappings.
> Jun 25 15:32:52 desperados kernel: ACPI: PCI interrupt 0000:00:1f.1[A] -> GSI 
> 9 (level, low) -> IRQ 9
> Jun 25 15:32:52 desperados kernel: ACPI: PCI interrupt 0000:00:1f.5[B] -> GSI 
> 3 (level, low) -> IRQ 3
> Jun 25 15:32:52 desperados kernel: ACPI: PCI interrupt 0000:01:0a.0[A] -> GSI 
> 9 (level, low) -> IRQ 9
> Jun 25 15:32:52 desperados kernel: ACPI: PCI interrupt 0000:01:0c.0[A] -> GSI 
> 3 (level, low) -> IRQ 3
> Jun 25 15:32:52 desperados kernel: eth0: Setting full-duplex based on 
> negotiated link capability.
> Jun 25 15:32:52 desperados kernel: Restarting tasks... done
> 
> dmesg | grep ACPI:
>  BIOS-e820: 000000000f7d0000 - 000000000f7df000 (ACPI data)
>  BIOS-e820: 000000000f7df000 - 000000000f800000 (ACPI NVS)
> ACPI: RSDP (v000 ACPIAM                                    ) @ 0x000f5540
> ACPI: RSDT (v001 A M I  OEMRSDT  0x10000309 MSFT 0x00000097) @ 0x0f7d0000
> ACPI: FADT (v002 A M I  OEMFACP  0x10000309 MSFT 0x00000097) @ 0x0f7d0200
> ACPI: MADT (v001 A M I  OEMAPIC  0x10000309 MSFT 0x00000097) @ 0x0f7d0390
> ACPI: OEMB (v001 A M I  AMI_OEM  0x10000309 MSFT 0x00000097) @ 0x0f7df040
> ACPI: DSDT (v001 UW____ 755II5__ 0x00000016 INTL 0x02002026) @ 0x00000000
> ACPI: PM-Timer IO Port: 0x408
> ACPI: Subsystem revision 20040326
> ACPI: IRQ9 SCI: Level Trigger.
> ACPI: Interpreter enabled
> ACPI: Using PIC for interrupt routing
> ACPI: PCI Root Bridge [PCI0] (00:00)
> ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
> ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P2._PRT]
> ACPI: Power Resource [URP1] (off)
> ACPI: Power Resource [URP2] (off)
> ACPI: Power Resource [FDDP] (off)
> ACPI: Power Resource [LPTP] (off)
> ACPI: Embedded Controller [EC0] (gpe 28)
> ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
> ACPI: PCI Interrupt Link [LNKB] (IRQs *3 4 5 6 7 9 10 11 12 14 15)
> ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
> ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 *5 6 7 9 10 11 12 14 15)
> ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, 
> disabled.
> ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, 
> disabled.
> ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, 
> disabled.
> ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 *10 11 12 14 15)
> PCI: Using ACPI for IRQ routing
> ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11
> ACPI: PCI interrupt 0000:00:02.0[A] -> GSI 11 (level, low) -> IRQ 11
> ACPI: PCI interrupt 0000:00:1d.0[A] -> GSI 11 (level, low) -> IRQ 11
> ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 5
> ACPI: PCI interrupt 0000:00:1d.1[B] -> GSI 5 (level, low) -> IRQ 5
> ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 9
> ACPI: PCI interrupt 0000:00:1d.2[C] -> GSI 9 (level, low) -> IRQ 9
> ACPI: PCI Interrupt Link [LNKH] enabled at IRQ 10
> ACPI: PCI interrupt 0000:00:1d.7[D] -> GSI 10 (level, low) -> IRQ 10
> ACPI: PCI interrupt 0000:00:1f.1[A] -> GSI 9 (level, low) -> IRQ 9
> ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 3
> ACPI: PCI interrupt 0000:00:1f.3[B] -> GSI 3 (level, low) -> IRQ 3
> ACPI: PCI interrupt 0000:00:1f.5[B] -> GSI 3 (level, low) -> IRQ 3
> ACPI: PCI interrupt 0000:00:1f.6[B] -> GSI 3 (level, low) -> IRQ 3
> ACPI: PCI interrupt 0000:01:03.0[A] -> GSI 3 (level, low) -> IRQ 3
> ACPI: PCI interrupt 0000:01:0a.0[A] -> GSI 9 (level, low) -> IRQ 9
> ACPI: PCI interrupt 0000:01:0c.0[A] -> GSI 3 (level, low) -> IRQ 3
> ACPI: Processor [CPU1] (supports C1, 8 throttling states)
> ACPI: Thermal Zone [THRM] (75 C)
> ACPI: PCI interrupt 0000:00:1f.6[B] -> GSI 3 (level, low) -> IRQ 3
> ACPI: PCI interrupt 0000:00:1f.1[A] -> GSI 9 (level, low) -> IRQ 9
> ACPI: (supports S0 S3 S4 S5)
> ACPI: AC Adapter [AC0] (on-line)
> ACPI: Battery Slot [BAT0] (battery present)
> ACPI: Power Button (FF) [PWRF]
> ACPI: Lid Switch [LID]
> ACPI: Sleep Button (CM) [SLPB]
> ACPI: PCI interrupt 0000:01:0a.0[A] -> GSI 9 (level, low) -> IRQ 9
> ACPI: PCI interrupt 0000:01:0c.0[A] -> GSI 3 (level, low) -> IRQ 3
> ACPI: PCI interrupt 0000:01:0c.0[A] -> GSI 3 (level, low) -> IRQ 3
> ACPI: PCI interrupt 0000:01:03.0[A] -> GSI 3 (level, low) -> IRQ 3
> ACPI: PCI interrupt 0000:00:1d.0[A] -> GSI 11 (level, low) -> IRQ 11
> ACPI: PCI interrupt 0000:00:1d.1[B] -> GSI 5 (level, low) -> IRQ 5
> ACPI: PCI interrupt 0000:00:1d.2[C] -> GSI 9 (level, low) -> IRQ 9
> ACPI: PCI interrupt 0000:00:1f.5[B] -> GSI 3 (level, low) -> IRQ 3
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
> digital self defense, top technical experts, no vendor pitches, 
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Acpi-devel mailing list
> Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/acpi-devel



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: Still problems with ACPI sleep state

[Stefan Seyfried]

On Fri, Jun 25, 2004 at 03:47:20PM +0200, Lars Amsel wrote:

> Any hints what I can do to get a working display after restart (relevant parts 
> of /var/log/messages and dmesg appended)? 

Read /usr/src/linux/Documentation/power/video.txt
-- 
Stefan Seyfried



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: Still problems with ACPI sleep state

[Nate Lawson]

On Fri, 25 Jun 2004, Herman Sheremetyev wrote:
> Hi Lars,
>
> Try booting with acpi_sleep=s3_bios, I had the same problem on my Asus
> M6N and that made the LCD come back on after an S3 resume.
>
> -Herman

Could someone familiar with Linux let me know what s3_bios does
differently from a normal S3?

-Nate


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: Still problems with ACPI sleep state

[Nate Lawson]

[context recovered]
On Sat, 26 Jun 2004, Michael Frank wrote:
> On Fri, 25 Jun 2004 21:15:21 -0700 (PDT), Nate Lawson <nate-Y6VGUYTwhu0@public.gmane.org> wrote:
> > On Fri, 25 Jun 2004, Herman Sheremetyev wrote:
> >> Try booting with acpi_sleep=s3_bios, I had the same problem on my Asus
> >> M6N and that made the LCD come back on after an S3 resume.
> >>
> >> -Herman
> >
> > Could someone familiar with Linux let me know what s3_bios does
> > differently from a normal S3?
> >
> > -Nate
>
> The suspend is performed in the BIOS without OS interaction.
>
> BIOS grabs CPU/its state, suspends devices, saves state,  powers down
> and on powerup restores state, resumes devices, releases its state/CPU.
>
> (more or less)
>
> In short, BIOS does all the work. Used to be like that before ACPI.
> And few systems do it now like that...

I could use a bit more technical response.  For instance, are SLP_TYP_A/B
written to a different register?  If so, which?  Does the system
transition to legacy mode (disabling ACPI), trigger APM suspend, then
re-enable ACPI on resume?  What caveats are there?

-Nate


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: Still problems with ACPI sleep state

[Michael Frank]

On Fri, 25 Jun 2004 23:30:35 -0700 (PDT), Nate Lawson <nate-Y6VGUYTwhu0@public.gmane.org> wrote:

> [context recovered]
> On Sat, 26 Jun 2004, Michael Frank wrote:
>> On Fri, 25 Jun 2004 21:15:21 -0700 (PDT), Nate Lawson <nate-Y6VGUYTwhu0@public.gmane.org> wrote:
>> > On Fri, 25 Jun 2004, Herman Sheremetyev wrote:
>> >> Try booting with acpi_sleep=s3_bios, I had the same problem on my Asus
>> >> M6N and that made the LCD come back on after an S3 resume.
>> >>
>> >> -Herman
>> >
>> > Could someone familiar with Linux let me know what s3_bios does
>> > differently from a normal S3?
>> >
>> > -Nate
>>
>> The suspend is performed in the BIOS without OS interaction.
>>
>> BIOS grabs CPU/its state, suspends devices, saves state,  powers down
>> and on powerup restores state, resumes devices, releases its state/CPU.
>>
>> (more or less)
>>
>> In short, BIOS does all the work. Used to be like that before ACPI.
>> And few systems do it now like that...
>
> I could use a bit more technical response.  For instance, are SLP_TYP_A/B
> written to a different register?  If so, which?  Does the system
> transition to legacy mode (disabling ACPI), trigger APM suspend, then
> re-enable ACPI on resume?  What caveats are there?
>

No idea, only the BIOS supplier will know the details...
	Michael



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com

Re: Still problems with ACPI sleep state

[Matthew Garrett]

On Fri, 2004-06-25 at 21:15 -0700, Nate Lawson wrote:

> Could someone familiar with Linux let me know what s3_bios does
> differently from a normal S3?

It tries to reinitialise the video bios after resume. This sometimes
helps get some amount of video functionality back. The actual sleep and
resume process is identical other than that.

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



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: Still problems with ACPI sleep state

[Stefan Seyfried]

On Fri, Jun 25, 2004 at 11:30:35PM -0700, Nate Lawson wrote:
> [context recovered]
> On Sat, 26 Jun 2004, Michael Frank wrote:
> > On Fri, 25 Jun 2004 21:15:21 -0700 (PDT), Nate Lawson <nate-Y6VGUYTwhu0@public.gmane.org> wrote:
> > > On Fri, 25 Jun 2004, Herman Sheremetyev wrote:
> > >> Try booting with acpi_sleep=s3_bios, I had the same problem on my Asus
> > >> M6N and that made the LCD come back on after an S3 resume.
> > >>
> > >> -Herman
> > >
> > > Could someone familiar with Linux let me know what s3_bios does
> > > differently from a normal S3?
> > >
> > > -Nate
> >
> > The suspend is performed in the BIOS without OS interaction.
> >
> > BIOS grabs CPU/its state, suspends devices, saves state,  powers down
> > and on powerup restores state, resumes devices, releases its state/CPU.

i believe that is was "echo 4b > /proc/acpi/sleep" does.
> >
> > In short, BIOS does all the work. Used to be like that before ACPI.
> > And few systems do it now like that...
 
> I could use a bit more technical response.  For instance, are SLP_TYP_A/B
> written to a different register?  If so, which?  Does the system
> transition to legacy mode (disabling ACPI), trigger APM suspend, then
> re-enable ACPI on resume?  What caveats are there?

i *believe* that acpi_sleep=s3_bios just invokes a hack to call some BIOS
routines to reinitialize the video card since the drivers often cannot
do this themselves ("warm booting" the card).

cite from Documentation/power/video.txt:
----
There are three types of systems where video works after S3 resume:

* systems where video state is preserved over S3. (HP Omnibook xe3)

* systems that initialize video card into vga text mode and where BIOS
  works well enough to be able to set video mode. Use
  acpi_sleep=s3_mode on these. (Toshiba 4030cdt)

* systems where it is possible to call video bios during S3
  resume. Unfortunately, it is not correct to call video BIOS at that
  point, but it happens to work on some machines. Use
  acpi_sleep=s3_bios (Athlon64 desktop system)

Now, if you pass acpi_sleep=something, and it does not work with your
bios, you'll get hard crash during resume. Be carefull.

You may have system where none of above works. At that point you
either invent another ugly hack that works, or write proper driver for
your video card (good luck getting docs :-().
----

so it seems to be purely a video card initialization hack.
-- 
Stefan Seyfried



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: Still problems with ACPI sleep state

[Nate Lawson]

On Sat, 26 Jun 2004, Matthew Garrett wrote:
> On Fri, 2004-06-25 at 21:15 -0700, Nate Lawson wrote:
>
> > Could someone familiar with Linux let me know what s3_bios does
> > differently from a normal S3?
>
> It tries to reinitialise the video bios after resume. This sometimes
> helps get some amount of video functionality back. The actual sleep and
> resume process is identical other than that.

I see.  I didn't know if it was something else.  This is just the lcall
hack.  We do that too:

        /* Re-initialize video BIOS if the reset_video tunable is set. */
        cmp     $0,reset_video
        je      wakeup_16_gdt
        lcall   $0xc000,$3

-Nate


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: Re: Still problems with ACPI sleep state

[Pavel Machek]

Hi!

> i *believe* that acpi_sleep=s3_bios just invokes a hack to call some BIOS
> routines to reinitialize the video card since the drivers often cannot
> do this themselves ("warm booting" the card).

Correct.
				Pavel

-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: Still problems with ACPI sleep state

[Pavel Machek]

Hi!

> > > Could someone familiar with Linux let me know what s3_bios does
> > > differently from a normal S3?
> >
> > It tries to reinitialise the video bios after resume. This sometimes
> > helps get some amount of video functionality back. The actual sleep and
> > resume process is identical other than that.
> 
> I see.  I didn't know if it was something else.  This is just the lcall
> hack.  We do that too:
> 
>         /* Re-initialize video BIOS if the reset_video tunable is set. */
>         cmp     _0,reset_video
>         je      wakeup_16_gdt
>         lcall   _0xc000,_3
> 

Who is "we"? Do you have any other usefull hacks?
(we have second one trying to change the video mode)

				Pavel
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: Still problems with ACPI sleep state

[Nate Lawson]

On Tue, 29 Jun 2004, Pavel Machek wrote:
> > > > Could someone familiar with Linux let me know what s3_bios does
> > > > differently from a normal S3?
> > >
> > > It tries to reinitialise the video bios after resume. This sometimes
> > > helps get some amount of video functionality back. The actual sleep and
> > > resume process is identical other than that.
> >
> > I see.  I didn't know if it was something else.  This is just the lcall
> > hack.  We do that too:
> >
> >         /* Re-initialize video BIOS if the reset_video tunable is set. */
> >         cmp     _0,reset_video
> >         je      wakeup_16_gdt
> >         lcall   _0xc000,_3
> >
>
> Who is "we"? Do you have any other usefull hacks?
> (we have second one trying to change the video mode)

We == FreeBSD.  I don't think your int 10h video hack helps so we don't
use it.  Do you know of a system that it helps?

As far as getting suspend/resume to work, I'm very suspicious
of the disable bus mastering call in AcpiEnterSleepState.  It's known to
cause laptops (IBM T40) not to enter S5.  That's why it's currently only
enabled for sleep states other than S5.  I suspect it may affect S4 and
possible S3 also.

Could you give me a quick summary of how linux sets up its drivers for
suspend/resume?  I've found a Dell where Linux S3 works but FreeBSD's does
not.  Even with all the drivers removed, it "bounces" back to life instead
of going to sleep in FreeBSD.  It doesn't crash though.  For
suspend/resume, we save/restore the PCI BARs for the drivers and then let
the drivers save their own private state.  Is there anything else you know
of that would cause this "bounce"?  It happens even with no drivers
installed except for ATA and all removable hw removed.

-Nate


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: Still problems with ACPI sleep state

[Matthew Garrett]

On Thu, 2004-07-01 at 12:42 -0700, Nate Lawson wrote:

> We == FreeBSD.  I don't think your int 10h video hack helps so we don't
> use it.  Do you know of a system that it helps?

s3_bios seems to help on almost all recent Thinkpads. s3_mode helped on
my old Thinkpad 240X - I didn't get a text console back, but it /did/
get the backlight switched on, and X was able to reinitialise the
screen. I really need to test that machine with a more recent kernel and
BIOS, though.
-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: Still problems with ACPI sleep state

[Pavel Machek]

Hi!

> > > > It tries to reinitialise the video bios after resume. This sometimes
> > > > helps get some amount of video functionality back. The actual sleep and
> > > > resume process is identical other than that.
> > >
> > > I see.  I didn't know if it was something else.  This is just the lcall
> > > hack.  We do that too:
> > >
> > >         /* Re-initialize video BIOS if the reset_video tunable is set. */
> > >         cmp     _0,reset_video
> > >         je      wakeup_16_gdt
> > >         lcall   _0xc000,_3
> > >
> >
> > Who is "we"? Do you have any other usefull hacks?
> > (we have second one trying to change the video mode)
> 
> We == FreeBSD.  I don't think your int 10h video hack helps so we don't
> use it.  Do you know of a system that it helps?

Toshiba 4030cdt notebook. Its VGA is in default text mode... which is
bad if you are trying to use vesafb. int 10 fixes it.

> As far as getting suspend/resume to work, I'm very suspicious
> of the disable bus mastering call in AcpiEnterSleepState.  It's known to
> cause laptops (IBM T40) not to enter S5.  That's why it's currently only
> enabled for sleep states other than S5.  I suspect it may affect S4 and
> possible S3 also.
> 
> Could you give me a quick summary of how linux sets up its drivers for
> suspend/resume?  I've found a Dell where Linux S3 works but FreeBSD's does
> not.  Even with all the drivers removed, it "bounces" back to life instead
> of going to sleep in FreeBSD.  It doesn't crash though.  For

Do you enable proper GPEs? I'm not ACPI wizard but I heard something
like that.

> suspend/resume, we save/restore the PCI BARs for the drivers and then let
> the drivers save their own private state.  Is there anything else you know
> of that would cause this "bounce"?  It happens even with no drivers
> installed except for ATA and all removable hw removed.

We do PCI BARs too (but started doing that only recently), plus many
drivers have specific things they do...
								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 sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com