Re: [BUILD_FAILURE] 2.6.25-rc2-mm1 - Build Failure at acpi_os
On Thu, Feb 21, 2008 at 05:38:52PM -0800, Nish Aravamudan wrote: On 2/21/08, Sam Ravnborg [EMAIL PROTECTED] wrote: On Thu, Feb 21, 2008 at 10:54:40AM -0800, Nish Aravamudan wrote: On 2/20/08, Len Brown [EMAIL PROTECTED] wrote: On Saturday 16 February 2008 14:47, Kamalesh Babulal wrote: Hi Andrew, The 2.6.25-rc2-mm1 kernel with randconfig build option, fails to build on x86_64 machine CC drivers/acpi/osl.o drivers/acpi/osl.c:60:38: error: empty filename in #include drivers/acpi/osl.c: In function 'acpi_os_table_override': drivers/acpi/osl.c:399: error: 'AmlCode' undeclared (first use in this function) drivers/acpi/osl.c:399: error: (Each undeclared identifier is reported only once drivers/acpi/osl.c:399: error: for each function it appears in.) make[2]: *** [drivers/acpi/osl.o] Error 1 make[1]: *** [drivers/acpi] Error 2 make: *** [drivers] Error 2 # # Automatically generated make config: don't edit # Linux kernel version: 2.6.25-rc2-mm1 # Sun Feb 17 08:07:17 2008 # CONFIG_ACPI_CUSTOM_DSDT=y CONFIG_ACPI_CUSTOM_DSDT_FILE= garbage in, garbage out. garbage explicitly *allowed* by Kconfig in this case, though. If you don't give this build option a file name where AmlCode lives, then the build will be unable to find AmlCode[]. http://www.lesswatts.org/projects/acpi/overridingDSDT.php So we have a .config option whose sole purpose is to use another .config option? That seems ... less than ideal. Is there not some Kconfig voodoo we can do to only require the one option? Maybe something like how CONFIG_INITRAMFS_SOURCE is done? Adding Sam to the Cc, in case he has any ideas. Make sure STANDALONE is y for your randconfig builds. See README for examples. Hrm, if this is needed for randconfig to work, perhaps randconfig itself should somehow be specifying it? STANALONE is there exactly to prevent the above but we cannot control randconfig. While setting STANDALONE does fix the above, it doesn't answer the more basic question I had -- do we really need both .config options in this case? If it's simply a case of That's how it is, won't be fixed, there are higher priorities, that's good enough by me. Just seems a shame that we have an option to enable another option, which is required for the first option to be sensible -- seems like we should only need the second option... I really do not see what problem you are trying to address. STANDALONE is there as an easy way to turn of the options that requires sensible input to make a kernel compile. And that makes _perfect_ sense when you do randconfig builds. Sam - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUILD_FAILURE] 2.6.25-rc2-mm1 - Build Failure at acpi_os
Is there a way to generate (in Kconfig language) the boolean CONFIG_ACPI_CUSTOM_DSDT based on whether CONFIG_ACPI_CUSTOM_DSDT_FILE == or != ? I tried to muck around with that last night but couldn't get it to work. I.e., just present the ACPI_CUSTOM_DSDT_FILE config symbol to the user and then generate the ACPI_CUSTOM_DSDT bool based on the string value. Something following this example? config STRING string prompt What string default config STRING_IS_NOT_EMPTY bool default STRING != But that seems too easy - were you trying to do something more complex than this? Sam - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUILD_FAILURE] 2.6.25-rc2-mm1 - Build Failure at acpi_os
On Fri, Feb 22, 2008 at 10:29:38AM -0800, Randy Dunlap wrote: Sam Ravnborg wrote: Is there a way to generate (in Kconfig language) the boolean CONFIG_ACPI_CUSTOM_DSDT based on whether CONFIG_ACPI_CUSTOM_DSDT_FILE == or != ? I tried to muck around with that last night but couldn't get it to work. I.e., just present the ACPI_CUSTOM_DSDT_FILE config symbol to the user and then generate the ACPI_CUSTOM_DSDT bool based on the string value. Something following this example? config STRING string prompt What string default config STRING_IS_NOT_EMPTY bool default STRING != But that seems too easy - were you trying to do something more complex than this? Yes, that's almost what I had. I used def_bool n on the second config symbol, but the bool value never changed when I changed the string value. I'll be glad to look at it again though. I tested that above in a small Kconfig file and it works as expected. When I set the string to something STRING_IS_NOT_EMPTY is equal to y. Sam - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCH] ACPI patches for 2.6.25-rc2
On Thu, Feb 21, 2008 at 03:57:07AM -0500, Len Brown wrote: Hi Linus, please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git release Fixes a pair of a boot regressions, and some churn mostly related to some of the new thermal and thinkpad code that went into -rc1. This will update the files shown below. Hi Len. Any specific reason the two section mismatch patches that I posted a few days ago are not included? If they are buggy or questionable please let me know. I can resend if you like. Sam - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCH] ACPI patches for 2.6.25-rc2
On Thu, Feb 21, 2008 at 07:17:16AM -0500, Len Brown wrote: On Thursday 21 February 2008 04:54, Sam Ravnborg wrote: On Thu, Feb 21, 2008 at 03:57:07AM -0500, Len Brown wrote: Hi Linus, please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git release Fixes a pair of a boot regressions, and some churn mostly related to some of the new thermal and thinkpad code that went into -rc1. This will update the files shown below. Hi Len. Any specific reason the two section mismatch patches that I posted a few days ago are not included? If they are buggy or questionable please let me know. I can resend if you like. they're still in the test branch. OK - thanks, Sam - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 9/10] introduce intel_menlow platform specific driver
+config INTEL_MENLOW +tristate Thermal Management driver for Intel menlow platform +depends on ACPI_THERMAL + default n default n is not needed - it is default. Sam - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: scripts/mod/file2alias.c cross compile problem
On Thu, Aug 02, 2007 at 09:15:09PM +0200, Adrian Bunk wrote: On Thu, Aug 02, 2007 at 08:09:03PM +0200, Sam Ravnborg wrote: I second this. For anything visible in userspace from include/* we require usage of the kernel specific __u8, __u16, __u32, __u64 typedefs but for device_id we accept kernel_ulong_t which result in the following crap in file2alias.c: /* We use the ELF typedefs for kernel_ulong_t but bite the bullet and * use either stdint.h or inttypes.h for the rest. */ #if KERNEL_ELFCLASS == ELFCLASS32 typedef Elf32_Addr kernel_ulong_t; #define BITS_PER_LONG 32 #else typedef Elf64_Addr kernel_ulong_t; #define BITS_PER_LONG 64 #endif And we ought to have __u64 available. See for example types.h from asm-i386: #if defined(__GNUC__) !defined(__STRICT_ANSI__) typedef __signed__ long long __s64; typedef unsigned long long __u64; #endif You are talking about something different than the current problem. The current problem is that when crosscompiling we get a different _padding_ due to file2alias.c being compiled with HOSTCC. I am well aware of that. My point was that we are dealing with userspace - in this case depmod. So I wondered why we had special (as in less strict) rules here. Sam - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [1/4] 2.6.22-rc3: known regressions
On Tue, May 29, 2007 at 02:52:53PM +0200, Michal Piotrowski wrote: Hi all, Here is a list of some known regressions in 2.6.22-rc3. Kbuild Subject: make M=$PWD modules_install does nothing References : http://lkml.org/lkml/2007/5/27/190 Submitter : Andrey Borzenkov [EMAIL PROTECTED] Status : Unknown Closed - see http://lkml.org/lkml/2007/5/29/497 Sam - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Use of __init in asus_acpi.c + sony_acpi.c?
When running the section mismatch check on latest -mm I see:
WARNING: drivers/acpi/asus_acpi.o - Section mismatch: reference to \
.init.text:asus_hotk_add from .data between 'asus_hotk_driver' (at \
offset 0xe0) and 'model_conf'
WARNING: drivers/acpi/sony_acpi.o - Section mismatch: reference to \
.init.text:sony_acpi_add from .data between 'sony_acpi_driver' (at \
offset 0xe0) and 'sony_acpi_values'
WARNING: drivers/acpi/sony_acpi.o - Section mismatch: reference to\
.exit.text:sony_acpi_remove from .data between 'sony_acpi_driver' (at \
offset 0xe8) and 'sony_acpi_values'
Browsing the source I see that this is assignments to struct acpi_driver
structure:
static struct acpi_driver asus_hotk_driver = {
.name = ACPI_HOTK_NAME,
.class = ACPI_HOTK_CLASS,
.ids = ACPI_HOTK_HID,
.ops = {
.add = asus_hotk_add, __init
.remove = asus_hotk_remove,
},
};
From browsing the code I cannot see when this happens.
In asus_acpi.c and sony_acpi.c the .add and .remove methods are
declared __init/__exit indicating that the add method is solely used
during early init of the module.
Is it correct that acpi_bus_register_driver() is only called during the
early init phase of a drivers and so we can discard the .add methods
after first usage?
Likewise for .remove that this is only used when a module is unloaded
and so can be discarded when builtin?
Either asus_acpi.c and sony_acpi.c needs updates or the rest of
acpi_driver needs an update (fails to use __init, __exit).
Sam
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
