From owner-freebsd-smp Thu Jul 24 13:54:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA23495 for smp-outgoing; Thu, 24 Jul 1997 13:54:33 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id NAA23490 for ; Thu, 24 Jul 1997 13:54:31 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA18027; Thu, 24 Jul 1997 13:49:06 -0700 From: Terry Lambert Message-Id: <199707242049.NAA18027@phaeton.artisoft.com> Subject: Re: 3.0-SMP + COMPAT_LINUX ? To: brian@mpress.com (Brian Litzinger) Date: Thu, 24 Jul 1997 13:49:06 -0700 (MST) Cc: root@deadline.snafu.de, smp@FreeBSD.ORG In-Reply-To: <19970723191751.30899@mpress.com> from "Brian Litzinger" at Jul 23, 97 07:17:51 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > I recently tried to run some Linux binaries on top of 3.0-current SMP, > > but when I start them the machine hangs forever. Is this "supposed" to > > be so at the current stage of development or doesn't anybody notice > > until now? > > I run ApplixWare, and the linux version of netscape on an > SMP -current machine with linux compatibility compiled into the > kernel quite extensively. This issue was discussed on the list in the past. The upshot was "if it's an LKM, it will crash with an SMP kernel, but if it's compiled in, it will work". I believe the problem is that there is not a dual mapping established for kernel memory allocations of a particular class. It may be as simple as stale cache data, since the data load is a two stage process, or it may be as complex as the particular kernel reoutine used to allocate the logically contiguous pages. My personaly suspicion is that if the LKM load occurs entirely on one processor, then code using the LKM will run, assuming it always runs on that same processor (hence the intermittent behaviour). One issue is that the LKM code required the kernel address space to be mapped in its entirety. I believe the SMP code *requires* seperate regions (per processor data areas and kernel stacks), *but* (and this is a biggie) the memory map for the rest of the address space was not adjusted when the change went in. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.