Re: Unusable PS/2 mouse
> > The problem springs, I think, from confusion between (Intellimouse) and > > (!Intellimouse). The box pretends to be an Intellimouse even when you > > don't have one [or this is what seems to happen in my case], and so > > FreeBSD detects that you have an Intellimouse. However, then it all > > goes wrong, and I don't really know why! > > >My mouse is always detected as a MouseMan+. Here is couple dmesg logs >from boots with and without monitor switch. We have two separate issues here. One is Logitech mouse support in the psm driver. The psm driver had been unable to handle some wheel mice models, including Logitech M-S48, until recently. It was fixed about a week ago both in -CURRENT and -STABLE. So, you should now be able to use your Logitech mouse, detected as MouseMan+, without the flags 0x100. The second is problems related to switch box products. As Ian summarized beautifully, some "intelligent" switch box products erroneously pretend the IntelliMouse is present even when it is not. This leads to data protocol mismatch and you will see the mouse cursor jumps around the screen and "psmintr: out of sync.." messages The dumb mechanical switch box, like the one you are talking about, may also cause problems. When you switch between computers using this type of switch box, the power to the mouse may be momentarily cut! and the mouse will be reset. After reset, the settings the psm driver set up for the mouse will be lost, and may lead to, again, the protocol mismatch problem. After the reset, the mouse will behave as the generic 2/3 button PS/2 mouse. If you don't switch between computers, I guess you won't have a problem. (But, this defeats the reason why you want to have the switch box in the first place!) People often say "I don't have a problem with this mouse and the dumb switch box in other OSes..." This is true, if these OSes do not have specific drivers for your mouse and are treating the mouse as the generic PS/2 mouse without a wheel. But, I suspect if you install mouse drivers from wheel mouse vendors in W*ndows, you will notice the problem when switching between computers. (No, I don't have a switch box here. I am just guessing :-) Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Unusable PS/2 mouse
>Is there any support for the wheel in FreeBSD/X, the moused man page seems >to suggest there is but I've not managed to get it to do anything yet. > >Paul. You will find the following URL useful to utilize the wheel in the X environment. http://www.inria.fr/koala/colas/mouse-wheel-scroll/ Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Kensington mouse (was: Re: Unusable PS/2 mouse)
>On Tue, 20 Jul 1999, Warner Losh wrote: > >> I had problems with the my Kensignton mouse in a box, but some fixes >> were made to -current that fixed the problems. A workaround is to set >> flags 0x20 (the NOIDPROBE) which forces it to behave as if it were a >> plain old 2 button (or in my case 3 button) mouse. >> > >For my Kensington (on -stable) I used 'flags 0x10' (NOCHECKSYNC) to kill >the out of sync messages. The only side effect I've seen is that the >cursor speed is faster [than with using the serial port connector]. Which model is it? Kensington sells quite a number of mouse/trackball products. The model Warner talked about is "Kensington Mouse in a Box Scroll". It has a wheel between two buttons. Is that the one you are talking about? (The problem regarding "Kensington Mouse in a Box Scroll" was fixed in both -CURRENT and -STABLE about a week ago.) If not, would you give -v option to the boot command when you boot the kernel and send me /var/run/dmesg.out, so that I can diagnose what the psm driver is doing to the mouse? Kazu [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for Alpha/AXP
>Does this look right? Without this patch, my AXP was memory faulting >every time it booted, in the dev2udev routine. I am afraid this is not quite right. Bruce, Doug and I are currently in discussion to fix this. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for Alpha/AXP
>> I am afraid this is not quite right. >> >> Bruce, Doug and I are currently in discussion to fix this. > >Hrm. Why does the AXP cons.c track udev_t while the x86 verson >doesn't? As best as I can tell, the AXP doesn't seem to need it any >more than the x86 does, unless I've missed something. As dev_t is now a struct, we cannot track dev_t for SYSCTL. It has to be udev_t. sys/i386/i386/cons.c should be doing the same as the alpha version, rather than vice versa. To quote Bruce: "alpha/alpha/cons.c should be identical with i386/i386/cons.c and not in a machine-dependent place. All current differences are bugs" :-) Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make release doc failure
> For those of you who may not have seen this, and my apologies >if I haven't seen it and everyone else has... [...] >===> en/handbook >/usr/local/bin/jade -V html-manifest -ioutput.html -c /usr/doc/share/sgml/cat >alog -c /usr/local/share/sgml/docbook/dsssl/modular/catalog -c /usr/local/shar >e/sgml/docbook/catalog -c /usr/local/share/sgml/jade/catalog -d /usr/doc/shar >e/sgml/freebsd.dsl -t sgml handbook.sgml >/usr/local/bin/jade:serialcomms/chapter.sgml:2016:2:E: general entity "man.boo >t.8" not defined and no default entity >/usr/local/bin/jade:serialcomms/chapter.sgml:2016:19:E: general entity "man.lo >ader.8" not defined and no default entity >/usr/local/bin/jade:serialcomms/chapter.sgml:2680:12:E: general entity "man.lo >ader.conf.5" not defined and no default entity >*** Error code 1 [...] You need the following patch to doc/share/sgml/man-refs.ent. I submitted this to Nik this morning. Kazu Index: man-refs.ent === RCS file: /src/CVS/doc/share/sgml/man-refs.ent,v retrieving revision 1.6 diff -u -r1.6 man-refs.ent --- man-refs.ent1999/06/07 22:33:12 1.6 +++ man-refs.ent1999/07/19 10:06:11 @@ -79,6 +79,7 @@ + @@ -92,6 +93,7 @@ + @@ -106,6 +108,7 @@ + To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VMware X11 and -current
>At this point we must still be in freebsd xinit, then XF86_VMware(linux >server) get started. I'm running a linux X server under freebsd. Under >3.2R all I had to do was change the symlink for X to point to XF86_VMware, >under -current /dev/tty0 can't be found. > >Where was linux "/dev/tty0" coming from under emulation in 3.2R, the >kernel device struct changed under -current? > >I made these symlinks as suggested, ttyp0 -> tty0 and ttyp4 -> tty4 gave ~ ~ Symlinks should be ttyv0 -> tty0 and ttyv4 -> tty4. Notice ttyv*, not ttyp* ~ ~ Kazu >me errors with VT_ACTIVE, VT_WAITACTIVE, VT_GETMODE. I should have to >make these symlinks they should be handled under emulation, just like >3.2R. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VMware X11 and -current
>> >At this point we must still be in freebsd xinit, then XF86_VMware(linux >> >server) get started. I'm running a linux X server under freebsd. Under >> >3.2R all I had to do was change the symlink for X to point to XF86_VMware, >> >under -current /dev/tty0 can't be found. >> > >> >Where was linux "/dev/tty0" coming from under emulation in 3.2R, the >> >kernel device struct changed under -current? >> > >> >I made these symlinks as suggested, ttyp0 -> tty0 and ttyp4 -> tty4 gave >> ~ ~ >> Symlinks should be ttyv0 -> tty0 and ttyv4 -> tty4. >> >> Notice ttyv*, not ttyp* >> ~ ~ >Hello > > I had tried it both ways, when I said having them symlinked to >ttyv0 and ttyv4 would panic with "fatal trap 12" It was suggested that I >use ttyp0 and ttyp4 respectfully. I don't think ttyp* will work. I don't know who suggested it to you. I have never run Linux X server binaries on FreeBSD, but, I can assure you that ttyp* won't work. The ttyp* refers to the "pseudo" tty. The Linux X server opens tty0 and tty4 which are "virtual terminals" in Linux. Virtual terminals are named ttyv* in FreeBSD. If the Linux X server are ever made to work in FreeBSD, it must be ttyv* which the X server should be fooled to access. VT_ACTIVATE, VT_WAITACTIVE and VT_GETMODE ioctls are valid only for virtual terminals ttyv* and certainly result in error for pseudo ttys. I suspect that the fatal trap you are seeing has little to do with ttyv* symlinks and the real culprit lies somewhere else. Kazu >Are you running a linux Xserver under freebsd, XF86_VMware? Why arn't >these needed under emulation with freebsd 3.2R? This is the main thing >I'm looking for in the code. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problem using XFree86 3.3.4 w/ VESA kernel option
>There have been a few posts on -misc and on the XFree86 newsgroup >reporting problems when using certain video adapters (The Voodoo 3 was >one of them) w/ XFree86 3.3.4 on CURRENT. Symptoms varied from >"pixelisation" when switching back to text mode, to "ghost" white lines >when dragging windows, etc... Would you give me the pointer to these posts? I seem to be unable to locate the posts you are referring to. Kazu >After a bit of digging, I found that removing the VESA kernel option >cured the problem on my Voodoo 3 2000 PCI adapter. I would be >interesting to know whether this is the case for all other hardware? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VESA module doesn't work with ATI Mach64 RagePro
>I have switched graphics card from S3Virge to ATI Mach64 RagePro rev 92 >with 8 MB RAM a I have noticed that VESA module doesn't work with this >graphics card on my -current box - I can't use VESA_XXX console modes now. >Command kldstat says there is loaded module vesa.ko. No errors are >reported when I'm trying to unload/load vesa.ko module. Kernel reports >during boot: > >VESA: v2.0, 8192k memory, flags:0x0, mode table:0xc024f622 (122) >VESA: ATI MACH64 > >Command "vidcontrol -i mode" reports lines below. It looks VESA module >can't read mode table properly. But simple VESA utilities in DOS are capable >to determine all VESA modes supported by ATI Mach64 card with VESA 2.0 BIOS. >Is this known problem? Or should I invetigate this problem further? There is a good possibility that the VESA BIOS extension for this card is provided in a DOS TSR program and the VESA BIOS entry in the ROM BIOS is just a stub. Such implementation is allowed in the VESA spec. Please examine the manual of the video card for information. Kazu >mode# flags typesize font window linear buffer >-- > 0 (0x000) 0x0001 T 40x25 8x8 0xb8000 32k 32k 0x 32k [...] > 45 (0x02d) 0x T 90x43 8x8 0xb8000 32k 32k 0x 32k > 46 (0x02e) 0x0001 T 90x50 8x8 0xb8000 32k 32k 0x 32k > 48 (0x030) 0x0001 T 90x60 8x8 0xb8000 32k 32k 0x 32k >112 (0x070) 0x T 80x43 8x8 0xb8000 32k 32k 0x 32k >113 (0x071) 0x0001 T 80x43 8x8 0xb8000 32k 32k 0x 32k To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problems with 4.0 keyboard input!
[...]
>I also get the keyboard problem periodically, and I've been
>trying to isolate just what I do to cause it. Generally, if I
>reboot and don't hit a key before FreeBSD boots, it never
>happens. If I tap enter to abort the countdown, the keyboard
>scrambles perhaps one time in five.
If you hit the keyboard at the "wrong" moment during keyboard
initialization, the keyboard driver may get confused.
In your case, you type something before the kernel is loaded and that
seems to be causing the trouble.
Such key input should be discarded by the keyboard driver before it
tries to initialize the keyboard. There may be a nasty timing problem
here...
As a temporary workaround, please apply the following patch to
/sys/dev/atkbd.c and see how it works.
Kazu
>Resetting seems to be the only remedy. This persists with two
>different keyboard models and on unplugging and reinserting the
>keyboard.
Index: atkbd.c
===
RCS file: /src/CVS/src/sys/dev/kbd/atkbd.c,v
retrieving revision 1.12
diff -u -r1.12 atkbd.c
--- atkbd.c 1999/07/18 06:16:25 1.12
+++ atkbd.c 1999/08/14 03:10:40
@@ -1153,7 +1178,7 @@
}
/* save the current controller command byte */
- empty_both_buffers(kbdc, 10);
+ empty_both_buffers(kbdc, 200);
c = get_controller_command_byte(kbdc);
if (c == -1) {
/* CONTROLLER ERROR */
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: console support (was RIDE for BSD)
>I second this. I'm not a linux user, but as a FreeBSD newbie >I had a lot of trouble getting anywhere with console programs, >esp. emacs and various IDE's that I tried to install. The key >board mapping was difficult/impossible to figure out, and it [...] If the program in question is written so that it will properly use termcap, and your TERM environment variable is set correctly, this sort of thing shouldn't be happening. Emacs definitely works on cons25. If it isn't, there must be something wrong with your terminal settings. If the program dosn't work because it assumes a particular terinal type, it won't work on many serial terminal and X terminal emulators. This is not the way the UNIX program should be written. I would rather blame the programmer who wrote such programs... >> -Original Message- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED]]On Behalf Of Jonathon >> McKitrick >> Sent: Tuesday, January 04, 2000 9:42 AM >> To: Alexey N. Dokuchaev >> Cc: Adam; [EMAIL PROTECTED] >> Subject: Re: RIDE for BSD >> >> On Tue, 4 Jan 2000, Alexey N. Dokuchaev wrote: >> >> >Probably improving terminal would be one of the things Fbsd might consider >> >for future releases? >> > >> >And one more thing: until I wait for cool FreeBSD native terminal support, >> >I consider copying linux-terminal descrition for my linux box termcap. Did >> >anyone do anything like this before? What problems/pitfalls should I >> >encounter? Copying the linux terminal description won't solve anything, because the Linux console and the FreeBSD console drivers are DIFFERENT. Importing the termcap entry of the linux console and use it for FreeBSD console simply won't work. >> I must admit, this is one concept i do not understand. I mean, it makes >> sense to leave the system freely configurable, but wouldn't it make sense >> that the default config be useable? For exampl,e little things, like >> linux uses bash as the default shell. [...] You can use bash in FreeBSD as well, and it works. Only that bash is not the default shell in FreeBSD :-) This is because of licensing reason. And I believe bash will not be made to default in the future too. The default configuration in FreeBSD is usable. It is unfortunate that you don't like this default configuration because it doesn't look like Linux. But, what should we do? We cannot please everybody. You see, if we adopt one configuration, I am sure someone will say "Why on earth? I don't like this configuration." If there is a sound technical reason to use one particular configuration, we can persuade people. But, if it concerns people's preference, we are in LOOSE-LOOSE situation. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: World Breakage in sys/modules/ukbd
Oops, sorry. Apply the attached patch to /sys/modules/ukbd/Makefile.
Kazu
>A buildworld done in the last hour with a fresh cvsup fails with the
>following:
>
>touch opt_usb.h
>echo > ukbd.h
>echo '#define KBD_INSTALL_CDEV 1' > opt_kbd.h
>rm -f .depend
>mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I- -I. -I@ -I@/../
>include -I/usr/obj/usr/src/i386/usr/include /usr/src/sys/modules/ukbd/../../
>dev/usb/ukbd.c
>/usr/src/sys/modules/ukbd/../../dev/usb/ukbd.c:46: opt_ukbd.h: No such file or
>
>directory
>mkdep: compile failed
>*** Error code 1
[...]
Index: Makefile
===
RCS file: /src/CVS/src/sys/modules/ukbd/Makefile,v
retrieving revision 1.8
diff -u -r1.8 Makefile
--- Makefile1999/11/28 18:53:31 1.8
+++ Makefile1999/12/13 10:07:14
@@ -5,15 +5,18 @@
.PATH: ${.CURDIR}/../../dev/usb
KMOD= ukbd
SRCS= bus_if.h device_if.h vnode_if.h \
- opt_usb.h ukbd.h opt_kbd.h \
+ opt_usb.h ukbd.h opt_kbd.h opt_ukbd.h \
ukbd.c
NOMAN =
-CLEANFILES = ukbd.h opt_kbd.h
+CLEANFILES = ukbd.h opt_kbd.h opt_ukbd.h
ukbd.h:
echo > ukbd.h
opt_kbd.h:
echo '#define KBD_INSTALL_CDEV 1' > opt_kbd.h
+
+opt_ukbd.h:
+ echo > opt_ukbd.h
.include
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: rpc.statd won't fire on friday's build
Hi, I am experiencing the same problem on the 4.0-CURRENT system built from the source around Saturday. Another -CURRENT box, for which 'make world' was done from the source about a week ago, appears to have no problem. I suspect `portmap' is somewhat broken. In addition to `rpc.statd', `nfsd' and `mountd' are also unable to register ports. nfsd:[88]: can't register with udp portmap mountd[86]: can't register mount Kazu >no idea what i've done here. > >friday's cvsup and build...new kernel...installed on 2 systems. on one of >the systems, rpc.statd will not run, gets: > >rpc.statd: unable to register (SM_PROG, SM_VERS, udp) > >this particular system has about 50 ip's assigned to lo0...and that has >worked fine as is for months, inspite of all the verbage here about >netmasks and such. loopback IS configured. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ps/2 mouse and new 6btm bios - bug report
>i have uploaded a new bios (6btm0c23.bin, 1999/12/23) into Chaintech 6BTM >motherboard and faced with a problem. my Genius NewScroll PS/2 mouse is ~ NetScroll? >not functioning under FreeBSD 4.0 OS anymore. the kernel just ignores a >mouse or detects it as Generic PS/2 mouse (instead of >NetMouse) accompanying this by the messages: > >psm0: cannot get data >psm0: cannot get status > >anyway, the mouse does not work. > >the "mouse" string in kernel config is: > >device psm0 at atkbdc? irq 12 Would you give "boot -v" to the boot loader when starting the system, and send me the entire `dmesg' output? Does the BIOS setup menu have anything related to the PS/2 mouse port? What is your CPU? You said you wanted to use the latest BIOS because it supports Coppermine. Did you use Coppermine with the older BIOS and find the PS/2 mouse working? Or was it another CPU? Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Moused hanging...
>Hi, I've noticed a strange problem with vidcontrol and moused recently >with current. I also had the same problem about 3 weeks back, and it >doesn't seem to be occurring all that regularly. What type of mouse is it, PS/2, serial, or USB? Is the power supply in your system big enough? Is the mouse's cable and connector look OK? >Here's what I was doing: I had just exited out of X, XFree86 Version >3.9.17. I had two sessions of bladeenc going simultaneously (if that even >matters). I'm guessing maybe the issue is with the PCI bus being accessed >by moused and the ATA driver at the same time, since bladeenc does >generate some disk activity. Anyway, I heard a `pop' through my speakers, >and at the same time, moused went dead. I cannot immediately see why only the mouse suddenly died, while the rest of the system was healthy, >I su'd to root, killed and >restarted moused. Please try `kill -HUP' to moused next time. This will make moused reopen the mouse port. >I could not get my moused cursor back (tried vidcontrol >-m off ; vidcontrol -m on a couple of times). I never heard this before. When did you make this kernel? Would you tell me the revision number of /sys/dev/syscons/syscons.c and /sys/dev/syscons/scmouse.c? >The only way I could get moused to work again was to >reboot. (???) Actually, this is a minor issue, but it is an >inconvenience, since I have to reboot to get vidcontrol to work >again. I'm sure some people have seen this. The last time this happened, >my mouse in X stopped responding. This time, though, no X was running. > >As for the cause, I'm sure it is a PCI/ISA bus issue. I am not sure. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VESA modes broken in syscons driver
>It seems that recent kernels have problems initialising syscons in VESA pixel >modes. Particularly "vidcontrol VESA_800x600" (actually "vidcontrol >VESA_800x600 < /dev/ttyv1" to see what's going on ttyv0) command make my kerne >l >panicing with the following output: [...] >Looking into nm /kernel output I figured that 0xc01baee9 pointer is within >sc_mouse_move procedure, however I doesn't use moused. Moreover, disabling >mouse support in syscons (SC_NO_SYSMOUSE) seems like a temporary workaround to >this bug. Thank you for the report. Apply the following patch to /sys/dev/syscons/scmouse.c and see if it fixes the problem. Kazu Index: scmouse.c === RCS file: /src/CVS/src/sys/dev/syscons/scmouse.c,v retrieving revision 1.10 diff -u -r1.10 scmouse.c --- scmouse.c 2000/01/20 13:21:45 1.10 +++ scmouse.c 2000/01/24 12:56:02 @@ -124,8 +124,11 @@ s = spltty(); scp->mouse_xpos = x; scp->mouse_ypos = y; -scp->mouse_pos = scp->mouse_oldpos = - (y/scp->font_size - scp->yoff)*scp->xsize + x/8 - scp->xoff; +if (ISGRAPHSC(scp)) + scp->mouse_pos = scp->mouse_oldpos = 0; +else + scp->mouse_pos = scp->mouse_oldpos = + (y/scp->font_size - scp->yoff)*scp->xsize + x/8 - scp->xoff; splx(s); } To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
[PATCH] Please test the PS/2 mouse driver patch
I wrote a patch for the psm driver to add support for several PS/2 mice. It is in http://www.freebsd.org/~yokota/ps2mice-24Jan2000.tar.gz. I am attaching README included in the patch. Thank you. Kazu -- PS/2 mouse driver patch for 4.0-CURRENT 24 January 2000 Kazutaka YOKOTA, [EMAIL PROTECTED] This patch adds support for the following PS/2 mice to the psm driver. - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. - MouseSystems SmartScroll Mouse: 3 buttons on top, 1 side button and a wheel. - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. (The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected, but is quietly ignored by the psm driver, as we don't have framework to support it.) There are two diff files: ps2mice.diff moused.diff Apply them to 4.0-CURRENT as follows: cd /sys/isa patch < ps2mice.diff cd /usr/src/usr.sbin/moused patch < moused.diff Rebuild the kernel and moused. (Note that you need to copy /sys//include/mouse.h to /usr/include/machine/mouse.h before you rebuild moused.) The following is the list of files modified by this patch. /sys/alpha/include/mouse.h /sys/dev/kbd/atkbdcreg.h /sys/i386/include/mouse.h /sys/isa/psm.c /usr/src/usr.sbin/moused/moused.c This patch is for 4.0-CURRENT. Although I personally have not tested yet, I expect you can apply it to 3.4-STABLE without much difficulty. (FYI, /sys/isa/psm.c is for alpha only in 3.4-STABLE. psm.c for i386 is in /sys/i386/isa in 3.4-STABLE.) Kazu -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VESA_800x600 mode -> kernel crash at boot time?
>Could someone with a recent (ie < 1 week) -CURRENT confirm whether they >have problems booting their system when setting allscreens_flags to >"VESA_800x600"? I have now verified the problem with two different >systems -- Compaq Professional Workstation 5100 (UP, Matrox Millenium >II) and Intel Providence PR440FX (SMP, Matrox G200) -- neither of which >exhibited the problem previously. This was just fixed in the following commit. Kazu - yokota 2000/01/24 05:44:39 PST Modified files: sys/dev/syscons scmouse.c Log: Fix a bug exposed by the previous commit. Do not use scp->font_size, if the screen is in a graphics mode Reported by: Maxim Sobolev <[EMAIL PROTECTED]> Revision ChangesPath 1.11 +6 -3 src/sys/dev/syscons/scmouse.c - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Moused hanging...
>Well, it's an ISA bus mouse. I bought this thing back in 1994. It's
>an IMSI mouse. I'll bet this stupid thing could last for 5 more
>years. :-)
>
>> I cannot immediately see why only the mouse suddenly died, while the
>> rest of the system was healthy,
>
>Yeah, I don't know. It happens extremely rarely. Maybe it's because
>I have an ISA bus mouse. I suppose I really should be using a PS/2 or
>USB mouse. (BTW, is a PS/2 mouse a type of bus mouse?)
This may be "THE GREAT CASE OF LOST INTERRUPTS" :-) I haven't heard
that the mse driver looses interrupts, but there may be a possibility
that we loose interrupts on ISA bus under heavy load.
The following patch will add a watch dog timer to the mse driver.
When the bus mouse interrupt seems to be lost, it will print "mse0:
lost interrupt?" and forcefully read from the bus mouse port.
I hope it may get the thing going again.
Kazu
Index: mse.c
===
RCS file: /src/CVS/src/sys/i386/isa/mse.c,v
retrieving revision 1.48
diff -u -r1.48 mse.c
--- mse.c 1999/10/06 13:01:55 1.48
+++ mse.c 2000/01/27 14:25:17
@@ -95,6 +95,7 @@
};
static ointhand2_t mseintr;
+static timeout_t msetimeout;
/*
* Software control structure for mouse. The sc_enablemouse(),
@@ -114,6 +115,8 @@
int sc_buttons;
int sc_bytesread;
u_char sc_bytes[MOUSE_SYS_PACKETSIZE];
+ struct callout_handle sc_callout;
+ int sc_watchdog;
mousehw_t hw;
mousemode_t mode;
mousestatus_t status;
@@ -263,6 +266,7 @@
idp->id_ointr = mseintr;
sc->sc_port = idp->id_iobase;
+ callout_handle_init(&sc->sc_callout);
sc->mode.accelfactor = (idp->id_flags & MSE_CONFIG_ACCEL) >> 4;
make_dev(&mse_cdevsw, unit << 1, 0, 0, 0600, "mse%d", unit);
make_dev(&mse_cdevsw, (unit<<1)+1, 0, 0, 0600, "nmse%d", unit);
@@ -293,6 +297,8 @@
sc->sc_obuttons = sc->sc_buttons = MOUSE_MSC_BUTTONS;
sc->sc_deltax = sc->sc_deltay = 0;
sc->sc_bytesread = sc->mode.packetsize = MOUSE_MSC_PACKETSIZE;
+ sc->sc_watchdog = FALSE;
+ sc->sc_callout = timeout(msetimeout, dev, hz*2);
sc->mode.level = 0;
sc->status.flags = 0;
sc->status.button = sc->status.obutton = 0;
@@ -320,6 +326,8 @@
struct mse_softc *sc = &mse_sc[MSE_UNIT(dev)];
int s;
+ untimeout(msetimeout, dev, sc->sc_callout);
+ callout_handle_init(&sc->sc_callout);
s = spltty();
(*sc->sc_disablemouse)(sc->sc_port);
sc->sc_flags &= ~MSESC_OPEN;
@@ -545,6 +553,26 @@
}
/*
+ * msetimeout: watchdog timer routine.
+ */
+static void
+msetimeout(arg)
+ void *arg;
+{
+ dev_t dev;
+ struct mse_softc *sc;
+
+ dev = (dev_t)arg;
+ sc = &mse_sc[MSE_UNIT(dev)];
+ if (sc->sc_watchdog) {
+ printf("mse%d: lost interrupt?\n", MSE_UNIT(dev));
+ mseintr(MSE_UNIT(dev));
+ }
+ sc->sc_watchdog = TRUE;
+ sc->sc_callout = timeout(msetimeout, dev, hz);
+}
+
+/*
* mseintr: update mouse status. sc_deltax and sc_deltay are accumulative.
*/
static void
@@ -602,6 +630,8 @@
sc->status.flags |= ((dx || dy) ? MOUSE_POSCHANGED : 0)
| (sc->status.button ^ but);
sc->status.button = but;
+
+ sc->sc_watchdog = FALSE;
/*
* If mouse state has changed, wake up anyone wanting to know.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Problems installing FreeBSD 4.0 20000125-CURRENT
>>> 3. On the first reboot after installing, the keyboard was in a funny >>> state. > >> Urk, can't reproduce it. I need a reproducible sequence of operations >> before we'll have any hope of tackling this one. > >>> Control-alt-del definitely didn't work, so I had to power off and >>> reboot. This hasn't repeated itself. > >> Same here. > >I have on a number of occasions had my laptop boot with a >non-functional keyboard. Sometimes the keyboard is just locked; other >times it generates garbage. Never managed to isolate the >circumstances in which this happened (but it didn't happen with a >kernel from last September or there-abouts). Haven't had it happen on >a desktop or server yet. I have had reports on similar lockup in both 4.0-CURRENT and 3.X. I personally have not been able to reproduce it, but now my new sand box machine exhibits this problem occasionally. The I/O access to the AT keyboard by the atkbd driver have not changed much for the last couple of years, despite massive source tree reorganization. And yes, problem reports started to pop-up since sometime around the last summer. I have not been able to track down the cause of the problem, but am suspecting possibility of the clock/timer problem. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problems installing FreeBSD 4.0 20000125-CURRENT
>I seem to have this problem occasionaly, the keyboard keymap gets all screwed >up somehow, and the only way to get out is to hit the reset button. But I've >been having the problem for a long time, and with different boxes. It happens >about every 1 out of 15 reboots but randomly. I haven't been able to connect >it to any event or anything, but I notice that hitting keys during boot can >increase the probability of it occurring, but again, nothing reproducible. If you hit any key while the keyboard driver is trying to initialize the keyboard, there is a good possibility that the driver will be screwed. But, it mustn't show problems if you hit the keyboard during the boot loader or after the driver is attached... Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problems installing FreeBSD 4.0 20000125-CURRENT
>> In message <[EMAIL PROTECTED]> Mike Smith writes: >> : It doesn't do anything to the keyboard, it just calls the BIOS to find >> : out whether keys have been pressed. >> >> I've been seeing the hit twice fast problem for months. > >It's always been a problem; we don't understand the mechanics of it >however. Susceptibility varies widely between systems, and the best >hypothesis I've been able to come up with is that there are issues with >taking interrupts in vm86 mode; possibly the BIOS is being re-entered in >a fashion it doesn't like. I wonder if the keyboard interrupt is blocked for a prolonged period in the boot loader because of vm86, and quite a number of (up to 16 or something) scan codes are waiting in the keyboard to be received by the host computer, when the kernel is loaded. The keyboard driver atkbd tries to flush pending scan codes, left over from the boot loader, before it starts initializing the keyboard. It may be failing to flush all the pending scan codes if there are too many of them. The following patch will make the driver wait slightly longer to flush inputs. I would like to see if this makes any difference. I should come up with something better this, though... Kazu Index: atkbd.c === RCS file: /src/CVS/src/sys/dev/kbd/atkbd.c,v retrieving revision 1.22 diff -u -r1.22 atkbd.c --- atkbd.c 2000/01/20 13:32:53 1.22 +++ atkbd.c 2000/01/28 00:47:27 @@ -1085,7 +1098,7 @@ } /* flush any noise in the buffer */ - empty_both_buffers(kbdc, 10); + empty_both_buffers(kbdc, 200); /* save the current keyboard controller command byte */ m = kbdc_get_device_mask(kbdc) & ~KBD_KBD_CONTROL_BITS; To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH] Please test the PS/2 mouse driver patch
>Do you have specs on the Trackpoint PS/2 mice found on Thinkpads? No. >The version on my 770X has a double click by "pushing hard on the >trackpoint" feature. It also has the ability to do the scroll >thing if you hold the middle mouse button and move the trackpoint. You mean, there features are available in W*ndoes, but not in FreeBSD? There can be two possible explanations: a) These features are implemented in the device firmware level and need to be explicitly activated by the driver software on the host computer. W*ndows driver knows it, but our psm driver doesn't. b) These features are entirely implemented by the W*ndows driver software. The TrackPoint itself is behaving just like the ordinary 2, or 3, button pointing device. The W*ndows driver is so smart, our psm driver isn't :-) Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Keyboard problem (was: Re: Problems installing FreeBSD 4.0 20000125-CURRENT)
Ok, guys.
This is another patch for the atkbd driver. I expect this one is
better than my previous one. Remove the previous patch and try this
one instead. Stress the keyboard (like hitting the Return key twice
when booting the system), and see if it works.
Thank you.
Kazu
>> I have on a number of occasions had my laptop boot with a
>> non-functional keyboard. Sometimes the keyboard is just locked; other
>> times it generates garbage. Never managed to isolate the
>> circumstances in which this happened (but it didn't happen with a
>> kernel from last September or there-abouts). Haven't had it happen on
>> a desktop or server yet.
>
>I have seen this on numerious occasion, but have never tracked it down
>to any one specific thing. All on desktop and servers, but thats
>only because we don't do laptops.
>
>I have not seen it in quite some time (about a month), so I am thinking
>it has probably been unknowingly fixed someplace. I'll keep an eye
>out for it.
>
>--
>Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED]
Index: atkbd.c
===
RCS file: /src/CVS/src/sys/dev/kbd/atkbd.c,v
retrieving revision 1.22
diff -u -r1.22 atkbd.c
--- atkbd.c 2000/01/20 13:32:53 1.22
+++ atkbd.c 2000/01/28 02:11:50
@@ -1084,8 +1097,11 @@
return ENXIO;
}
+ /* temporarily block data transmission from the keyboard */
+ write_controller_command(kbdc, KBDC_DISABLE_KBD_PORT);
+
/* flush any noise in the buffer */
- empty_both_buffers(kbdc, 10);
+ empty_both_buffers(kbdc, 100);
/* save the current keyboard controller command byte */
m = kbdc_get_device_mask(kbdc) & ~KBD_KBD_CONTROL_BITS;
@@ -1133,8 +1148,11 @@
return EIO;
}
+ /* temporarily block data transmission from the keyboard */
+ write_controller_command(kbdc, KBDC_DISABLE_KBD_PORT);
+
/* save the current controller command byte */
empty_both_buffers(kbdc, 200);
c = get_controller_command_byte(kbdc);
if (c == -1) {
/* CONTROLLER ERROR */
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: rpc.statd won't fire on friday's build
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 should have just one word, "auto". Kazu >I am experiencing the same problem on the 4.0-CURRENT system >built from the source around Saturday. Another -CURRENT box, >for which 'make world' was done from the source about a week ago, >appears to have no problem. > >I suspect `portmap' is somewhat broken. In addition to `rpc.statd', >`nfsd' and `mountd' are also unable to register ports. > >nfsd:[88]: can't register with udp portmap >mountd[86]: can't register mount > >Kazu > >>no idea what i've done here. >> >>friday's cvsup and build...new kernel...installed on 2 systems. on one of >>the systems, rpc.statd will not run, gets: >> >>rpc.statd: unable to register (SM_PROG, SM_VERS, udp) >> >>this particular system has about 50 ip's assigned to lo0...and that has >>worked fine as is for months, inspite of all the verbage here about >>netmasks and such. loopback IS configured. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: syscons: cursor going off simultaneously on all vtys
>On Tue, Feb 08, 2000 at 11:44:41PM +0900, Kazutaka YOKOTA wrote: >> >On a recent -current (don't know if this is a known problem), >> >when cursor is switched off on one virtual console, it is >> >turned off on *all* virtual consoles. Any patch to try? >>=20 >> Do you mean the "text" cursor, or the "mouse" cursor? >>=20 >text, here is some additional info: > >vidcontrol -c destructive >echo -n "=1B[=3D14;12C" (cursor will go away) >echo -n "=1B[=3D10;12C" (cursor will appear again) The text cursor shape is "global" property, in the sense that if you change it in one vty, the cursor shape in the other vtys changes too. When you run "vidcontrol -c destructive", you will have the "blinking underline" cursor in ALL vtys. This has been so for a long time. The escape sequence ESC[=nC invokes the normal/blink/destructive cursor. This has effect in all vtys at once, just as "vidcontrol -c". The escape sequence ESC[=n;mC sets the cursor height. syscons.c used to change the cursor height in the current vty only. This was considered a bug, because it is inconsistent with the way ESC[=nC works, and corrected in 1.307 (around June 1999). What you are now seeing is the correct and expected result. The previous behavior was considered incorrect. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: syscons: incorrect behavior of blinking cursor
>On Wed, Feb 09, 2000 at 08:35:07PM +0200, Ruslan Ermilov wrote:
>> Hi!
>>
>> 1. Set cursor "blinking" or "destructive" (SC_BLINK_CURSOR)
>> 2. Press Scroll Lock (cursor will go away)
>> 3. Switch to another vtyX
>> 4. Switch to the original vty, where you pressed Scroll Lock
>> 5. Watch the cursor will appear at the same position as it was on vtyX.
>>
>The following patch fixes the problem.
Thank you for the report and patch.
While your patch seems to work, it looks to me it's slightly over-kill
for this problem; we shouldn't need to call sc_remove_cursor_image()
every time the screen is refreshed in scrn_upcate().
Because this problem is caused by exchange_scr() not removing the text
cursor when changing to the vty where the cursor is not currently
shown, we had better fix exchange_scr().
The attached patch is simpler and fixes the problem. I verified it
works here. Please test. Thank you.
Kazu
Index: syscons.c
===
RCS file: /src/CVS/src/sys/dev/syscons/syscons.c,v
retrieving revision 1.335
diff -u -r1.335 syscons.c
--- syscons.c 2000/01/29 15:08:49 1.335
+++ syscons.c 2000/02/10 01:52:28
@@ -2335,6 +2337,8 @@
/* save the current state of video and keyboard */
sc_move_cursor(sc->old_scp, sc->old_scp->xpos, sc->old_scp->ypos);
+if (!ISGRAPHSC(sc->old_scp))
+ sc_remove_cursor_image(sc->old_scp);
if (sc->old_scp->kbd_mode == K_XLATE)
save_kbd_state(sc->old_scp);
>Index: scvgarndr.c
>===
>RCS file: /usr/FreeBSD-CVS/src/sys/dev/syscons/scvgarndr.c,v
>retrieving revision 1.5
>diff -u -p -r1.5 scvgarndr.c
>--- scvgarndr.c2000/01/29 15:08:47 1.5
>+++ scvgarndr.c2000/02/09 23:52:53
>@@ -225,10 +225,8 @@ vga_txtcursor(scr_stat *scp, int at, int
> at%scp->xsize,
> at/scp->xsize);
> } else {
>- if (scp->status & VR_CURSOR_ON)
>- (*vidsw[adp->va_index]->set_hw_cursor)(adp,
>- -1, -1);
> scp->status &= ~VR_CURSOR_ON;
>+ (*vidsw[adp->va_index]->set_hw_cursor)(adp, -1, -1);
> }
> } else {
> scp->status &= ~VR_CURSOR_BLINK;
>Index: syscons.c
>===
>RCS file: /usr/FreeBSD-CVS/src/sys/dev/syscons/syscons.c,v
>retrieving revision 1.335
>diff -u -p -r1.335 syscons.c
>--- syscons.c 2000/01/29 15:08:49 1.335
>+++ syscons.c 2000/02/09 23:52:53
>@@ -1806,7 +1806,8 @@ scrn_update(scr_stat *scp, int show_curs
> scp->cursor_pos));
> }
> }
>-}
>+} else
>+ sc_remove_cursor_image(scp);
>
> #ifndef SC_NO_CUTPASTE
> /* update "pseudo" mouse pointer image */
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: here's some feedback on 4.0-RC ...
>> o Is there a way to increase the number of lines of console output that are >> "remembered" when you hit Scroll-Lock. Is this the MSGBUF_SIZE parameter? >> What would be the consequences of increasing this slightly? e. > >The value compiled into the kenrnel is set with SC_HISTORY_SIZE; see LINT or >syscons(4). I normally up this to 500. The problem with that is that syscons >apparently preallocates all the history memory, for all the virtual consoles. >Since MAXCONS defaults to 16, that can be a lot of memory. This is not true. syscons does not reserve history buffers beforehand. It allocates a buffer for a vty when the vty is first opened. The history buffer for the first vty (/dev/ttyv0) gets slightly different treatment; it is allocated as soon as syscons can allocate kernel memory via malloc(). In any case, setting a large value to SC_HISTORY_SIZE shouldn't immediately bloat the kernel. Kazu >Perhaps a modest increase in the default SC_HISTORY_SIZE, but with sysinstall >doing a CONS_HISTORY ioctl to increase the value on just the first vty? 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
REQUEST FOR COMMENTS: a few patches for -CURRENT
I have prepared a set of patches which I intend to commit to the
-CURRENT branch after the code freeze is lifted.
http://people.freebsd.org/~yokota/patches-4.0-CURRENT.12Feb2000.tar.gz
Please have a look and send me your comments.
I am attaching notes extracted from README in the above file. (Please
examine README first when using the patches. It contains some more info
than extracted here.)
Kazu
=
Assorted patches for 4.0-CURRENT.
12 February 2000
Kazutaka YOKOTA
This archive contains assorted patches for 4.0-CURRENT. I intend
to commit them to the source tree once the code freeze on 4.0-CURRENT
is over.
I would be grateful if you could review and test them. Thank you.
PS: I am also working on the following patch:
- "propeller" code submitted by [EMAIL PROTECTED]
(in kern/15436: syscons extension: "propellers" )
=
Patch #1: mse.diff
File: /sys/i386/isa/mse.c
- `Newbus'ified the driver.
- Properly keep track of resources (I/O ports and irq).
- Use bus_space_read/write() to access the ports.
- Add PnP IDs.
...
(You may ask if we should bother with the mse driver. Yes, the bus
mouse is a dying beast. I am doing this just for practice :-)
=
Patch #2: psm.diff
File: /sys/isa/psm.c, /sys/i386/include/mouse.h, /sys/alpha/include/mouse.h,
/sys/dev/kbd/atkbdcreg.h
- Add Support for the following PS/2 mice: MS IntelliMouse Explorer,
Genius NetScroll Optical, MouseSystems SmartScroll, IBM ScrollPoint,
A4 Tech 4D/4D+ mice.
- Add driver configuration flags which correspond to the kernel
options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't
need to recompile the kernel when we need these functions.
- Properly keep track of the irq resource.
...
=
Patch #3: moused.diff
File: /usr/src/usr.sbin/moused/moused.c
- Add support for IntelliMouse Explorer, NetScroll Optical, SmartScroll,
Scroll Point, and 4D/4D+ mice.
- Add a couple of serial mouse PnP IDs.
- Extend the `-z' option so that the second wheel (or the horizontal
movement of the `scroll' device) can be mapped to buttons.
=
Patch #4: atkbdc.diff
File: /sys/dev/kbd/{atkbdc.c, atkbdcreg.h, atkbd.c, atkbdreg.h},
/sys/isa/{atkbdc_isa.c, atkbd_isa.c}
- Properly keep track of I/O port resources.
- Use bus_space_read/write() to access the ports.
- Add PnP IDs.
=
Patch #5: vga.diff, vgavar.h, vga_pci.c
File: /sys/dev/fb/{fb.c, fbreg.h, vga.c, vgareg.h}, /sys/isa/vga_isa.c
/sys/conf/{files.i386, files.alpha}, /sys/pci/pcisupport.c,
/sys/sys/fbio.h
- Add PCI bus front-end to the vga driver so that we no longer see
the PCI vga card recognized twice during boot.
- Remove FB_INSTALL_CDEV, which was never functional.
- Try to keep track of resources (not completed yet).
- Use bus_space_read/write() to access the ports (not completed yet).
=
Patch #6: scvgarndr.diff
File: /sys/dev/syscons/scvgarndr.c
- Fix bugs when painting border and the mouse cursor in the raster
text mode.
=
Patch #7: vidcontrol.diff
File: /usr/src/usr.sbin/vidcontrol/vidcontrol.c
- Allow the user to set arbitrary number of rows and columns for the
raster text mode by the new option `-S [FF] CCxNN', where CC is the
number of column, NN is the number of rows, and FF (optional) is the
font height.
- Allow the user to specify the video mode by the mode number.
=
Patch #8: altmouse.diff
File: /sys/dev/syscons/{syscons.c, syscons.h, scvidctl.c, scmouse.c}
- Fix SC_ALT_MOUSE_IMAGE; don't blink the mouse cursor.
Patch #9: moused-3.diff
File: /usr/src/usr.sbin/moused/moused.c
- This is the second attempt to fix the `-3' option for moused :-)
It also adds a new option, `-E', to set the timeout value for
the three button emulation.
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 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: CGA instead of VGA
>On -current my VGA card is being used as a CGA card. It is correctly >recognized as a VGA: > >vga-pci0: mem 0xf800-0xfbff irq 11 at d >evice 15.0 on pci0 The above message simply means that a PCI card classified as VGA is found. This does not necessarily means that the card can be used as VGA. >vga0: at port 0x3d0-0x3db iomem 0xb8000-0xb on isa0 > >but then used as a CGA: > >sc0: CGA <16 virtual consoles, flags=0x200> The BIOS setup menu usually has an entry to specify the type of the installed video card. If this item is set to CGA, the BIOS and the vga driver will initialize the card, even if it is a VGA, as the CGA card. Are you sure that this doesn't happen to be the case with your system? >The problem is, that I can't set fonts: > ># vidcontrol vidcontrol: can't load font: Device not configured If the card is recognized as CGA, you cannot load font or switch video modes. >I vaguely remember seing a commit from Kazu that supposedly fixed this, >although I still experience it with a -current machine as of a couple of >days ago. That commit fixed the problem where the vga driver wrongly thought the card is CGA when the BIOS DOES initialize the card as VGA. If the BIOS initialize the card as CGA, the vga driver is still led to believe the card is CGA. (And I believe that is the reasonable behavior.) Kazu >The motherboard is an Intel AN430TX, the graphics card is a S3 Trio 64V+ >based card. Below is the full dmesg. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 release candidate issues
>> Possible Problem 3 >During setup, I configure my Intellimouse as an "Intellimouse" on port >"ps/2". The mouse cursor works as it should but during boot I get the >following diagnostic: > >rc.i386 configuring syscons: blank_time mousedmoused: mouse type mismatch >(ps/2 != intellimouse), ps/2 is assumed If you read the notice in the mouse configuration screen, you should have understood that you should ALWAYS choose the type "Auto" for ANY mouse connected to the PS/2 mouse port, regardless of the brand and model of the mouse. The type "IntelliMouse" is for the SERIAL IntelliMouse. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 release candidate issues
>>>rc.i386 configuring syscons: blank_time mousedmoused: mouse type mismatch >>>(ps/2 != intellimouse), ps/2 is assumed >> >> If you read the notice in the mouse configuration screen, you should >> have understood that you should ALWAYS choose the type "Auto" for ANY >> mouse connected to the PS/2 mouse port, regardless of the brand and >> model of the mouse. The type "IntelliMouse" is for the SERIAL >> IntelliMouse. > > On my Fujitsu Lifebook 535Tx I also set 'moused_type="glidepoint"' >along with the 'moused_port="/dev/psm0"' in /etc/rc.conf and receive the >abovementioned message on every reboot, BUT with such settings I can >'tap' and receive button event where as without setting moused_type to >glidepoint this 'tapping' not works. I can assure you that setting `moused_type' to "glidepoint" does not directly affect your pad device. The protocol type "glidepoint" is for the "serial" GlidePoint. PS/2 GlidePoint should be used with the "auto" (or "ps/2"). When moused finds that the user selected a protocol type which is incompatible with the mouse driver (psm or mse), it warns the user: moused: mouse type mismatch (XXX != YYY), XXX is assumed Where XXX is the basic, default protocol type of the mouse driver, and YYY is the protocol type supplied by the user. As you can infer from the the message, moused will ignore the type supplied by the user and use the driver's protocol instead. In you case `glidepoint' is utterly ignored, sorry :-) As for the `tap' feature, I assume the pad device on your notebook computer is reporting the `tapping' action as the button 4 click. If you want `tap' would be the button 1 click, you set moused_flags="-m 1=4" in your /etc/rc.conf. You may think this is arcane, but this arrangement gives us more flexibility; believe it or not, there are people who don't like the `tap' feature and don't want the button 1 click for `tap'. Now, you want to ask me a question, don't you? "But `tapping' is reported as the button 1 down on my machine without the -m option!" This is because moused finds that a wrong protocol type is supplied, and tries to use the "basic, default" protocol type the mouse driver is suggesting. For the PS/2 mouse driver psm, it is the "ps/2" protocol type which has no provision of accommodating the button 4 (tap) status. The psm driver "automatically" maps the button 4 click to the button 1 click when the "ps/2" protocol is being used. This mapping is done in the psm driver and not in moused. If no protocol type is supplied or the "auto" is specified to moused, moused will try to use more advanced protocol type than the mouse driver's basic default protocol. In such protocol, the button 4 status can be reported and the psm driver won't need to map the button 4 (tap) to the button 1. That's why you thought `tapping' didn't work when you had moused_type="auto" in your rc.conf. The recommended settings for you notebook computer is moused_type="auto" moused_flags="-m 1=4" You may use the "ps/2" protocol type in order to avoid setting mouse_flags. moused_type="ps/2" moused_flags="" (But, I wouldn't recommend this.) Kazu Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 release candidate issues
>1. The kernel compiled from GENERIC doesn't find my PS2 mouse.=20 >2. 'options XSERVER' renders the kernel incapable of booting. The >config file is included below. >3. Adding 'device pcm0' also makes the kernel unable to boot. The >bootloader loads, tries to load the kernel and freezes up.=20 Your kernel configuration file lacks a console driver. You MUST have either device sc0 at isa? or device vt0 at isa? Without a console driver, the kernel will print nothing to the screen (and that would make you think the system is frozen...) `options XSERVER' is for vt0 only. sc0 doesn't need it to run the X server. As for the PS/2 mouse, please type 'boot -v' at the loader prompt, and show us /var/run/dmesg.boot once the system is up. The file will contain various diagnostic messages. We also need to know the exact model name of your PS/2 mouse. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0-CURRENT issues...
>I have 2 issues with 4.0-CURRENT. The first is the plethora of >"microuptime() went backwards..." errors that scroll on my console. > >The second is that I have DDB compiled into my kernel (and a USB keyboard) >either on vga or serial console, if I trip DDB (control-shift-esc), I will >either get the ddb> prompt or the system will hard lock. Below is my >dmesg and kernel config. Help is appreciated. Is there a reliable way to reproduce this? Do you have any error messages when this happens? Kazu [...] >usb0: on uhci0 >usb0: USB revision 1.0 >uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 >uhub0: 2 ports with 2 removable, self powered >ums0: Microsoft Microsoft IntelliMouse\M-. Explorer, rev 1.10/1.03, addr 2, ic >lass 3/1 >ums0: 5 buttons and Z dir. >ukbd0: Microsoft Natural Keyboard Elite, rev 1.00/1.04, addr 3, iclass 3/1 [...] >vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 >sc0: at flags 0x100 on isa0 >sc0: VGA <16 virtual consoles, flags=0x100> >sio0 at port 0x3f8-0x3ff irq 4 flags 0x30 on isa0 >sio0: type 16550A, console >sio1 at port 0x2f8-0x2ff irq 3 on isa0 >sio1: type 16550A [...] >device vga0at isa? > ># syscons is the default console driver, resembling an SCO console >device sc0 at isa? flags 0x100 [...] >device uhci# UHCI PCI->USB interface >device ohci# OHCI PCI->USB interface >device usb # USB Bus (required) >device ugen# Generic >device uhid# "Human Interface Devices" >device ukbd# Keyboard >device ulpt# Printer >device umass # Disks/Mass storage - Requires scbus and da >device ums # Mouse To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
AP #1 failed!
In the last few days, I occasionally see the following message when I boot the 4.0-CURRENT kernel. AP #1 (PHY# 1) failed! panic y/n [y]? This doesn't always happen. But, roughly once in a few reboots. My MB is Gigabyte GA-6BXD with two Celerons (400MHz). Do I have a hardware problem? How should I diagnose the problem? Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0-20000307-CURRENT kern.flp keyboard probe questions
>Maybe there is a valid reason for this, but when I attempt to boot the 4.0 >kern.flp without a keyboard attached (I share one keyboard between four >systems, here), it displays keyboard: no and the BTX loader message, and >ceases to display ANY output on the attached monitor (though it does >continue to access the disk, I'm assuming, until the MFS root floppy is >needed)? > >I assume this is because, without a keyboard, the loader assumes a serial >console is attached. Yes. And this has been the behavior since FreeBSD 2.X. >This is not the case in my situation. > >Isn't there a better way to identify a serial console? I don't understand. What do you expect the boot loader to do? >And, if not, could >the loader at least not display a message on the local monitor like >"Switching output to serial console...", or better yet, "Switching output >to serial console in 10 seconds.. press any key to abort"? Which key do you mean? The system has found no keyboard, you know :-) Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Keyboard troubles
>On my -current system, after rebooting, the keyboard was in a funny state >(all 4 LEDs were turned on. My keyboard also has an internal click >mechanism, which was no longer functional) I plugged the keyboard into >another machine at that point, and it reset itself and worked fine on that >machine. Plugging it back into the -current box, however, produced the >same results as before. > >Fearing incompatibility, I dug out an old AT keyboard and plugged it >in. No LEDs lit, and also no response from keypresses (including the >obvious escape characters). > >The machine didn't hang... console message were still being displayed. I >ended up rebooting the thing remotely, and after that, the keyboard >functioned normally. > >If somebody can tell me what else to check, I can try and provide a few >mroe details. It sounds like the keyboard interface of your motherboard has somewhat become flaky; it may even be broken. It is NOT recommended that you attach or detach the keyboard while the power is on. The keyboard interface of the PC motherboard is not designed for hot-plugging/unplugging. It is too easy to fry the keyboard interface and/or controller by doing so. Even if the keyboard interface survives hot-plugging, there is no assurance that the keyboard and the keyboard controller on the motherboard can communicate properly after hot-plugging; they are simply not designed to cope with such situation. I personally know a couple of people who broke their motherboard this way. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0-20000307-CURRENT kern.flp keyboard probe questions
>> >And, if not, could >> >the loader at least not display a message on the local monitor like >> >"Switching output to serial console...", or better yet, "Switching output >> >to serial console in 10 seconds.. press any key to abort"? >> >> Which key do you mean? The system has found no keyboard, you know :-) >> >> Kazu > >Exactly... My suggestion resembles the common BIOS boot message from days >of old: > > Keyboard not found. Press [F1] to continue. The PC BIOS prints "Press [F1] to continue" for ANY error detected during POST. I found it damm stupid. As I wrote in another posting, the keyboard interface on the PC motherboard is not designed for hot-plugging/unplugging. And I don't think the BIOS is expecting you to attach the keyboard without turning off the system in the above situation. You may say it works. But, I can say, with confidence, it is not generally the case with the average PC motherboard. I strongly object to the idea to put some logic or message to actively "encourage" users to hot-plug the keyboard. That will certainly lead to breakage of many motherboards. If the user hot-plug the keyboard, knowing involved risks, that's his problem; he is expected to know what he is doing and is prepared to accept the risks. It's indeed inconvenient that you cannot safely hot-plug the keyboard. And the world is heading for the USB standard... :-) Kazu >The novice reads, laughs out loud, and wonders if the joke is really on >them. After all, how COULD they press F1 if a keyboard does not exist? > >The expert checks his/her keyboard connection, (or plugs a keyboard in) >and, indeed, hits F1 to continue. BIOS programmers have been doing it >for about two decades. Why not the FreeBSD boot loader? :-) > >My idea is a similar one. Have the boot loader (with a reasonably >configured timeout--we don't want to wait indefinitely) display a similar >message (perhaps with copious beeping), giving the busy sysadmin a chance >to switch keyboards, or at least notice that a keyboard was not detected. > >If I install FreeBSD on multiple systems, I might throw boot disks in a >dozen machines so I don't have to wait for each one. I come around with >my $370 keyboard later to start the actual installs over NFS. I call it >'pipelining' :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Keyboard troubles
>I don't make a habit of keyboard swapping, and I HAVE experienced some >minor glitches before (such as weird scan codes being sent, or the state >of caps lock changing). You have been lucky that you didn't broke the motherboard when swapping the keyboard. The fact that you only had minor problems does not mean the rest of the world should be Ok too. >In any case, though, a keyboard reset or even >just a few key presses would fix. In the last 10 years, I have NEVER had >to reboot a system because they keyboard wasn't responding. Well, as I wrote before, I suspect that the keyboard interface of your motherboard is becoming flaky. This is a hardware problem, rather than software. It is not certainly the FreeBSD boot loader problem as it relies on the BIOS to detect the presense of the keyboard. >> Even if the keyboard interface survives hot-plugging, there is no >> assurance that the keyboard and the keyboard controller on the >> motherboard can communicate properly after hot-plugging; they are >> simply not designed to cope with such situation. >> >> I personally know a couple of people who broke their motherboard this >> way. > >Bummer for them.. Really, though, I would rather fry a $200 motherboard >than my $500CDN keyboard (my fingers have developed expensive tastes). >:-) None of my motherboard documentation warns agains swapping keyboards, >either. That doens't mean the motherboard manufacturer recommend keyboard swapping :-) I certainly don't like the idea that we encourage users something which may break their motherboard. I will tell more. Many motherboard, if not all, has a small fuse around the keyboard connector. This fuse will burn if large current runs in the keyboard interface. This may happen when you hot-plug/unplug the keyboard. The trouble is that this fuse cannot be easily replaced on many motherboard. Some old motherboards have a socketed fuse, so it's not hard to replace it (but it is still a hassle for non-engineering type folks). Many recent motherboard has the fuse SOLDERED on the motherboard, and the fuse itself is a small chip. This makes it hard for us to identify the fuse and repair it when it goes off. It is certainly unreasonable to assume any user can fix it himself. >In any case, I never had problems swapping keyboards between prior FreeBSD >releases, other UNIX platforms, Windows machines, DOS machines. Hell, >even my old Nintendo never complained if you plugged in a different >controller while it was powered on. :-) I was just wondering if >something had been done to 4.0 that didn't handle this situation like >previous releases. Nothing changed in the 4.0 boot loader. # Other UNIX boxes and the Nintendo game console are not relevant here. # They use different keyboard interface circuit. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0-20000307-CURRENT kern.flp keyboard probe questions
>> It's indeed inconvenient that you cannot safely hot-plug the keyboard. >> And the world is heading for the USB standard... :-) > >This actually opens another entire can of worms; detecting a USB keyboard >at the bootstrap level is _not_ easy. It looks like at least some >systems aren't setting the 'extended keyboard' flag. 8( I wasn't talking about specific implementation which should be in FreeBSD. But, the general technological trend the world is following :-) Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Keyboard troubles
>> Why not just get a decent monitor/keyboard switch? Belkin makes a >> nice 4-port in the $200 range that makes your motherboard think >> there's a keyboard attached even if you are not currently switched >> onto the system. > >I have something quite similar.. Still, seems like some individuals >remain adamantly opposed to the idea of keyboard swapping, however >careful one is. :-) For the record,... I never said that I was against using console switch products. (They are designed to be safe. If it causes the problem, we can categorically say that it is the manufacturer's fault.) I am against hot-plugging and swapping the keyboard. You may be careful and you know the risk. But, others may not. I don't like to spread the false impression that the PC keyboard interface is designed for hot-plugging/unplugging, and will repeat (or even shout :-) as many times as necessary, "It is not recommended to attach or detach the PC keyboard while the power is on". If you want to hot-plug the keyboard, do it at your own risk. But, please, please, please do not advice other users that it is a safe thing to do; it simply is not. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: psm.c broken
>linking kernel.debug >psm.o: In function `psmprobe': >/sys/compile/RJK191/../../isa/psm.c(.text+0x9fe): undefined >reference to `atkbdc >_open' >*** Error code 1 > >I know psm.c was changed today, I'd suppose one reference here was >missed in the process. Just figured I'd be the first to say so. Oops, sorry. I forgot to commit another update for atkbdc. I will fix it later today. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: psm.c broken
>After a cvsup today, building a kernel finishes with this: > >linking kernel.debug >psm.o: In function `psmprobe': >/sys/compile/RJK191/../../isa/psm.c(.text+0x9fe): undefined >reference to `atkbdc >_open' >*** Error code 1 > >I know psm.c was changed today, I'd suppose one reference here was >missed in the process. Just figured I'd be the first to say so. The following commit is related to the psm update and should have been committed together. Sorry. Kazu - yokota 2000/03/18 19:25:13 PST Modified files: sys/isa atkbd_isa.c atkbdc_isa.c sys/dev/kbd atkbd.c atkbdc.c atkbdcreg.h atkbdreg.h sys/i386/isa/pcvtpcvt_hdr.h Log: - Properly keep track of I/O port resources. - Use bus_space_read/write() to access the ports. Revision ChangesPath 1.8 +24 -19src/sys/isa/atkbd_isa.c 1.15 +54 -24src/sys/isa/atkbdc_isa.c 1.26 +13 -10src/sys/dev/kbd/atkbd.c 1.6 +100 -79 src/sys/dev/kbd/atkbdc.c 1.6 +16 -6 src/sys/dev/kbd/atkbdcreg.h 1.6 +3 -3 src/sys/dev/kbd/atkbdreg.h 1.37 +3 -1 src/sys/i386/isa/pcvt/pcvt_hdr.h - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VESA_800x600 mode on CT65554 based videocard.
>I'm trying to get VESA_800x600 mode to work on my notebook (Toshiba >SatellitePro 445, CT65554 videocard, 2MB, 800x600 LCD), and >unfortunately found that it is impossible. Any ideas of what is wrong? You need to add options SC_PIXEL_MODE to your kernel configuration file. There is a note in http://www.freebsd.org/~yokota/sc_update-June.txt, which is referenced by /usr/src/UPDATING, about this option. - options SC_PIXEL_MODE Syscons has supported the raster console mode (VESA 800x600) by default. This is now an optional feature, and must be explicitly enabled by SC_PIXEL_MODE. If you have been using this mode, add the above option. - Please also refer to the man page syscons(4). Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: followup to apm problems.
>> OK. Probably `slept 00:00:00 - 00:00:40' problem was caused by PS/2 >> mouse, I think. Do we need something to do with psm on suspending as >> well as resuming? > >Im not sure anything needs to be done for PS/2.. check out these >results.. The PS/2 mouse generates interrupt when /dev/psm0 is open and the user moves the mouse. If you are running moused or X when you suspend the system, /dev/psm0 is left open and might generate interrupts. I think modern motherboard BIOSes have a setup menu that lists which IRQ will wake up the system. I wonder what if you remove IRQ 12 (PS/2 mouse interrupt) from this list. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Weird syscons keyboard behaviour
>I've noticed some odd syscons keyboard behaviour over the past
>month or so. Sometimes I get a vty that outputs PC graphics characters
>for all of my input. This is always at a "login:" prompt. I think
>I can duplicate this by typing a bunch of garbage at a login prompt,
>but I don't feel like trying to test it right now and have to
>reboot my main machine.
[...]
>I think this might be some kind of timing problem. I was starting
>to type in my username right away when I saw the boot was finishing,
>and if I recall the past incidents correctly, I may have been
>doing the same thing.
>
>I've seen this probably 4 or 5 times in the past month, maybe
>6 weeks. Anyone have any ideas what is going on?
It appears that if you hit the keyboard before (at the boot loader
prompt or during the kernel is probing devices) or while the keyboard
driver is being initialized, you may see the problem.
The keyboard driver does try to flush keyboard input before it
manipulates the keyboard controller and the keyboard, but apparently it
is sometimes confused.
# One possible explanation for this failure of keyboard flushing is
# that the clock or timer calibration is not correctly done and I/O
# delay is not working properly. Well, I am not sure, though...
I have no idea why this is cropping up now, rather than before... The
AT keyboard driver has unchanged for some time. Yes, there has been
some commits in the past couple of months, but they don't change the
basic operation of the driver.
Would you please try the following patch for /sys/dev/kbd/atkbd.c and
see how it fares?
Kazu
Index: atkbd.c
===
RCS file: /src/CVS/src/sys/dev/kbd/atkbd.c,v
retrieving revision 1.13
diff -u -r1.13 atkbd.c
--- atkbd.c 1999/08/15 06:06:14 1.13
+++ atkbd.c 1999/08/19 12:08:22
@@ -1154,7 +1189,7 @@
}
/* save the current controller command byte */
- empty_both_buffers(kbdc, 10);
+ empty_both_buffers(kbdc, 200);
c = get_controller_command_byte(kbdc);
if (c == -1) {
/* CONTROLLER ERROR */
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
HEADS UP: console code change
Becase of the following change in /sys/dev/syscons, you need to recompile both the kernel, the vesa module and screen savers. # Well, if you don't use the vesa module and the screen savers, # you can forget about this :-) Thank you for your cooperation. Kazu >yokota 1999/09/19 01:58:54 PDT > > Modified files: >sys/dev/syscons schistory.c scmouse.c scvesactl.c > scvidctl.c syscons.c syscons.h > Log: > - Hang the scr_stat struct from dev_t. > - Remove sc_get_scr_stat(). It's not necessary anymore. > - Call ttymalloc() to allocate the struct tty for each vty, rather than >statically declaring an array of struct tty. We still need a statically >allocated struct tty for the first vty which is used for the kernel >console I/O, though. > - Likewise, call ttymalloc() for /dev/sysmouse and /dev/consolectl. > - Delete unnecessary test on the pointer struct tty *tp in some functions. > - Delete unused code in scmouse.c. > > WARNING: this change requires you to recompile screen savers! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vga driver and signal
AFAIK, not all video cards generate the vertical retrace interrupt. Even worse, some BIOSes have a configuration option which instract the BIOS NOT to assign an IRQ to the PCI video card. I fully agree that the vertical retrace interrupt will be of great value, but I wonder if it is really worth the trouble, because it might be available in only few cards and systems at the end of the day... Well, I may be wrong :-) Kazu >Say is there anyone that can add signal delivery to the /sys/dev/fb/vga.c? >(For now any quick hack to the driver for delivering the signal will do ) > >The context is from a posting to the xfree86 mailing list: > > >[EMAIL PROTECTED] said: >> You need to fit one event in per retrace. If you knew >> the phase of the sampling clock with respect to the retrace >> you could do that by skipping one sample then two then one, etc... >> But we don't know the phase and if you do that with >> arbitrary phase you end up sending two events in one retrace >> and then skipping the next and it looks worse. >> If we had a signal delivered at vertical retrace time, we could easily >> sync the mouse rate with the video rate -- run the mouse events >> through a simple filter and estimate mouse position at the vertical >> retrace interval using some forward estimation. > >> Additionally, the vertical retrace signal could be used for the double >> buffering extension to avoid tearing, and for the sync extension which >> kinda wants this. And for many video cards which can't update >> colormaps or cursor positions at other times without visible artifacts >> on the screen. > >> It would take some kernel work though; the results might well be worth >> the effort. > >> -keith > >I am too busy nowdays working :( To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vga driver and signal
>> Well, I may be wrong :-) > >Well, sortof :) > >The delay caused by the system to process the interrupt and deliver >the signal etc is unpredictable (well sortof) and is almost certainly >too long so the window of opportunity will be missed ... > >This has been discussed to death many times in the past for the >mouse pointer updates etc etc... > >-Soren You are absolutely right. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libvgl - status and perspectives
>Today I noticed accidentally that either libvgl is broken, or the demo >program does something wrong - the mouse cursor doesn't move. Oops, sos and I have developed a new version of libsvgl which can handle VESA modes in addition to the standard VGA graphics modes. But I haven't committed it to the source tree yet (yes, I should have done so weeks ago ;-( Anyway, if you are interested, I can send you a copy for testing. Kazu >But this brings more general question regarding console graphics library. >As it is today, libvgl is almost useless due to very limited set of >functions. There were discussions whether to port SVGAlib or GGI. Do you >know if someone is working/planning to work on it? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libvgl - status and perspectives
>Any docs for e.g.the fb device? I know,you can always UTSL, but it takes >more time. No docs yet, sorry. >OBTW. there is an error in mouse(4) manpage. The ioctl is called >MOUSE_GETSTATUS, not MOUSE_GETSTATE as the manpage claims. Thank you for spotting the error! I will fix it. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
[PATCH] Four patches for review and test
Four patches for review and test. They are for 4.0-CURRENT. (moused patch should also work with -STABLE too.) http://www.freebsd.org/~yokota/moused-991129.diff http://www.freebsd.org/~yokota/kbdcontrol-991129.diff http://www.freebsd.org/~yokota/panickey-991129.diff http://www.freebsd.org/~yokota/altlock-991129.diff Kazu [EMAIL PROTECTED] Patch #1. moused: the -3 option (moused-991129.diff) The three-button emulation of the mouse daemon has been somewhat difficult to use for many people. This patch will try to improve the situation by introdusing a small state machine. There is a new option, -E, to set timeout value to detect two buttons are pressed down simulteneously. The default value for this timeout is 200 msec. The patch should work with both 4.0-CURRENT and 3.3-STABLE. cd /usr/src/usr.sbin/moused patch < moused-991129.diff Patch #2. kbdcontrol (kbdcontrol-991129.diff) The patch will add a few new key definitions. This patch is required for the patches 3 and 4 below. cd /usr/src patch < kbdcontrol-991129.diff Patch #3. Panic key (panickey-991129.diff) The patch adds "panic key" function to syscons. When this key is defined in a keymap and pressed, the system panic will be forced. As this can be a security problem, this feature must be specifically enabled by a new sysctl variable: machdep.enable_panic_key. The default value is 0. The panic key won't do anything unless this variable is set to non-zero. To use the panic key, add a keyword 'panic' to a key in your keymap file. The following example assigns the panic function to SysReq (Alt-PrintScreen) key (keycode 84). 083 del'.''.''.''.''.'boot bootN 084 panic nopnopnoppanic nopnopnop O 085 nopnopnopnopnopnopnopnop O The patch requires the patch #2 above. Related PR: kern/13721 cd /sys/dev/syscons patch < panickey-991129.diff Patch #4. Adding AltLock function to shift keys (altlock-991129.diff) Our keymap may contain AltLock (alock) or AltShift (ashift) keys. This patch will add new keys: lshifta, rshifta, lctrla, rctrla, lalta, and ralta. These keys combine shift/ctrl/alt function and the AltLock function. When these keys pressed together with another key, they act just like the ordinary shift/ctrl/alt keys. When these keys are pressed and released alone, Alt state is locked/unlocked. Related PR: kern/12475 cd /sys/dev/kbd patch < altlock-991129.diff To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
[PATCH] Importing Eric's latest termcap?
I have been contemplating replacing our /usr/src/share/termcap/termcap.src with the latest termcap file maintained by Eric Raymond. His latest version seems 10.2.7 dated 10 March 1999. While our termcap.src has been maintained well by ache and other committers, Eric's version appears more comprehensive. If we are to use it, we shall modify other files in /usr/src/share/termcap as well. Makefile-> needs to be updated README -> delete, it is obsolete tck -> delete reorder -> delete, as it is unnecessary anymore The patch is placed in: http://www.freebsd.org/~yokota/termcap.diff.gz cd /usr/src/share/termcap gunzip < termcap.diff.gz | patch rm README tck reorder Please have a look and try. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problem with syscons in VESA mode
>I'm using non-standard 100x37 console mode on my notebook, because in 80x25 >text mode letters seems too big for my 12' panel, while other modes doesn't >cover all panel size. So I've patched vidcontrol to switch to the VESA_800x600 >100x37 mode (instead of default 80x25) with 8x16 font, and in most cases all >works just fine (including ncurses and dialog bases apps), but sometimes when >I'm building world or some other app text suddenly shifts from the edge of the >screen by several spaces and all text passed to the console after that also >being printed with that offset. For example: [...] This strange behavior was reported several times in the past. It must be related to screen update logic in syscons. But, I don't think we have successfully fixed it at that time :-( It's time to analyze the problem again... Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problem with syscons in VESA mode
>Yes. I know about this problem too but I have no time to fix and test >it. Is anybody interested in bug reports? ;-) > >* Left margin moving to the right is related to the screen width not > divisible by 8 and an use of tabulators at the end of line after the > last valid tab position. So the same problem could be seen for > example with screen width 90, which is accessible for all [...] > I think the fix should be trivial (syscons.c,v 1.327) - but it is > speculated right now without testing: This is an excellent analysis. I will test your patch. Thank you. >* There are another problems with syscons updating: When a block > of text is selected by mouse, it should be hidden when text in this > block is changed. Unfortunately in many cases the block stays > selected on the same position... I think we should learn from > xterm. (But when I tested xterm, it had some problems too...) This is a known problem which I haven't worked on... ;-< Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Using USB modules with an USB keyboard...
>Is there any way to use only the USB KLDs (i.e. remove all the USB >options from the kernel config file) on a machine that has an USB >keyboard? Add "flags 0x100" to syscons. Note this is still an experimental flag. device sc0 at isa? flags 0x100 >I tried doing this (removed all the USB options from my config file, >but left KBD_INSTALL_CDEV). However, this caused the kernel build to >fail with undefined symbols when compiling the syscons stuff. So, I Would you provide your kernel configuration file and exact error messages when you compiled a kernel with this configuration? >tried it with putting the normal keyboard line back in (atkbdc and >atkbd), but this just caused the system to look for a normal >keyboard. And the atkbd driver fails to find an AT keyboard, right? That should not cause any problem to you. Or, did you find any trouble? But, if it still bothers you, you may "disable" the atkbd driver included in the kernel, by specifying device atkbd0 at atkbdc? disable irq 1 Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Using USB modules with an USB keyboard...
Thank you for your detailed report. >I added your recommendations above to the kernel config file >(TWELVE). It didn't work. As can be seen from the dmesg below, when >the USB options are present in the kernel, ukbd0 is found. When USB >KLDs are used, uhid0 seems to grab the keyboard. > >[This is the dmesg from a kernel (ELEVEN) that works. The config file for this >includes all the USB options except for ums, which is loaded at bootup] > >As seen below, I have an USB mouse (ums0), and an USB keyboard (which >seems to register as an USB keyboard and a mouse -- ums1). The >keyboard does have a PS/2 mouse connector on it. This is the correct hehavior. If a USB device has more than one interface, it may require multiple drivers; one driver for each interface. >[This is the kernel (TWELVE) that has no USB options. All the USB modules are >loaded at bootup by the loader.conf scripts.] >Dec 7 19:57:33 frabjous /kernel: real memory = 134217728 (131072K bytes) >Dec 7 19:57:33 frabjous /kernel: avail memory = 127352832 (124368K bytes) >Dec 7 19:57:33 frabjous /kernel: Preloaded elf kernel "kernel" at 0xc02ae000. >Dec 7 19:57:33 frabjous /kernel: Preloaded elf module "vesa.ko" at 0xc02ae09c >. >Dec 7 19:57:33 frabjous /kernel: Preloaded elf module "cd9660.ko" at 0xc02ae1 >38. >Dec 7 19:57:33 frabjous /kernel: Preloaded elf module "procfs.ko" at 0xc02ae1 >d8. >Dec 7 19:57:33 frabjous /kernel: Preloaded elf module "green_saver.ko" at 0xc >02ae278. >Dec 7 19:57:33 frabjous /kernel: Preloaded elf module "usb.ko" at 0xc02ae31c. >Dec 7 19:57:33 frabjous /kernel: Preloaded elf module "ugen.ko" at 0xc02ae3b8 >. >Dec 7 19:57:33 frabjous /kernel: Preloaded elf module "uhid.ko" at 0xc02ae454 >. >Dec 7 19:57:33 frabjous /kernel: Preloaded elf module "ukbd.ko" at 0xc02ae4f0 >. >Dec 7 19:57:33 frabjous /kernel: Preloaded elf module "ulpt.ko" at 0xc02ae58c >. >Dec 7 19:57:33 frabjous /kernel: Preloaded elf module "ums.ko" at 0xc02ae628. >Dec 7 19:57:33 frabjous /kernel: Preloaded elf module "umass.ko" at 0xc02ae6c >4. >Dec 7 19:57:33 frabjous /kernel: link_elf: symbol cam_simq_alloc undefined >... >Dec 7 19:57:33 frabjous /kernel: uhci0: ler> irq 10 at device 7.2 on pci0 >Dec 7 19:57:33 frabjous /kernel: usb0: er> on uhci0 >Dec 7 19:57:33 frabjous /kernel: usb0: USB revision 1.0 >Dec 7 19:57:33 frabjous /kernel: uhub0: Intel UHCI root hub, class 9/0, rev 1 >.00/1.00, addr 1 >Dec 7 19:57:33 frabjous /kernel: uhub0: 2 ports with 2 removable, self powere >d >Dec 7 19:57:33 frabjous /kernel: ums0: Logitech USB-PS/2 Mouse M-BA47, rev 1. >00/1.10, addr 2, iclass 3/1 >Dec 7 19:57:33 frabjous /kernel: ums0: 4 buttons and Z dir. >Dec 7 19:57:33 frabjous /kernel: uhid0: QTRONIX USB Keyboard and Mouse, rev 1 >.00/1.10, addr 3, iclass 3/1 >Dec 7 19:57:33 frabjous /kernel: ums1: QTRONIX USB Keyboard and Mouse, rev 1. >00/1.10, addr 3, iclass 3/1 >Dec 7 19:57:33 frabjous /kernel: ums1: 3 buttons [...] Ok, I got the picture. The fix is on the way. I will contact you later. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: syscons extension: "propellers"
>> I'm not yet 100% convinced that it would make sense to separate >> the propellers code into a module. Is 5 Kbyte of kernel code >> really that much of a problem? Please note that > >I certainly wouldn't argue this based on size, no. To understand the >point I was arguing, consider what would have been the case if the >very first screen saver had been hacked straight into syscons rather >than making it an optional component. We'd probably have 2 or 3 [...] >So I see it with "propellers" - they're an optional feature component >and there should be a way of bolting such optional features into >syscons without having to recompile the kernel. It's not a question >of size, it's a question of design and flexibility and I can argue >from such a purist's perspective because I'm not doing any of the work >involved and it's thus really easy to do so. :-) I am looking at Oliver Fromme's code. It is interesting. I am currently preparing the final stage of syscons clean-up (which was outlined a year ago), and will think about reasonably generalized way of adding extentions to syscons. Kazu PS: As for screen savers, there have been a plan to move screen savers out of the kernel to userland. A part of the necessary infrastructure is there, but it's not fininished... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [usb-bsd] USB To Do list
>To Do list for the USB project: > >Let meknow if you would like to participate in any way, or you have >done one of the items below! [...] >- USB Keyboards >- Keyboard in DDB debugger does not work. In what configuration does it not work? I can use my USB keyboard in DDB without problems on a dual PPro box (4.0-STABLE) with a UHCI controller (VIA 83c572) card and a Pentium box (3.4-STABLE) with Intel PIIX3 here... Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
SMP problem? (was: Re: [usb-bsd] USB To Do list)
>To Do list for the USB project: [...] >- USB base stack and general items. I am currently having trouble with Gigabyte GA-6BXD, dual Pentium III motherboard. If I boot a UP kernel (5.0-CURRENT), the PIIX4 USB controller works fine. If I boot a SMP kernel (the only difference from the UP kernel is support for SMP), the kernel seems unable to communicate with the USB device. When I plug a USB keyboard, I get uhci_timeout: ii=0xc0a601c0 uhci_timeout: ii=0xc0a601c0 uhci_timeout: ii=0xc0a601c0 usbd_new_device: addr=2, getting first desc failed uhub_explore: usb_new_device failed, error=TIMEOUT uhub0: device problem, disabling port 1 I vaguely remember someone also reported similar problems with the SMP kernel in the past Interesting thing is that I have another SMP box, and its USB works fine. The version is 4.0-STABLE. The USB controller is VIA 83c572. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP problem? (was: Re: [usb-bsd] USB To Do list)
>What does it say before this info? In dmesg.boot (after `boot -v' at the loader prompt): uhci0: port 0xe000-0xe01f irq 15 at device 7.2 on pci0 uhci0: LegSup = 0x0010 uhci_run: setting run=0 uhci_run: done cmd=0x80 sts=0x20 uhci_run: setting run=1 uhci_run: done cmd=0x81 sts=0x0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered Both uhci and usb drivers are statically linked to the kernel. When I connected a USB keyboard, I got the messages in my previous mail below. >Shared interrupt? No shared interrupt. Both IDE channels are disabled by BIOS, thus, irq 15 is free. After all, The USB drivers work if I run a UP kernel on the same machine. >USB does work on SMP (or at least in some cases). I know. It works on my another SMP box running 4.0-STABLE ;-< Kazu >> uhci_timeout: ii=0xc0a601c0 >> uhci_timeout: ii=0xc0a601c0 >> uhci_timeout: ii=0xc0a601c0 >> usbd_new_device: addr=2, getting first desc failed >> uhub_explore: usb_new_device failed, error=TIMEOUT >> uhub0: device problem, disabling port 1 >> >> I vaguely remember someone also reported similar problems with the SMP >> kernel in the past >> >> Interesting thing is that I have another SMP box, and its USB works fine. >> The version is 4.0-STABLE. The USB controller is VIA 83c572. >> >> Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: middle mouse button emulation broken in 4.0-STABLE?
>This has been fixed in both -STABLE and -CURRENT a week ago. The left >button is working, the timeout is just to long. Read moused manpage >and set the timeout to 200ms as a workaround (this is the default >according to the manpage, but not according to the code in >4.0-RELEASE). > > Sam 200 msec may be still too long. Maybe we had better change the default value to 100 msec or so... Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Anyone else seeing jumpy mice?
>May 19 00:50:45 zippy /kernel: psmintr: out of sync (00c0 != ). > >I've seen it for the last few weeks and can only think that something >must be stomping on the psm driver now (or the driver is missing >interrupts for reasons of its own). Anyone else seeing this? Do you, by any chance, use a KVM? Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Anyone else seeing jumpy mice?
>: May 19 00:50:45 zippy /kernel: psmintr: out of sync (00c0 != ). >: >: I've seen it for the last few weeks and can only think that something >: must be stomping on the psm driver now (or the driver is missing >: interrupts for reasons of its own). Anyone else seeing this? > >I see this from time to time on whacked out mice that come into my >posession. Sadly, I see it most on my laptop. It seems to happen >less offten when I have > PSM_HOOKRESUME > PSM_RESETAFTERSUSPEND >defined in my kernel config file. > >I've also seen this when I've tried to hot plug mice. This includes >when power is lost to my KVM switch. When that happens, I gotta >reboot all the machines that are attached to it since something is >whacko at that point, I get those messages, or worse no mice and no >message at all. When power to the mouse is, either accidentally or intentionally, cut, the internal setting of the mouse is naturally lost, and the mouse may behave in a different way than the way the psm driver assumes... >Hmmm, time for a good ioctl interface to newbus :-) Or, an ioctl to reset the mouse... I have long rejected this idea because it will only encourage people to detach and attach the PS/2 mouse, which is generally not capable of hot plug/unplug. But, there now are so many dumb KVMs which screw us, and we may have to accept that... Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Anyone else seeing jumpy mice?
>> May 19 00:50:45 zippy /kernel: psmintr: out of sync (00c0 != ). >> >> I've seen it for the last few weeks and can only think that something >> must be stomping on the psm driver now (or the driver is missing >> interrupts for reasons of its own). Anyone else seeing this? > >I haven't seen this message, but I _have_ been seeing an off-and-on problem >where my PS/2 (Logitech Firstmouse) mouse will go insane. Just moving it >causes clicks, wild pointer motion, all sorts of stuff. I usually have to >log in from another box and kill and restart moused; that fixes things. Um, if you don't see the above message but see erratic mouse behavior, then there may be a configuration problem (for moused or X), or a hardware problem. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Anyone else seeing jumpy mice?
>> I've seen it for the last few weeks and can only think that something >> must be stomping on the psm driver now (or the driver is missing >> interrupts for reasons of its own). Anyone else seeing this? > >Yes, recently on 4.0-stable, though provoked by unplugging and >replugging in the mouse. It did not recover. This I thought >sounded like a PR on the mouse being dead after a wakeup >from sleep mode. Please, if you can avoid it, don't unplug and replug the mouse while the power is on. The PS/2 mouse interface is generally not capable of hot plugging/unplugging. As for sleep/wake-up problem on the laptop computers, you may be able to resolve the problem by adding the following kernel options. options PSM_HOOKRESUME options PSM_RESETAFTERSUSPEND Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Anyone else seeing jumpy mice?
>> > Um, if you don't see the above message but see erratic mouse >> > behavior, then there may be a configuration problem (for moused or >> > X), or a hardware problem. > >Well, the mouse is fairly new (less than 6 months) and otherwise works like >a charm. I never saw this before 4.0, but that was also about the time >I added the KVM. Oh, I see. You also use a KVM. The psm driver in FreeBSD versions before 4.0 is also screwed when a less-than-compatible KVM is used. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Anyone else seeing jumpy mice?
>> FWIW, those are all the symptoms of this problem too. The mouse >> doesn't just jump, it goes nuts with simulated button events. :) > >This can really suck with certain email clients, too. > >My hardware: Sony VAIO PCG-F160 w/integrated trackpad: > > psm0: irq 12 on atkbdc0 > psm0: model GlidePoint, device ID 0 Don't the following kernel options work for this machine? options PSM_HOOKRESUME options PSM_RESETAFTERSUSPEND Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Anyone else seeing jumpy mice?
>Try flags 0x04 on device psm. > >This undocumented option fixed my PS/2 IntelliMouse clone that has a >wheel (which is also the center button). As you have not given details on your problem and mouse, I don't understand why this flag solved your problem... That flag simply sets the mouse's resolution to "high". >Bug Kazu as to why this isn't documented in LINT. This flag IS documented in the man page for psm(4) :-) As Bruce says, LINT is not the place for documenting driver flags. They should be explained fully in the drivers' manual pages. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Anyone else seeing jumpy mice?
>> I've seen it for the last few weeks and can only think that something >> must be stomping on the psm driver now (or the driver is missing >> interrupts for reasons of its own). Anyone else seeing this? > > FWIW, with -current from 5/8, I don't have any of those in >/var/log/messages, going back to 5/1. I have a logitech PS/2 mouse, and >I don't use moused, since I couldn't get it to work with my wheel. In what way doesn't the wheel work? Would you provide the following information? 1. Which mouse model is it? 2. /var/run/dmesg.boot after starting "boot -v" at the loader prompt. 3. Run moused as follows to get debug log and send it to me. moused -d -f -p /dev/psm0 >& /tmp/moused.out Thank you. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Anyone else seeing jumpy mice?
>I see those messages, however I do not have any problems mousing afterwards. >I'm using a switchview, which at least resets the mouse when I switch. Your Logitech 3-button mouse may be generic enough and is not affected much by power cut when you use the KVM. Which model is it? >On Sun, May 21, 2000 at 08:41:57PM -0700, Mike Smith wrote: >> > Um, if you don't see the above message but see erratic mouse >> > behavior, then there may be a configuration problem (for moused or >> > X), or a hardware problem. > >My configuration works fine, the mouse worked without messages until >I installed 5.0-current. Do you get the "out-of-sync" messages when you don't use KVM? Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Anyone else seeing jumpy mice?
>I stopped using moused sometime during 4.0-current as a result of this. When was it? >It ocasionally froze, moved randomly around the screen, clicked without >being touched, and yes, got extreamly jumpy. The hardware's rock solid, >and once I ditched moused and read the device directly, life went back to >normal. Umm... The "out-of-sync" message comes from the psm driver and is generated when the driver finds mouse data stream odd. It doesn't matter if it is moused or the X server that is reading from the psm driver. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Anyone else seeing jumpy mice?
>Yes. Just today, I was installing a Digital PC with 4.0-release. Before >start using it, I upgraded to 4.0 Stable. Then I starded configuring X. > >FYI: > >FreeBSD 4.0-STABLE #0: Wed May 24 13:34:42 GMT 2000 >CPU: Pentium II/Pentium II Xeon/Celeron (265.75-MHz 686-class CPU) >psm0: irq 12 on atkbdc0 >psm0: model Generic PS/2 mouse, device ID 0 > >I have a HP-mouse (2 button) which is actually a logitec. > >>> FWIW, with -current from 5/8, I don't have any of those in >>>/var/log/messages, going back to 5/1. I have a logitech PS/2 mouse, and >>>I don't use moused, since I couldn't get it to work with my wheel. > >I tried with both moused and X. Both giving errors: > > psmintr: out of sync (0080 != ). > psmintr: out of sync (00c0 != ). > psmintr: out of sync (0040 != ). > >I tried several mousesystems, like 'ps/2', 'sysmouse', 'logitec'. They all >go crappy. It's no use trying one protocol type after another like this... You should configure moused and X as follows. In /etc/rc.conf, set moused_enable="YES" moused_type="auto" moused_port="/dev/psm0" moused_flags="" In the "Pointer" section of /etc/XF86Config, you should have Protocol "SysMouse" # or "Auto" Device "/dev/sysmouse" Do you still see error messages after setting up the things as above? Kazu >On my other machine, which is a Dell optiplex gx1, with > FreeBSD 5.0-CURRENT #9: Tue May 2 13:17:27 CEST 2000 > psm0: irq 12 on atkbdc0 > psm0: model Generic PS/2 mouse, device ID 0 >and a 3-button Digital mouse, I don't have the problem. But I really need >to upgrade to the next current ;-)) I am curious if I have the same problems >then on that machine. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: not making a splash
>I've tried to get a splash screen with two different 320x200x256 >bitmaps now, and all I get is a blank screen. Is there something else >I'm missing? Would you type 'boot -v' at the boot loader prompt and send me /var/run/dmesg.boot? I also like to see the output from 'vidcontrol -i mode' and 'vidcontrol -i adapter'. Are you sure the bitmap file is in BMP format and is not larger than 320x200? Is it possible for me to have a look at the file? Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
[PATCH] psmintr out of sync..
Ok, folks. This is a test patch for the psm driver. I would like you
to do some test for me.
This is NOT the fix for the infamous "psmintr out of sync" message,
but is a test patch to see how things are on your machines. The patch
is for both CURRENT and STABLE.
Please apply the patch to /sys/isa/psm.c (make backup copy first!),
and rebuild the kernel. I would like you to carry out two tests:
Test #1.
Make sure you remove the flags 0x100 from the psm driver and see how
your PS/2 mouse works.
You may still see "psmintr out of sync", but I would like to know if
the mouse pointer goes berserk when this message appears, or it seems
to operate properly despite the message.
Test #2.
Add the flags 0x100 (NOCHECKSYNC) to the psm driver and see what
happens.
Please report your results together with your motherboard model, mouse
model, FreeBSD version, mouse settings in /etc/rc.conf and XF86Config,
and /var/run/dmesg.boot (after you reboot the kernel by typing "boot
-v" at the boot loader prompt).
Thank you for your cooperation.
Kazu
Index: psm.c
===
RCS file: /src/CVS/src/sys/isa/psm.c,v
retrieving revision 1.26
diff -u -r1.26 psm.c
--- psm.c 2000/04/19 14:57:50 1.26
+++ psm.c 2000/06/09 01:19:59
@@ -1830,10 +1830,11 @@
unit = (int)arg;
sc = devclass_get_softc(psm_devclass, unit);
-if (sc->watchdog) {
+if (sc->watchdog && kbdc_lock(sc->kbdc, TRUE)) {
if (verbose >= 4)
log(LOG_DEBUG, "psm%d: lost interrupt?\n", unit);
psmintr(sc);
+ kbdc_lock(sc->kbdc, FALSE);
}
sc->watchdog = TRUE;
sc->callout = timeout(psmtimeout, (void *)unit, hz);
@@ -1880,18 +1881,6 @@
if ((sc->state & PSM_OPEN) == 0)
continue;
-/*
-* Check sync bits. We check for overflow bits and the bit 3
-* for most mice. True, the code doesn't work if overflow
-* condition occurs. But we expect it rarely happens...
-*/
- if ((sc->inputbytes == 0)
- && ((c & sc->mode.syncmask[0]) != sc->mode.syncmask[1])) {
-log(LOG_DEBUG, "psmintr: out of sync (%04x != %04x).\n",
- c & sc->mode.syncmask[0], sc->mode.syncmask[1]);
-continue;
- }
-
sc->ipacket[sc->inputbytes++] = c;
if (sc->inputbytes < sc->mode.packetsize)
continue;
@@ -1904,6 +1893,13 @@
c = sc->ipacket[0];
+ if ((c & sc->mode.syncmask[0]) != sc->mode.syncmask[1]) {
+log(LOG_DEBUG, "psmintr: out of sync (%04x != %04x).\n",
+ c & sc->mode.syncmask[0], sc->mode.syncmask[1]);
+ sc->inputbytes = 0;
+continue;
+ }
+
/*
* A kludge for Kensington device!
* The MSB of the horizontal count appears to be stored in
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: freezing and rebooting with vidcontrol -m on
>Okay, answering my own question for the sake of the archive, I believe it >was an on combination of some of the options SC_something that >vidcontrol -m on and my mouse and kernel didnt like. I was using some to >save on kernel size and memory used but then decided to start using the >computer on the console again so I just commented all those SC feature >disabling out and all seems well. Thank you for reporting. Would you tell me which SC_XXX options you used to have in your kernel configuration file? Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: syscons rebooting when going to 80x50
>After taking the patches for config and booting my box reboots Which patch is it? Kazu >because I have: > >#allscreens_flags="-m on 80x50" >#saver="logo" >#font8x8="cp437-8x8" >#font8x14="cp437-8x14" >#font8x16="cp437-8x16" > >enabled in my rc.conf, a kernel from ~2 days ago is fine with this. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Crashs with vidcontrol...
>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, but it is a crash because the system is waiting for me to press >a key before rebooting. As it is a problem dealing with graphic modes, i >unfortunately can't see anything that is surely written >For those who want more details on my hardware and software >configuration, please look to the "vidcontrol VESA_800x600 makes my box >reboot" mails. You will found information on my hardware configuration >and output of dmesg, vidcontrol -i adapter, vidcontrol -i mode and my >kernel configuration file. >If i can do anything to help and fix this problem, please let me >know. I do intend to fix console problems in both -STABLE and -CURRENT. But, I am on business trip this weekend and will not be able to work on the problems before Sunday evening ;-< Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Mouse behaving funny since 5.0-CURRENT upgrade
Try the attached patch for /sys/isa/psm.c, and please report the
result.
Kazu
>Robert Watson wrote:
>>
>> I'm using a Micron P133 box with a PS/2 mouse. Up until this morning, I
>> was running 4.0-STABLE from a month or two back. I upgraded to
>> 5.0-CURRENT, and since that time, my mouse has been responding slowly and
>> erratically, jumping as it moves, et al.
>
>> I'm using the default arguments to moused, with moused enabled in
>> /etc/rc.conf. I'm not sure what changed, but it would be nice if it
>> hadn't :-).
>
>Yep. It's been that way in 5.0-current for about 2-3 weeks now. When
>I use /dev/sysmouse in X, my mouse is really jumpy. It's so bad that
>I don't use moused anymore in X. When I use my mouse normally, i.e.
>without moused (/dev/mouse), in X, mouse movements are OK. Also,
>cursor motion is jumpy as well. Must be the recent commits to
>syscons.
>
>--
>- Donn
Index: psm.c
===
RCS file: /src/CVS/src/sys/isa/psm.c,v
retrieving revision 1.27
diff -u -r1.27 psm.c
--- psm.c 2000/07/22 04:08:12 1.27
+++ psm.c 2000/07/27 06:53:24
@@ -1827,9 +1827,11 @@
{
struct psm_softc *sc;
int unit;
+int s;
unit = (int)arg;
sc = devclass_get_softc(psm_devclass, unit);
+s = spltty();
if (sc->watchdog && kbdc_lock(sc->kbdc, TRUE)) {
if (verbose >= 4)
log(LOG_DEBUG, "psm%d: lost interrupt?\n", unit);
@@ -1837,6 +1839,7 @@
kbdc_lock(sc->kbdc, FALSE);
}
sc->watchdog = TRUE;
+splx(s);
sc->callout = timeout(psmtimeout, (void *)unit, hz);
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Mouse behaving funny since 5.0-CURRENT upgrade
>Kazutaka YOKOTA wrote: >> >> Try the attached patch for /sys/isa/psm.c, and please report the >> result. > >Actually, I use the mse0 device, because I have an isa bus mouse. > >-- >- Donn Robert, I still want you to try my patch, as you are using the PS/2 mouse. Donn, would you please run moused at higher priority, (for example, "nice -5 moused..." or "nice -10 moused...",) in order to see if this is caused by moused somewhat not running in a timely manner. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Another minor mouse problem w/XFree86-4
>I have a Logitech Trackball. I have tried it on the serial port >and the PS/2 port and have the same problem in both places: > >5.0-CURRENT FreeBSD 5.0-CURRENT #0: Thu Jul 27 06:00:20 EDT 2000 >XFree86-3.3.6 and >TkDesk-1.2 > >I right click on a directory or file in TkDesk, and a popup menu >appears and *stays up* (thank goodness). > >Change to XFree86-4, and I need to hold the button down to keep the >menu. Man I hate that. Which is supposed to be the correct behavior of TkDesk? The popup menu should stay up as in XFree86 3.3.6? I have no experience on TkDesk. >Any ideas. I'm RTFM moused and psm, but I don't see any obviously >related adjustments. Run `xev' and click the button in the xev window and see what messages are generated. If you still have XFree86 3.3.6 around. Do the same and compare the results in two versions of XFree86. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Mouse behaving funny since 5.0-CURRENT upgrade
>Donn, would you please run moused at higher priority, (for example, >"nice -5 moused..." or "nice -10 moused...",) in order to see if this Oh, I meant "nice --5 mouse..." and "nice --10 moused..." :-) Kazu >is caused by moused somewhat not running in a timely manner. > >Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Mouse behaving funny since 5.0-CURRENT upgrade
>> Oh, I meant "nice --5 mouse..." and "nice --10 moused..." :-) > >Tried this. It doesn't fix the problem. The mouse is still jumpy no >matter what the nice level. I believe it's a problem with syscons as >a whole. For example, whenever I switch to a VC and do kbdcontrol -r >240.34 to get a very fast keyboard repeat rate, the rate at which the >characters repeat is very jumpy as well, much like the mouse. It was >never like this before. So, I don't think the problem is specific to >the syscons mouse drivers, just syscons itself. This started >happening after some commits to syscons a couple of weeks back. I find quite hard to believe this was caused by recent syscons changes. Because these changes are about /dev/random thingie and color attribute handling in terminal emulator part of syscons. They have nothing to do with keyboard and mouse input. I am suspecting there may be something in tty interrupt handling in general in the kernel... Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vga0, atkbdc0, fdc0 attaching to ISA bus?
>On Sun, 6 Aug 2000, Warner Losh wrote: > >>In message <[EMAIL PROTECTED]> Warner Losh writes: >>: The reason you have a ISA to PCI bridge still is that the serial >>: ports, parallel ports, floppy, keyboard and mouse devices still live >>: on the ISA bus. They aren't full PCI nodes just yet in most hardware >>: designs (I've yet to see a floppy, keyboard or mouse on the pci bus, >>: but I'm sure people will tell me where I can find such beasts). >> >>I should have also added: >> >>Even though there are no ISA expansion slots on your machine, you >>still have an ISA bus living inside (unless it is a legacy free >>machine we keep hearing about, which I didn't think was on the >>market). The PC-99 standard (not to be confused with the Japanese >>PC-98 machines) states that you cannot have a ISA expansion slot, but >>a later clarification to the standard states clearly that you can >>still have ISA devices built into the mother board. >> >>In other words, No ISA slots doesn't necessarily mean that the machine >>doesn't have an ISA bus. > >Well, I understand that, my question is, why are true PCI devices like >video controllers still shown as being on isa0 by the kernel? I wanted >an explanation of that. That's what doesn't make sense to me. Perhaps >there's a valid PC/AT hardware limitation reason for it. Otherwise it >seems silly. =) > >Brandon D. Valentine If you read the PCI's specification, video cards are given special treatment due to necessary backward compatibility with ISA video cards. PCI video cards occupies ISA bus resources (ports and memory range) and these are handled in a special manner which is not quite PCI bus's way. If a video card uses only PCI bus resources and does not occupy any of legacy ISA bus resoruces, it is indeed silly that it is recognized to be on the ISA bus. But, the reality is that the PCI video card is a half-PCI and half-ISA device... Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Recent -current breaks console probing on dell notebook?
>Until yesterday, I was running -CURRENT from around July 4th on my >notebook, given that I was travelling and unwilling to break my means of >giving presentations on my trip :-). Yesterday, I decided to upgrade, and >built kernel/world. The userland stuff appears to work fine, but >interestingly, my kernel seems not to probe the console, and instead, use >the serial console. The boot loader does not have this problem, and sees >the console fine. The symptoms are that as the kernel loads (spin spin) >after the boot loader, it ceases spinning, the cursor changes to a block, This means that the video card is initialized Ok... >and after a delay for hardware probes (&tc), the login prompt comes up but syscons is working and providing /dev/ttyv%d... >without the ability to type. Umm, the keyboard is not available... >Unfortunately, I don't have a box with me I >can use as a serial console, so I can't attempt to see what it did or >didn't probe successfully, just that things got that far. When I get home >tomorrow, I'll attempt to debug it, but was wondering if anyone else had >experienced this, or could point me at any commits that might potentially >impact this. > >Thanks, > >Robert N M Watson FreeBSD Core Team, TrustedBSD Project >[EMAIL PROTECTED] NAI Labs, Safeport Network Services Can you login to your notebook via network? As the loader seems working, you can boot the machine with bootverbose set, and can get dmesg output if you are able to login via network. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: ACPI CHANGES AFFECTING MOST -CURRENT USERS
>The loader now detects ACPI in your system, and loads the ACPI >module if it is present. This has major ramifications for the >device probe and attach phases of system initialisation. > > - Root PCI bridges are detected using ACPI. > - PCI interrupt routing is now performed using ACPI. > - The PnP BIOS is disabled and onboard peripherals are detected > using ACPI, and attach to ACPI and not isa. > - System-owned resources are detected and reserved by ACPI. Then, shouldn't we remove the PnP BIOS driver (pnpbios) from the kernel and make it a module, so that the boot loader will load either the ACPI module or the PnP BIOS module? Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: my psm0 doesn't work with new acpi :(
>So i can't use X server. The problem appeared right after i've compiled >and installed freshly cvsuped kernel after new acpi first commit (31.08). >I'm sending dmesg and kernel config files in attach, and waiting for >help/comments. Thank you. Please apply the attached patch in /sys/isa and see what it does. Thank you. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: my psm0 doesn't work with new acpi :(
>So i can't use X server. The problem appeared right after i've compiled
>and installed freshly cvsuped kernel after new acpi first commit (31.08).
>I'm sending dmesg and kernel config files in attach, and waiting for
>help/comments. Thank you.
Please apply the attached patch in /sys/isa and see what it does.
Thank you.
Kazu
begin 666 atkbdcident.diff.gz
M'XL("%:OE#L V%T:V)D8VED96YT+F1I9F8 Q5C_4^)*$O\Y_!7SO"H?D" )
M("C6[JTK7"UUZ\J)N[?WK5(Q&30E)+Q)T.=Y_N_7W3-))A#4MU?UCK),,M/=
MTU\_,SV3*."_#IF7WET'OALFWH%?>_>__VJ79S,V#Q=\R-J)\-MGWV;T3!Z3
M-BS2UM>S[FN"IR+D]V%TPP0\DC".F'/0Z=2"<#YGK35K"?PLJ]EJM4H#1L>V
MG;9]U.[:S#X>.H?#3L<@*:9I5E$>M^T><^RA/1CVG-J'#ZS5MZT^,_L=ZXA]
M^%!C-9:D7AKZ+(Q20PE8B?B:UP/0TN=NRN"E<5)%YZ6IY]]N$IJ*,!O.J8/
M]6_#15 P7*\3"P6R6 1<6,R_]01K1MZ26S73@!]-KJ,PK59@)>"C4NCKR@ON
M!6YX[XD7.*5R(>:/56.DT!I&5JF ^>:]MP#1Z--!!WTZZ%L#\JDQ&G\['U]]
MNAAELI-ULN)18!FPA'O#(RY"/QML6%4<@B=K<$.)08XA/7BGX$"2W+G6EKLW
MY".UYC>KPI<5'+FWK"W_55 _B##E9?)B".C19T[G&)WF='LJ$XUGS$:#"Q$+
M]H[IN>AB"F2>N>%I_MVPV"H6J2T?#F:?$"Y^F+3;[V\R]',_&][J6
MTY66 S:L1<1(:Q".CFBIC+V/PZ#6TF(JO5 OIZD?1TFJET]1.+764ZV512&O
MR>8=O)[ 1#Y"D<<1K!$CA3=\!U]FUKF8'Y#S:UZ72Z!XB^T%@#?7"Q[L66P_
M;9#3V?X^2]E/Y/Z6H-$Z7B3RAU:ZFW*!^*7S2]203*:KV'
M"5 3W6#P1<(W)UK.V]>8+[R;I'H5FJI>)YNRY4(4'OA4\2J!J<6*]1I:4!.H
M%*RXI"Y+G=W)M&\]@T@-$FOL!4"OL2?(4$60Q//4Q_1)_#Q5I)4!/JC\LC&L
M$OK(TEI^B;#(LA#?BMPU5.XV WS*\D1)A=FEVD>1B0^3S7I9/=9L-C0&&E4<
M6($=Q[$ZAU"!1P.K>YQCC_%F,; DV@]%:K2;\(\UV6D0,$AII6>"!3D/;]:"
M!RR-V35GTK7R4RYC'Q!K&_ZCN64C<40S%/RE4L%X@%!R5B^R;@[[D[OT4@C<
M?@A9%D@G[@(,LDS4(O"I3B?WQ%[_^WSJR$]T5.
M*\!78 N*F<\U<^NX4C-_Z+RB :[Y!&6P W#-+< U<\ %77X8'LUJ>#1U>#0S
M>&1?OG[^+-?;"2MD:@E6I"S%\(YDZ#)S1,S7P!K]578QG0]T^)YH#<[OW-^\TMXX=JF]
M<>R2DGEW4VI9!NV.S9SNT#X<=GL&RIG,(C1 A^V''0*()+"#M]JP&2X>O,>$>;CKIPR[ -@3(BXK%/=&T_CX=>:>
MCD;NV:?)YU%=BJ >0HIOO9<0@MV$N5G0;%="9:6^2I:_3Y'30CO+N]LOE7>W
MKQ3#PJ8W5:G==J?/G,ZP9P\/!P;Q84GK)%3,]O'PL#,\[*MC6A^#C0_55D/[
M33_<:INTXUIL&:\3CJZ#+1]&&S+[(43S=>2GJ":X,8W3QQ6M.ZUH2%.%OE.L3F2@RBF,WE4SQ5\D"7DV&/NC:=%O3M1WE S!,TJ@T@B]
M,^&E'$T%^W85/BRT4?8,$WDDA8$J7,P]>*/]C :9FU[&@MQ-U632
M-T0F7Q4.#(X< H(C0(*!0GJP!L@ROX"*XA$:;[",XLXVBE^SXZVECZD'B\")
MX '.\P*]QJ;1%%(PP/-G'/T,;8S@$ OF95&*8([-8P$O#P<'!^1>2F$X5B!T
MX_'HGD=!#&V1 HE&?BK)FEDS7_MUW$'"-T)/RVFH,S#[0\#A2,[!:PIU[AO&
MDU+S.HY3X+J.$]Z@.[!_RJNP5DN-G@"A&G_I)ULKL#=+32^YJR=^ZSU.0"'#
M9^,$A%#M8V2[4/R#X[YU)"-,(#FZG'P;7[KG%Z.OG\=U"**ECL4697@6/WI7
M&SU9;LN3%#0S)O0R5[=API*U?Y>P]8H!37@3+3EFRES$2S;],OTXN9A1RW-Z
M-IT<(%,;^3,_36?G9T#E*G6^G)Z/#6,/5O57T6JOV&D,[?A!)8'SVA&D1)A7
M3XF81DXVZ631E CET,EV2Z-C %&^NOUK-5SHT+"J2+5"UK0@6OA[(M]#Z,S2
M_IL77.X16;12G0KGHK@-[7'( 1T1Q:*8T59/42JMI%HG+#7DE9COR]?" :#F
MKT[7G@=VSX'S_'36[LB-A6[N]MBS1XWYL2-ES/]>/58WT#?[EMAIL PROTECTED];"\+DF1)39>[B&%O!IDBU;[]>!VE
M1<\E^^*TN+!$&,CO*R__0J6R3T+@25*V9EK&=]S!FJS3'N\2DEO.;OCC]>Q
M)P*\=$E%O%A )I&[T=Q$-Y?P8M->9:ZT]D2Q!7S!4_Z2HQJY8H#KH 8=-/"B
MA^Y):$M'Y2+^P#"H4B-E6*G8@2&[I #],D@NI4>I#C=.A.5TD&!81'PR.W6Q
MEJ:7%Q_'^@VZC(>Z0Z=[%*TP&CNC /\ /R>T!>(E#IBKULQV/#B&H-T)7@WA
M)8+D4/LBAH^\ 22"']!<.[\M*6X-Z'ZH=/FRI3/=?9QM@H0\(U;=%N;)IM:"
M_E^7C>[F:H[Z^!%D[]75Z=FG\4BZHURCV:Y3-.F0"7>
Re: my psm0 doesn't work with new acpi :(
>> Please apply the attached patch in /sys/isa and see what it does.
>It does panic with a smiling face ;-)))
>
>panic message was "bad ivar read request"
Would try the following patch for /sys/isa/psm.c IN ADDITION TO
my previous patch?
(This is a test patch. It's not a final fix.)
Kazu
--- psm.c-save Tue Sep 4 20:51:39 2001
+++ psm.c Tue Sep 4 22:29:49 2001
@@ -779,12 +779,8 @@
psmidentify(driver_t *driver, device_t parent)
{
-/* if we are in PnP mode, don't create a device node for now... */
-if (isa_get_vendorid(parent) != 0)
- return;
-
/* always add at least one child */
-BUS_ADD_CHILD(parent, 0, driver->name, -1);
+BUS_ADD_CHILD(parent, 0, NULL, -1);
}
#define endprobe(v){ if (bootverbose)\
@@ -814,6 +810,17 @@
BUS_READ_IVAR(device_get_parent(dev), dev, KBDC_IVAR_IRQ, &irq);
BUS_READ_IVAR(device_get_parent(dev), dev, KBDC_IVAR_FLAGS, &flags);
+/* see if IRQ is available */
+rid = 0;
+sc->intr = bus_alloc_resource(dev, SYS_RES_IRQ, &rid, irq, irq, 1,
+ RF_ACTIVE);
+if (sc->intr == NULL) {
+ if (bootverbose)
+device_printf(dev, "unable to allocate the IRQ resource (%d).\n",
+ (int)irq);
+return (ENXIO);
+}
+
sc->kbdc = atkbdc_open(device_get_unit(device_get_parent(dev)));
sc->config = flags & PSM_CONFIG_FLAGS;
/* XXX: for backward compatibility */
@@ -1083,19 +1090,8 @@
endprobe(ENXIO);
}
-/* see if IRQ is available */
-rid = 0;
-sc->intr = bus_alloc_resource(dev, SYS_RES_IRQ, &rid, irq, irq, 1,
- RF_ACTIVE);
-if (sc->intr == NULL) {
-printf("psm%d: unable to allocate the IRQ resource (%d).\n",
- unit, (int)irq);
-endprobe(ENXIO);
-} else {
- bus_release_resource(dev, SYS_RES_IRQ, rid, sc->intr);
-}
-
/* done */
+bus_release_resource(dev, SYS_RES_IRQ, rid, sc->intr);
kbdc_set_device_mask(sc->kbdc, mask | KBD_AUX_CONTROL_BITS);
kbdc_lock(sc->kbdc, FALSE);
return (0);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: my psm0 doesn't work with new acpi :(
>> Would try the following patch for /sys/isa/psm.c IN ADDITION TO
>> my previous patch?
>>
>> (This is a test patch. It's not a final fix.)
>
>panic: nexus_setup_intr: NULL irq resource!
Ok, this is one last test patch. Please remove ALL my previous
patches and apply this one in /sys/isa.
Thanks.
Kazu
begin 666 atkbdcident.diff3.gz
M'XL("%@HE3L V%T:V)D8VED96YT+F1I9F8S ,T;:7?;QO$S]"O6RHO* Q0!
M4K>:-+1$QVPL49%HQVG:APC
M8UEVV]IO=RQF=X^LW:/NCD$PFLUFQ<3#MK7#[(.CG=VC3G?CN^]8:[=CVAW6
MW-TQ[1WVW7<;;(/Y_-Z;N''L)(: H :.X6TS3MPD\-A]&/CB=>#S:1*,'VM^
M%-SSR$E80SR9""GP.(S 0QU6R[7!5$*>1>$UKZV:Y2:)Z]VLG!;Q>'ZW$%J&
M+S+$@551#<=8PXT^X+QTI@1PQY.;T N1%,JF\T@3? G7:#N9,']S%F
MKN\#!]F$NW'"PBEGWDTP :ZW8=;+MU=.[_34.7D]>'-:$R!,9@%8 M_Z=NH"
M3QI>*C@\ 4# #1^K$99/]
M\/+TA*8Y@\L?3;8%Z-6/GPOBU9O>]U< A A#]AKT!+JM :"AFC0C(=28AX[[F02>H[BL>#1U<^(\I4D!):1
MT/\#_]LFNWSE]$Y&@W=]0@LVJQ&P;]CYVS=OZF1[-'H=A@DHR748\SJ.&:EI
M@9#&4ACS*:&7A(SP1%'S>;+""3ZY!JA#*2UA(C &=G'U/["+&F*,Y\&B2Y2
M]9U\0$:R_JI"^M(1''9->X\U;7L?/]$3? 0H.2_ &K$'LC9NI0+C"+P^7M.@
M%AH.TPR''GD4A9$PCMC+:QVA(K6N]7]D(BROX4(S4 40D!*_U)!*)5C+S SB
M#$P0L"V8)K6!L;7U0.(^S2<0=O2/;:*[?A:0
MU+$HFO$/?,S5ZQZHQ,LW??:IPN5D>TF_4W80C-3JJC]Z>^$,SDAGPDK@Q/+!BI6!Z^[>T6Z'5'5GWX2P9N?0/)!A*V@E
MQ1; >G*HR>.,^WS,Y#$O@4J/BS%"YJ!0H[UP.@X^S".(,( B8:>DQS@-71I.
M&ESUZ/"X<^-;<>@5@@AG$L39MT+, X2OG0[X#/O^=0/2Z,QCP)WDA^;A!\"
MSYW@5"1[#\(YFS7W.F;'EH07 V'/62^N]ISJR+J9#X2SV;[O$(>S!6"()@)D
M8>1C/.C=N&#]%+;1F6S02_1%U0C085T)=#7R$7?!7.[=:,E*@5R AJ,<0'9N
M->[=237HARA(^#-@:\ %;,7**BU!!C7DAKDSA%1H.3L6P-5!EOWC4CK06I3,
MQ!^.-LB'RG.=SK;T&RAP?KX<]\+YE&:EYJ7AFQ-?.7):%T-E4V:1 13#K\[F
MO$(ZMRI#DQ:E,BI(F;NL>;"#B16=D:75\3R>(8,,$2!,P:X]-;@\@=,7I'D<
MRR6<=/HI6S1+UEF C[,U,S,K3*]B16I<9LG<*F9G]F*630CFMXK8YW0S3W3^
M7<7BHN(4>99_6S=+O"L9F[G("BL6%U&OM+:*=66L%]A!!7M=+P%&)MIBEN-8
M\74%")^O %(Q807K"GR?Y%Y6K(V7K8V7K_6!2^K#BLD9H.+X:7(XJ/:3-*/M9?9F?($=W=/7-G!PC?W47?
M2)07\@9D1$LO+K4TQR6X4,L[?8C(X"#40HHLF-AH80"7"^D@3FG_4N
M*L>MV$>]LL1&HA:89L.Y --DV7YU3:CH*?!8B6OB/&.WLE;P&4"6*X350:Y6
M^_!4\<.@XH=4%4&ECQ\RAA=CLH!A&$JMQ3>*Y.72 )\RW36D[C9\_!3FB9#R
M18#4]H]52:11RZ/'&HWZ@C()6F#'MLT="RSP\-#<[Z:^QU@;#&Q)Q1] OMV
M?UB#];!V.YE(/.,T1>(^5M2N.1.L%5_%-M8V+<6\" !1
MBZVJFK@N1PUG/<33-:D(B"UT(#)5)QG@E>(X4DI^=JM>.(\QJ%AAI&N8IK2NEG*0 M
M @/W _JRA>M;WZ9IM=A0C%&5B1BNZJM">=VI+UGR-Y@, X.Q7G(-8C8-P4(A
MK$U @:\?Z>7%](*]' RO "#KG5P,3+$TXF,>H9++Q3<@DYB-8=+@\L=MV'29
MQO_9VHZ"&5SUG(OS"^?B:Z =!F>!0):LKAV2DCD"GFIH.MI61Z02=BWF5K UV14B2[2$GBATD29I76WB0DAO(.4%IF12[
M51VM:Y9OR61S6%>QJ$R9U4Y*)'?Q*2O&_:E"5#Z[>O?]NDXJVVK@P. ZX7:!F+
MH.&$KWT=DKC-6'F%()1)1[>Y&MWL'O")]QHI=LH\<7-)W,*MB;8)$B=H6B:8
M<1@F><&P++>HB74J!-K=IUZ&SOZ!N2=KH^K$?(*>&/%# )X8R,#27IU*Q1YD
M1/GKI2.46T-H94VH;UWX%7D_9ES#T7)[7%Y,%TN+ETO%SP"P(H!W_?/3X>7@
M] BKCI4P].JR D,<.C@@#G6M[A_$H90EN -(M7Z/]>VUN*.Q8\'BY9S)LT+P
M2!;5!: \;[JVA:E[USXTN_OYJZ_^^;!_/CJ6$?6" +&ZQ/N\ F]EC,A4C)C%
M@>O++'7IQ:-Q.149 <\I)V1L+JCZ/8&AZ=Z5M>\_C%62@J@W;W@
MW3V)&-Y_TI.\SNRV.WO,[ASM6$>[^P:MPXM/?4K:JK=SU-F7*?X>>BC\4 [*
MT*YJ2#M,=A?.8XX:A_5+D*HX,=L--IY//;K;G$5A$J)HZ()3;_A"!%2W%W.<
MBYK6\I4I93U_:8:+1$>+6+%XEHBE5T[S>?4T\M*6\-*6+7E O0B4E E496<"
M)'5(*MX#+[@(@HU*MT [%2FA]C3,'8]V=JTI-M/8]GR7C_%IN6=?BF;JJ<)
MWM T\2COI+HV-7#"\;4G3W;\RQ<(D&*J]Z3-?JVO(%R#-/B1)VEM5D[&/H39
M=.8(IO]?7@I
M3QC6L;5\1=*#46K\0+3(1R2&KO,.;%2I_?W=K 46F[3B.Z52(-WH$?"DK!]5
MJM EJ:G ^CV2B.A:;9(XL;I3TE[<*:F8 ]P2=P/W=>,C>HI"YQS=6_]37%^W
M6G+T&";*\65_HJQ(W8_"M-SXECIGA!?'K_5C $),/NQBN\;^X:Z9]IXIS[6\
M&DIZ7%!@[%-;TC5&84:A7RT_IK)+A0**\Y?NO[01+[R[^<_V8<&T8B1*>
MZ,"B^]^F_$2:T)JLC8PW/K^>?ZB-+M]B8Q%+-3=G=5(-O!ONW5+Y:7 :IWJ/
MT@([6%JZ\;,F(VFH5!N@+J5ZEOG+KB5E/TQL\.7-=<^&4FI!E9Q8UF)*X0/%
M\K9<\(5-8?G6+\7R4O<7%:W*3:>Z,:3._EG=IPJ*RFN%].0+BI04L:A8V45B
M../3JBO$JJX_)2V$(BKY $>D5UOLXNK,.1F>OQI\+P2CL3>=6UEPJ%S+I"Q!
M=X^H3'KM>K_BK)YQ0^+VZ1MY_6H==$T;&QCQX2 ]!_$O]82*MTSQ5MG@$LUK99IG:6S\
MPI[&EHB)=1U,S;Y*!UN*%E5) 8/_VC]B:^@9JWWMU[=!VW!7"474%2FQUHRY
MDE?T)BW@MI[4^JPH2<'@X2U9[N-1IRS[F4#7/8O8)_0^3N_M>]36T>7PC?-R
M,+K*00#NZ]=Y<]=4$99M6UBN+@3CHVI]UJ*6;J.:-F5URQD4N*%2!NDF*ZP26))KV_9.OXW!\OO8V._\S'"%IJP
M5KC,.2'5'?*LAF(IY3VAB_9N1R9&.A88WG#IJ8<7_7,-DSYL^O.Q\H)9@WN.
M1TR)=-3O79X.?SI_4L=SUL+\)58N4N!]\.M=+/'N'9H'@M"*0@+8E*H8B*A(
MQ>+T7"PA0##>;@#%#3:Z <#
MV[BHC>M5N T,/L%@3:)SWCOK&P:Z:0]RJN(Q8\ Z:6X^RTW7
M/"'%I34E7E"U4%Q/.Z[CA;/'K$:H5#L=N..R\)"K,9J+_OBE$(]U:EKPJW)$Y\'Y3WX7F+_S%
MA?QAX5UX+WYWDL8V$/A@O#/E#PSY)'A:;#D43B%'GJV.B;0KI-!'N( C H_M
M[6W8=2I_S27:#:AP!0>_^#VR0IPSKD+;4E[&@I52L&O<
M\N=31:7M]86L3OLF'CC#%@4@4NZI:F[AE#@?8^,#EGW%"J&U)".2!TR)^#:]
M:Z?%Z2S4H>Z'W"5R"6?J&SDI6KZH?U:%6*E&R;VVMI@.F\Y#^8ZRY5/0T-&H
M=_*Z?RK8D3<\S=XR^=]R/F._S@,NQ2WATTBQ=%Z\+,H)NK)!3?Z0MKB^=,XA
semi-HEADS UP: PnP resouce parser update (was: Re: cvs commit: src/sys/isa pnp.c pnpparse.c pnpvar.h isa_common.c isa_common.h isavar.h src/sys/i386/i386 bios.c)
I just committed update to the PnP resource parser for the PnP ISA and PnP BIOS devices. As this is a bug fix, there shouldn't be any nasty surprises. But, if you have PnP ISA cards and encounter any problems or suspicious behavior, please report. Thanks. Kazu >yokota 2001/09/04 20:54:33 PDT > > Modified files: >sys/isa pnp.c pnpparse.c pnpvar.h isa_common.c > isa_common.h isavar.h >sys/i386/i386bios.c > Log: > Rework the ISA PnP driver pnp and the PnP resource parser to fix > the following bugs. > > - When constructing a resource configuration, respect the order >in which resource descriptors are read, in order to establish >the correct mapping between the descriptors and configuration >registers. >"Plug and Play ISA Specification, Version 1.0a", Sec 4.6.1, May 5, >1994. "Clarifications to the Plug and Play ISA Specification, >Version 1.0a", Sec 6.2.1, Dec. 10, 1994. > > - Do not ignore null (empty) descriptors; they are valid descriptors >acting as filler. >"Clarifications to the Plug and Play ISA Specification, Version 1.0a", >Sec 6.2.1. > > - Correctly set up logical device configuration registers for null >resources. >"Clarifications to the Plug and Play ISA Specification, Version 1.0a" > > - Handle null resources properly in the resource allocator for the >ISA bus. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: my psm0 doesn't work with new acpi :(
>> > PS. I just removed and checkout sys/isa.
>> hope you did a "make clean" too...
>I tried this too - nothing changed. :(
>Where is my netscroll genius... I want it back
>;-)
What was the message? Is that the following?
panic: nexus_setup_intr: NULL irq resource!
Or, something else?
Can you provide the last few boot messages before the panic?
Would you please apply the attached patch in addition to my last one,
in order to get some more information on your system and ACPI BIOS.
I am afraid this patch still won't make your mouse available, but
it may stop your system from panicing and let you go through the boot
process. When the system comes completely up, please send me
entire dmesg output and /boot/device.hints.
It now appears we have several classes of symptoms regarding the PS/2
mouse and ACPI. Each may need different trick to fix...
Thanks
Kazu
--- psm.c-save Wed Sep 5 18:54:27 2001
+++ psm.c Wed Sep 5 19:07:09 2001
@@ -2818,8 +2818,14 @@
bus_set_resource(psm, SYS_RES_IRQ, 1, irq, 1);
bus_delete_resource(me, SYS_RES_IRQ, 0);
+ printf("adding...");
+ BUS_PRINT_CHILD(device_get_parent(psm), psm);
+
+ return 0;
+#if 0
/* ...then probe and attach it */
return device_probe_and_attach(psm);
+#endif
}
static int
@@ -2830,6 +2836,9 @@
if (ISA_PNP_PROBE(device_get_parent(dev), dev, psmcpnp_ids))
return ENXIO;
+ printf("probing...");
+ BUS_PRINT_CHILD(device_get_parent(dev), dev);
+
/*
* If we find an atkbdc device on the same bus,
* create our copy there.
@@ -2838,6 +2847,9 @@
device_get_unit(dev));
if (atkbdc && (device_get_state(atkbdc) == DS_ATTACHED))
create_a_copy(atkbdc, dev);
+
+ printf("quiting...");
+ BUS_PRINT_CHILD(device_get_parent(dev), dev);
/* keep quiet */
device_quiet(dev);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: my psm0 doesn't work with new acpi :(
Thank you. I got the files. Then, would you remove my previous small patch from psm.c, and put the following line in /boot/device.hints instead and reboot? debug.acpi.disable="sysresource" Or, you may type set debug.acpi.disable="sysresource" at the loader prompt before "boot -v". Kazu >You missunderstand or maybe i wrote something wrong. Now i've got a >bootable kernel with no panic and NO psm0 messages at all. So i had to >boot -v to produse some. Now i applied your patches and next mail would >be with boot -v messages > >> process. When the system comes completely up, please send me >> entire dmesg output and /boot/device.hints. >Ok. > >> It now appears we have several classes of symptoms regarding the PS/2 >> mouse and ACPI. Each may need different trick to fix... >I think that it is ASUS A7V-133 feature. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: my psm0 doesn't work with new acpi :(
As I wrote in another mail to Harti Brandt and cc'ed to you, it now appears that ACPI on your motherboard declares IRQ 12 BOTH in the PS/2 mouse resource descriptors and in the system reserved resource descriptors. The system reserved resources are sucked by the sysresource driver in the acpi module. If the psm driver can get at IRQ 12 BEFORE the sysresource driver, or the sysresource driver is made to be probed AFTER all other acpi device nodes are probed, all should be fine... As some other people are not having this problem, this may be called a quirk or anomaly, to say the least. Kazu >> Then, would you remove my previous small patch from psm.c, and put the >> following line in /boot/device.hints instead and reboot? >> debug.acpi.disable="sysresource" >> Or, you may type >> set debug.acpi.disable="sysresource" >> at the loader prompt before "boot -v". > >Wow, my NetScroll is back in bussiness!!! ;-))) >So is it buggy BIOS, chipset, ASUS or PS/2 mouse? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ACPI and PS/2 mouse problem
As reported in this list by several people, you may be seeing that your PS/2 mouse is not detected after the recent ACPI update. This seems to be caused by ACPI in some BIOS assigns IRQ 12 (mouse interrupt) to both the PS/2 mouse device node and the system reserved resource node. To see if this is to be your case, put the following line in /boot/device.hints and reboot. debug.acpi.disable="sysresource" If this brings your mouse back, I recommend you to keep that line there until the proper fix is committed. If it doesn't solve the problem, there must be other causes ;-( You had better contact the FreeBSD ACPI developers ([EMAIL PROTECTED]) ML. Kazu PS: I am going to commit some update to the psm driver shortly. But, that alone won't fix the problem. Sorry... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
