Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 22 Jul 1999 18:39:10 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        nate@mt.sri.com (Nate Williams)
Cc:        tlambert@primenet.com, scheper@beast.toad.net, freebsd-smp@FreeBSD.ORG
Subject:   Re: SMP + XDM = keyboard lockup
Message-ID:  <199907221839.LAA10550@usr05.primenet.com>
In-Reply-To: <199907221812.MAA02907@mt.sri.com> from "Nate Williams" at Jul 22, 99 12:12:02 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> > 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.
> 
> Why would the other CPU doing the same inb/outb's as X?  By the time
> init is run, the kernel is done 'setting up' the kernel.

It wouldn't be.

It would merely be trying to latch different addresses on the I/O
bus and/or write data to the previously latched address, at the
same time.

Basically, user space code should keep its cold, wet nose out of
the kernels crotch.

I believe the issue is the system is still starting up, and thus
has the kernel poking at things.

You could guess that the init and the X server might be running
on different CPU's, but then you would expect the /etc/ttys file
based xdm startup to work.

This jibes with his statement that manually starting the xdm from
a root shell prompt on a relatively quiescent system "works".  It
is likely that it "works" only because there is not simultaneous
activity.

If I am correct, I suspect that on an active SMP system, console
switching in and out of X would result in similar lockups, so this
should be verifiable.

Since he appears to have a way in, other than the console, he
should:

1)	Cause the lockup

2)	Go in and do a 'ps' to see if conflicting processes are
	running

3)	Force a console switch via escape sequence to a console
	vty not currently in use.  This should result in the X
	server disengaging, and the input devices being detached
	and reattached to the new vty, if the problem is merely
	a race.

Also, if both terminals are reading input, as has been posited,
a ctrl-alt-F2 should still result in a console switch, regardless
of who takes the keypress event (ctrl and alt are modifiers, so
only the F2 keycode should be relevent).


					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?199907221839.LAA10550>