#9391 NORM 1.5-F11: HPET address in ACPI table is not valid (was: Can't turn on HPET)
Zarro Boogs per Child
bugtracker at laptop.org
Thu Jul 16 11:48:01 EDT 2009
#9391: HPET address in ACPI table is not valid
-------------------------------------------+--------------------------------
Reporter: cjb | Owner: wmb at firmworks.com
Type: defect | Status: new
Priority: normal | Milestone: 1.5-F11
Component: ofw - open firmware | Version: not specified
Resolution: | Keywords:
Next_action: never set | Verified: 0
Deployment_affected: | Blockedby:
Blocking: |
-------------------------------------------+--------------------------------
Changes (by dsaxena):
* cc: dsaxena (added)
* owner: dsaxena => wmb at firmworks.com
* component: kernel => ofw - open firmware
Comment:
Basically what is happening is that the value we are getting from ACPI for
hpet_address (see arch/x86/kernel/acpi/boot.c)is 0xffffffff and when we
try to ioremap() that, we run into the following code in the low-level
remap path:
{{{
static void __iomem *__ioremap_caller(resource_size_t phys_addr,
unsigned long size, unsigned long prot_val, void *caller)
{
...
/* Don't allow wraparound or zero size */
last_addr = phys_addr + size - 1;
if (!size || last_addr < phys_addr)
return NULL;
}}}
The HPET driver in the kernel does not check for the return value, and
when we try to access the HPET via the NULL mapping, we get page fault and
die miserably. This is obviously a bug and I'll submit a patch upstream to
gracefully exit the HPET init path in this situation; however, for us to
have the HPET working, we need to get the proper info from ACPI.
--
Ticket URL: <http://dev.laptop.org/ticket/9391#comment:1>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system
More information about the Bugs
mailing list