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