Date: Tue, 21 Sep 2004 13:22:39 -0700 From: Nate Lawson <nate@root.org> To: John Baldwin <jhb@FreeBSD.org> Cc: Roman Kurakin <rik@cronyx.ru> Subject: Re: mp_machdep.c (was Re: [Fwd: Re: Bug reports requested - acpi]) Message-ID: <41508D8F.70002@root.org> In-Reply-To: <200409211441.42325.jhb@FreeBSD.org> References: <41421D6A.8070805@cronyx.ru> <41505663.40407@cronyx.ru> <4150607D.3020900@root.org> <200409211441.42325.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote:
> On Tuesday 21 September 2004 01:10 pm, Nate Lawson wrote:
>>A quick "no" vote from me until this is really understood. I think the
>>real problem is an interference between the pmap for the AP trampoline
>>and the acpi wake code (sys/i386/acpica/acpi_wakeup.c). The address you
>>gave (0x9f000) is right before the base address we use for the wakeup
>>code (0xa0000). As I woke up this morning, I was wondering if this
>>could be the issue. An easy way to test is to disable the call to
>>acpi_install_wakeup_handler() in sys/i386/acpica/acpi_machdep.c and see
>>if this alone fixes the problem.
>>
>>If I'm wrong, feel free to commit your patch.
>>
>>P.S. Spaces instead of tabs in your diff.
>
> Umm, 0xa0000 is the start of Video RAM, so I sure hope the ACPI wake code
> doesn't try to write code into Video memory. The pmap_invalidate_page is
> certainly needed.
This call to alloc the memory seems to say 0xa0000 is the first valid
start address:
if (bus_dma_tag_create(/* parent */ NULL, /* alignment */ 2, 0,
/* lowaddr below 1MB */ 0x9ffff,
/* highaddr */ BUS_SPACE_MAXADDR, NULL, NULL,
PAGE_SIZE, 1, PAGE_SIZE, 0, busdma_lock_mutex,
&Giant, &acpi_waketag) != 0)
In any case, you're right about needing to invalidate the mapping after
creating it so feel free to commit. Do we also need this after
pmap_enter() in acpi_sleep_machdep() (i386/acpica/acpi_wakeup.c)?
--
Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41508D8F.70002>