From owner-freebsd-current@FreeBSD.ORG Wed Sep 22 08:11:33 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 A166B16A4CE for ; Wed, 22 Sep 2004 08:11:33 +0000 (GMT) Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id E791A43D45 for ; Wed, 22 Sep 2004 08:11:32 +0000 (GMT) (envelope-from rik@cronyx.ru) Received: (from root@localhost) by hanoi.cronyx.ru id i8M88Foq026995 for freebsd-current@FreeBSD.org.checked; (8.12.8/vak/2.1) Wed, 22 Sep 2004 12:08:15 +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 i8M86TVA026899; (8.12.8/vak/2.1) Wed, 22 Sep 2004 12:06:29 +0400 (MSD) (envelope-from rik@cronyx.ru) Message-ID: <415130B3.5040205@cronyx.ru> Date: Wed, 22 Sep 2004 11:58:43 +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: John Baldwin References: <41421D6A.8070805@cronyx.ru> <200409201652.24457.jhb@FreeBSD.org> <41505663.40407@cronyx.ru> <200409211445.52372.jhb@FreeBSD.org> In-Reply-To: <200409211445.52372.jhb@FreeBSD.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Roman Kurakin cc: FreeBSD Current cc: Ian Freislich cc: Nate Lawson 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 08:11:33 -0000 John Baldwin: >On Tuesday 21 September 2004 12:27 pm, 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! >> >>PS. John: I am against of pmap_kenter/pmap_invalidate_XXX since we could >>get >>the same problem if we would use atomic functions instead of composite >>functions, >>which, I hope, will track all changes in the future. >> >> >pmap_foo() doesn't change much. :) One reason I would prefer the >kenter/invalidate is that we explicitly assume a single page for the boot >code when we go to allocate an address for it, so I'd kind of like to keep it >as an explicit assumption, but I'd be ok with just adding a KASSERT(size <= > Are you sure that some one who will add new features wouldn't forget about this place? If you consider that we can ignore this I'll commit kenter/invalidate pair with KASSERT(). >PAGE_SIZE, ("bewm")); Also, I think your end va needs to be boot_address + >size -1 so that if size == PAGE_SIZE you don't bogusly try to map the first >page of Video RAM as read/write memory. > Tell me if I am wrong, but as I understand this code "end" is not really last, but next to last. Hm, may be this is other (potential) bug, probably we should rename 'end' to smth else? (va + psz < va + psz) rik