From owner-freebsd-current@FreeBSD.ORG Wed Sep 22 07:56:07 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9C0DF16A4CE for ; Wed, 22 Sep 2004 07:56:07 +0000 (GMT) Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id C360843D1D for ; Wed, 22 Sep 2004 07:56:06 +0000 (GMT) (envelope-from rik@cronyx.ru) Received: (from root@localhost) by hanoi.cronyx.ru id i8M7rx4M026380 for freebsd-current@FreeBSD.org.checked; (8.12.8/vak/2.1) Wed, 22 Sep 2004 11:53:59 +0400 (MSD) (envelope-from rik@cronyx.ru) Received: from cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by hanoi.cronyx.ru with ESMTP id i8M7qqik026309; (8.12.8/vak/2.1) Wed, 22 Sep 2004 11:52:52 +0400 (MSD) (envelope-from rik@cronyx.ru) Message-ID: <41512D81.1030602@cronyx.ru> Date: Wed, 22 Sep 2004 11:45:05 +0400 From: Roman Kurakin User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.2.1) Gecko/20030426 X-Accept-Language: ru-ru, en MIME-Version: 1.0 To: Nate Lawson References: <41421D6A.8070805@cronyx.ru> <41505663.40407@cronyx.ru> <4150607D.3020900@root.org> <200409211441.42325.jhb@FreeBSD.org> <41508D8F.70002@root.org> In-Reply-To: <41508D8F.70002@root.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: Roman Kurakin cc: FreeBSD Current cc: Ian Freislich cc: John Baldwin Subject: Re: mp_machdep.c (was Re: [Fwd: Re: Bug reports requested - acpi]) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Sep 2004 07:56:07 -0000 Nate Lawson: > 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)? No, a quick view tells that pmap_enter() do this by it self. In my case pmap_kenter (). rik > >