lkml.org 
[lkml]   [2012]   [Dec]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [tip:x86/build] x86: Default to ARCH= x86 to avoid overriding CONFIG_64BIT
From
Date
On Tue, 2012-12-25 at 22:32 -0800, David Rientjes wrote:
> This creates quite a few build failures on auto-latest:
>
> arch/x86/built-in.o: In function `hpet_setup_msi_irq':
> hpet.c:(.text+0x34638): undefined reference to `arch_setup_hpet_msi'
> hpet.c:(.text+0x34651): undefined reference to `destroy_irq'
> arch/x86/built-in.o: In function `hpet_msi_capability_lookup':
> hpet.c:(.text+0x347ff): undefined reference to `create_irq_nr'
> arch/x86/built-in.o:(.data+0xd1c): undefined reference to `native_setup_msi_irqs'
> arch/x86/built-in.o:(.data+0xd20): undefined reference to `native_teardown_msi_irq'
> drivers/built-in.o: In function `dmar_set_interrupt':
> (.text+0x89eec0): undefined reference to `create_irq'
> drivers/built-in.o: In function `dmar_set_interrupt':
> (.text+0x89ef0b): undefined reference to `arch_setup_dmar_msi'
> drivers/built-in.o: In function `dmar_set_interrupt':
> (.text+0x89ef44): undefined reference to `destroy_irq'
> drivers/built-in.o: In function `free_dmar_iommu':
> (.text+0x8a6ae8): undefined reference to `destroy_irq'
>
> These functions require CONFIG_X86_IO_APIC, which is only possible with
> X86_64 or X86_32_NON_STANDARD. CONFIG_HPET_TIMER, however, can be enabled
> with X86_32, and CONFIG_DMAR_TABLE can be enabled with any X86 via
> CONFIG_INTEL_IOMMU.

I don't think it can have created them, surely? They must have existed
already when building with ARCH=x86. And probably with ARCH=i386 too?
I'll take a further look in more detail, but at first glance it doesn't
seem correct to describe them as bugs caused by this patch; merely bugs
that this patch helped us to *find*.

Please could you provide the .config file?

> That said, I didn't try to fix this up because I believe the commit itself
> is wrong.

That seems like completely the wrong approach.

> When I do "make randconfig" and uname -m is x86_64, I expect
> CONFIG_64BIT to always be set. This commit makes this random for all x86
> so that "make randconfig" may result in a 32-bit build. That should be
> the behavior for "make ARCH=i386 randconfig" but not "make randconfig" on
> a 64-bit machine.

We've had this bizarre "I don't really want randconfig to be random"
conversation before. If don't want randconfig to be random, you can use
$KCONFIG_ALLCONFIG to override anything you like. Or, for the specific
case of CONFIG_64BIT on x86, you can use ARCH=i386 or ARCH=x86_64 to
override just that one option.

I'll look at the dependency problems that already existed, and try to
sort them out despite the fact that they seem unrelated to the patch I
posted. Thanks for reporting them.

--
dwmw2

[unhandled content-type:application/x-pkcs7-signature]
\
 
 \ /
  Last update: 2012-12-26 10:01    [W:0.107 / U:0.332 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site