From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 8 22:10:40 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 166E1106566C for ; Tue, 8 Nov 2011 22:10:40 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 63EC88FC16 for ; Tue, 8 Nov 2011 22:10:39 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id AAA29189; Wed, 09 Nov 2011 00:10:35 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RNtsJ-0008PG-7p; Wed, 09 Nov 2011 00:10:35 +0200 Message-ID: <4EB9A8D9.3090303@FreeBSD.org> Date: Wed, 09 Nov 2011 00:10:33 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111002 Thunderbird/7.0.1 MIME-Version: 1.0 To: Russell Cattelan References: <4DFA4C47.8060503@digitalelves.com> <4EA5A676.5040500@thebarn.com> <4EB67C2A.4000906@FreeBSD.org> <4EB99BB8.3000401@thebarn.com> In-Reply-To: <4EB99BB8.3000401@thebarn.com> X-Enigmail-Version: undefined Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org Subject: Re: kexec or similar for FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 22:10:40 -0000 on 08/11/2011 23:14 Russell Cattelan said the following: > On 11/6/11 6:23 AM, Andriy Gapon wrote: >> on 24/10/2011 20:55 Russell Cattelan said the following: >>> So it has been a while and a lot of hair pulling but kload is sorta >>> alive and kicking. It can now load the kernel from userspace, copy it >>> over the running kernel and jump the the kernel entry point. >>> >>> I'm still having problems getting through the boot process due to >>> interrupts arriving for unconfigured handlers. Fatal Trap (30) > >> Just in case, is your original kernel running SMP? > > I'm working on the SMP stuff now. Trying to get the processors in a state > where the restart process can complete. > > For now I removed the panic call in the unknown interrupt case. > > > What I finally figured out was that starting up the system was overwriting > the page tables and caused any of AP's still looking at those locations to > cause qemu / kvm to reset :-( Very interesting. You might also find the following information useful in case you haven't implemented that yet: http://www.intel.com/design/pentium/datashts/242016.htm specifically the Appendix B.5. That is something that we are not doing right now, but what I would prefer us doing even for a "normal" warm reboot. Namely: In order to do a complete system shutdown, followed by a warm restart if necessary, the operating system should return the system to a state similar to that at power-on. This includes disabling the Local APIC interrupts (LINT0/LINT1/Local APIC Timer/Error interrupt) on all processors, disabling the Local APIC on all APs and disabling all interrupts at all the I/O APICs in the system. I believe that this could be a reason for the spurious interrupts that you get. BTW, I am not completely sure, but it seems that we never disable the timer interrupt(s) during shutdown (unlike interrupts for all/most of other devices). You might also find OpenSolaris code interesting in this respect: http://fxr.watson.org/fxr/source/i86pc/io/pcplusmp/apic_common.c?v=OPENSOLARIS#L1160 http://fxr.watson.org/fxr/source/i86pc/os/machdep.c?v=OPENSOLARIS#L191 All the best! -- Andriy Gapon