From owner-freebsd-smp Thu Jul 22 11: 0:55 1999 Delivered-To: freebsd-smp@freebsd.org Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id 4E9AD1528B for ; Thu, 22 Jul 1999 11:00:45 -0700 (PDT) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id LAA16499; Thu, 22 Jul 1999 11:00:41 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp01.primenet.com, id smtpd016441; Thu Jul 22 11:00:33 1999 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id LAA08972; Thu, 22 Jul 1999 11:00:29 -0700 (MST) From: Terry Lambert Message-Id: <199907221800.LAA08972@usr05.primenet.com> Subject: Re: SMP + XDM = keyboard lockup To: scheper@beast.toad.net (Richard Scheper) Date: Thu, 22 Jul 1999 18:00:29 +0000 (GMT) Cc: freebsd-smp@FreeBSD.ORG In-Reply-To: from "Richard Scheper" at Jul 22, 99 08:31:47 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Heres my problem. I have an rc.local which starts up xdm, i.e. > > /usr/X11R6/bin/xdm > > which starts up the xdm login screen. However, at this point the keyboard > input is locked out. Absolutely no key sequences have any effect. All else > appears to work, i.e. the mouse still functions. I've experimented with > this and have gathered the following clues: The xdm program, among other things, starts X. I believe the issue is one CPU running X doing inb/outb's while the other CPU is in the kernel -- doing the same. In order to fix this properly, you would need to do one of the following: o modify X to use a system-call based mechanism to do the requisite inb/outb calls o modify X to use a device-I/O based mechanism to do the requisite inb/outb calls o map a read-only page into user space as the I/O space, and have X write to it, doing the actual I/O in the fault handler in the kernel o Implement GGI for FreeBSD (the GGI people are willing to let the kernel components be BSD licensed for FreeBSD, and seem very interested in a FreeBSD version, but they lack a FreeBSD volunteer for their project) o Externalize access to the "Big Giant Lock", and let the X server hold the lock while doing its inb/outb calls, taking special care about involuntary context switches while the lock is held (Note: this approach sucks for many reasons, including that user space access to the lock seriously damages the concurrency model) o Do what Linux does, and virtualize the I/O bus space through traps (this would also let you limit the I/O space exposure you allow, since it would prevent access to all but designated I/O areas; in all, it's a security win, as well as a method of serializing I/O space access) o Don't have more than one CPU running while the X server has its cold, wet nose in the kernel's crotch All of these have to do with preventing reentrancy of the I/O bus space by more than one processor, and all but the last of them have to do with holding the BGL while doing the I/O. The last keeps the processors from hitting the BGL until after X is up (e.g. they spin on the AP startup spinlock waiting for the BP to get their environment fully set up). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message