On Thursday 31 May 2007 00:17, Andrew Morton wrote:
> initcall 0xffffffff8066281b: rtc_init+0x0/0x1aa() returned 0.
> initcall 0xffffffff8066281b ran for 0 msecs: rtc_init+0x0/0x1aa()
> Calling initcall 0xffffffff806629c5: hpet_init+0x0/0x69()
> hpet_resources: 0xfed00000 is busy
> ACPI Error (utglobal-0126): Unknown exception code: 0xFFFFFFF0 [20070126]
>
> Call Trace:
> [<ffffffff80384004>] acpi_format_exception+0x38/0x43
> [<ffffffff80380ac9>] acpi_ut_status_exit+0x43/0x85
> [<ffffffff803ad958>] hpet_resources+0x0/0x138
This stack track is actually triggered in acpi_walk_resources(),
by return_ACPI_STATUS(status);
because the return type here
static acpi_status hpet_resources(struct acpi_resource *res, void *data)
is not consistent with the return value here:
return -EBUSY;
> [<ffffffff8037e341>] acpi_walk_resources+0x13c/0x14e
> [<ffffffff803ad907>] hpet_acpi_add+0x40/0x91
> [<ffffffff80387a27>] acpi_device_probe+0x51/0x109
> [<ffffffff803bca00>] driver_probe_device+0xdd/0x164
> [<ffffffff803bcbc7>] __driver_attach+0x89/0xc9
> [<ffffffff803bcb3e>] __driver_attach+0x0/0xc9
> [<ffffffff803bbaaa>] bus_for_each_dev+0x49/0x7a
> [<ffffffff803bc76b>] driver_attach+0x1c/0x1e
> [<ffffffff803bc0b2>] bus_add_driver+0x7f/0x184
> [<ffffffff803bcf94>] driver_register+0x73/0x77
> [<ffffffff80387bbd>] acpi_bus_register_driver+0x3e/0x40
> [<ffffffff80662a00>] hpet_init+0x3b/0x69
> [<ffffffff8064f8fb>] kernel_init+0x171/0x2e1
> [<ffffffff804ed953>] _spin_unlock_irq+0x14/0x30
> [<ffffffff8020a618>] child_rip+0xa/0x12
> [<ffffffff8064f78a>] kernel_init+0x0/0x2e1
> [<ffffffff8020a60e>] child_rip+0x0/0x12
> initcall 0xffffffff806629c5: hpet_init+0x0/0x69() returned 0.
>
> This is with a git pull from this morning. The machine is one
> of those Intel Noncna boxen. I'm not sure how it identifies itself.
Nocona
> I put a copy of /proc/acpi/dsdt at http://userweb.kernel.org/~akpm/dsdt
> if that's any help.
>
> Full dmesg at http://userweb.kernel.org/~akpm/dmesg-x.txt
Okay, this BIOS actually has a real HPET table:
ACPI: HPET 7FFD7460, 0038 (r1 A M I OEMHPET 5000427 MSFT 97)
and the hpet is actually found:
Calling initcall 0xffffffff80652488: late_hpet_init+0x0/0xd1()
hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
hpet0: 3 64-bit timers, 14318180 Hz
initcall 0xffffffff80652488: late_hpet_init+0x0/0xd1() returned 0.
initcall 0xffffffff80652488 ran for 0 msecs: late_hpet_init+0x0/0xd1()
...
Perhaps Venki can comment on if the resource conflict is expected
to be fatal or not.
-Len
-
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
