From owner-freebsd-current@FreeBSD.ORG Tue Sep 21 20:14:12 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 CFDEA16A4CE for ; Tue, 21 Sep 2004 20:14:12 +0000 (GMT) Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2822843D2F for ; Tue, 21 Sep 2004 20:14:12 +0000 (GMT) (envelope-from rik@cronyx.ru) Received: (from root@localhost) by hanoi.cronyx.ru id i8LKB6R0065285 for freebsd-current@FreeBSD.org.checked; (8.12.8/vak/2.1) Wed, 22 Sep 2004 00:11:06 +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 i8LK8UUT065166; (8.12.8/vak/2.1) Wed, 22 Sep 2004 00:08:30 +0400 (MSD) (envelope-from rik@cronyx.ru) Message-ID: <4150886F.1040101@cronyx.ru> Date: Wed, 22 Sep 2004 00:00:47 +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> <414E7581.2070505@root.org> <414F256B.1030304@cronyx.ru> <200409201652.24457.jhb@FreeBSD.org> <41505663.40407@cronyx.ru> <4150607D.3020900@root.org> In-Reply-To: <4150607D.3020900@root.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: Roman Kurakin cc: FreeBSD Current 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: Tue, 21 Sep 2004 20:14:12 -0000 Nate Lawson: > Roman Kurakin wrote: > >> My solution works for current so I am going to commit it and MFC after >> a while. To be sure that I am not on the wrong way I need some >> reviewed/approved signs ;-) I also hope to get one (or more) tested >> signs. >> >> Patch I plan to commit following patch: >> >> Index: mp_machdep.c >> =================================================================== >> RCS file: /home/ncvs/src/sys/i386/i386/mp_machdep.c,v >> retrieving revision 1.238 >> diff -u -r1.238 mp_machdep.c >> --- mp_machdep.c 1 Sep 2004 06:42:01 -0000 1.238 >> +++ mp_machdep.c 21 Sep 2004 15:54:41 -0000 >> @@ -743,10 +743,11 @@ >> u_int8_t *dst8; >> u_int16_t *dst16; >> u_int32_t *dst32; >> + vm_offset_t va = (vm_offset_t) dst; >> >> POSTCODE(INSTALL_AP_TRAMP_POST); >> >> - pmap_kenter(boot_address + KERNBASE, boot_address); >> + pmap_map(&va, boot_address, boot_address + size, 0); >> for (x = 0; x < size; ++x) >> *dst++ = *src++; >> >> Any signs for(or against)? >> >> Thanks! > > > 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. Ok, I'll check it tomorrow. If it is, it really should be fixed. But any way, we modify pte and it could be cached (we have this now). Who could guarantee that it wouldn't/shouldn't. If it shouldn't, do we really should rely on it, or cache invalidation is unsafe or have some side effects? I can't unsfer to these questions for sure by my self ... If I didn't miss smth, it seems that install_ap_tramp is the only place that do not invalidate cache after modifing pte entry. > If I'm wrong, feel free to commit your patch. > > P.S. Spaces instead of tabs in your diff. I know, it was just cat-pasted from console as an example. Real one without spaces. rik > -Nate