>-----Original Message----- >From: Len Brown [mailto:lenb@xxxxxxxxxx] >Sent: Wednesday, May 30, 2007 11:02 PM >To: Andrew Morton; Pallipadi, Venkatesh >Cc: linux-acpi@xxxxxxxxxxxxxxx >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 - 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
