acpi exception with current -mm lineup

acpi exception with current -mm lineup

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

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

[Len Brown]

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
 

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

[Pallipadi, Venkatesh]

 

>-----Original Message-----
>From: Len Brown [mailto:lenb@kernel.org] 
>Sent: Wednesday, May 30, 2007 11:02 PM
>To: Andrew Morton; Pallipadi, Venkatesh
>Cc: linux-acpi@vger.kernel.org
>Subject: Re: acpi exception with current -mm lineup (HPET)
>
>
>> 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.
>


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