Hans de Hartog [EMAIL PROTECTED] wrote:
Something else you might want to try: put
-P in /boot.config and disconnect your
keyboard during the BIOS-blabla
/boot.config is obsolete
No, it isn't obsolete, and it works. And I see no immediate need/plan
to make it obsolete.
and doesn't work
My NCD keyboard N-123UX doesn't seem to work with FreeBSD 4.2 and
FreeBSD 4.4-RC on two PCs and one laptop. It works fine with FreeBSD
3.2 and OpenBSD 2.9-current (two machines are dual boot: one 3.2
and 4.2, the other 4.4-RC and OpenBSD-current, so it shouldn't be
a hardware problem). No key
:If the flags 0x100 is specified to syscons (this is now default in
:GENERIC), syscons should revert to the AT keyboard when the USB
:keyboard has gone.
:
:Kazu
ok... so if we remove 'flags 0x1' from atkbd0, and leave
'flags 0x100' on sc0, and add an entry to /etc/usbd.conf to
At first I was laboring under the assumption that this was an
SMP-related problem and, while intensely irritating on my box "zippy",
I figured it would at least only bite a small number of people and
only in -current.
Now I've switched over to a single-CPU box running RELENG_4 and this
problem
I already sent a mail about this problem a while ago, but it has not
been solved yet. I mail again because I've made a mistake describing the
problem. So, the problem was that when i type "vidcontrol VESA_800x600",
it makes my box crash. I first thought that this was making my box
reboot,
I'd like to report a "Me too" on Robert Watson's report of
middle mouse emulation breakage under X. I just updated a
laptop (touchpad with 2 button mouse) running 4.0-RELEASE
to 4.0-STABLE using sources cvsup'd this morning.
[...]
# Sorry for not replying earlier. I have been out of town for
The GENERIC kernel ought to print from the parallel port out of the box.
Networking with the parallel port bus (for zip dirves?) ought to take
second place.
GENERIC is the kernel used for installation. PLIP is one of the
installation media. Therefore, GENERIC needs to configure the parallel
Oops, my loopback (lo0) was down. It's a pilot error. Sorry for the
false alarm. `portmap' is OK in -CURRENT.
Jeffrey, your problem may be the same as mine. You had better check
`network_interfaces' in /etc/rc.conf. It should have `lo0' together
with all other network interfaces. Or, it
Unfortunately, the suggested remedy only compounded the problem.
Setting the psm0 flags to 0x100 killed X when the mouse lost sync.
Running moused and using sysmouse caused extremely eratic behavior.
Without moused and using /dev/psm0 for X simply froze the mouse --
although switching to another
: I think you should still be able to login to the system via network.
: Send me /var/run/dmesg.out, /boot.config, /boot/loader.rc and your
: kernel configuration file for examination.
(Sorry. Insufficient clarity is ever the petty hobgoblin that haunts
my email. Or is it otiose purple? I
Ok, the problem seems to be with the mouse, rather than the serial
port.
Give me some more details about your serial mouse.
What model from which manufacuture is it?
I suspect it's rather an old model, because moused should be able to
detemine the protocol type if it is one of newer
Please tell us detail of your mouse: manufacture, model name/number,
etc.
Microsoft PS/2 "Mouse port compatible mouse 2.1A"
There should be no problem with this mouse. *sigh*
Does the mouse work in the text console? Please run
vidcontrol -m on
in a text console and see if the
I've just upgraded from FBSD 2.2.8 to 3.2 via CD then to
3.2 stable by cvsup. Since then X dies when I touch the mouse.
It's a PS/2 that I have moused running with (works on text
screen) and have configured X for SysMouse + /dev/sysmouse.
Even if I startup XF86Setup and touch the mouse, that
13 matches
Mail list logo