[2.5.50, ACPI] link error

[2.5.50, ACPI] link error

[Jochen Hein]

When compiling 2.5.50 with CONFIG_ACPI_SLEEP=y
I get:

   ld -m elf_i386  -r -o init/built-in.o init/main.o init/version.o init/do_mounts.o init/initramfs.o
        ld -m elf_i386 -e stext -T arch/i386/vmlinux.lds.s arch/i386/kernel/head.o arch/i386/kernel/init_task.o  init/built-in.o --start-group  usr/built-in.o  arch/i386/kernel/built-in.o  arch/i386/mm/built-in.o  arch/i386/mach-generic/built-in.o  kernel/built-in.o  mm/built-in.o  fs/built-in.o  ipc/built-in.o  security/built-in.o  crypto/built-in.o  lib/lib.a  arch/i386/lib/lib.a  drivers/built-in.o  sound/built-in.o  arch/i386/pci/built-in.o  net/built-in.o --end-group  -o vmlinux
arch/i386/kernel/built-in.o(.data+0x1304): In function `do_suspend_lowlevel':
: undefined reference to `save_processor_state'
arch/i386/kernel/built-in.o(.data+0x130a): In function `do_suspend_lowlevel':
: undefined reference to `saved_context_esp'
arch/i386/kernel/built-in.o(.data+0x130f): In function `do_suspend_lowlevel':
: undefined reference to `saved_context_eax'
arch/i386/kernel/built-in.o(.data+0x1315): In function `do_suspend_lowlevel':
: undefined reference to `saved_context_ebx'
arch/i386/kernel/built-in.o(.data+0x131b): In function `do_suspend_lowlevel':
: undefined reference to `saved_context_ecx'
arch/i386/kernel/built-in.o(.data+0x1321): In function `do_suspend_lowlevel':
: undefined reference to `saved_context_edx'
arch/i386/kernel/built-in.o(.data+0x1327): In function `do_suspend_lowlevel':
: undefined reference to `saved_context_ebp'
arch/i386/kernel/built-in.o(.data+0x132d): In function `do_suspend_lowlevel':
: undefined reference to `saved_context_esi'
arch/i386/kernel/built-in.o(.data+0x1333): In function `do_suspend_lowlevel':
: undefined reference to `saved_context_edi'
arch/i386/kernel/built-in.o(.data+0x133a): In function `do_suspend_lowlevel':
: undefined reference to `saved_context_eflags'
arch/i386/kernel/built-in.o(.data+0x137a): In function `do_suspend_lowlevel':
: undefined reference to `saved_context_esp'
arch/i386/kernel/built-in.o(.data+0x1380): In function `do_suspend_lowlevel':
: undefined reference to `saved_context_ebp'
arch/i386/kernel/built-in.o(.data+0x1385): In function `do_suspend_lowlevel':
: undefined reference to `saved_context_eax'
arch/i386/kernel/built-in.o(.data+0x138b): In function `do_suspend_lowlevel':
: undefined reference to `saved_context_ebx'
arch/i386/kernel/built-in.o(.data+0x1391): In function `do_suspend_lowlevel':
: undefined reference to `saved_context_ecx'
arch/i386/kernel/built-in.o(.data+0x1397): In function `do_suspend_lowlevel':
: undefined reference to `saved_context_edx'
arch/i386/kernel/built-in.o(.data+0x139d): In function `do_suspend_lowlevel':
: undefined reference to `saved_context_esi'
arch/i386/kernel/built-in.o(.data+0x13a3): In function `do_suspend_lowlevel':
: undefined reference to `saved_context_edi'
arch/i386/kernel/built-in.o(.data+0x13a8): In function `do_suspend_lowlevel':
: undefined reference to `restore_processor_state'
arch/i386/kernel/built-in.o(.data+0x13ae): In function `do_suspend_lowlevel':
: undefined reference to `saved_context_eflags'
make: *** [vmlinux] Fehler 1

Re: [2.5.50, ACPI] link error

[Eric Altendorf]

Try turning on software suspend in the kernel hacking section.  I had 
to clean and recompile a couple times after doing that but that 
eventually got it to compile.  Of course, once I got it compiled it 
oops'ed on boot, so that may not get you anywhere, but.... :-)

eric

On Monday 02 December 2002 12:24, Jochen Hein wrote:
> When compiling 2.5.50 with CONFIG_ACPI_SLEEP=y
> I get:
>
>    ld -m elf_i386  -r -o init/built-in.o init/main.o init/version.o
> init/do_mounts.o init/initramfs.o ld -m elf_i386 -e stext -T
> arch/i386/vmlinux.lds.s arch/i386/kernel/head.o
> arch/i386/kernel/init_task.o  init/built-in.o --start-group 
> usr/built-in.o  arch/i386/kernel/built-in.o 
> arch/i386/mm/built-in.o  arch/i386/mach-generic/built-in.o 
> kernel/built-in.o  mm/built-in.o  fs/built-in.o  ipc/built-in.o 
> security/built-in.o  crypto/built-in.o  lib/lib.a 
> arch/i386/lib/lib.a  drivers/built-in.o  sound/built-in.o 
> arch/i386/pci/built-in.o  net/built-in.o --end-group  -o vmlinux
>
> arch/i386/kernel/built-in.o(.data+0x1304): In function 
`do_suspend_lowlevel':
> : undefined reference to `save_processor_state'
>
> arch/i386/kernel/built-in.o(.data+0x130a): In function 
`do_suspend_lowlevel':
> : undefined reference to `saved_context_esp'
>
> arch/i386/kernel/built-in.o(.data+0x130f): In function 
`do_suspend_lowlevel':
> : undefined reference to `saved_context_eax'
>
> arch/i386/kernel/built-in.o(.data+0x1315): In function 
`do_suspend_lowlevel':
> : undefined reference to `saved_context_ebx'
>
> arch/i386/kernel/built-in.o(.data+0x131b): In function 
`do_suspend_lowlevel':
> : undefined reference to `saved_context_ecx'
>
> arch/i386/kernel/built-in.o(.data+0x1321): In function 
`do_suspend_lowlevel':
> : undefined reference to `saved_context_edx'
>
> arch/i386/kernel/built-in.o(.data+0x1327): In function 
`do_suspend_lowlevel':
> : undefined reference to `saved_context_ebp'
>
> arch/i386/kernel/built-in.o(.data+0x132d): In function 
`do_suspend_lowlevel':
> : undefined reference to `saved_context_esi'
>
> arch/i386/kernel/built-in.o(.data+0x1333): In function 
`do_suspend_lowlevel':
> : undefined reference to `saved_context_edi'
>
> arch/i386/kernel/built-in.o(.data+0x133a): In function 
`do_suspend_lowlevel':
> : undefined reference to `saved_context_eflags'
>
> arch/i386/kernel/built-in.o(.data+0x137a): In function 
`do_suspend_lowlevel':
> : undefined reference to `saved_context_esp'
>
> arch/i386/kernel/built-in.o(.data+0x1380): In function 
`do_suspend_lowlevel':
> : undefined reference to `saved_context_ebp'
>
> arch/i386/kernel/built-in.o(.data+0x1385): In function 
`do_suspend_lowlevel':
> : undefined reference to `saved_context_eax'
>
> arch/i386/kernel/built-in.o(.data+0x138b): In function 
`do_suspend_lowlevel':
> : undefined reference to `saved_context_ebx'
>
> arch/i386/kernel/built-in.o(.data+0x1391): In function 
`do_suspend_lowlevel':
> : undefined reference to `saved_context_ecx'
>
> arch/i386/kernel/built-in.o(.data+0x1397): In function 
`do_suspend_lowlevel':
> : undefined reference to `saved_context_edx'
>
> arch/i386/kernel/built-in.o(.data+0x139d): In function 
`do_suspend_lowlevel':
> : undefined reference to `saved_context_esi'
>
> arch/i386/kernel/built-in.o(.data+0x13a3): In function 
`do_suspend_lowlevel':
> : undefined reference to `saved_context_edi'
>
> arch/i386/kernel/built-in.o(.data+0x13a8): In function 
`do_suspend_lowlevel':
> : undefined reference to `restore_processor_state'
>
> arch/i386/kernel/built-in.o(.data+0x13ae): In function 
`do_suspend_lowlevel':
> : undefined reference to `saved_context_eflags'
>
> make: *** [vmlinux] Fehler 1
>
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
"First they ignore you.  Then they laugh at you.
 Then they fight you.  And then you win."             -Gandhi

Re: [2.5.50, ACPI] link error

[Jochen Hein]

Eric Altendorf <EricAltendorf@orst.edu> writes:

> On Monday 02 December 2002 12:24, Jochen Hein wrote:
>> When compiling 2.5.50 with CONFIG_ACPI_SLEEP=y
>> I get:
>>
>> arch/i386/kernel/built-in.o(.data+0x1304): In function 
> `do_suspend_lowlevel':
>> : undefined reference to `save_processor_state'
>>
>> arch/i386/kernel/built-in.o(.data+0x130a): In function 
> `do_suspend_lowlevel':
>> : undefined reference to `saved_context_esp'
>>
> Try turning on software suspend in the kernel hacking section.  

It is off (and has been all the time, AFAIR).

Jochen

-- 
Wenn Du nicht weißt was Du tust, tu's mit Eleganz.

Re: [2.5.50, ACPI] link error

[Eric Altendorf]

On Tuesday 03 December 2002 10:35, Jochen Hein wrote:
> Eric Altendorf <EricAltendorf@orst.edu> writes:
> > On Monday 02 December 2002 12:24, Jochen Hein wrote:
> >> When compiling 2.5.50 with CONFIG_ACPI_SLEEP=y
> >> I get:
> >>
> >> arch/i386/kernel/built-in.o(.data+0x1304): In function
> >
> > `do_suspend_lowlevel':
> >> : undefined reference to `save_processor_state'
> >>
> >> arch/i386/kernel/built-in.o(.data+0x130a): In function
> >
> > `do_suspend_lowlevel':
> >> : undefined reference to `saved_context_esp'
> >
> > Try turning on software suspend in the kernel hacking section.
>
> It is off (and has been all the time, AFAIR).

Right ... I'm no kernel hacker so I don't know why, but I can only get 
the recent kernels to compile with sleep states if I turn *ON* 
software suspend as well.  However, as soon as I turn on swsusp and 
get a compiled kernel, it oops'es on boot.

eric

-- 
"First they ignore you.  Then they laugh at you.
 Then they fight you.  And then you win."             -Gandhi

Re: [2.5.50, ACPI] link error

[Pavel Machek]

Hi!

> > >> When compiling 2.5.50 with CONFIG_ACPI_SLEEP=y
> > >> I get:
> > >>
> > >> arch/i386/kernel/built-in.o(.data+0x1304): In function
> > >
> > > `do_suspend_lowlevel':
> > >> : undefined reference to `save_processor_state'
> > >>
> > >> arch/i386/kernel/built-in.o(.data+0x130a): In function
> > >
> > > `do_suspend_lowlevel':
> > >> : undefined reference to `saved_context_esp'
> > >
> > > Try turning on software suspend in the kernel hacking section.
> >
> > It is off (and has been all the time, AFAIR).
> 
> Right ... I'm no kernel hacker so I don't know why, but I can only get 
> the recent kernels to compile with sleep states if I turn *ON* 
> software suspend as well.  However, as soon as I turn on swsusp and 
> get a compiled kernel, it oops'es on boot.

Can you mail me decoded oops?
								Pavel
-- 
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?

Re: [2.5.50, ACPI] link error

[Jeff Garzik]

Note that this link error occurs for me when swsusp is off, but 
CONFIG_ACPI_SLEEP is on.

Disabling CONFIG_ACPI_SLEEP fixes the kernel build.

Re: [2.5.50, ACPI] link error

[Pavel Machek]

Hi!

> Note that this link error occurs for me when swsusp is off, but 
> CONFIG_ACPI_SLEEP is on.
> 
> Disabling CONFIG_ACPI_SLEEP fixes the kernel build.

Yes, there are about 10 patches to fix it floating around... I just
hope linus takes one of them. (Fix is make ACPI_SLEEP depend on
swsusp).


								Pavel

-- 
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.

Re: [2.5.50, ACPI] link error

[Jeff Garzik]

Pavel Machek wrote:
> Yes, there are about 10 patches to fix it floating around... I just
> hope linus takes one of them. (Fix is make ACPI_SLEEP depend on
> swsusp).


I haven't seen the patch, but does it make sense for hardware suspend to 
depend on software suspend?

IMO there should be a common core (CONFIG_SUSPEND?), not force ACPI to 
depend on swsusp.  That way you get the _least_ common denominator, not 
the union of two sets.

	Jeff

Re: [2.5.50, ACPI] link error

[Pavel Machek]

Hi!

> >Yes, there are about 10 patches to fix it floating around... I just
> >hope linus takes one of them. (Fix is make ACPI_SLEEP depend on
> >swsusp).
> 
> 
> I haven't seen the patch, but does it make sense for hardware suspend to 
> depend on software suspend?
> 
> IMO there should be a common core (CONFIG_SUSPEND?), not force ACPI to 
> depend on swsusp.  That way you get the _least_ common denominator, not 
> the union of two sets.

Feel free to fix that, but as swsusp is needed for S4, anyway, I do not
see big need to do that.
								Pavel
-- 
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.

Re: [2.5.50, ACPI] link error

[Jeff Garzik]

Pavel Machek wrote:
> Hi!
> 
> 
>>>Yes, there are about 10 patches to fix it floating around... I just
>>>hope linus takes one of them. (Fix is make ACPI_SLEEP depend on
>>>swsusp).
>>
>>
>>I haven't seen the patch, but does it make sense for hardware suspend to 
>>depend on software suspend?
>>
>>IMO there should be a common core (CONFIG_SUSPEND?), not force ACPI to 
>>depend on swsusp.  That way you get the _least_ common denominator, not 
>>the union of two sets.
> 
> 
> Feel free to fix that, but as swsusp is needed for S4, anyway, I do not
> see big need to do that.


Why should I fix your fix?

Doesn't that imply your fix is broken to begin with?

Re: [2.5.50, ACPI] link error

[Pavel Machek]

Hi!

> >>>Yes, there are about 10 patches to fix it floating around... I just
> >>>hope linus takes one of them. (Fix is make ACPI_SLEEP depend on
> >>>swsusp).
> >>
> >>
> >>I haven't seen the patch, but does it make sense for hardware suspend to 
> >>depend on software suspend?
> >>
> >>IMO there should be a common core (CONFIG_SUSPEND?), not force ACPI to 
> >>depend on swsusp.  That way you get the _least_ common denominator, not 
> >>the union of two sets.
> >
> >
> >Feel free to fix that, but as swsusp is needed for S4, anyway, I do not
> >see big need to do that.
> 
> 
> Why should I fix your fix?
> 
> Doesn't that imply your fix is broken to begin with?

ACPI/S4 support needs swsusp. ACPI/S3 needs big part of
swsusp. Splitting CONFIG_ACPI_SLEEP to S3 and S4 part seems like
overdesign to me, OTOH if you do the work it is okay with me.

								Pavel

-- 
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.

Re: [2.5.50, ACPI] link error

[Patrick Mochel]

> > Doesn't that imply your fix is broken to begin with?
> 
> ACPI/S4 support needs swsusp. ACPI/S3 needs big part of
> swsusp. Splitting CONFIG_ACPI_SLEEP to S3 and S4 part seems like
> overdesign to me, OTOH if you do the work it is okay with me.

You broke the design. S3 support was developed long before swsusp was in 
the kernel, and completely indpendent of it. It should have remained that 
way. 

S3 support is a subset of what is need for S4 support. 

swsusp is an implementation of S4 support. In theory, there could be 
multiple implementations that all use the same core (saving/restoring 
state). 

There could also be different power management schemes that use swsusp as 
an implementation for suspend-to-disk. But, that's another tangent. 

CONFIG_ACPI_SLEEP should give you S3 support, and the ACPI side of S4 
support. The comment in the config option should tell the user that they 
must choose a suspend implementation (e.g. CONFIG_SUSPEND, which should 
prolly be CONFIG_SWAP_SUSPEND) in order to get complete S4 support. (The 
ACPI side can make an empty call to swsusp if no implementation is 
selected). 


Some time ago, I made a BK repo for suspend support. I axed it, since no 
one ever used it. But, it's back again, and I'll be integrating your 
patches and try to dedicate a few extra cycles to resolving some of the 
issues. I'll send an announcement to the list once I've integrated your 
patches. 

	-pat

Re: [2.5.50, ACPI] link error

[Pavel Machek]

Hi!

> > > Doesn't that imply your fix is broken to begin with?
> > 
> > ACPI/S4 support needs swsusp. ACPI/S3 needs big part of
> > swsusp. Splitting CONFIG_ACPI_SLEEP to S3 and S4 part seems like
> > overdesign to me, OTOH if you do the work it is okay with me.
> 
> You broke the design. S3 support was developed long before swsusp was in 
> the kernel, and completely indpendent of it. It should have remained that 
> way. 
> 
> S3 support is a subset of what is need for S4 support. 

That's not true. acpi_wakeup.S is nasty piece of code, needed for S3
but not for S4. Big part of driver support is only needed for S3.

> swsusp is an implementation of S4 support. In theory, there could be 
> multiple implementations that all use the same core (saving/restoring 
> state). 

There were patches for S4bios floating around, but it never really
worked, IIRC.

> There could also be different power management schemes that use swsusp as 
> an implementation for suspend-to-disk. But, that's another tangent. 
> 
> CONFIG_ACPI_SLEEP should give you S3 support, and the ACPI side of S4 
> support. 

What's ACPI side of S4 good for when you can not do S4?

> The comment in the config option should tell the user that they 
> must choose a suspend implementation (e.g. CONFIG_SUSPEND, which should 
> prolly be CONFIG_SWAP_SUSPEND) in order to get complete S4 support. (The 
> ACPI side can make an empty call to swsusp if no implementation is 
> selected). 

S3 needs process stopper from kernel/suspend.c. I did not want to have
#ifdefs all over suspend.c...

> Some time ago, I made a BK repo for suspend support. I axed it, since no 
> one ever used it. But, it's back again, and I'll be integrating your 
> patches and try to dedicate a few extra cycles to resolving some of the 
> issues. I'll send an announcement to the list once I've integrated your 
> patches. 

I probably will not persuade you to make it CVS, right? [Sorry, I'm
not going to touch bitkeeper.]
								Pavel
-- 
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.

Re: [2.5.50, ACPI] link error

[Patrick Mochel]

> > S3 support is a subset of what is need for S4 support. 
> 
> That's not true. acpi_wakeup.S is nasty piece of code, needed for S3
> but not for S4. Big part of driver support is only needed for S3.

Ok, acpi_wakeup.S is only for S3.

As for drivers, I'm dubious of swsusp's handling of device and driver
support. A suspend cycle is supposed to leave devices in the same state
they were in before the cycle.  So, you need suspend and resume hooks in
the drivers, even for S4 support, to capture and restore context in the
devices themselves. Then again, I've no proof that swsusp doesn't get 
everything right as is.

> > CONFIG_ACPI_SLEEP should give you S3 support, and the ACPI side of S4 
> > support. 
> 
> What's ACPI side of S4 good for when you can not do S4?

To not litter the code with #ifdefs. 

> > The comment in the config option should tell the user that they 
> > must choose a suspend implementation (e.g. CONFIG_SUSPEND, which should 
> > prolly be CONFIG_SWAP_SUSPEND) in order to get complete S4 support. (The 
> > ACPI side can make an empty call to swsusp if no implementation is 
> > selected). 
> 
> S3 needs process stopper from kernel/suspend.c. I did not want to have
> #ifdefs all over suspend.c...

Then break it up into separate files in a separate directory.

> > Some time ago, I made a BK repo for suspend support. I axed it, since no 
> > one ever used it. But, it's back again, and I'll be integrating your 
> > patches and try to dedicate a few extra cycles to resolving some of the 
> > issues. I'll send an announcement to the list once I've integrated your 
> > patches. 
> 
> I probably will not persuade you to make it CVS, right? [Sorry, I'm
> not going to touch bitkeeper.]

I know, and that's fine. I won't touch CVS again, unless there's a hefty 
sum and a lot of good beer involved. (Or, after I've consumed a lot of 
good beer). Patches can be made from the repo, most easily after merging 
to a new kernel version.

	-pat

Re: [2.5.50, ACPI] link error

[Pavel Machek]

Hi!

> > > S3 support is a subset of what is need for S4 support. 
> > 
> > That's not true. acpi_wakeup.S is nasty piece of code, needed for S3
> > but not for S4. Big part of driver support is only needed for S3.
> 
> Ok, acpi_wakeup.S is only for S3.
> 
> As for drivers, I'm dubious of swsusp's handling of device and driver
> support. A suspend cycle is supposed to leave devices in the same state

Some devices do not really have a state (timer -- it needs to be set
to 1kHz, but that's it), and they do not need support for S4 but need
it for S3.

> > > The comment in the config option should tell the user that they 
> > > must choose a suspend implementation (e.g. CONFIG_SUSPEND, which should 
> > > prolly be CONFIG_SWAP_SUSPEND) in order to get complete S4 support. (The 
> > > ACPI side can make an empty call to swsusp if no implementation is 
> > > selected). 
> > 
> > S3 needs process stopper from kernel/suspend.c. I did not want to have
> > #ifdefs all over suspend.c...
> 
> Then break it up into separate files in a separate directory.

Uff, having kernel/suspend/freezer.c and kernel/suspend/disk.c would
seem very ugly to me, and freezer is pretty short in fact... I do not
think we want separate directory for suspend.

> > > Some time ago, I made a BK repo for suspend support. I axed it, since no 
> > > one ever used it. But, it's back again, and I'll be integrating your 
> > > patches and try to dedicate a few extra cycles to resolving some of the 
> > > issues. I'll send an announcement to the list once I've integrated your 
> > > patches. 
> > 
> > I probably will not persuade you to make it CVS, right? [Sorry, I'm
> > not going to touch bitkeeper.]
> 
> I know, and that's fine. I won't touch CVS again, unless there's a hefty 
> sum and a lot of good beer involved. (Or, after I've consumed a lot of 
> good beer). Patches can be made from the repo, most easily after merging 
> to a new kernel version.

:-) there should be some good beer around here ;-).

I'd like to keep it simple for now. I feel alone developing sleep on
2.5, and it is easier for me not to ave to test different
configurations. So I think ACPI_SLEEP requiring SOFTWARE_SUSPEND is
okay for now (code bloat is not too bad). If you are joining and will
work on ACPI_SLEEP && !SOFTWARE_SUSPEND, you can easily catch
non-compilations and similar mistakes, and it will be okay to separate
the two.

								Pavel
-- 
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.

Re: [2.5.50, ACPI] link error

[Jeff Garzik]

Pavel Machek wrote:
> S3 needs process stopper from kernel/suspend.c. I did not want to have
> #ifdefs all over suspend.c...


Then move it to a different file, that may be shared between various 
CONFIG_xxx features.

Re: [ACPI] Re: [2.5.50, ACPI] link error

[Ducrot Bruno]

On Fri, Dec 06, 2002 at 01:06:18AM +0100, Pavel Machek wrote:
> Hi!
> 
> > > > Doesn't that imply your fix is broken to begin with?
> > > 
> > > ACPI/S4 support needs swsusp. ACPI/S3 needs big part of
> > > swsusp. Splitting CONFIG_ACPI_SLEEP to S3 and S4 part seems like
> > > overdesign to me, OTOH if you do the work it is okay with me.
> > 
> > You broke the design. S3 support was developed long before swsusp was in 
> > the kernel, and completely indpendent of it. It should have remained that 
> > way. 
> > 
> > S3 support is a subset of what is need for S4 support. 
> 
> That's not true. acpi_wakeup.S is nasty piece of code, needed for S3
> but not for S4. Big part of driver support is only needed for S3.
> 
> > swsusp is an implementation of S4 support. In theory, there could be 
> > multiple implementations that all use the same core (saving/restoring 
> > state). 
> 
> There were patches for S4bios floating around, but it never really
> worked, IIRC.

No.  It work.  I do not resubmmited patches because I think that
swsusp is better.

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.

Re: [ACPI] Re: [2.5.50, ACPI] link error

[Ducrot Bruno]

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

Hi, Pavel.

On Fri, Dec 06, 2002 at 07:57:02PM +0100, Ducrot Bruno wrote:
> On Fri, Dec 06, 2002 at 01:06:18AM +0100, Pavel Machek wrote:
> > Hi!
> > 
> > > > > Doesn't that imply your fix is broken to begin with?
> > > > 
> > > > ACPI/S4 support needs swsusp. ACPI/S3 needs big part of
> > > > swsusp. Splitting CONFIG_ACPI_SLEEP to S3 and S4 part seems like
> > > > overdesign to me, OTOH if you do the work it is okay with me.
> > > 
> > > You broke the design. S3 support was developed long before swsusp was in 
> > > the kernel, and completely indpendent of it. It should have remained that 
> > > way. 
> > > 
> > > S3 support is a subset of what is need for S4 support. 
> > 
> > That's not true. acpi_wakeup.S is nasty piece of code, needed for S3
> > but not for S4. Big part of driver support is only needed for S3.
> > 
> > > swsusp is an implementation of S4 support. In theory, there could be 
> > > multiple implementations that all use the same core (saving/restoring 
> > > state). 
> > 
> > There were patches for S4bios floating around, but it never really
> > worked, IIRC.
> 
> No.  It work.  I do not resubmmited patches because I think that
> swsusp is better.
> 

I attach also this patch, it is ughly, though, but if you are sure
that your laptop can support S4BIOS (I do not include basic checks for
that), it should survive (I need myself to reset at wakeup the keyboard controller,
though).

It is again acpi on sf.net of today, and some of your patches for S3 support.

echo 4b > /proc/acpi/sleep if you want to say goodbye to your data :)

Cheers,

-- 
Ducrot Bruno
http://www.poupinou.org        Page profaissionelle
http://toto.tu-me-saoules.com  Haume page

[-- Attachment #2: s4bios-2.5.50.diff --]
[-- Type: text/plain, Size: 5017 bytes --]

--- linux-2.5.50/arch/i386/kernel/acpi_wakeup.S	2002/12/06 21:34:17	1.1
+++ linux-2.5.50/arch/i386/kernel/acpi_wakeup.S	2002/12/06 21:48:14
@@ -336,6 +336,48 @@
 	pushl saved_context_eflags ; popfl
 	ret
 
+ENTRY(do_suspend_lowlevel_s4bios)
+	cmpl $0,4(%esp)
+	jne .L1432
+	call save_processor_state
+
+	movl %esp, saved_context_esp
+	movl %eax, saved_context_eax
+	movl %ebx, saved_context_ebx
+	movl %ecx, saved_context_ecx
+	movl %edx, saved_context_edx
+	movl %ebp, saved_context_ebp
+	movl %esi, saved_context_esi
+	movl %edi, saved_context_edi
+	pushfl ; popl saved_context_eflags
+
+	movl $.L1432,saved_eip
+	movl %esp,saved_esp
+	movl %ebp,saved_ebp
+	movl %ebx,saved_ebx
+	movl %edi,saved_edi
+	movl %esi,saved_esi
+
+	pushl $3
+	call acpi_enter_sleep_state_s4bios
+	addl $4,%esp
+	ret
+	.p2align 4,,7
+.L1433:
+	movl $__KERNEL_DS,%eax
+	movw %ax, %ds
+	movl saved_context_esp, %esp
+	movl saved_context_ebp, %ebp
+	movl saved_context_eax, %eax
+	movl saved_context_ebx, %ebx
+	movl saved_context_ecx, %ecx
+	movl saved_context_edx, %edx
+	movl saved_context_esi, %esi
+	movl saved_context_edi, %edi
+	call restore_processor_state
+	pushl saved_context_eflags ; popfl
+	ret
+
 ALIGN
 # saved registers
 saved_gdt:	.long	0,0
--- linux-2.5.50/drivers/acpi/include/acpixf.h	2002/12/06 21:56:49	1.1
+++ linux-2.5.50/drivers/acpi/include/acpixf.h	2002/12/06 22:02:42
@@ -380,6 +380,10 @@
 	u8                      sleep_state);
 
 acpi_status
+acpi_enter_sleep_state_s4bios (
+	void);
+
+acpi_status
 acpi_leave_sleep_state (
 	u8                      sleep_state);
 
--- linux-2.5.50/drivers/acpi/hardware/hwsleep.c	2002/12/06 21:39:07	1.1
+++ linux-2.5.50/drivers/acpi/hardware/hwsleep.c	2002/12/06 22:08:22
@@ -319,6 +319,51 @@
 
 /******************************************************************************
  *
+ * FUNCTION:    Acpi_enter_sleep_state_s4bios
+ *
+ * PARAMETERS:  None
+ *
+ * RETURN:      Status
+ *
+ * DESCRIPTION: Perform a s4 bios request.
+ *              THIS FUNCTION MUST BE CALLED WITH INTERRUPTS DISABLED
+ *
+ ******************************************************************************/
+
+acpi_status
+acpi_enter_sleep_state_s4bios (void)
+{
+	u32                     in_value;
+	acpi_status             status;
+
+
+	ACPI_FUNCTION_TRACE ("Acpi_enter_sleep_state_s4bios");
+
+
+	acpi_set_register (ACPI_BITREG_WAKE_STATUS, 1, ACPI_MTX_LOCK);
+	acpi_hw_clear_acpi_status();
+
+	acpi_hw_disable_non_wakeup_gpes();
+
+	ACPI_FLUSH_CPU_CACHE();
+
+	acpi_os_stall (10000);
+
+	status = acpi_os_write_port (acpi_gbl_FADT->smi_cmd, (acpi_integer) acpi_gbl_FADT->S4bios_req, 8);
+
+	do {
+		status = acpi_get_register (ACPI_BITREG_WAKE_STATUS, &in_value, ACPI_MTX_LOCK);
+		if (ACPI_FAILURE (status)) {
+			return_ACPI_STATUS (status);
+		}
+	} while (!in_value);
+
+	return_ACPI_STATUS (AE_OK);
+}
+
+
+/******************************************************************************
+ *
  * FUNCTION:    Acpi_leave_sleep_state
  *
  * PARAMETERS:  Sleep_state         - Which sleep state we just exited
--- linux-2.5.50/drivers/acpi/sleep.c	2002/12/06 21:21:25	1.1
+++ linux-2.5.50/drivers/acpi/sleep.c	2002/12/06 22:29:28
@@ -149,8 +149,10 @@
 		if (state > ACPI_STATE_S1) {
 			error = acpi_save_state_mem();
 
+#if 0
 			if (!error && (state == ACPI_STATE_S4))
 				error = acpi_save_state_disk();
+#endif
 
 			if (error) {
 				device_resume(RESUME_RESTORE_STATE);
@@ -227,6 +229,8 @@
 	case ACPI_STATE_S3:
 		do_suspend_lowlevel(0);
 #endif
+	case ACPI_STATE_S4:
+		do_suspend_lowlevel_s4bios(0);
 		break;
 	}
 	local_irq_restore(flags);
@@ -253,7 +257,7 @@
 	freeze_processes();		/* device_suspend needs processes to be stopped */
 
 	/* do we have a wakeup address for S2 and S3? */
-	if (state == ACPI_STATE_S2 || state == ACPI_STATE_S3) {
+	if (state == ACPI_STATE_S2 || state == ACPI_STATE_S3 || state == ACPI_STATE_S4) {
 		if (!acpi_wakeup_address)
 			return AE_ERROR;
 		acpi_set_firmware_waking_vector((ACPI_PHYSICAL_ADDRESS) acpi_wakeup_address);
@@ -336,12 +340,14 @@
 	if (!sleep_states[state])
 		return_VALUE(-ENODEV);
 
+	if (state == 4 && state_string[1] != 'b') {
 #ifdef CONFIG_SOFTWARE_SUSPEND
-	if (state == 4) {
+	/* if (state == 4) { */
 		software_suspend();
 		return_VALUE(count);
-	}
+	/* } */
 #endif
+	}
 	status = acpi_suspend(state);
 
 	if (ACPI_FAILURE(status))
--- linux-2.5.50/drivers/acpi/acpi_ksyms.c	2002/12/06 21:58:48	1.1
+++ linux-2.5.50/drivers/acpi/acpi_ksyms.c	2002/12/06 21:59:12
@@ -86,6 +86,7 @@
 EXPORT_SYMBOL(acpi_get_register);
 EXPORT_SYMBOL(acpi_set_register);
 EXPORT_SYMBOL(acpi_enter_sleep_state);
+EXPORT_SYMBOL(acpi_enter_sleep_state_s4bios);
 EXPORT_SYMBOL(acpi_get_system_info);
 EXPORT_SYMBOL(acpi_get_devices);
 
--- linux-2.5.50/include/linux/suspend.h	2002/12/06 21:53:17	1.1
+++ linux-2.5.50/include/linux/suspend.h	2002/12/06 21:54:27
@@ -71,6 +71,8 @@
 
 extern void do_suspend_lowlevel(int resume);
 
+extern void do_suspend_lowlevel_s4bios(int resume);
+
 #else
 static inline void software_suspend(void)
 {

Re: [ACPI] Re: [2.5.50, ACPI] link error

[Pavel Machek]

Hi!

> > > > > Doesn't that imply your fix is broken to begin with?
> > > > 
> > > > ACPI/S4 support needs swsusp. ACPI/S3 needs big part of
> > > > swsusp. Splitting CONFIG_ACPI_SLEEP to S3 and S4 part seems like
> > > > overdesign to me, OTOH if you do the work it is okay with me.
> > > 
> > > You broke the design. S3 support was developed long before swsusp was in 
> > > the kernel, and completely indpendent of it. It should have remained that 
> > > way. 
> > > 
> > > S3 support is a subset of what is need for S4 support. 
> > 
> > That's not true. acpi_wakeup.S is nasty piece of code, needed for S3
> > but not for S4. Big part of driver support is only needed for S3.
> > 
> > > swsusp is an implementation of S4 support. In theory, there could be 
> > > multiple implementations that all use the same core (saving/restoring 
> > > state). 
> > 
> > There were patches for S4bios floating around, but it never really
> > worked, IIRC.
> 
> No.  It work.  I do not resubmmited patches because I think that
> swsusp is better.

I think that s4bios is nice to have. Its similar to S3 and easier to
set up than swsusp... It would be nice to have it.
								Pavel
-- 
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.

Re: [ACPI] Re: [2.5.50, ACPI] link error

[Constantinos Antoniou]

On Sun, 2002-12-08 at 14:49, Pavel Machek wrote:
> Hi!
> 
> > > > > > Doesn't that imply your fix is broken to begin with?
> > > > > 
> > > > > ACPI/S4 support needs swsusp. ACPI/S3 needs big part of
> > > > > swsusp. Splitting CONFIG_ACPI_SLEEP to S3 and S4 part seems like
> > > > > overdesign to me, OTOH if you do the work it is okay with me.
> > > > 
> > > > You broke the design. S3 support was developed long before swsusp was in 
> > > > the kernel, and completely indpendent of it. It should have remained that 
> > > > way. 
> > > > 
> > > > S3 support is a subset of what is need for S4 support. 
> > > 
> > > That's not true. acpi_wakeup.S is nasty piece of code, needed for S3
> > > but not for S4. Big part of driver support is only needed for S3.
> > > 
> > > > swsusp is an implementation of S4 support. In theory, there could be 
> > > > multiple implementations that all use the same core (saving/restoring 
> > > > state). 
> > > 
> > > There were patches for S4bios floating around, but it never really
> > > worked, IIRC.
> > 
> > No.  It work.  I do not resubmmited patches because I think that
> > swsusp is better.
> 
> I think that s4bios is nice to have. Its similar to S3 and easier to
> set up than swsusp... It would be nice to have it.

(I do not know much, but) another reason may be that some laptops do not
support S3, while they support S4? for example, in my Compaq Presario
1700T:

$ more /proc/acpi/info
ACPI-CA Version:         20011018
Sx States Supported:     S0 S1 S4 S5

(unpatched 2.4.19, if this has anything to do)

Costas

> 								Pavel
-- 
Constantinos Antoniou
Ph.D. Candidate
Massachusetts Institute of Technology
Intelligent Transportation Systems Program
77 Massachusetts Ave., NE20-208, Cambridge, MA 02139
(T) 617-252-1113 * (F) 617-252-1130 * (email) costas@mit.edu

Re: [ACPI] Re: [2.5.50, ACPI] link error

[Ducrot Bruno]

On Sun, Dec 08, 2002 at 03:46:20PM -0500, Constantinos Antoniou wrote:
> On Sun, 2002-12-08 at 14:49, Pavel Machek wrote:
> > Hi!
> > 
> > > > > > > Doesn't that imply your fix is broken to begin with?
> > > > > > 
> > > > > > ACPI/S4 support needs swsusp. ACPI/S3 needs big part of
> > > > > > swsusp. Splitting CONFIG_ACPI_SLEEP to S3 and S4 part seems like
> > > > > > overdesign to me, OTOH if you do the work it is okay with me.
> > > > > 
> > > > > You broke the design. S3 support was developed long before swsusp was in 
> > > > > the kernel, and completely indpendent of it. It should have remained that 
> > > > > way. 
> > > > > 
> > > > > S3 support is a subset of what is need for S4 support. 
> > > > 
> > > > That's not true. acpi_wakeup.S is nasty piece of code, needed for S3
> > > > but not for S4. Big part of driver support is only needed for S3.
> > > > 
> > > > > swsusp is an implementation of S4 support. In theory, there could be 
> > > > > multiple implementations that all use the same core (saving/restoring 
> > > > > state). 
> > > > 
> > > > There were patches for S4bios floating around, but it never really
> > > > worked, IIRC.
> > > 
> > > No.  It work.  I do not resubmmited patches because I think that
> > > swsusp is better.
> > 
> > I think that s4bios is nice to have. Its similar to S3 and easier to
> > set up than swsusp... It would be nice to have it.
> 
> (I do not know much, but) another reason may be that some laptops do not
> support S3, while they support S4? for example, in my Compaq Presario
> 1700T:
> 
> $ more /proc/acpi/info
> ACPI-CA Version:         20011018
> Sx States Supported:     S0 S1 S4 S5

Some southbrigdes have well know design flaw that prevent a 'good' S3
functionality.  Those this is disabled.

-- 
Ducrot Bruno
http://www.poupinou.org        Page profaissionelle
http://toto.tu-me-saoules.com  Haume page

Re: [ACPI] Re: [2.5.50, ACPI] link error

[Ducrot Bruno]

Hi Pavel:

On Sun, Dec 08, 2002 at 08:49:45PM +0100, Pavel Machek wrote:
> Hi!
> 
> > > > > > Doesn't that imply your fix is broken to begin with?
> > > > > 
> > > > > ACPI/S4 support needs swsusp. ACPI/S3 needs big part of
> > > > > swsusp. Splitting CONFIG_ACPI_SLEEP to S3 and S4 part seems like
> > > > > overdesign to me, OTOH if you do the work it is okay with me.
> > > > 
> > > > You broke the design. S3 support was developed long before swsusp was in 
> > > > the kernel, and completely indpendent of it. It should have remained that 
> > > > way. 
> > > > 
> > > > S3 support is a subset of what is need for S4 support. 
> > > 
> > > That's not true. acpi_wakeup.S is nasty piece of code, needed for S3
> > > but not for S4. Big part of driver support is only needed for S3.
> > > 
> > > > swsusp is an implementation of S4 support. In theory, there could be 
> > > > multiple implementations that all use the same core (saving/restoring 
> > > > state). 
> > > 
> > > There were patches for S4bios floating around, but it never really
> > > worked, IIRC.
> > 
> > No.  It work.  I do not resubmmited patches because I think that
> > swsusp is better.
> 
> I think that s4bios is nice to have. Its similar to S3 and easier to
> set up than swsusp... It would be nice to have it.

for me:
pros:
-----
1- it is really really more easier to implement than S4;
2- we can even have it with 2.4 kernels (it seems that it work without
the need of freezing processes, but I suspect that this statement
is 'wrong' by nature).

cons:
-----
1- it is much slower (especially at save time) than your swsusp;
2- end users must setup their systems (need to create a suspend partition,
or to keep a vfat partition as the really first one (/dev/hda1));
3- we use a bios function.  Actually, everything can happen...

That why I prefer swsusp at this time, or any other implementation of S4 (I
think about an implementation of S4 via LKCD).

Cheers,

-- 
Ducrot Bruno
http://www.poupinou.org        Page profaissionelle
http://toto.tu-me-saoules.com  Haume page

Re: [ACPI] Re: [2.5.50, ACPI] link error

[Pavel Machek]

Hi!

> > I think that s4bios is nice to have. Its similar to S3 and easier to
> > set up than swsusp... It would be nice to have it.
> 
> for me:
> pros:
> -----
> 1- it is really really more easier to implement than S4;
> 2- we can even have it with 2.4 kernels (it seems that it work without
> the need of freezing processes, but I suspect that this statement
> is 'wrong' by nature).
> 
> cons:
> -----
> 1- it is much slower (especially at save time) than your swsusp;
> 2- end users must setup their systems (need to create a suspend partition,
> or to keep a vfat partition as the really first one (/dev/hda1));
> 3- we use a bios function.  Actually, everything can happen...
> 
> That why I prefer swsusp at this time, or any other implementation of S4 (I
> think about an implementation of S4 via LKCD).

Yes I think swsusp is better (long term), but it might be worth it to
have S4bios, too. At least it has nice graphical task bars :-). Can
you push the patch, or is it okay for me to try to get it merged?

								Pavel
-- 
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.

Re: [ACPI] Re: [2.5.50, ACPI] link error

[Ducrot Bruno]

On Mon, Dec 09, 2002 at 12:01:11PM +0100, Pavel Machek wrote:
> Hi!
> 
> > > I think that s4bios is nice to have. Its similar to S3 and easier to
> > > set up than swsusp... It would be nice to have it.
> > 
> > for me:
> > pros:
> > -----
> > 1- it is really really more easier to implement than S4;
> > 2- we can even have it with 2.4 kernels (it seems that it work without
> > the need of freezing processes, but I suspect that this statement
> > is 'wrong' by nature).
> > 
> > cons:
> > -----
> > 1- it is much slower (especially at save time) than your swsusp;
> > 2- end users must setup their systems (need to create a suspend partition,
> > or to keep a vfat partition as the really first one (/dev/hda1));
> > 3- we use a bios function.  Actually, everything can happen...
> > 
> > That why I prefer swsusp at this time, or any other implementation of S4 (I
> > think about an implementation of S4 via LKCD).
> 
> Yes I think swsusp is better (long term), but it might be worth it to
> have S4bios, too. At least it has nice graphical task bars :-). Can
> you push the patch, or is it okay for me to try to get it merged?
> 

Ok, ok.  I will try to push the patch.

-- 
Ducrot Bruno
http://www.poupinou.org        Page profaissionelle
http://toto.tu-me-saoules.com  Haume page

Re: [2.5.50, ACPI] link error

[David Ford]

The odd part is that I must enable ACPI and SW SUSPEND to get things to 
compile but then I have to turn around and put acpi=off in my boot 
config because it still hangs my laptop (as well as IDE w/ DMA).

So I find it a bit ironic :)

-d

Jeff Garzik wrote:

> Pavel Machek wrote:
>
>> Yes, there are about 10 patches to fix it floating around... I just
>> hope linus takes one of them. (Fix is make ACPI_SLEEP depend on
>> swsusp).
>
>
>
> I haven't seen the patch, but does it make sense for hardware suspend 
> to depend on software suspend?
>
> IMO there should be a common core (CONFIG_SUSPEND?), not force ACPI to 
> depend on swsusp.  That way you get the _least_ common denominator, 
> not the union of two sets.
>
>     Jeff
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.5.50, ACPI] link error

[Eric Altendorf]

On Thursday 05 December 2002 09:31, Pavel Machek wrote:
> Hi!
>
> > Right ... I'm no kernel hacker so I don't know why, but I can
> > only get the recent kernels to compile with sleep states if I
> > turn *ON* software suspend as well.  However, as soon as I turn
> > on swsusp and get a compiled kernel, it oops'es on boot.
>
> Can you mail me decoded oops?
> 								Pavel

This is the first time I've decoded an oops, and since I had to decode it on a different kernel (2.5.25) than the one I'm debugging (2.5.50 + Dec 6 ACPI patch), and I couldn't get the ksyms file, I used -K ... and because I built w/o modules I used -L and -O.  Let me know if I did it wrong or if you need more info...  Thanks.  (Also I had to transcribe the oops by hand ... I'm pretty sure I got all the values right but I could have missed something)

ksymoops 2.4.4 on i586 2.5.25.  Options used
     -v vmlinux (specified)
     -K (specified)
     -L (specified)
     -O (specified)
     -m System.map (specified)

*pde = 00000000
Oops: 0000
CPU: 0
EIP:  0060:[<c013a6b1>]   Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010246
eax: a55a5a5a  ebx: 00001000  ecx: 00000000  edx: 00000200
esi: c130f628  edi: cedc5000  ebp: c0326e00  esp: c12bdf7c
ds: 0068  es: 0068  ss: 0068
Stack: c130f628 00000000 c0121816 c130f628 00001000 c130d628 00000001 00000000
       00000003 c03f0080 00000000 c03f0045 00000000 c0121937 c0326e00 00000000
       c02c5c9f c0326e00 c01051c4 c02bed13 00000000 00000000 c0105020 00000000
 [<c0121816>] read_suspend_image+0x81/0x107
 [<c0121937>] software_resume+0x9b/0xc0
 [<c01051c4>] prepare_namespace+0x84/0x10c
 [<c0105020>] init+0x0/0x120
 [<c010503f>] init+0x1f/0x120
 [<c0105020>] init+0x0/0x120
 [<c0106ca9>] kernel_thread_helper+0x5/0xb
Code: 8b 40 28 85 c0 74 11 66 83 b8 b6 00 00 00 00 74 07 0f b7 90

>>EIP; c013a6b1 <set_blocksize+26/83>   <=====
Code;  c013a6b1 <set_blocksize+26/83>
00000000 <_EIP>:
Code;  c013a6b1 <set_blocksize+26/83>   <=====
   0:   8b 40 28                  mov    0x28(%eax),%eax   <=====
Code;  c013a6b4 <set_blocksize+29/83>
   3:   85 c0                     test   %eax,%eax
Code;  c013a6b6 <set_blocksize+2b/83>
   5:   74 11                     je     18 <_EIP+0x18> c013a6c9 <set_blocksize+3e/83>
Code;  c013a6b8 <set_blocksize+2d/83>
   7:   66 83 b8 b6 00 00 00      cmpw   $0x0,0xb6(%eax)
Code;  c013a6bf <set_blocksize+34/83>
   e:   00 
Code;  c013a6c0 <set_blocksize+35/83>
   f:   74 07                     je     18 <_EIP+0x18> c013a6c9 <set_blocksize+3e/83>
Code;  c013a6c2 <set_blocksize+37/83>
  11:   0f b7 90 00 00 00 00      movzwl 0x0(%eax),%edx

 <0>Kernel panic: Attempted to kill init!

eric

-- 
"First they ignore you.  Then they laugh at you.
 Then they fight you.  And then you win."             -Gandhi

Re: [2.5.50, ACPI] link error

[Pavel Machek]

Hi!

> > > Right ... I'm no kernel hacker so I don't know why, but I can
> > > only get the recent kernels to compile with sleep states if I
> > > turn *ON* software suspend as well.  However, as soon as I turn
> > > on swsusp and get a compiled kernel, it oops'es on boot.
> >
> > Can you mail me decoded oops?
> > 								Pavel
> 
> This is the first time I've decoded an oops, and since I had to decode it on a different kernel (2.5.25) than the one I'm debugging (2.5.50 + Dec 6 ACPI patch), and I couldn't 
Can you try passing 
"resume=hda5_or_whatever_your_swap_partition_is"?


-- 
				Pavel
Written on sharp zaurus, because my Velo1 broke. If you have Velo you don't need...

Re: [2.5.50, ACPI] link error

[Eric Altendorf]

On Sunday 08 December 2002 23:29, Pavel Machek wrote:
> Hi!
>
> > > > Right ... I'm no kernel hacker so I don't know why, but I can
> > > > only get the recent kernels to compile with sleep states if I
> > > > turn *ON* software suspend as well.  However, as soon as I
> > > > turn on swsusp and get a compiled kernel, it oops'es on boot.
> > >
> > > Can you mail me decoded oops?
> > > 								Pavel
> >
> > This is the first time I've decoded an oops, and since I had to
> > decode it on a different kernel (2.5.25) than the one I'm
> > debugging (2.5.50 + Dec 6 ACPI patch), and I couldn't
>
> Can you try passing
> "resume=hda5_or_whatever_your_swap_partition_is"?

Well, I've had "resume=/dev/hda6" in there the whole time (same as it 
was on prior kernels that booted).  I tried passing "resume=hda6" 
instead just for kicks and got the same result, though...  (This is 
still on the 2.5.50 + Dec6ACPI kernel)

Thanks,

Eric
-- 
"First they ignore you.  Then they laugh at you.
 Then they fight you.  And then you win."             -Gandhi

Re: [2.5.50, ACPI] link error

[Pavel Machek]

Hi!
> >
> > > > > Right ... I'm no kernel hacker so I don't know why, but I can
> > > > > only get the recent kernels to compile with sleep states if I
> > > > > turn *ON* software suspend as well.  However, as soon as I
> > > > > turn on swsusp and get a compiled kernel, it oops'es on boot.
> > > >
> > > > Can you mail me decoded oops?
> > > > 								Pavel
> > >
> > > This is the first time I've decoded an oops, and since I had to
> > > decode it on a different kernel (2.5.25) than the one I'm
> > > debugging (2.5.50 + Dec 6 ACPI patch), and I couldn't
> >
> > Can you try passing
> > "resume=hda5_or_whatever_your_swap_partition_is"?
> 
> Well, I've had "resume=/dev/hda6" in there the whole time (same as it 
> was on prior kernels that booted).  I tried passing "resume=hda6" 
> instead just for kicks and got the same result, though...  (This is 
> still on the 2.5.50 + Dec6ACPI kernel)

Strange... Can you report if it is still broken with 2.5.51?

								Pavel
-- 
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.

Re: [2.5.50, ACPI] link error

[Pavel Machek]

Hi!

> When compiling 2.5.50 with CONFIG_ACPI_SLEEP=y

Enable SWSUSP... Then investigate why it is possible to select
ACPI_SLEEP but not SWSUSP...
							Pavel

-- 
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?

Re: [2.5.50, ACPI] link error

[Adrian Bunk]

On Wed, Dec 04, 2002 at 12:41:19PM +0100, Pavel Machek wrote:

> Hi!

Hi Pavel!

> > When compiling 2.5.50 with CONFIG_ACPI_SLEEP=y
> 
> Enable SWSUSP... Then investigate why it is possible to select
> ACPI_SLEEP but not SWSUSP...

In drivers/acpi/Config.in in 2.5.44:

<--   snip  -->

...
if [ "$CONFIG_ACPI_HT_ONLY" != "y" ]; then
   bool     '  Sleep States' CONFIG_ACPI_SLEEP
...
   define_bool CONFIG_ACPI_SLEEP $CONFIG_SOFTWARE_SUSPEND
...
fi
...

<--  snip  -->


This double definition was at least confusing, a simple

  dep_bool '  Sleep States' CONFIG_ACPI_SLEEP $CONFIG_SOFTWARE_SUSPEND

would have expressed it better.


The transition to the new kconfig converted this confusing Config.in 
snipped to the following code in drivers/acpi/Kconfig:

<--  snip  -->

...
config ACPI_SLEEP
        bool "Sleep States"
        depends on X86 && ACPI && !ACPI_HT_ONLY
        default SOFTWARE_SUSPEND
...

<--  snip  -->


The following patch makes it work the way it was intended:

--- linux-2.5.50/drivers/acpi/Kconfig.old	2002-12-04 14:24:14.000000000 +0100
+++ linux-2.5.50/drivers/acpi/Kconfig	2002-12-04 14:27:17.000000000 +0100
@@ -58,7 +58,7 @@
 
 config ACPI_SLEEP
 	bool "Sleep States"
-	depends on X86 && ACPI && !ACPI_HT_ONLY
+	depends on X86 && ACPI && !ACPI_HT_ONLY && SOFTWARE_SUSPEND
 	default SOFTWARE_SUSPEND
 	---help---
 	  This option adds support for ACPI suspend states. 


Another thing that seems to be suboptimal is that the question for 
SOFTWARE_SUSPEND comes _after_ the question for ACPI_SLEEP, IOW someone 
doing a "make config" to configure his kernel doesn't have a chance to 
select ACPI_SLEEP. To fix this (and it seems to be logical) the 
SOFTWARE_SUSPEND question should be moved to the "Power management 
options" menu. The patch below tries to solve this and it makes ACPI 
dependant on PM as the comments in PM indicate:
- move "Software Suspend" to the "Power management options" menu above
  the ACPI entry
- let ACPI depend on PM

Any comments on this patch?

> 							Pavel

cu
Adrian


--- linux-2.5.50/arch/i386/Kconfig.old	2002-12-04 14:47:03.000000000 +0100
+++ linux-2.5.50/arch/i386/Kconfig	2002-12-04 14:43:48.000000000 +0100
@@ -789,8 +789,6 @@
 
 menu "Power management options (ACPI, APM)"
 
-source "drivers/acpi/Kconfig"
-
 config PM
 	bool "Power Management support"
 	---help---
@@ -811,6 +809,37 @@
 	  will issue the hlt instruction if nothing is to be done, thereby
 	  sending the processor to sleep and saving power.
 
+config SOFTWARE_SUSPEND
+        bool "Software Suspend (EXPERIMENTAL)"
+        depends on EXPERIMENTAL && PM
+        ---help---
+          Enable the possibilty of suspendig machine. It doesn't need APM.
+          You may suspend your machine by 'swsusp' or 'shutdown -z <time>'
+          (patch for sysvinit needed).
+
+          It creates an image which is saved in your active swaps. By the next
+          booting the, pass 'resume=/path/to/your/swap/file' and kernel will
+          detect the saved image, restore the memory from
+          it and then it continues to run as before you've suspended.
+          If you don't want the previous state to continue use the 'noresume'
+          kernel option. However note that your partitions will be fsck'd and
+          you must re-mkswap your swap partitions/files.
+
+          Right now you may boot without resuming and then later resume but
+          in meantime you cannot use those swap partitions/files which were
+          involved in suspending. Also in this case there is a risk that buffers
+          on disk won't match with saved ones.
+
+          SMP is supported ``as-is''. There's a code for it but doesn't work.
+          There have been problems reported relating SCSI.
+
+          This option is about getting stable. However there is still some
+          absence of features.
+
+          For more information take a look at Documentation/swsusp.txt.
+
+source "drivers/acpi/Kconfig"
+
 config APM
 	tristate "Advanced Power Management BIOS support"
 	depends on PM
@@ -1516,35 +1545,6 @@
 
 menu "Kernel hacking"
 
-config SOFTWARE_SUSPEND
-	bool "Software Suspend (EXPERIMENTAL)"
-	depends on EXPERIMENTAL && PM
-	---help---
-	  Enable the possibilty of suspendig machine. It doesn't need APM.
-	  You may suspend your machine by 'swsusp' or 'shutdown -z <time>' 
-	  (patch for sysvinit needed). 
-
-	  It creates an image which is saved in your active swaps. By the next
-	  booting the, pass 'resume=/path/to/your/swap/file' and kernel will 
-	  detect the saved image, restore the memory from
-	  it and then it continues to run as before you've suspended.
-	  If you don't want the previous state to continue use the 'noresume'
-	  kernel option. However note that your partitions will be fsck'd and
-	  you must re-mkswap your swap partitions/files.
-
-	  Right now you may boot without resuming and then later resume but
-	  in meantime you cannot use those swap partitions/files which were
-	  involved in suspending. Also in this case there is a risk that buffers
-	  on disk won't match with saved ones.
-
-	  SMP is supported ``as-is''. There's a code for it but doesn't work.
-	  There have been problems reported relating SCSI.
-
-	  This option is about getting stable. However there is still some
-	  absence of features.
-
-	  For more information take a look at Documentation/swsusp.txt.
-
 config DEBUG_KERNEL
 	bool "Kernel debugging"
 	help
--- linux-2.5.50/drivers/acpi/Kconfig.old	2002-12-04 14:39:24.000000000 +0100
+++ linux-2.5.50/drivers/acpi/Kconfig	2002-12-04 14:42:57.000000000 +0100
@@ -3,6 +3,7 @@
 #
 
 menu "ACPI Support"
+	depends on PM
 
 config ACPI
 	bool "ACPI Support" if X86

Re: [2.5.50, ACPI] link error

[Jochen Hein]

Adrian Bunk <bunk@fs.tum.de> writes:

> Any comments on this patch?

Both look reasonable to me.  "make config" works as intended.  I'll
try compiling them now.  Thanks.

Jochen

-- 
Wenn Du nicht weißt was Du tust, tu's mit Eleganz.

Re: [2.5.50, ACPI] link error

[Roman Zippel]

Hi,

On Wed, 4 Dec 2002, Adrian Bunk wrote:

> In drivers/acpi/Config.in in 2.5.44:
> 
> <--   snip  -->
> 
> ...
> if [ "$CONFIG_ACPI_HT_ONLY" != "y" ]; then
>    bool     '  Sleep States' CONFIG_ACPI_SLEEP
> ...
>    define_bool CONFIG_ACPI_SLEEP $CONFIG_SOFTWARE_SUSPEND
> ...
> fi
> ...
> 
> <--  snip  -->
> 
> 
> This double definition was at least confusing, a simple
> 
>   dep_bool '  Sleep States' CONFIG_ACPI_SLEEP $CONFIG_SOFTWARE_SUSPEND
> 
> would have expressed it better.

It's not really the same and the first probably heavily confuses xconfig.
If CONFIG_SOFTWARE_SUSPEND can do without CONFIG_ACPI_SLEEP, the second 
version should work fine.

>  config ACPI_SLEEP
>  	bool "Sleep States"
> -	depends on X86 && ACPI && !ACPI_HT_ONLY
> +	depends on X86 && ACPI && !ACPI_HT_ONLY && SOFTWARE_SUSPEND
>  	default SOFTWARE_SUSPEND
>  	---help---
>  	  This option adds support for ACPI suspend states. 

The default is probably not needed anymore.

> Another thing that seems to be suboptimal is that the question for 
> SOFTWARE_SUSPEND comes _after_ the question for ACPI_SLEEP, IOW someone 
> doing a "make config" to configure his kernel doesn't have a chance to 
> select ACPI_SLEEP.

That was only true with the old "make config". :)

> To fix this (and it seems to be logical) the 
> SOFTWARE_SUSPEND question should be moved to the "Power management 
> options" menu. The patch below tries to solve this and it makes ACPI 
> dependant on PM as the comments in PM indicate:
> - move "Software Suspend" to the "Power management options" menu above
>   the ACPI entry
> - let ACPI depend on PM

Is ACPI really only a PM thingie?

Anyway, I had a cleaned up drivers/acpi/Kconfig lying around. The ACPI 
config file was not really easy to convert automatically. I integrated 
your change from above, it would be nice if some could check if every 
still works as it should.

bye, Roman

--- linux/drivers/acpi/Kconfig	31 Oct 2002 13:26:48 -0000	1.1.1.1
+++ linux/drivers/acpi/Kconfig	4 Dec 2002 20:12:43 -0000
@@ -35,9 +35,11 @@ config ACPI
 	  available at:
 	  <http://www.acpi.info>
 
+if ACPI
+
 config ACPI_HT_ONLY
 	bool "CPU Enumeration Only"
-	depends on X86 && ACPI && X86_LOCAL_APIC
+	depends on X86_LOCAL_APIC
 	---help---
 	  This option enables limited ACPI support -- just enough to 
 	  enumerate processors from the ACPI Multiple APIC Description 
@@ -51,15 +53,12 @@ config ACPI_HT_ONLY
 	  There is no command-line option to disable this, but the kernel
 	  will fall back to the MPS table if the MADT is not present.
 
-config ACPI_BOOT
-	bool
-	depends on IA64 && (!IA64_HP_SIM || IA64_SGI_SN) || X86 && ACPI && !ACPI_HT_ONLY || X86 && ACPI
-	default y
+
+if X86 && !ACPI_HT_ONLY || IA64 && !IA64_HP_SIM
 
 config ACPI_SLEEP
 	bool "Sleep States"
-	depends on X86 && ACPI && !ACPI_HT_ONLY
-	default SOFTWARE_SUSPEND
+	depends on X86 && SOFTWARE_SUSPEND
 	---help---
 	  This option adds support for ACPI suspend states. 
 
@@ -78,7 +77,7 @@ config ACPI_SLEEP
 
 config ACPI_AC
 	tristate "AC Adapter"
-	depends on X86 && ACPI && !ACPI_HT_ONLY
+	depends on X86
 	help
 	  This driver adds support for the AC Adapter object, which indicates
 	  whether a system is on AC, or not.  Typically, only mobile systems 
@@ -86,7 +85,7 @@ config ACPI_AC
 
 config ACPI_BATTERY
 	tristate "Battery"
-	depends on X86 && ACPI && !ACPI_HT_ONLY
+	depends on X86
 	help
 	  This driver adds support for battery information through
 	  /proc/acpi/battery. If you have a mobile system with a battery, 
@@ -94,7 +93,6 @@ config ACPI_BATTERY
 
 config ACPI_BUTTON
 	tristate "Button"
-	depends on IA64 && !IA64_HP_SIM || X86 && ACPI && !ACPI_HT_ONLY
 	help
 	  This driver registers for events based on buttons, such as the
 	  power, sleep, and lid switch.  In the future, a daemon will read
@@ -104,14 +102,12 @@ config ACPI_BUTTON
 
 config ACPI_FAN
 	tristate "Fan"
-	depends on IA64 && !IA64_HP_SIM || X86 && ACPI && !ACPI_HT_ONLY
 	help
 	  This driver adds support for ACPI fan devices, allowing user-mode 
 	  applications to perform basic fan control (on, off, status).
 
 config ACPI_PROCESSOR
 	tristate "Processor"
-	depends on IA64 && !IA64_HP_SIM || X86 && ACPI && !ACPI_HT_ONLY
 	help
 	  This driver installs ACPI as the idle handler for Linux, and uses
 	  ACPI C2 and C3 processor states to save power, on systems that
@@ -119,7 +115,7 @@ config ACPI_PROCESSOR
 
 config ACPI_PROCESSOR_PERF
 	bool "Processor Performance States"
-	depends on X86 && ACPI && !ACPI_HT_ONLY && ACPI_PROCESSOR && CPU_FREQ
+	depends on X86 && ACPI_PROCESSOR && CPU_FREQ
 	help
 	  This driver adds support for CPU frequency scaling, if this is supported
 	  by the hardware and the BIOS. If you are compiling for a mobile system,
@@ -135,12 +131,12 @@ config ACPI_THERMAL
 	  may be damaged without it.
 
 config ACPI_NUMA
-	bool "NUMA support" if NUMA && (IA64 && !IA64_HP_SIM || X86 && ACPI && !ACPI_HT_ONLY)
-	default y if IA64 && IA64_SGI_SN
+	bool "NUMA support"
+	depends on NUMA
 
 config ACPI_TOSHIBA
 	tristate "Toshiba Laptop Extras"
-	depends on X86 && ACPI && !ACPI_HT_ONLY
+	depends on X86
 	---help---
 	  This driver adds support for access to certain system settings
 	  on "legacy free" Toshiba laptops.  These laptops can be recognized by
@@ -166,7 +162,6 @@ config ACPI_TOSHIBA
 
 config ACPI_DEBUG
 	bool "Debug Statements"
-	depends on IA64 && !IA64_HP_SIM || X86 && ACPI && !ACPI_HT_ONLY
 	help
 	  The ACPI driver can optionally report errors with a great deal
 	  of verbosity. Saying Y enables these statements. This will increase
@@ -174,17 +169,15 @@ config ACPI_DEBUG
 
 config ACPI_BUS
 	bool
-	depends on IA64 && !IA64_HP_SIM || X86 && ACPI && !ACPI_HT_ONLY
 	default y
 
 config ACPI_INTERPRETER
 	bool
-	depends on IA64 && !IA64_HP_SIM || X86 && ACPI && !ACPI_HT_ONLY
 	default y
 
 config ACPI_EC
 	bool
-	depends on X86 && ACPI && !ACPI_HT_ONLY
+	depends on X86
 	default y
 	help
 	  This driver is required on some systems for the proper operation of
@@ -193,26 +186,35 @@ config ACPI_EC
 
 config ACPI_POWER
 	bool
-	depends on IA64 && !IA64_HP_SIM || X86 && ACPI && !ACPI_HT_ONLY
 	default y
 
 config ACPI_PCI
 	bool
-	depends on IA64 && !IA64_HP_SIM || X86 && ACPI && !ACPI_HT_ONLY
 	default PCI
 
 config ACPI_SYSTEM
 	bool
-	depends on IA64 && !IA64_HP_SIM || X86 && ACPI && !ACPI_HT_ONLY
 	default y
 	help
 	  This driver will enable your system to shut down using ACPI, and
 	  dump your ACPI DSDT table using /proc/acpi/dsdt.
 
+endif
+
+config ACPI_NUMA
+	depends IA64 && IA64_SGI_SN
+	default y
+
 config ACPI_EFI
 	bool
 	depends on IA64 && (!IA64_HP_SIM || IA64_SGI_SN)
 	default y
+
+config ACPI_BOOT
+	bool
+	default y
+
+endif
 
 endmenu
 

RE: [ACPI] Re: [2.5.50, ACPI] link error

[Grover, Andrew]

> From: Ducrot Bruno [mailto:poup@poupinou.org] 

> > I think that s4bios is nice to have. Its similar to S3 and easier to
> > set up than swsusp... It would be nice to have it.
> 
> for me:
> pros:
> -----
> 1- it is really really more easier to implement than S4;
> 2- we can even have it with 2.4 kernels (it seems that it work without
> the need of freezing processes, but I suspect that this statement
> is 'wrong' by nature).
> 
> cons:
> -----
> 1- it is much slower (especially at save time) than your swsusp;
> 2- end users must setup their systems (need to create a 
> suspend partition,
> or to keep a vfat partition as the really first one (/dev/hda1));
> 3- we use a bios function.  Actually, everything can happen...
> 
> That why I prefer swsusp at this time, or any other 
> implementation of S4 (I
> think about an implementation of S4 via LKCD).

I concur with your pros and cons. This makes me think that if S4BIOS support
ever gets added, it should get added to 2.4 only.

Regards -- Andy

RE: [ACPI] Re: [2.5.50, ACPI] link error

[Alan Cox]

On Mon, 2002-12-09 at 19:12, Grover, Andrew wrote:
> I concur with your pros and cons. This makes me think that if S4BIOS support
> ever gets added, it should get added to 2.4 only.

That assumes no box exists where S4bios works an S4 doesnt (eg due to
bad tables or "knowing" what other-os does)

Re: [ACPI] Re: [2.5.50, ACPI] link error

[Pavel Machek]

Hi!

> > I concur with your pros and cons. This makes me think that if S4BIOS support
> > ever gets added, it should get added to 2.4 only.

And S4BIOS will never get added to 2.4 since it needs driver model
:-(.

> That assumes no box exists where S4bios works an S4 doesnt (eg due to
> bad tables or "knowing" what other-os does)

We have full control over S4 (== swsusp), so we can fix that in most
cases.

S4BIOS is still little friendlier to the user -- no need to set up
swap partition and command line parameter, can't go wrong if you boot
without resume=, etc.
								Pavel

-- 
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.

Re: [ACPI] Re: [2.5.50, ACPI] link error

[Andrew McGregor]

I strongly suspect that s4bios will work on this machine, but swsusp won't. 
Why?  It's a Dell Inspiron 8000 with an NVidia Geforce2go, and until NVidia 
put pm support in their driver, it's game over for Linux.  Except that the 
BIOS knows how to suspend it, so some kernel/driver combinations work with 
APM.  I suspect any Geforce2go Dell is the same.

Andrew

--On Tuesday, December 10, 2002 21:40:31 +0100 Pavel Machek <pavel@suse.cz> 
wrote:

> Hi!
>
>> > I concur with your pros and cons. This makes me think that if S4BIOS
>> > support ever gets added, it should get added to 2.4 only.
>
> And S4BIOS will never get added to 2.4 since it needs driver model
> :-(.
>
>> That assumes no box exists where S4bios works an S4 doesnt (eg due to
>> bad tables or "knowing" what other-os does)
>
> We have full control over S4 (== swsusp), so we can fix that in most
> cases.
>
> S4BIOS is still little friendlier to the user -- no need to set up
> swap partition and command line parameter, can't go wrong if you boot
> without resume=, etc.
> 								Pavel
>
> --
> Casualities in World Trade Center: ~3k dead inside the building,
> cryptography in U.S.A. and free speech in Czech Republic.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
>

Re: [ACPI] Re: [2.5.50, ACPI] link error

[Ducrot Bruno]

On Wed, Dec 11, 2002 at 09:50:48AM +1300, Andrew McGregor wrote:
> I strongly suspect that s4bios will work on this machine, but swsusp won't. 
> Why?  It's a Dell Inspiron 8000 with an NVidia Geforce2go, and until NVidia 
> put pm support in their driver, it's game over for Linux.  Except that the 
> BIOS knows how to suspend it, so some kernel/driver combinations work with 
> APM.  I suspect any Geforce2go Dell is the same.

No.  You are wrong.  I need to suspend allmost all the drivers, and the
video chipset is not an execption (or go to a console before suspending,
in fact).
You still need to bug NVIDIA in order to have proper pm support
in their driver.

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.

Re: [ACPI] Re: [2.5.50, ACPI] link error

[Alan Cox]

On Wed, 2002-12-11 at 10:14, Ducrot Bruno wrote:
> No.  You are wrong.  I need to suspend allmost all the drivers, and the
> video chipset is not an execption (or go to a console before suspending,
> in fact).
> You still need to bug NVIDIA in order to have proper pm support
> in their driver.

To an extent. However you can also switch back to text mode on suspend
to disk, then resume back into text mode and effectively switch back
into X11

Re: [ACPI] Re: [2.5.50, ACPI] link error

[Ducrot Bruno]

On Tue, Dec 10, 2002 at 09:40:31PM +0100, Pavel Machek wrote:
> Hi!
> 
> > > I concur with your pros and cons. This makes me think that if S4BIOS support
> > > ever gets added, it should get added to 2.4 only.
> 
> And S4BIOS will never get added to 2.4 since it needs driver model
> :-(.

Well, it worked for me with 2.4 with 'basic' pm_send_xxx

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.