Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 8 Sep 1995 10:22:44 -0700 (MST)
From:      Terry Lambert <terry@lambert.org>
To:        pw@lysator.liu.se (P{r Winzell)
Cc:        questions@freebsd.org
Subject:   Re: your mail
Message-ID:  <199509081722.KAA04318@phaeton.artisoft.com>
In-Reply-To: <199509080816.KAA07879@katinka.lysator.liu.se> from "P{r Winzell" at Sep 8, 95 10:16:31 am

next in thread | previous in thread | raw e-mail | index | archive | help
> I wrote a previous letter but it was in the midst of installation
> confusion and didn't really contain direct and identifiable questions.
> I have now been running my system happily and with impressive stability
> for quite a some time, though, and I hope somebody will be able to
> briefly answer me these two questions:
> 
> A) Using a serial mouse for X, the pointer jitters all over the place.
>    Is anybody likely to fix the serial driver? Friends tell me the FreeBSD
>    serial driver is known to be buggy, which seems to me to be quite big a
>    problem for an operating system?

man 4 sio

Add flag 0x0002 when rebuilding your kernel to disable the FIFO.  The
proper way to handle this is to disable the FIFO when the mouse line
discipline is used, only X doesn't set the mouse line discipline.

> B) Is there any chance of seeing a combined keyboard/mouse "PS/2-mouse"-
>    capable anytime soon? Altneratively a hack to the driver that exists
>    so that it works? (Currently, the probe for the mouse locks up the
>    keyboard).

more /sys/i386/conf/LINT

There are various options dealing with the PS/2 mouse probe lockup.  The
problem is that theres not a standard implementation of the hardware unless
you are running a genuine IBM machine (in which case the thing doesn't
lockup).

> C) I have a definite bug in the NFS filesystem and it seems to me it could
>    only be on my end of the link that the problem lies. It is most easily
>    identified by simply su:ing to root and doing a 'mv' of a file to a NFS-
>    mounted filesystem. A chown will then be attempted, and fail, and some
>    buffer fails to flush properly because the destination file will be
>    truncated to some even number (eg a 51134-size file will be 49152).
>    This is obviously a rather serious problem and is keeping me from using
>    NFS for anything other than read-only-mounting eg the src directory.

The chown "problem" was discussed in detail some time ago, and has to do
with your expectation of the semantics.

An 'mv; will *not* truncate a file unless that 'mv' is a copy (ie: across
file systems).  Potentially, there's an interaction with the chown failing
(which in your case will only happen if you as a root user are attempting
to do something for which the remote file system is not granting root
permissions -- the default way remote file systems are exported in any
case).  This type of interaction will only take place if the server or
client is doing caching /in violation of the protocol definition/.  An
aborted operation at that point may prevent a cache flush.

>    I do not run YP/NIS.

Bad idea in an NFS environment.  How you you make sure the files owned
by "Bob" on the remote machine aren't owned by "Phil" on the local machine?


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509081722.KAA04318>