On Fri, Jun 20, 2008 at 9:00 PM, Len Brown <lenb@xxxxxxxxxx> wrote:
>> @@ -333,6 +333,9 @@ static int __init acpi_rtc_init(void)
>> {
>> struct device *dev = get_rtc_dev();
>>
>> + if (acpi_disabled)
>> + return 0;
>> +
>
> hmm, i would expect dev to be 0 for acpi=off,
> since pnp_match would fail, no?
Obviously not. Because Ingo is booting with acpi=off and he still gets
a warning about some mutex operation that originates from this very
initcall:
[ 3.976213] calling acpi_rtc_init+0x0/0xd3
[ 3.980213] ACPI Exception (utmutex-0263): AE_BAD_PARAMETER, Thread
F7C50000 could not acquire Mutex [3] [20080321]
This function seems to do the discovery of the rtc device:
static int __init pnpacpi_init(void)
{
if (acpi_disabled || pnpacpi_disabled) {
pnp_info("PnP ACPI: disabled");
return 0;
}
...
subsys_initcall(pnpacpi_init);
So we have these functions:
1. acpi_early_init() - happens before any initcall. This would
initialize mutexes, but simply returns if acpi_disabled.
2. pnpacpi_init() - subsys_initcall. Does the initial discovery of
pnpacpi devices, but simply returns if acpi_disabled.
3. acpi_init() - subsys_initcall. Simply returns if acpi_disabled.
4. acpi_rtc_init() - fs_initcall (after subsys_initcall).
So I don't know. We also know that things like dock_init() are wrong
for sure (with attached patch):
------------[ cut here ]------------
WARNING: at drivers/acpi/osl.c:821 acpi_os_wait_semaphore+0x21/0xf0()
Modules linked in:
Pid: 1, comm: swapper Not tainted 2.6.26-rc6-00161-g952f4a0-dirty #20
...
[<c0222762>] acpi_os_wait_semaphore+0x21/0xf0
[<c023ce2a>] acpi_ut_acquire_mutex+0x5e/0xc4
[<c0233778>] acpi_walk_namespace+0x24/0x60
[<c05d005f>] dock_init+0x0/0x48
[<c05d008f>] dock_init+0x30/0x48
[<c0242eb3>] find_dock+0x0/0x2f0
[<c05bb422>] kernel_init+0x120/0x254
...
ACPI Exception (utmutex-0263): AE_BAD_PARAMETER, Thread C7820000 could
not acquire Mutex [1] [20080321]
I guess Ingo should revert my bogus changes to acpi_rtc_init() and use
your suggestion of a BUG() (or maybe just WARN()) to catch the
backtrace so we can figure out how it gets there when acpi_disabled.
The only thing I can think of now is that pnp_match() is doing
something wrong. It returns 1 when it shouldn't, or something. But I
can't really spot it :-(
Vegard
diff --git a/drivers/acpi/namespace/nsxfeval.c b/drivers/acpi/namespace/nsxfeval
index a8d5491..7c444de 100644
--- a/drivers/acpi/namespace/nsxfeval.c
+++ b/drivers/acpi/namespace/nsxfeval.c
@@ -556,6 +556,8 @@ acpi_get_devices(const char *HID,
ACPI_FUNCTION_TRACE(acpi_get_devices);
+ WARN_ON(acpi_disabled);
+
/* Parameter validation */
if (!user_function) {
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 235a138..ca661e7 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -818,6 +818,8 @@ acpi_status acpi_os_wait_semaphore(acpi_handle handle, u32 u
long jiffies;
int ret = 0;
+ WARN_ON(acpi_disabled);
+
if (!sem || (units < 1))
return AE_BAD_PARAMETER;
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
