Date: Sun, 1 Dec 1996 23:35:47 +1100 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, pst@shockwave.com Cc: bde@freefall.freebsd.org, cvs-all@freefall.freebsd.org, CVS-committers@freefall.freebsd.org, cvs-sys@freefall.freebsd.org Subject: Re: cvs commit: src/sys/i386/isa sio.c Message-ID: <199612011235.XAA19611@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>OK, we're in perfect agreement there. So now, the $24 question is: > >"If I set comdefaultrate to 115200 and don't open /dev/ttyd0, exactly what > is going to happen every time we output a character?" The speed will be 9600 to begin with. It will be changed to 115200. Then the character will be written. Then the output routine will spin until the output is incomplete. Then the speed will be restored to 9600. Context switching the speed (and other h/w state) is bad iff input is arriving while you're switching and if input arrives while you're not in the spinloop waiting for it. This is bad for gdb of course. There is a simple workaround: set the initial speed of /dev/ttyd0 to 115200 and don't neglect to open it (stty 115200 </dev/ttyid0; stty -f /dev/ttyd0). There may be other problems at 115200. It's not clear how input at any speed works - if you do a block of output large than the input fifo size, then input is certain to be lost while the output routine is spinning. gdb-remote apparently doesn't do this often. I wrote some better buffering code a few months ago but got confused by a hardware bug and never finished. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612011235.XAA19611>