x86 git acpi issue?

x86 git acpi issue?

[Hiroshi Shimamoto]

Hi,

commit: afcab879e4044f952b7a031d5fd504e0feb7df41
visws: build fix

breaks something around acpi on 32bit.
In my test box scsi driver complains and the kernel doesn't boot.

I'm not sure, but when moving the acpi.o before legacy.o, it works.
--- a/arch/x86/pci/Makefile_32
+++ b/arch/x86/pci/Makefile_32
@@ -6,11 +6,11 @@ obj-$(CONFIG_PCI_DIRECT)	+= direct.o
 obj-$(CONFIG_PCI_OLPC)		+= olpc.o
 
 pci-y				:= fixup.o
+pci-$(CONFIG_ACPI)		+= acpi.o
 pci-y				+= legacy.o irq.o
 
 pci-$(CONFIG_X86_VISWS)		:= visws.o fixup.o
 pci-$(CONFIG_X86_NUMAQ)		:= numa.o irq.o
-pci-$(CONFIG_ACPI)		+= acpi.o
 pci-$(CONFIG_NUMA)		+= mp_bus_to_node.o
 
 obj-y				+= $(pci-y) common.o early.o

of cause this isn't correct patch, it's just a workaround for me.

thanks,
Hiroshi Shimamoto

Re: x86 git acpi issue?

[H. Peter Anvin]

Hiroshi Shimamoto wrote:
> Hi,
> 
> commit: afcab879e4044f952b7a031d5fd504e0feb7df41
> visws: build fix
> 
> breaks something around acpi on 32bit.
> In my test box scsi driver complains and the kernel doesn't boot.
> 
> I'm not sure, but when moving the acpi.o before legacy.o, it works.
> --- a/arch/x86/pci/Makefile_32
> +++ b/arch/x86/pci/Makefile_32
> @@ -6,11 +6,11 @@ obj-$(CONFIG_PCI_DIRECT)	+= direct.o
>  obj-$(CONFIG_PCI_OLPC)		+= olpc.o
>  
>  pci-y				:= fixup.o
> +pci-$(CONFIG_ACPI)		+= acpi.o
>  pci-y				+= legacy.o irq.o
>  
>  pci-$(CONFIG_X86_VISWS)		:= visws.o fixup.o
>  pci-$(CONFIG_X86_NUMAQ)		:= numa.o irq.o
> -pci-$(CONFIG_ACPI)		+= acpi.o
>  pci-$(CONFIG_NUMA)		+= mp_bus_to_node.o
>  
>  obj-y				+= $(pci-y) common.o early.o
> 
> of cause this isn't correct patch, it's just a workaround for me.
> 

The problem is that := should be += for the VISWS and NUMAQ lines. 
There is already a patch queued up to fix that.

	-hpa

Re: x86 git acpi issue?

[Hiroshi Shimamoto]

H. Peter Anvin wrote:
> Hiroshi Shimamoto wrote:
>> Hi,
>>
>> commit: afcab879e4044f952b7a031d5fd504e0feb7df41
>> visws: build fix
>>
>> breaks something around acpi on 32bit.
>> In my test box scsi driver complains and the kernel doesn't boot.
>>
>> I'm not sure, but when moving the acpi.o before legacy.o, it works.
>> --- a/arch/x86/pci/Makefile_32
>> +++ b/arch/x86/pci/Makefile_32
>> @@ -6,11 +6,11 @@ obj-$(CONFIG_PCI_DIRECT)	+= direct.o
>>  obj-$(CONFIG_PCI_OLPC)		+= olpc.o
>>  
>>  pci-y				:= fixup.o
>> +pci-$(CONFIG_ACPI)		+= acpi.o
>>  pci-y				+= legacy.o irq.o
>>  
>>  pci-$(CONFIG_X86_VISWS)		:= visws.o fixup.o
>>  pci-$(CONFIG_X86_NUMAQ)		:= numa.o irq.o
>> -pci-$(CONFIG_ACPI)		+= acpi.o
>>  pci-$(CONFIG_NUMA)		+= mp_bus_to_node.o
>>  
>>  obj-y				+= $(pci-y) common.o early.o
>>
>> of cause this isn't correct patch, it's just a workaround for me.
>>
> 
> The problem is that := should be += for the VISWS and NUMAQ lines. 
> There is already a patch queued up to fix that.
> 
OK, thanks.

Hiroshi Shimamoto

Re: x86 git acpi issue?

[Adrian Bunk]

On Fri, May 02, 2008 at 05:08:12PM -0700, H. Peter Anvin wrote:
> Hiroshi Shimamoto wrote:
>> Hi,
>>
>> commit: afcab879e4044f952b7a031d5fd504e0feb7df41
>> visws: build fix
>>
>> breaks something around acpi on 32bit.
>> In my test box scsi driver complains and the kernel doesn't boot.
>>
>> I'm not sure, but when moving the acpi.o before legacy.o, it works.
>> --- a/arch/x86/pci/Makefile_32
>> +++ b/arch/x86/pci/Makefile_32
>> @@ -6,11 +6,11 @@ obj-$(CONFIG_PCI_DIRECT)	+= direct.o
>>  obj-$(CONFIG_PCI_OLPC)		+= olpc.o
>>   pci-y				:= fixup.o
>> +pci-$(CONFIG_ACPI)		+= acpi.o
>>  pci-y				+= legacy.o irq.o
>>   pci-$(CONFIG_X86_VISWS)		:= visws.o fixup.o
>>  pci-$(CONFIG_X86_NUMAQ)		:= numa.o irq.o
>> -pci-$(CONFIG_ACPI)		+= acpi.o
>>  pci-$(CONFIG_NUMA)		+= mp_bus_to_node.o
>>   obj-y				+= $(pci-y) common.o early.o
>>
>> of cause this isn't correct patch, it's just a workaround for me.
>>
>
> The problem is that := should be += for the VISWS and NUMAQ lines. There 
> is already a patch queued up to fix that.

Commit afcab879e4044f952b7a031d5fd504e0feb7df41 is the commit where Ingo 
both _reverts_ his patch you describe in the x86 tree and additionally 
moves pci-$(CONFIG_ACPI) in exactly the way that causes this breakage.

In the 4 hours between Ingo doing the += change and Ingo reverting his 
own patch in the x86 tree it was in a pull request to Linus, so the
"queued up" patch is in Linus' tree but reverted in the x86 tree.

I saw neither the patch changing the :='s to += on linux-kernel nor does 
"do not override the existing pci-y rule when adding visws or numaq 
rules." in the commit description give any indication what the actual 
problem was.

It's also not obvious why the revert with the subject "visws: build fix" 
also moved the pci-$(CONFIG_ACPI) causing this bug here.

> 	-hpa

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: x86 git acpi issue?

[Thomas Gleixner]

On Sat, 3 May 2008, Adrian Bunk wrote:
> Commit afcab879e4044f952b7a031d5fd504e0feb7df41 is the commit where Ingo 
> both _reverts_ his patch you describe in the x86 tree and additionally 
> moves pci-$(CONFIG_ACPI) in exactly the way that causes this breakage.
> 
> In the 4 hours between Ingo doing the += change and Ingo reverting his 
> own patch in the x86 tree it was in a pull request to Linus, so the
> "queued up" patch is in Linus' tree but reverted in the x86 tree.
> 
> I saw neither the patch changing the :='s to += on linux-kernel nor does 
> "do not override the existing pci-y rule when adding visws or numaq 
> rules." in the commit description give any indication what the actual 
> problem was.
> 
> It's also not obvious why the revert with the subject "visws: build fix" 
> also moved the pci-$(CONFIG_ACPI) causing this bug here.

Right. This Makefile is a nasty trap. I looked into it and the fix for
now is below. Long term this Makefile trickery needs to be cleaned up
to avoid trapping into this again.

Thanks,
	tglx

--------->
Subject: x86: undo visws/numaq build changes
From: Thomas Gleixner <tglx@linutronix.de>
Date: Fri, 02 May 2008 21:24:30 +0200

arch/x86/pci/Makefile_32 has a nasty detail. VISWS and NUMAQ builds
override the generic pci-y rules. This needs a proper cleanup, but
that needs more thoughts. Undo

commit 895d30935ebe05f192e844792668bf8d19deaae7
    x86: numaq fix
    do not override the existing pci-y rule when adding visws or
    numaq rules.

and add a comment to the Makefile.

Remove the srat stub code in discontig_32.c to allow a proper NUMAQ
build.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
 arch/x86/mm/discontig_32.c |   26 --------------------------
 arch/x86/pci/Makefile_32   |    8 ++++++--
 2 files changed, 6 insertions(+), 28 deletions(-)
Index: linux-2.6/arch/x86/mm/discontig_32.c
===================================================================
--- linux-2.6.orig/arch/x86/mm/discontig_32.c
+++ linux-2.6/arch/x86/mm/discontig_32.c
@@ -476,29 +476,3 @@ int memory_add_physaddr_to_nid(u64 addr)
 
 EXPORT_SYMBOL_GPL(memory_add_physaddr_to_nid);
 #endif
-
-#ifndef CONFIG_HAVE_ARCH_PARSE_SRAT
-/*
- * XXX FIXME: Make SLIT table parsing available to 32-bit NUMA
- *
- * These stub functions are needed to compile 32-bit NUMA when SRAT is
- * not set. There are functions in srat_64.c for parsing this table
- * and it may be possible to make them common functions.
- */
-void acpi_numa_slit_init (struct acpi_table_slit *slit)
-{
-	printk(KERN_INFO "ACPI: No support for parsing SLIT table\n");
-}
-
-void acpi_numa_processor_affinity_init (struct acpi_srat_cpu_affinity *pa)
-{
-}
-
-void acpi_numa_memory_affinity_init (struct acpi_srat_mem_affinity *ma)
-{
-}
-
-void acpi_numa_arch_fixup(void)
-{
-}
-#endif /* CONFIG_HAVE_ARCH_PARSE_SRAT */
Index: linux-2.6/arch/x86/pci/Makefile_32
===================================================================
--- linux-2.6.orig/arch/x86/pci/Makefile_32
+++ linux-2.6/arch/x86/pci/Makefile_32
@@ -9,8 +9,12 @@ pci-y				:= fixup.o
 pci-$(CONFIG_ACPI)		+= acpi.o
 pci-y				+= legacy.o irq.o
 
-pci-$(CONFIG_X86_VISWS)		+= visws.o fixup.o
-pci-$(CONFIG_X86_NUMAQ)		+= numa.o irq.o
+# Careful: VISWS and NUMAQ overrule the pci-y above. The colons are
+# therefor correct. This needs a proper fix by distangling the code.
+pci-$(CONFIG_X86_VISWS)		:= visws.o fixup.o
+pci-$(CONFIG_X86_NUMAQ)		:= numa.o irq.o
+
+# Necessary for NUMAQ as well
 pci-$(CONFIG_NUMA)		+= mp_bus_to_node.o
 
 obj-y				+= $(pci-y) common.o early.o

Re: x86 git acpi issue?

[Ingo Molnar]

* Thomas Gleixner <tglx@linutronix.de> wrote:

> On Sat, 3 May 2008, Adrian Bunk wrote:
> > Commit afcab879e4044f952b7a031d5fd504e0feb7df41 is the commit where Ingo 
> > both _reverts_ his patch you describe in the x86 tree and additionally 
> > moves pci-$(CONFIG_ACPI) in exactly the way that causes this breakage.
> > 
> > In the 4 hours between Ingo doing the += change and Ingo reverting his 
> > own patch in the x86 tree it was in a pull request to Linus, so the
> > "queued up" patch is in Linus' tree but reverted in the x86 tree.
> > 
> > I saw neither the patch changing the :='s to += on linux-kernel nor does 
> > "do not override the existing pci-y rule when adding visws or numaq 
> > rules." in the commit description give any indication what the actual 
> > problem was.
> > 
> > It's also not obvious why the revert with the subject "visws: build fix" 
> > also moved the pci-$(CONFIG_ACPI) causing this bug here.
> 
> Right. This Makefile is a nasty trap. I looked into it and the fix for 
> now is below. Long term this Makefile trickery needs to be cleaned up 
> to avoid trapping into this again.

Thanks Thomas, i messed up that commit - i should have known that the 
NUMAQ build fix looked _too_ easy ;-)

	Ingo

Re: x86 git acpi issue?

[Thomas Gleixner]

On Sat, 3 May 2008, Ingo Molnar wrote:
> > Right. This Makefile is a nasty trap. I looked into it and the fix for 
> > now is below. Long term this Makefile trickery needs to be cleaned up 
> > to avoid trapping into this again.
> 
> Thanks Thomas, i messed up that commit - i should have known that the 
> NUMAQ build fix looked _too_ easy ;-)

Also the move of 
pci-$(CONFIG_ACPI)             += acpi.o
is what broke things.

There is a nasty init function ordering problem as well between

pci-$(CONFIG_ACPI)             += acpi.o
pci-y                          += legacy.o irq.o

Sigh.

	tglx

Re: x86 git acpi issue?

[Sam Ravnborg]

On Sat, May 03, 2008 at 12:02:37PM +0200, Thomas Gleixner wrote:
> On Sat, 3 May 2008, Ingo Molnar wrote:
> > > Right. This Makefile is a nasty trap. I looked into it and the fix for 
> > > now is below. Long term this Makefile trickery needs to be cleaned up 
> > > to avoid trapping into this again.
> > 
> > Thanks Thomas, i messed up that commit - i should have known that the 
> > NUMAQ build fix looked _too_ easy ;-)
> 
> Also the move of 
> pci-$(CONFIG_ACPI)             += acpi.o
> is what broke things.
> 
> There is a nasty init function ordering problem as well between
> 
> pci-$(CONFIG_ACPI)             += acpi.o
> pci-y                          += legacy.o irq.o
> 
> Sigh.

This is the kind of stuff that has prevented me from
unifying the two Makefiles.
But if no-one beats me I will give it a shot soon.
It will be a microsteps because we will likeky hit
such issues.

	Sam

Re: x86 git acpi issue?

[Ingo Molnar]

* Sam Ravnborg <sam@ravnborg.org> wrote:

> On Sat, May 03, 2008 at 12:02:37PM +0200, Thomas Gleixner wrote:
> > On Sat, 3 May 2008, Ingo Molnar wrote:
> > > > Right. This Makefile is a nasty trap. I looked into it and the fix for 
> > > > now is below. Long term this Makefile trickery needs to be cleaned up 
> > > > to avoid trapping into this again.
> > > 
> > > Thanks Thomas, i messed up that commit - i should have known that the 
> > > NUMAQ build fix looked _too_ easy ;-)
> > 
> > Also the move of 
> > pci-$(CONFIG_ACPI)             += acpi.o
> > is what broke things.
> > 
> > There is a nasty init function ordering problem as well between
> > 
> > pci-$(CONFIG_ACPI)             += acpi.o
> > pci-y                          += legacy.o irq.o
> > 
> > Sigh.
> 
> This is the kind of stuff that has prevented me from unifying the two 
> Makefiles. But if no-one beats me I will give it a shot soon. It will 
> be a microsteps because we will likeky hit such issues.

yeah, it needs to be micro-steps (nice word! :) as this stuff is very 
subtle.

	Ingo