From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4a931622734509c053a05c6571e827ac@coraid.com> To: 9fans@cse.psu.edu Subject: Re: [9fans] rdbfs From: Brantley Coile Date: Wed, 24 Aug 2005 18:56:51 -0400 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: 7daa14d6-ead0-11e9-9d60-3106f5b1d025 i seem to have it working somewhat now. i'm just not sure how much i can do with it. it doesn't seem to have a stack to backtrace. does anyone use this rdb? regarding serial ports, back in 1982 i wrote my first device driver for a serial port. it was a Signetics something. we connected two of our systems up with hardware flow control connected and could move bytes at any speed. (slow for the day, but still faster than 19200.) later, we had systems with another chip, a Mot part if i recall, and everything stopped working. that Signetics part has been the only one i have used that can assert/deassert the CTS in 1 byte time. most of the other parts just allow software control of these bits. bc >>> could it be that some other process is stealing bytes >>> out of the uart? how do i make sure that's not happening? >> >> that's really unlikely given that the kernel is splhi >> looping to poll the uart. > > I don't think another process is stealing bytes but I do sympathize > with anybody having uart problems. I couldn't read all the bytes > off a GPS when it's baud rate was set higher than 4800. > > Sape