2.5.45 build failed with ACPI turned on

2.5.45 build failed with ACPI turned on

[Robert Varga]

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

Hi

Build fails with:

drivers/acpi/sleep.c: In function `acpi_system_suspend':
drivers/acpi/sleep.c:209: warning: implicit declaration of function `do_suspend_lowlevel'
drivers/acpi/sleep.c: In function `acpi_sleep_init':
drivers/acpi/sleep.c:707: `sysrq_acpi_poweroff_op' undeclared (first use in this function)
drivers/acpi/sleep.c:707: (Each undeclared identifier is reported only once
drivers/acpi/sleep.c:707: for each function it appears in.)

The structure declaration is protected by

#if defined(CONFIG_MAGIC_SYSRQ) && defined(CONFIG_PM)

on line 640.

Config file attached.

-- 
Kind regards,
Robert Varga
------------------------------------------------------------------------------
n@hq.sk                                          http://hq.sk/~nite/gpgkey.txt

[-- Attachment #2: config.gz --]
[-- Type: application/octet-stream, Size: 4296 bytes --]

Re: 2.5.45 build failed with ACPI turned on

[Jos Hulzink]

On Thursday 31 October 2002 20:45, Robert Varga wrote:
> The structure declaration is protected by
>
> #if defined(CONFIG_MAGIC_SYSRQ) && defined(CONFIG_PM)
>
> on line 640.

At the moment CONFIG_PM seems to be enabling APM, though it clearly does more than that. I think the config options for ACPI and APM should be sorted out sooner or later. Just enable Power Management and this should compile.

Jos

Re: 2.5.45 build failed with ACPI turned on

[Jos Hulzink]

After some more puzzling, it becomes clear that much more ACPI code should rely on CONFIG_PM. (Sleep.c should not be compiled in at all without CONFIG_PM) As the ACPI guys seem awake, I assume this will be fixed soon. For now: don't forget to enable CONFIG_PM (Power Management in the root of ACPI / APM configuration)

Jos

On Thursday 31 October 2002 20:45, Robert Varga wrote:
> Hi
>
> Build fails with:
>
> drivers/acpi/sleep.c: In function `acpi_system_suspend':
> drivers/acpi/sleep.c:209: warning: implicit declaration of function
> `do_suspend_lowlevel' drivers/acpi/sleep.c: In function `acpi_sleep_init':
> drivers/acpi/sleep.c:707: `sysrq_acpi_poweroff_op' undeclared (first use in
> this function) drivers/acpi/sleep.c:707: (Each undeclared identifier is
> reported only once drivers/acpi/sleep.c:707: for each function it appears
> in.)
>
> The structure declaration is protected by
>
> #if defined(CONFIG_MAGIC_SYSRQ) && defined(CONFIG_PM)
>
> on line 640.
>
> Config file attached.

RE: 2.5.45 build failed with ACPI turned on

[Grover, Andrew]

> From: Jos Hulzink [mailto:josh@stack.nl] 
> After some more puzzling, it becomes clear that much more 
> ACPI code should rely on CONFIG_PM. (Sleep.c should not be 
> compiled in at all without CONFIG_PM) As the ACPI guys seem 
> awake, I assume this will be fixed soon. For now: don't 
> forget to enable CONFIG_PM (Power Management in the root of 
> ACPI / APM configuration)

ACPI implements PM but that's not all it implements. Is making CONFIG_PM
true if ACPI or APM are on a viable option? I think that would more
accurately reflect reality.

Or can we get rid of CONFIG_PM?

Regards -- Andy

Re: 2.5.45 build failed with ACPI turned on

[Dave Jones]

On Fri, Nov 01, 2002 at 11:37:26AM -0800, Grover, Andrew wrote:
 > ACPI implements PM but that's not all it implements. Is making CONFIG_PM
 > true if ACPI or APM are on a viable option? I think that would more
 > accurately reflect reality.
 > 
 > Or can we get rid of CONFIG_PM?

I'm not sure of places that do it off the top of my head, but
CONFIG_PM would save us having to do ugly CONFIG_APM || CONFIG_ACPI
tests.

		Dave

-- 
| Dave Jones.        http://www.codemonkey.org.uk

Re: 2.5.45 build failed with ACPI turned on

[Dave Jones]

On Fri, Nov 01, 2002 at 10:21:56PM +0100, Jos Hulzink wrote:
 > Other issue: Are ACPI and APM not mutually exclusive ? If so, I would propose 
 > a selection box: <ACPI> <APM> <none> with related options shown below. Hmzz.. 
 > there the issue of the fact that ACPI is more than power management shows up 
 > again.

Whilst they can't both run at the same time, it's perfectly possible
(and useful) to build a kernel with both included. ACPI will quit
if APM is already running, so booting with apm=off turns the same
kernel into 'ACPI mode'

Quite useful for me right now, as currently my Vaio won't boot
an ACPI kernel if its on mains power for some reason. 8-)

		Dave

-- 
| Dave Jones.        http://www.codemonkey.org.uk

Re: 2.5.45 build failed with ACPI turned on

[Jos Hulzink]

On Friday 01 November 2002 20:47, Dave Jones wrote:
> On Fri, Nov 01, 2002 at 11:37:26AM -0800, Grover, Andrew wrote:
>  > ACPI implements PM but that's not all it implements. Is making CONFIG_PM
>  > true if ACPI or APM are on a viable option? I think that would more
>  > accurately reflect reality.
>  >
>  > Or can we get rid of CONFIG_PM?
>
> I'm not sure of places that do it off the top of my head, but
> CONFIG_PM would save us having to do ugly CONFIG_APM || CONFIG_ACPI
> tests.

This seems to be true from what I have seen of the source so far.

I'm thinking....

ACPI is more than Power Management. The fact that a system supports ACPI does 
not mean that the user wants to use power management. On the other hand, I 
see no reason why a user does NOT want a system to auto poweroff, and sleep 
and suspend are easy to configure in BIOS, or by linux tools. (Does Linux 
take over the BIOS settings for suspend & sleep ? Don't use them, so 
donnow....) What I wanna say: I think it is okay if CONFIG_PM is replaced by 
CONFIG_APM || CONFIG_ACPI

Other issue: Are ACPI and APM not mutually exclusive ? If so, I would propose 
a selection box: <ACPI> <APM> <none> with related options shown below. Hmzz.. 
there the issue of the fact that ACPI is more than power management shows up 
again.

And well... CONFIG_APM || CONFIG_ACPI might look ugly to you, I think it isn't 
that bad, besides, you gain a lot from the configuration side. IMHO 
configuring the kernel has become hard enough with the new input layer 
already :( Maybe it is time for a "[ ] show expert options" in the 
configuration tool... 

Jos

Re: 2.5.45 build failed with ACPI turned on

[Jos Hulzink]

On Friday 01 November 2002 21:31, Dave Jones wrote:
> On Fri, Nov 01, 2002 at 10:21:56PM +0100, Jos Hulzink wrote:
>  > Other issue: Are ACPI and APM not mutually exclusive ? If so, I would
>  > propose a selection box: <ACPI> <APM> <none> with related options shown
>  > below. Hmzz.. there the issue of the fact that ACPI is more than power
>  > management shows up again.
>
> Whilst they can't both run at the same time, it's perfectly possible
> (and useful) to build a kernel with both included. ACPI will quit
> if APM is already running, so booting with apm=off turns the same
> kernel into 'ACPI mode'

Hmzz.. in that case I vote for dropping CONFIG_PM in favour of CONFIG_APM || CONFIG_ACPI, even though it requires some more typing for the programmers. (I'm no ACPI programmer, so I don't care ;-)

Jos

Re: 2.5.45 build failed with ACPI turned on

[Bill Davidsen]

On Sat, 2 Nov 2002, Jos Hulzink wrote:

> On Friday 01 November 2002 21:31, Dave Jones wrote:
> > On Fri, Nov 01, 2002 at 10:21:56PM +0100, Jos Hulzink wrote:
> >  > Other issue: Are ACPI and APM not mutually exclusive ? If so, I would
> >  > propose a selection box: <ACPI> <APM> <none> with related options shown
> >  > below. Hmzz.. there the issue of the fact that ACPI is more than power
> >  > management shows up again.
> >
> > Whilst they can't both run at the same time, it's perfectly possible
> > (and useful) to build a kernel with both included. ACPI will quit
> > if APM is already running, so booting with apm=off turns the same
> > kernel into 'ACPI mode'
 
> Hmzz.. in that case I vote for dropping CONFIG_PM in favour of
> CONFIG_APM || CONFIG_ACPI, even though it requires some more typing for
> the programmers. (I'm no ACPI programmer, so I don't care ;-) 

More to the point, define CONFIG_PM as ( CONFIG_APM | CONFIG_ACPI ) and be
able to easily handle any new PM method on whatever hardware. PM is not
limited to Intel hardware. Make a new HAS_PM if reusing CONFIG_PM creates
problems.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: 2.5.45 build failed with ACPI turned on

[David Woodhouse]

davidsen@tmr.com said:
>  More to the point, define CONFIG_PM as ( CONFIG_APM | CONFIG_ACPI )
> and be able to easily handle any new PM method on whatever hardware.
> PM is not limited to Intel hardware. Make a new HAS_PM if reusing
> CONFIG_PM creates problems.

Er, there's no reason why PM even on Intel hardware should be restricted to
ACPI and APM. With appropriate chipset documentation there's nothing to stop
people from writing proper driver code to enter sleep states, etc. for i386 
chipsets just as we have for other architectures.

--
dwmw2

Re: 2.5.45 build failed with ACPI turned on

[Bill Davidsen]

On Wed, 6 Nov 2002, David Woodhouse wrote:

> 
> davidsen@tmr.com said:
> >  More to the point, define CONFIG_PM as ( CONFIG_APM | CONFIG_ACPI )
> > and be able to easily handle any new PM method on whatever hardware.
> > PM is not limited to Intel hardware. Make a new HAS_PM if reusing
> > CONFIG_PM creates problems.

Isn't this what I said?
> 
> Er, there's no reason why PM even on Intel hardware should be restricted to
> ACPI and APM.

That's what I proposed. Define CONFIG_PM as what we have now, or define a
new HAS_PM define to indicate that PM is present in some form, and be able
to add other schemes when/if they happen ("easily handle any new PM
method").
Ex:
 #define HAS_PM ( CONFIG_ACPI | CONFIG_APM | CONFIG_IMTU )
One master symbol to indicate that PM is present in any form.

>           With appropriate chipset documentation there's nothing to stop
> people from writing proper driver code to enter sleep states, etc. for i386 
> chipsets just as we have for other architectures.

Which could be handled by HAS_PM_SLEEP, HAS_PM_SUSPEND, HAS_PM_POWEROFF
and the like, if that seems desirable.

I can't see this being totally non-messy, but the config could probably be
clever and grey out anything which can't be done at all for the hardware
selected.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.