Re: 2.6.12-rc1-mm3

Re: 2.6.12-rc1-mm3

[Jason Uhlenkott]

On Fri, Mar 25, 2005 at 12:21:54AM -0800, Andrew Morton wrote:
>  bk-acpi.patch

This doesn't build for SGI sn2:

arch/ia64/kernel/mca.c: In function `ia64_mca_init':
arch/ia64/kernel/mca.c:1394: error: `ACPI_INTERRUPT_CPEI' undeclared (first use in this function)
arch/ia64/kernel/mca.c:1394: error: (Each undeclared identifier is reported only once
arch/ia64/kernel/mca.c:1394: error: for each function it appears in.)
make[1]: *** [arch/ia64/kernel/mca.o] Error 1
make: *** [arch/ia64/kernel] Error 2

This is because we lost CONFIG_ACPI_BOOT -- it now depends on
CONFIG_PM, which we don't have (or want) on sn2.  The following fixes
it, but I'm not sure what the original rationale was.  Len?

Signed-off-by: Jason Uhlenkott <jasonuhl@sgi.com>

Index: linux/drivers/acpi/Kconfig
===================================================================
--- linux.orig/drivers/acpi/Kconfig	2005-03-25 12:22:57.909667494 -0800
+++ linux/drivers/acpi/Kconfig	2005-03-25 16:28:35.793588269 -0800
@@ -3,7 +3,6 @@
 #
 
 menu "ACPI (Advanced Configuration and Power Interface) Support"
-	depends on PM
 	depends on !X86_VISWS
 	depends on !IA64_HP_SIM
 	depends on IA64 || X86

Re: Re: 2.6.12-rc1-mm3

[Len Brown]

On Fri, 2005-03-25 at 20:43, Jason Uhlenkott wrote:
> On Fri, Mar 25, 2005 at 12:21:54AM -0800, Andrew Morton wrote:
> >  bk-acpi.patch
> 
> This doesn't build for SGI sn2:
> 
> arch/ia64/kernel/mca.c: In function `ia64_mca_init':
> arch/ia64/kernel/mca.c:1394: error: `ACPI_INTERRUPT_CPEI' undeclared
> (first use in this function)
> arch/ia64/kernel/mca.c:1394: error: (Each undeclared identifier is
> reported only once
> arch/ia64/kernel/mca.c:1394: error: for each function it appears in.)
> make[1]: *** [arch/ia64/kernel/mca.o] Error 1
> make: *** [arch/ia64/kernel] Error 2
> 
> This is because we lost CONFIG_ACPI_BOOT -- it now depends on
> CONFIG_PM, which we don't have (or want) on sn2.  The following fixes
> it, but I'm not sure what the original rationale was.  Len?
> 
> Signed-off-by: Jason Uhlenkott <jasonuhl-sJ/iWh9BUns@public.gmane.org>
> 

Please send me the .config you'd like to build.
I believe that what we want to do is include CONFIG_PM.
Note also that CONFIG_ACPI_BOOT will be going away --
to be replaced simply by CONFIG_ACPI.

thanks,
-Len




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: [ACPI] Re: 2.6.12-rc1-mm3

[Jason Uhlenkott]

On Fri, Mar 25, 2005 at 08:56:58PM -0500, Len Brown wrote:
> Please send me the .config you'd like to build.

arch/ia64/configs/sn2_defconfig

> I believe that what we want to do is include CONFIG_PM.

At first glance, it looks like that will enable suspend/resume
functionality (which I don't think we want on SGI sn2) for a bunch of
drivers.

Re: Re: 2.6.12-rc1-mm3

[Len Brown]

On Fri, 2005-03-25 at 21:02, Jason Uhlenkott wrote:
> On Fri, Mar 25, 2005 at 08:56:58PM -0500, Len Brown wrote:
> > Please send me the .config you'd like to build.
> 
> arch/ia64/configs/sn2_defconfig


> > I believe that what we want to do is include CONFIG_PM.
> 
> At first glance, it looks like that will enable suspend/resume
> functionality (which I don't think we want on SGI sn2) for a bunch of
> drivers.

What bad things happen if you define CONFIG_PM on SN2?

Re: CONFIG_ACPI_BOOT
I've got a patch that makes it go away -- this looks like
a good reason for me to dust it off...  Looks like
arch/ia64/Kconfig defines ACPI and then pulls in drivers/acpi/Kconfig,
which it should not do - it should look like i386/Kconfig...

-Len



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: [ACPI] Re: 2.6.12-rc1-mm3

[Jason Uhlenkott]

On Fri, Mar 25, 2005 at 09:24:21PM -0500, Len Brown wrote:
> What bad things happen if you define CONFIG_PM on SN2?

None, other than slightly enlarging the kernel with some
suspend/resume stuff we don't care about.  It's always been
unavailable for SN2 builds:

depends on IA64_GENERIC || IA64_DIG || IA64_HP_ZX1 || IA64_HP_ZX1_SWIOTLB

but there doesn't appear to be any particular reason for that other
than us not needing it (and in fact SN2 systems can run IA64_GENERIC
kernels with CONFIG_PM enabled without incident).

> Re: CONFIG_ACPI_BOOT
> I've got a patch that makes it go away -- this looks like
> a good reason for me to dust it off...  Looks like
> arch/ia64/Kconfig defines ACPI and then pulls in drivers/acpi/Kconfig,
> which it should not do - it should look like i386/Kconfig...

Sounds good to me.  Does that mean everything currently controlled by
CONFIG_ACPI_BOOT will be controlled by CONFIG_ACPI instead?

Re: Re: 2.6.12-rc1-mm3

[Jesse Barnes]

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

On Friday, March 25, 2005 6:57 pm, Jason Uhlenkott wrote:
> On Fri, Mar 25, 2005 at 09:24:21PM -0500, Len Brown wrote:
> > What bad things happen if you define CONFIG_PM on SN2?
>
> None, other than slightly enlarging the kernel with some
> suspend/resume stuff we don't care about.  It's always been
> unavailable for SN2 builds:
>
> depends on IA64_GENERIC || IA64_DIG || IA64_HP_ZX1 || IA64_HP_ZX1_SWIOTLB
>
> but there doesn't appear to be any particular reason for that other
> than us not needing it (and in fact SN2 systems can run IA64_GENERIC
> kernels with CONFIG_PM enabled without incident).
>
> > Re: CONFIG_ACPI_BOOT
> > I've got a patch that makes it go away -- this looks like
> > a good reason for me to dust it off...  Looks like
> > arch/ia64/Kconfig defines ACPI and then pulls in drivers/acpi/Kconfig,
> > which it should not do - it should look like i386/Kconfig...

Yeah, I noticed that too.  If you've got a patch to clean it up, we should go 
ahead and get it sent off to Tony.

I sent this to linux-ia64 the other day to address these issues.

Jesse

[-- Attachment #2: ia64-kconfig-pm-fix.patch --]
[-- Type: text/x-diff, Size: 409 bytes --]

===== arch/ia64/Kconfig 1.85 vs edited =====
--- 1.85/arch/ia64/Kconfig	2005-01-28 15:32:25 -08:00
+++ edited/arch/ia64/Kconfig	2005-03-21 09:38:29 -08:00
@@ -328,7 +328,7 @@
 
 config PM
 	bool "Power Management support"
-	depends on IA64_GENERIC || IA64_DIG || IA64_HP_ZX1 || IA64_HP_ZX1_SWIOTLB
+	depends on !IA64_HP_SIM
 	default y
 	help
 	  "Power Management" means that parts of your computer are shut

Re: [ACPI] Re: 2.6.12-rc1-mm3

[Len Brown]

On Fri, 2005-03-25 at 21:57, Jason Uhlenkott wrote:
> On Fri, Mar 25, 2005 at 09:24:21PM -0500, Len Brown wrote:
> > What bad things happen if you define CONFIG_PM on SN2?
> 
> None, other than slightly enlarging the kernel with some
> suspend/resume stuff we don't care about.  It's always been
> unavailable for SN2 builds:
> 
> depends on IA64_GENERIC || IA64_DIG || IA64_HP_ZX1 ||
> IA64_HP_ZX1_SWIOTLB
> 
> but there doesn't appear to be any particular reason for that other
> than us not needing it (and in fact SN2 systems can run IA64_GENERIC
> kernels with CONFIG_PM enabled without incident).

good.

I realize now I didn't answer your original question.
The reason ACPI now depends on PM is that
it makes it easier for us to do a more orderly shutdown --
acpi registers as a device so it can do some stuff
upon the PM device shutdowns -- before interrupts are disabled.

I think with all the twisty turney passages
related to the suspend states, poweroff, sys-req, and now kexec,
that it is best if we can keep the code paths as
common as possible or some of them will never get the
testing needed to prevent them from getting broken.

Also, it is now common practice to include PM && ACPI together
in the x86 world.  Though technically one could have
ACPI w/o PM and you'd have lost only ACPI_SLEEP, virtually
nobody seems to use/depend-on that combination.

Obviously I hadn't considered SN2 or built its config
before that 1-liner.  I'll be sure to build it next time.

> > Re: CONFIG_ACPI_BOOT
> > I've got a patch that makes it go away -- this looks like
> > a good reason for me to dust it off...  Looks like
> > arch/ia64/Kconfig defines ACPI and then pulls in
> drivers/acpi/Kconfig,
> > which it should not do - it should look like i386/Kconfig...
> 
> Sounds good to me.  Does that mean everything currently controlled by
> CONFIG_ACPI_BOOT will be controlled by CONFIG_ACPI instead?

yes.  this was in -mm a while back, but got pushed onto the back
burner when more pressing things came up.

thanks,
-Len

Re: Re: 2.6.12-rc1-mm3

[Jason Uhlenkott]

On Fri, Mar 25, 2005 at 11:12:39PM -0500, Len Brown wrote:
> I realize now I didn't answer your original question.
> The reason ACPI now depends on PM is that
> it makes it easier for us to do a more orderly shutdown --
> acpi registers as a device so it can do some stuff
> upon the PM device shutdowns -- before interrupts are disabled.
> 
> I think with all the twisty turney passages
> related to the suspend states, poweroff, sys-req, and now kexec,
> that it is best if we can keep the code paths as
> common as possible or some of them will never get the
> testing needed to prevent them from getting broken.
> 
> Also, it is now common practice to include PM && ACPI together
> in the x86 world.  Though technically one could have
> ACPI w/o PM and you'd have lost only ACPI_SLEEP, virtually
> nobody seems to use/depend-on that combination.

OK, that makes sense.  I see now that Jesse has already sent a patch
to allow CONFIG_PM on sn2, so we'll be fine as soon as that gets
merged.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click