Return to BSD News archive
Path: sserve!manuel.anu.edu.au!munnari.oz.au!news.hawaii.edu!ames!agate!agate.berkeley.edu!cgd
From: cgd@toe.CS.Berkeley.EDU (Chris G. Demetriou)
Newsgroups: comp.unix.bsd
Subject: Re: [386BSD] 16550 Not Resetting.
Date: 26 Nov 92 17:58:45
Organization: Kernel Hackers 'r' Us
Lines: 33
Message-ID: <CGD.92Nov26175845@toe.CS.Berkeley.EDU>
References: <By8FAD.KAo@ucunix.san.uc.edu>
NNTP-Posting-Host: toe.cs.berkeley.edu
In-reply-to: pmartin@eniac.san.uc.edu's message of Tue, 24 Nov 1992 17:59:01 GMT
In article <By8FAD.KAo@ucunix.san.uc.edu> pmartin@eniac.san.uc.edu (Paul Martin) writes:
> [ ... ] I appears that the
>16550 uarts are left in some weird state. [ ... ]
Sounds like the DOS drivers for your mouse:
(1) don't initialize the 550 properly (i.e. don't reset it!)
(2) don't know how to deal with the fifo...
if they did (1), then the 550 would reset to non-fifo operation,
and it seems that if you're having strange problems with the mouse,
it would be directly because of (2)...
sort of odd; the only "weird" state that the 550 is left in (that i know of)
is that it has the FIFO enabled, and i'd *hope* that mouse drivers
would actually reset the serial chip before using it...
<sigh>
i've got my mouse on a '450, and don't use DOS, so i can't help much
more than that... your best bet to get it working would be to
write a little piece of code for DOS that explicitly resets your UART...
the code to do the actual reset could be pulled out of the probe/attach
routines of the serial driver, almost verbatim...
Chris
(wondering what the networking folks have done that causes 1/3 of the packets
between here and a machine 400 yards from here to die...)
--
Chris G. Demetriou cgd@cs.berkeley.edu
"Sometimes it is better to have twenty million instructions by
Friday than twenty million instructions per second." -- Wes Clark