Skip to contentSkip to conversation

acpi exception with current -mm lineup

DISCUSSION Andrew Morton 3 participants 3 messages May 31, 2007 ACPI

lore
Share & tools
lore

Andrew Morton

author
#0 lore raw

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
 [<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.

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

reviewer
#1 lore raw

Re: acpi exception with current -mm lineup (HPET)

Quoted 10 lines · Andrew Morton

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;
Quoted 19 lines
 [<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.
Quoted 2 lines

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

Quoted 4 lines

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

#2 lore raw

RE: acpi exception with current -mm lineup (HPET)

Quoted 29 lines

-----Original Message-----
From: Len Brown [mailto:[email protected]]
Sent: Wednesday, May 30, 2007 11:02 PM
To: Andrew Morton; Pallipadi, Venkatesh
Cc: [email protected]
Subject: Re: acpi exception with current -mm lineup (HPET)

Quoted 1 line

I put a copy of /proc/acpi/dsdt at

http://userweb.kernel.org/~akpm/dsdt

Quoted 3 lines

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()
...

Quoted 3 lines

Perhaps Venki can comment on if the resource conflict is expected to be fatal or not.

The issue seems to be HPET at two different places in BIOS/ACPI. One listing is in MADT which is used to set up kernel timer and which reserves this resource earlier

hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0

And later hpet character driver is finding HPET listed in _CRS And finds it is the same HPET as the one looked at before Causing this conflict. Totally nonfatal.
Just correcting the return type of hpet_resources should be fine here.

Thanks,
Venki