I was running the recently-tagged RELENG_7_1 on my laptop, doing stuff involving switching among a small handful of xterms, when the mouse became unresponsive.
Ctl+Alt+F2 got me to a vty, though, so the systems hadn't paniced.
A "ps ax | grep mouse" showed that moused(8) was running.
I tried re-starting moused(8) via "sh /etc/rc.d/moused restart", only to
be informed:
psm0: failed to reset the aux device.
psm0: the aux device has gone! (reinitialize).
This was not auspicious. :-{
I tried suspend (to RAM), then awakening the machine; no change.
I tried attaching an external PS/2 mouse; no change.
Eventually, I gave up & rebooted -- after appending
hint.psm.0.flags="0x2000"
to /boot/device.hints.
The machine is running:
FreeBSD 7.1-PRERELEASE #785: Tue Nov 25 05:59:55 PST 2008 [EMAIL
PROTECTED]:/common/S3/obj/usr/src/sys/CANARY i386
The hardware is a mutant/hybrid between a Dell Latitude D840 & a Dell
Inspiron 8200. While I normally run RELENG_6 when I'm doing most work
on it, I have been tracking RELENG_6 (on slice 1), RELENG_7 (on slice 3),
and HEAD (on slice 4). This morning, I "cloned" slice 3 to slice 2 &
set it up to track RELENG_7_1.
I've not encountered this behavior previously; the current hardware
configuration has been stable for at least 6 weeks or so (and most
of the significant parts have been in regular use for at least a
couple of years).
I'm not especially keen to turn psm(4) debugging on, unless there's
some way to get it to be pretty selective and only produce output
that has a reasonably high probability of being useful.
Any (other) suggestions?
Peace,
david
--
David H. Wolfskill [EMAIL PROTECTED]
Depriving a girl or boy of an opportunity for education is evil.
See http://www.catwhisker.org/~david/publickey.gpg for my public key.
pgpZ0HC00aljb.pgp
Description: PGP signature
