Date: Thu, 22 Jul 1999 18:00:29 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: scheper@beast.toad.net (Richard Scheper) Cc: freebsd-smp@FreeBSD.ORG Subject: Re: SMP + XDM = keyboard lockup Message-ID: <199907221800.LAA08972@usr05.primenet.com> In-Reply-To: <Pine.LNX.4.10.9907220813040.25064-100000@beast.toad.net> from "Richard Scheper" at Jul 22, 99 08:31:47 am
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907221800.LAA08972>