On Wed, 21 Jul 1999, David Coder wrote:
> I don't believe your mouse is on the first com port. If it were, the output
> of "moused -i all -p /dev/cuaa0" would be "device busy." The message you got
> is generated when there is nothing on the device at all. Check whether it
> isn't on the second
I don't believe your mouse is on the first com port. If it were, the output
of "moused -i all -p /dev/cuaa0" would be "device busy." The message you got
is generated when there is nothing on the device at all. Check whether it
isn't on the second com port.
dc
_
David Coder
[Charset iso-8859-1 unsupported, filtering to ASCII...]
> That's certainly possible. I yanked two of the
> 256M DIMMs out of the box (leaving 2) and the
> box has been stable for 1:17. Would be pretty
> odd that I just happened to grab the bad dimms.
>
Have the DIMM's been qualified to run in
Hi folks,
I've just committed a change to inetd that will effectively turn TCP
Wrapping off for anyone who has an installed /etc/rc.conf that specifies
an inetd_flags value, as well as anyone who makes world without running
mergemaster to update /etc/defaults/rc.conf .
This will not be a proble
>> Ok, the problem seems to be with the mouse, rather than the serial
>> port.
>>
>> Give me some more details about your serial mouse.
>>
>> What model from which manufacuture is it?
>>
>> I suspect it's rather an old model, because moused should be able to
>> detemine the protocol type if it
> Ok, the problem seems to be with the mouse, rather than the serial
> port.
>
> Give me some more details about your serial mouse.
>
> What model from which manufacuture is it?
>
> I suspect it's rather an old model, because moused should be able to
> detemine the protocol type if it is one of
>I posted the other day about sio problems and
>it seems that I'm still having trouble. Below
>is various output for sio (cuaa0). I'm trying to
>get the darn mouse to work ( to get X up and be done
>with it!) but I'm running into problems. For one,
>I can't seem to debug this problem so if AN
On Wed, 21 Jul 1999 14:24:40 -0400, Keith Stevenson wrote:
> I followed your how to repeat procedure (sans -w flag on inetd) and
> the problem still exists.
>
> From /var/log/messages
> inetd[33029]: write: Bad file descriptor
Ah, excellent. Bad news for me, but good to know. :-)
Thanks!
She
I posted the other day about sio problems and
it seems that I'm still having trouble. Below
is various output for sio (cuaa0). I'm trying to
get the darn mouse to work ( to get X up and be done
with it!) but I'm running into problems. For one,
I can't seem to debug this problem so if ANYONE k
On Wed, 21 Jul 1999 18:49:40 +0200, Sheldon Hearn wrote:
> If you have a bit of free time and a non-mission-critical inetd built
> from rev 1.46.2.3 of inetd.c running on 3.2-STABLE, I'd appreciate it if
> you'd look at PR 12731's How-To-Repeat, try it out on your box and let
> me know whether
Hi folks,
I'm looking for feedback on whether the bug listed in PR 12731 (inetd's
hosts_options(5) spawn handling breaks after SIGHUP) exists in inetd on
3.2-STABLE.
If you have a bit of free time and a non-mission-critical inetd built
from rev 1.46.2.3 of inetd.c running on 3.2-STABLE, I'd app
What is the maximum ammount of RAM that 3.2-STABLE will detect by default?
If more than 128M does it follow the same syntax to detect more as:
options "MAXMEM="
Thanks,
Chris Malayter
[EMAIL PROTECTED]
-
Administrator,
Moral of the story - search the news archives better...
I found the answer. My clock was (for some completely unknown reason) set
to 1996. Setting it to the right date in 1999 cleared up all the problems
and an upgrade from 2.2.8 -> 3.2 went on without a hitch.
Thanks for the suggestions.
-
subscribe freebsd-stable
subscribe cvs-all
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
14 matches
Mail list logo