Bruce Evans [EMAIL PROTECTED] wrote:
The -current cu is a crock of tip.
It has more missing features, compared to the Taylor version, like the
unability to run an external program with stdin and stdout piped to
the remote end simultaneously (like a local sz Z-modem program),
plus it has this
On Mon, Mar 11, 2002 at 10:43:22PM +0100, Joerg Wunsch wrote:
Bruce Evans [EMAIL PROTECTED] wrote:
used to have two alternatives, cu and tip. Now we only have tip and
tip. :( (I doubt tip has actually less security bugs than Taylor cu.
If we threw out all the BSD-originating programs that
Wilko Bulte wrote:
This is bug for bug compatible with the V7 cu except
for the unusably slow speed of 9600. For perfect brokenness, the
default speed should be 300.
*ROTFL*
Duh... goes hunting for the ASR33 to verify this. Strange that it
isn't 110baud :-P
The default is the
On Sun, Mar 10, 2002 at 10:07:07AM -0500, Robert Watson wrote:
For the past couple of months, I've been working with a set of identical
test boxes from SGI which, for some reason, stopped responding to serial
break on the serial console. I switched to the 'alternative break' option
in
On Sun, Mar 10, 2002 at 10:07:07AM -0500, Robert Watson [EMAIL PROTECTED] wrote:
(1) Is serial break currently broken in -CURRENT
(2) Is serial break currently broken in 'cu'?
I have't had a chance to follow up on either, but was wondering if anyone
else had experienced this? Essentially,
At 4:11 PM +0100 3/10/02, Wilko Bulte wrote:
On Sun, Mar 10, 2002 at 10:07:07AM -0500, Robert Watson wrote:
For the past couple of months, I've been working with a set of identical
test boxes from SGI which, for some reason, stopped responding to serial
break on the serial console. I
FreeBSD stash.attlabs.att.com 5.0-CURRENT FreeBSD 5.0-CURRENT #1: Fri Mar 8 18:16:53
PST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/STASHNOV6 i386
responds to a break from a Cisco terminal server, invoked by
/usr/ports/comms/conserver:
FreeBSD/i386 (stash.attlabs.att.com) (ttyd0)
On Sun, Mar 10, 2002 at 08:49:16AM -0800, Mark Peek wrote:
At 4:11 PM +0100 3/10/02, Wilko Bulte wrote:
On Sun, Mar 10, 2002 at 10:07:07AM -0500, Robert Watson wrote:
For the past couple of months, I've been working with a set of identical
test boxes from SGI which, for some reason,
Robert Watson [EMAIL PROTECTED] wrote:
(1) Is serial break currently broken in -CURRENT
I can drop just fine into ddb with a serial break on my -CURRENT
AlphaPC164. My kernel configuration has option BREAK_TO_DEBUGGER.
(2) Is serial break currently broken in 'cu'?
Works just fine from
Wilko Bulte [EMAIL PROTECTED] wrote:
It could be that the DS10 was sufficiently catatonic to not react to
a break (how likely is that in the first place? I was looking at a hard
lockup).
If you experience one of the lockups that currently plague
-CURRENT/alpha, the machine won't react to
Robert Watson wrote:
For the past couple of months, I've been working with a set of identical
test boxes from SGI which, for some reason, stopped responding to serial
break on the serial console. I switched to the 'alternative break' option
in LINT, and things work fine. I assumed it was
On Sun, Mar 10, 2002 at 06:15:53PM +, Christian Weisgerber wrote:
Wilko Bulte [EMAIL PROTECTED] wrote:
It could be that the DS10 was sufficiently catatonic to not react to
a break (how likely is that in the first place? I was looking at a hard
lockup).
If you experience one of the
I just rebuilt -current on two development machines I use here at home, the
serial break contol-alt-escape appears to work fine on a stand-alone vox.
(1) Is serial break currently broken in -CURRENT
If I do a 'tip com1' from one box to the other and then do an
'control-alt-escape' it breaks
On Sunday, 10 March 2002 at 10:07:07 -0500, Robert Watson wrote:
For the past couple of months, I've been working with a set of identical
test boxes from SGI which, for some reason, stopped responding to serial
break on the serial console. I switched to the 'alternative break' option
in
On Sun, Mar 10, 2002 at 06:15:53PM +, Christian Weisgerber wrote:
Wilko Bulte [EMAIL PROTECTED] wrote:
It could be that the DS10 was sufficiently catatonic to not react to
a break (how likely is that in the first place? I was looking at a hard
lockup).
If you experience one of the
serial break is different..
it is suppoesed to break into the d debugger if it receives a BREAK
(i.e framing error) in the serial port.
cu ,tip and other such programs have an escape sequence to send a break
julian
On Sun, 10 Mar 2002, Glenn Gombert wrote:
I just rebuilt -current on two
On Sun, 10 Mar 2002, Vallo Kallaste wrote:
work. The other thing I noticed was that -current cu handles speed
switch differently, e.g.:
stable: cu -l /dev/cuaa1 -9600 works well
current: cu -l /dev/cuaa1 -9600 will connect to cuaa0 not
cuaa1.. -s 9600 will work however.
What I recall is
17 matches
Mail list logo
