From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.11] helo=sc8-sf-mx1.sourceforge.net) by sc8-sf-list1.sourceforge.net with esmtp (Exim 4.24) id 1AbzPS-0008KS-Ej for user-mode-linux-devel@lists.sourceforge.net; Thu, 01 Jan 2004 01:46:30 -0800 Received: from smtp004.mail.ukl.yahoo.com ([217.12.11.35]) by sc8-sf-mx1.sourceforge.net with smtp (Exim 4.30) id 1AbzPR-0006O1-PB for user-mode-linux-devel@lists.sourceforge.net; Thu, 01 Jan 2004 01:46:29 -0800 From: BlaisorBlade Subject: Re: [uml-devel] Re: UML patches against vanilla 2.6.0 References: <200312261905.48277.blaisorblade_spam@yahoo.it> <200312271927.26870.blaisorblade_spam@yahoo.it> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Disposition: inline Message-Id: <200312311858.02382.blaisorblade_spam@yahoo.it> Sender: user-mode-linux-devel-admin@lists.sourceforge.net Errors-To: user-mode-linux-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Id: The user-mode Linux development list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 31 Dec 2003 18:58:02 +0100 Content-Transfer-Encoding: quoted-printable To: user-mode-linux-devel@lists.sourceforge.net Alle 21:09, luned=EC 29 dicembre 2003, Jason Lunz ha scritto: > blaisorblade_spam@yahoo.it said: > > I have some doubts about the 2.6 host-skas patch. I've searched through > > the list for earlier ports to 2.6 and I've seen someone (Bryan O'Sulliv= an > > ) complaining: > > > > "The big issue with the skas patches, though, appears to be that they > > don't handle the UML kernel being killed, which results in the host > > kernel's memory management being completely trashed." > > > > Is this a real issue or not? > > I think so. I'm running 2.6.0 vanilla + Ingo's combo -A2 on my host, > with 2.4.23 UMLs. > I tried to do something in the uml involving lots of > tmpfs usage, and the host system crashed. If you use the Ingo's combo patch, maybe it's not the Skas mode itself. There is a change in mm/memory.c which is fine for UML, but IMHO probably hurts for the host kernel. Looking at the patch he posts, however, he didn'= t=20 use this change, so beyond the mm/memory.c problem there must be another on= e. To test that, you can either select the changes to that file away from the = patch, or unapply (with -R option to patch) this patch, which contains=20 exactly that change: http://web.tiscali.it/no-redirect-tiscali/blaisorblade/linux/archives/UML/v= 2/A-04-MM-compile-fix.patch --=20 cat <