Date: Thu, 22 Jul 1999 14:17:07 -0400 (EDT) From: Richard Scheper <scheper@beast.toad.net> To: freebsd-smp@FreeBSD.ORG Subject: Re: SMP + XDM = keyboard lockup Message-ID: <Pine.LNX.4.10.9907221412360.27036-100000@beast.toad.net> In-Reply-To: <199907221800.LAA08972@usr05.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Wow! That's a lot to chew and mostly over my head, but a couple of questions.. If what you say is true, then wouldn't I have toruble running xdm even from a root login after the boot process is over? I don't. How could I delay the startup of one of the processors, as you suggest in your last point? thanks for the detailed response! -Rich On Thu, 22 Jul 1999, Terry Lambert wrote: > > 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?Pine.LNX.4.10.9907221412360.27036-100000>