[issue818] Modular Xorg 1.3 "WaitForSomething(): select: errno=673149184" bug

["Joe \"Floid\" Kanowitz" <sinknull@xxxxxxxxxxxxxxxxxxxxxxx>]

Joe "Floid" Kanowitz <jkanowitz@snet.net> added the comment:

Well, I was planning to add more data here, but, after rebooting, rebooting
again to disable gdm(!), and starting Xorg with moused running:

I can no longer reproduce the problem.  It actually just works now.  It works
with sysmouse, it works when aimed at the mouse port(s) directly.  It works
after rebooting again with just my original USB mouse and no PS/2 device attached.

Mysterious, indeed.  I can only assume that, somehow, on my last boot, the
previously-running monolithic server and gdm continued to cause some sort of
problem even after both were well and truly killed.

So... my gdm install is borked right now, probably easily cured tomorrow, and...
it otherwise works.  Downgrading this to 'bug,' as such, since there's no
'mystery that deserves documenting' priority.

I swear that fstat showed nothing left holding either /dev/ums0 or /dev/psm0
open after I'd gotten around to killing moused during my first round of testing.
 Of course, that doesn't mean something hadn't twiddled properties
not-readily-apparent.  (Would it be easy for some earlier access to screw up
/dev/sysmouse while moused is still happily providing services on the console? 
That seems to have been what happened, and killing and restarting moused N
times, where N is an integer >10 obviously didn't reset it.)

Possible steps to a fix for other victims:

1. Disable gdm (or xdm, etc.) completely in rc.conf and do a real reboot.

2. If that doesn't do it and you're a USB user, reboot again with a PS/2 mouse
attached.  Point Xorg at /dev/psm0 directly, then see if it's equally happy
using sysmouse with moused enabled.

3. If it persists, look for anything else possibly touching the mouse devices in
any way, and... well, get those out of the way and reboot.  It would seem that
stubbornly not-rebooting (why would I need to?) prevented me from discovering
that things *could* work perfectly under 'normal' conditions where nothing else
had meddled with the devices previously.

Many thanks to those around to stare at this with me, even if the 'solution'
proved anticlimactic.

----------
priority: urgent -> bug
status: unread -> chatting

_____________________________________________________
DragonFly issue tracker <bugs@lists.dragonflybsd.org>
<http://bugs.dragonflybsd.org/issue818>
_____________________________________________________