Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!elroy.jpl.nasa.gov!usc!acsc.com!acsc.com!fmayhar From: fmayhar@acsc.com (Frank Mayhar) Newsgroups: comp.os.386bsd.bugs Subject: Problems with patchkit 0.2.4 Date: 14 Jul 1993 21:34:12 GMT Organization: Advanced Computing Systems Company Lines: 115 Distribution: world Message-ID: <221u4k$lfn@acsc.com> Reply-To: fmayhar@acsc.com NNTP-Posting-Host: cpuserver.acsc.com OK, I installed the latest patchkit (0.2.4, which I got from bsd.coe.montana.edu as pub/patch-kit/0.2.3-0.2.4/patchkit-0.2.3-0.2.4.tar.z) last weekend. I have a few problems with it, some minor and some fairly major. For background, my system is a 486/33 ISA bus machine, with 8 MB memory, 2 IDE drives (a WD 2200 Caviar, which is all that 386bsd knows about, and a Quantum 80 MB), an Adaptec 1452B with a Maxtor LXT 340SY and an Archive 2150S. It has a multiport I/O card, with four serial ports, all supported as 16550A's via ASICs, and each with its own I/O port and IRQ. I also have a ZyXEL 1496E+ modem connected to serial port 0 (COM1, for you DOS folks). I don't know the brand of multiport card, as it's at home. If it's an issue, I'll find out. I had been using 386bsd 0.1.2.3 with Chris Demetriou's multiport serial mods, with few problems except for the occassional dropped character or characters, mostly when dialed up to work. I run the modem-connected serial port at 38400 bps, with a three-foot serial cable connecting it to the modem. I was eagerly looking forward to the new sio driver, since I hoped that it would eliminate the dropped characters. 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) /* ??? */ 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. /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: 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.) 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