Re: moused hangs HARD when mouse not plugged in
On Sat, 12 Feb 2000, Kazutaka YOKOTA wrote:
Both changes have effect only when we fail to attach a serial port,
which is not the case with your machine...
Hmm. Any idea, Bruce?
The usual (non-AST4) of COM_MULTIPORT is currently broken. This causes
non-working interrupts on all except the master port. I don't know
why this would cause moused to lock up the system, but it can't help.
Patch submitted by Chris Radek [EMAIL PROTECTED]:
% diff -u sio.c.orig sio.c
--- sio.c.orig Sun Feb 13 16:59:49 2000
+++ sio.c Sun Feb 13 18:23:22 2000
@@ -692,7 +692,7 @@
idev = dev;
mcr_image = MCR_IENABLE;
#ifdef COM_MULTIPORT
- if (COM_ISMULTIPORT(flags) !COM_NOTAST4(flags)) {
+ if (COM_ISMULTIPORT(flags)) {
Port_t xiobase;
u_long io;
@@ -702,14 +702,16 @@
device_get_unit(dev), COM_MPMASTER(flags));
idev = dev;
}
- if (bus_get_resource(idev, SYS_RES_IOPORT, 0, io, NULL) == 0) {
- xiobase = io;
- if (bus_get_resource(idev, SYS_RES_IRQ, 0, NULL, NULL))
- outb(xiobase + com_scr, 0x80); /* no irq */
- else
- outb(xiobase + com_scr, 0);
+ if (!COM_NOTAST4(flags)) {
+ if (bus_get_resource(idev, SYS_RES_IOPORT, 0, io, NULL) == 0)
+{
+ xiobase = io;
+ if (bus_get_resource(idev, SYS_RES_IRQ, 0, NULL, NULL))
+ outb(xiobase + com_scr, 0x80); /* no irq */
+ else
+ outb(xiobase + com_scr, 0);
+ }
+ mcr_image = 0;
}
- mcr_image = 0;
}
#endif /* COM_MULTIPORT */
if (bus_get_resource(idev, SYS_RES_IRQ, 0, NULL, NULL) != 0)
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: moused hangs HARD when mouse not plugged in
The fact remains, however -- If moused_enable is set to YES, and the mouse is not present, the kernel crashes when trying to start moused, and it crashes VERY hard. It is a total freeze. This crash is the issue. I'm pursuing the fact that if this is reproducible elsewhere that it is unacceptable. I've now done a completely clean cvs and world build, and the same for the kernel. The problem is still occuring. Would you carry out the following test? 1. Boot the system, but don't run moused yet. 2. Run moused as follows: moused -d -f -p /dev/cuaa0 -i all You should see something like the following (if everything is Ok :-) zeus# moused -d -f -p /dev/cuaa0 -i all moused: PnP COM device rev 1.0 probe... moused: modem status 03 moused: alternate probe... moused: cannot determine mouse type on /dev/cuaa0 /dev/cuaa0 unknown unknown generic zeus# I would like to know at which point your system hangs. (BTW, the above output is obtained from my -CURRENT box cvsupped and compiled on 8 February.) Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: moused hangs HARD when mouse not plugged in
The fact remains, however -- If moused_enable is set to YES, and the mouse is not present, the kernel crashes when trying to start moused, and it crashes VERY hard. It is a total freeze. This crash is the issue. I'm pursuing the fact that if this is reproducible elsewhere that it is unacceptable. I've now done a completely clean cvs and world build, and the same for the kernel. The problem is still occuring. Would you carry out the following test? 1. Boot the system, but don't run moused yet. 2. Run moused as follows: moused -d -f -p /dev/cuaa0 -i all You should see something like the following (if everything is Ok :-) zeus# moused -d -f -p /dev/cuaa0 -i all moused: PnP COM device rev 1.0 probe... moused: modem status 03 moused: alternate probe... moused: cannot determine mouse type on /dev/cuaa0 /dev/cuaa0 unknown unknown generic zeus# I would like to know at which point your system hangs. (BTW, the above output is obtained from my -CURRENT box cvsupped and compiled on 8 February.) Kazu The following is, as indicated, a kernel built from Jan 24 cvs snap. Everything with this kernel is fine. ttyp1:--ROOT--@portley (2)# uname -a FreeBSD portley.mrynet.com 4.0-CURRENT FreeBSD 4.0-CURRENT #24: Mon Jan 24 17:36:27 PST 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/PORTLEY i386 ttyp1:--ROOT--@portley (1)# moused -d -f -p /dev/cuaa0 -i all moused: PnP COM device rev 1.0 probe... moused: modem status 03 moused: alternate probe... moused: cannot determine mouse type on /dev/cuaa0 /dev/cuaa0 unknown unknown generic The kernel built today exhibits the same as mentioned before: hard hang. Nothing at all moves. Not even the keyboard lights for CAPS, etc. Just for graphics: ttyp1:--ROOT--@portley (2) moused -d -f -p /dev/cuaa0 -i all [The computer is now frozen solid] Lemme know if I should check anything else that might be amiss on my end, of if I can test anything else for you. Thanks Kazu, -skots -- Scott G. Akmentins-Taylor InterNet: [EMAIL PROTECTED] MRY Systems [EMAIL PROTECTED] (Skots Gregorijs Akmentins-Teilors -- just call me "Skots") - Labak miris neka sarkans - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: moused hangs HARD when mouse not plugged in
The following is, as indicated, a kernel built from Jan 24 cvs snap. Everything with this kernel is fine. ttyp1:--ROOT--@portley (2)# uname -a FreeBSD portley.mrynet.com 4.0-CURRENT FreeBSD 4.0-CURRENT #24: Mon Jan 24 17:36:27 PST 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/PORTLEY i386 ttyp1:--ROOT--@portley (1)# moused -d -f -p /dev/cuaa0 -i all moused: PnP COM device rev 1.0 probe... moused: modem status 03 moused: alternate probe... moused: cannot determine mouse type on /dev/cuaa0 /dev/cuaa0 unknown unknown generic The kernel built today exhibits the same as mentioned before: hard hang. Nothing at all moves. Not even the keyboard lights for CAPS, etc. Just for graphics: ttyp1:--ROOT--@portley (2) moused -d -f -p /dev/cuaa0 -i all [The computer is now frozen solid] Lemme know if I should check anything else that might be amiss on my end, of if I can test anything else for you. You have a multiport serial card in your system, right? What is it and how do you configure it in your kernel configuration file? Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: moused hangs HARD when mouse not plugged in
You have a multiport serial card in your system, right? What is it and how do you configure it in your kernel configuration file? Here's the relevant bits (note: sio0 has been tried without 0x10): # generic multi-I/O card with 16550 type UARTS device sio0at isa? port IO_COM1 flags 0x10 irq 4 device sio1at isa? port IO_COM2 irq 3 # STB-4 4-port serial - non-AST compatible device sio2at isa? port 0x1f8 flags 0x705 device sio3at isa? port 0x1e8 flags 0x705 device sio4at isa? port 0x2a8 flags 0x705 device sio5at isa? port 0x1a8 flags 0x705 irq 10 # S-LINK 4-port serial AST compatible device sio6at isa? port 0x180 flags 0x901 device sio7at isa? port 0x188 flags 0x901 device sio8at isa? port 0x190 flags 0x901 device sio9at isa? port 0x198 flags 0x901 irq 5 Cheers, -skots -- Scott G. Akmentins-Taylor InterNet: [EMAIL PROTECTED] MRY Systems [EMAIL PROTECTED] (Skots Gregorijs Akmentins-Teilors -- just call me "Skots") - Labak miris neka sarkans - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: moused hangs HARD when mouse not plugged in
Last cvs was a few hours ago and world was installed. A kernel built from this cvs hangs dead-hard when moused runs from rc.i386 and no mouse is plugged into the psm0 port device psm0at atkbdc? irq 12 The moused config is: moused_enable="NO" # Run the mouse daemon. moused_type="mousesystems" # See man page for rc.conf(5) for available se ttings. moused_port="/dev/cuaa0" # Set to your mouse port. moused_flags="" # Any additional flags to moused. Your configuration refers to a serial port, not the PS/2 mouse port. And moused is NOT running (moused_enable="NO")! You had better check the exact configuration when the lock up happened. As far as I can infer from the description above and the dmesg below, both the psm driver and moused has nothing to do the lock up. I haven't tested if the kernel hangs when a mouse IS actually plugged in, but by not running moused at all the kernel so far is fine otherwise. Last kernel built was Jan 24, and it works fine when no mouse is plugged in. A log of a verbose startup follows below. Regards, Scott -- Scott G. Akmentins-Taylor InterNet: [EMAIL PROTECTED] MRY Systems[EMAIL PROTECTED] (Skots Gregorijs Akmentins-Teilors -- just call me "Skots") - Labak miris neka sarkans - Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #1: Fri Feb 11 14:10:38 PST 2000 [...] psm0: current command byte:0047 kbdc: TEST_AUX_PORT status: kbdc: RESET_AUX return code:00fe kbdc: RESET_AUX return code:00fe kbdc: RESET_AUX return code:00fe kbdc: DIAGNOSE status:0055 kbdc: TEST_KBD_PORT status: psm0: failed to reset the aux device. The PS/2 mouse is not detected and the psm driver is NOT attached. This means that /dev/psm0 is inaccessible and you will get "device not configured" error when you try to access the PS/2 mouse port via moused, or by any means. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: moused hangs HARD when mouse not plugged in
moused_enable="NO" # Run the mouse daemon. moused_type="mousesystems" # See man page for rc.conf(5) for available se ttings. moused_port="/dev/cuaa0" # Set to your mouse port. moused_flags="" # Any additional flags to moused. Your configuration refers to a serial port, not the PS/2 mouse port. And moused is NOT running (moused_enable="NO")! You had better check the exact configuration when the lock up happened. As far as I can infer from the description above and the dmesg below, both the psm driver and moused has nothing to do the lock up. ... Kazu My misstatement on the psm issue. It would be indeed a serial mouse. The fact that moused_enable="NO" is due to the fact that I've had to explicitly disable the mouse in order to prevent the crash. The fact remains, however -- If moused_enable is set to YES, and the mouse is not present, the kernel crashes when trying to start moused, and it crashes VERY hard. It is a total freeze. This crash is the issue. I'm pursuing the fact that if this is reproducible elsewhere that it is unacceptable. I've now done a completely clean cvs and world build, and the same for the kernel. The problem is still occuring. This just doesn't seem at all acceptable to me that the kernel should simply hang upon moused startup when, for example, the mouse becomes disconnected. Like I stated previously, a kernel from January 24 does not exhibit this problem when moused is enabled with YES and there is no mouse connected. I've reproduced this on two machines, so I believe hardware can be ruled out. I'm now compelled to dig out a serial mouse to test to see how moused operates when the mouse is indeed present, and how -CURRENT handles the mouse being unplugged during system use. So, I'll pose a different question on this issue: Is anyone able to confirm or discount the issue of moused hanging the system when an expected serial mouse is not connected? Cheers, Scott The recent changes regarding moused and sio: usr.sbin/moused/moused.c revision 1.37 date: 2000/01/24 10:26:46; author: yokota; state: Exp; lines: +3 -1 Added the PnP ID for MouseSystems SmartScroll Mouse (serial mouse). This mouse may be a OEM version of Genius EasyScroll Mouse. (The mouse has three buttons on top, one side button and a wheel which also acts as a button. However, I know no way to activate the wheel, and it can only be used as an ordinary 3-buttons mouse :-) revision 1.36 date: 2000/01/20 13:39:08; author: yokota; state: Exp; lines: +3 -1 Add the PnP ID for the Logitech Cordless MouseMan Wheel (serial version). Both changes have nothing to do with the way moused accesses the serial port. sys/isa/sio.c revision 1.287 date: 2000/01/29 03:02:55; author: bde; state: Exp; lines: +9 -2 "Completed" the previous fix. Return ENOMEM on memory allocation failure in sioattach(), not ENXIO. Free resources before returning early in sioprobe() and sioattach(). revision 1.286 date: 2000/01/23 15:11:15; author: n_hibma; state: Exp; lines: +2 -2 Return ENXIO on error, not 0. Seems to have been skipped when converting to newbus. Reviewed by:bde Both changes have effect only when we fail to attach a serial port, which is not the case with your machine... Hmm. Any idea, Bruce? Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
