Return to BSD News archive
Newsgroups: comp.os.386bsd.bugs
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!haven.umd.edu!uunet!mcsun!sun4nl!relay.philips.nl!cnplss5!bashful!rooij
From: rooij@bashful.isp.cft.philips.nl (Guido van Rooij)
Subject: Re: Problems with patchkit 0.2.4
Message-ID: <1993Jul15.070541.27917@cnplss5.cnps.philips.nl>
Sender: news@cnplss5.cnps.philips.nl (USENET News System)
Nntp-Posting-Host: bashful
Organization: Philips Communications & Processing Services, Eindhoven
References: <221u4k$lfn@acsc.com>
Date: Thu, 15 Jul 1993 07:05:41 GMT
Lines: 107
fmayhar@acsc.com (Frank Mayhar) writes:
>Such is not the case. I encountered the first problem when building the
>kernel for the first time after installing the new patchkit (on a virgin
>386bsd 0.1 source tree, btw, with, of course, the old 0.2.3 patchkit in
>the same set of patches). The file sio.c wouldn't compile, due to the
>following line:
>#define CRTS_IFLOW CRTSCTS /* XXX, CCTS_OFLOW = CRTSCTS already
>Unfortunately, /usr/include/sys/termios.h contains the following lines:
>#define CCTS_OFLOW 0x00010000 /* CTS flow control of output */
>#define CRTS_IFLOW 0x00020000 /* RTS flow control of input */
>#define CRTSCTS (CCTS_OFLOW | CRTS_IFLOW) /* ??? */
^^^^^^^^^
You should of course get rid of the patches cgd's driver introduced.
In the stock termios.h it certainly didn't say that!
>Which makes for a circular loop in the definition in sio.c, and which gcc 1.39
>didn't like. I modified sio.c to:
>#define CRTS_IFLOW (0x00020000 | 0x00010000)
>and commented out the offending line. This solved that problem, but I'm
>not certain that it's the correct solution. Suggestions would be helpful.
>This is not where the story ends. I managed to get the entire system built
>and booted, using the following configuration for the serial port stuff:
>device sio0 at isa? port "IO_COM1" tty irq 4 vector siointr
>device sio1 at isa? port "IO_COM2" tty irq 3 vector siointr
>device sio2 at isa? port 0x3e8 tty irq 10 vector siointr
>device sio3 at isa? port 0x2e8 tty irq 12 vector siointr
>device sio4 at isa? port 0x338 tty irq 11 vector siointr
>This is exactly the same configuration as for Chris' driver, except that
>it uses the sio driver. Note that sio4 is a Mouse Systems bus mouse card,
>which looks like a 16450-based serial port. During configuration after
>boot, I see:
>Jul 14 09:23:54 tinker /386bsd: sio0 <16550A> at 0x3f8 irq 4 on isa
>Jul 14 09:23:54 tinker /386bsd: sio1 <16550A> at 0x2f8 irq 3 on isa
>Jul 14 09:23:55 tinker /386bsd: sio2 <16550A> at 0x3e8 irq 10 on isa
>Jul 14 09:23:55 tinker /386bsd: sio4 <16450> at 0x338 irq 11 on isa
>So where is sio3? I know it's there, I was able to use it before. I
>think it's odd that it's the last port on the card. Perhaps this is a
>problem similar to that which others have seen when using multiport cards.
>Suggestions would be helpful here, as well.
I think so. Probably the com_scratch register in the last comport
is used in some way, and thus breaks the porbing code.
>/dev/tty0? and /dev/sio0? are hard-linked. Ignore the ownership, that's
>just how it appears at the moment.
>That's still not the real problem, though. I can use the mouse with XFree
>1.2 just fine, so there's no problem there, but when I try to use the sio
>port 0, I see dropped characters like mad. I defined the devices as:
What do you mean? A mouse dropping characters?
>crw------- 2 frank tty 28, 0 Jul 14 14:22 /dev/sio00
>crw------- 2 root wheel 28, 1 Jul 10 09:37 /dev/sio01
>crw------- 2 uucp wheel 28, 2 Jul 10 09:37 /dev/sio02
>crw------- 2 uucp wheel 28, 3 Jul 10 09:37 /dev/sio03
>crw------- 2 frank tty 28, 0 Jul 14 14:22 /dev/tty00
>crw------- 2 root wheel 28, 1 Jul 10 09:37 /dev/tty01
>crw------- 2 uucp wheel 28, 2 Jul 10 09:37 /dev/tty02
>crw------- 2 uucp wheel 28, 3 Jul 10 09:37 /dev/tty03
>crw-rw-rw- 1 root wheel 28, 128 Jul 13 09:07 /dev/cua00
>crw-rw-rw- 1 root wheel 28, 129 Jul 10 09:40 /dev/cua01
>crw-rw-rw- 1 root wheel 28, 130 Jul 10 09:41 /dev/cua02
>crw-rw-rw- 1 root wheel 28, 131 Jul 10 09:41 /dev/cua03
>I am using /dev/cua00 as the callout device, with bidir enabled via
>comcontrol. There is a getty pending on /dev/tty00. Note that this
>getty has the same problem as described here before, regarding falling
>into a communications loop with the modem, when I hang up the line.
>I.e. getty isn't getting SIGHUP'd.
>I use Seyon version 2.03 to talk to the modem. When I connect, either
>by dialing out via seyon, or dialing in from work, I see numerous dropped
>characters, much more than with Chris' old driver. This has made dialing
>out almost unusable. Dialing in is better, but there are still dropped
>characters, apparently most usually in large chunks. (This may be a
>problem with the non-386bsd end (it's an AIX system, which apparently
>has problems with RTS/CTS), but it may not be. Regardless, the dialout
>problem remains.)
Check the cabling between the modem and the port. It should be a complete
nullmodem cable, with RTS/CTS,DTR/DSR! (so at least 7 wires!!) also make
sure teh carrier detect is wired!
>Any help, fixes, or pointers would be greatly, greatly appreciated. I have
>just been too busy to track this down myself, and it appears that that will
>continue to be the case for a while. Too, I would like to know whether other
>people have seem similar or identical problems.
>Thanks in advance, and if you can send me a fix, I owe you a homebrew the
>next time you're in LA!
>--
>Frank Mayhar fmayhar@acsc.com
> Advanced Computing Systems Company
> 3000 S. Robertson Blvd. Suite 400, LA, CA 90034 (310) 815-4858
-Guido