From owner-freebsd-current@FreeBSD.ORG Tue Sep 21 19:01:35 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 5CF8516A4CE for ; Tue, 21 Sep 2004 19:01:35 +0000 (GMT) Received: from mail1.speakeasy.net (mail1.speakeasy.net [216.254.0.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2ADF743D5F for ; Tue, 21 Sep 2004 19:01:35 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 18543 invoked from network); 21 Sep 2004 19:01:35 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 21 Sep 2004 19:01:34 -0000 Received: from [10.50.40.210] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i8LJ1NQZ033439; Tue, 21 Sep 2004 15:01:29 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Nate Lawson Date: Tue, 21 Sep 2004 14:41:42 -0400 User-Agent: KMail/1.6.2 References: <41421D6A.8070805@cronyx.ru> <41505663.40407@cronyx.ru> <4150607D.3020900@root.org> In-Reply-To: <4150607D.3020900@root.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409211441.42325.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: FreeBSD Current cc: Ian Freislich cc: Roman Kurakin 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 19:01:35 -0000 On Tuesday 21 September 2004 01:10 pm, Nate Lawson wrote: > 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. > > 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. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org