Re: Serial break into debugger broken from 'cu' on -CURRENT?
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... . Strange that it > isn't 110baud :-P The default is the default for the first open for the device. It's actually a compile-time tunable, and not a result of an explicit set of the baud rate. System V has always had a strange relationship with its ttys. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Serial break into debugger broken from 'cu' on -CURRENT?
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 once experienced > a security problem, we would rather quickly end up with a skeleton > that could hardly be named `Unix' anymore...) > > > 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... . Strange that it isn't 110baud :-P -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, the Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Serial break into debugger broken from 'cu' on -CURRENT?
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 annoying startup message "can't open log file /var/log/aculog" (why should it be able to open it at all?). I wish the Taylor version hadn't been thrown overboard at all. We 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 once experienced a security problem, we would rather quickly end up with a skeleton that could hardly be named `Unix' anymore...) > 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* -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Serial break into debugger broken from 'cu' on -CURRENT?
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 that some time back uucp was shaken out of base > system and cu also, cu's functionality was folded back to tip. > Stable indeed has different tip and cu binaries, in -current there's > hard link. The -current cu is a crock of tip. One of the bugs in it is that "cu -l /dev/foo" doesn't use the default line speed for /dev/foo; it enforces 9600. 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. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Serial break into debugger broken from 'cu' on -CURRENT?
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 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 into ddd just fine as well : > > >(2) Is serial break currently broken in 'cu'? > > > > Glenn Gombert > [EMAIL PROTECTED] > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Serial break into debugger broken from 'cu' on -CURRENT?
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 lockups that currently plague > -CURRENT/alpha, the machine won't react to break, ctrl-alt-esc, or > anything else except HALT and RESET. My testbox (NoName) doesn't even react on halt. But in the normal case a serial break just does what it should do. Serial client is tip from 4.3-20010630-STABLE. My notebook is running -current from 15th feb and tip's break also worked always fine. Well sending the break sequence against an ssh or not after a linebreak are typical mistakes in usage. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Serial break into debugger broken from 'cu' on -CURRENT?
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 LINT, and things work fine. I assumed it was actually some issue with > that particular batch of machines, since no one else had had a problem, > and I didn't really have time to follow up. Yesterday, I brought online > two more crash boxes via serial console, both older TeleNet servers, and > noticed that neither of them respond to serial break over the serial > console using cu. This leads me to wonder two things: > > (1) Is serial break currently broken in -CURRENT Yes, I think so. > (2) Is serial break currently broken in 'cu'? No opinion, since I haven't tried using it. What I have observed is: I use the same gdb for remote serial debugging both for FreeBSD and Linux (ia32). That's right, it's a FreeBSD box running FreeBSD gdb in both cases. I can break to the Linux kernel, but not to the FreeBSD kernel. From this, I conclude that it's a kernel issue, not a gdb issue. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Serial break into debugger broken from 'cu' on -CURRENT?
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 into ddd just fine as well : >(2) Is serial break currently broken in 'cu'? > Glenn Gombert [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Serial break into debugger broken from 'cu' on -CURRENT?
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 lockups that currently plague > -CURRENT/alpha, the machine won't react to break, ctrl-alt-esc, or > anything else except HALT and RESET. > > > Now that I followed Drew's suggestion to > > > > > > I suggest reverting rev 1.61 of alpha/alpha/interrupt.c (eg, disable > > interrupt thread preemption). > > > > > > I have not seen a lockup anymore. > > Neither have I, but I have only been running with it for a day, and > it has previously managed to survive for up to two days without > locking up. Well, I had a close to 100% lockup or panic chance when I ran a make release. I just completed a succesful buildworld, and will subsequently run a make release. W/ -- | / o / /_ _ FreeBSD core team secretary |/|/ / / /( (_) Bulte [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Serial break into debugger broken from 'cu' on -CURRENT?
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 actually some issue with > that particular batch of machines, since no one else had had a problem, > and I didn't really have time to follow up. Yesterday, I brought online > two more crash boxes via serial console, both older TeleNet servers, and > noticed that neither of them respond to serial break over the serial > console using cu. This leads me to wonder two things: > > (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, hitting ~# in cu no longer > results in boxes dropping to the debugger. Enabling the alternative break > and using ~^B works fine, and Ctrl-Alt-Escape works fine on the real > console. The break signal is "At least 250ms of marking space" (line silence), according to the Bell 103C and 212A and B standards. There are two ways that UNIX programs try to do this; the first is an ioctl() for "send a break"; the second is to set the baud rate to 0, and then set it back after a sufficient time. You should check to see if both approaches (the working one and the non-working one) are trying to use the same approach, or not. If they aren't, it could be something as simple as the number of loops before the baud rate is set back is wrong for your clock speed, and the loops should be replaced with a call to nanosleep. 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Serial break into debugger broken from 'cu' on -CURRENT?
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 break, ctrl-alt-esc, or anything else except HALT and RESET. > Now that I followed Drew's suggestion to > > > I suggest reverting rev 1.61 of alpha/alpha/interrupt.c (eg, disable > interrupt thread preemption). > > > I have not seen a lockup anymore. Neither have I, but I have only been running with it for a day, and it has previously managed to survive for up to two days without locking up. -- Christian "naddy" Weisgerber [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Serial break into debugger broken from 'cu' on -CURRENT?
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 abovementioned alpha to my sparc. I don't have a pair of FreeBSD boxes tied together like that. -- Christian "naddy" Weisgerber [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Serial break into debugger broken from 'cu' on -CURRENT?
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, 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 actually some issue with > >> that particular batch of machines, since no one else had had a problem, > >> and I didn't really have time to follow up. Yesterday, I brought online > >> two more crash boxes via serial console, both older TeleNet servers, and > >> noticed that neither of them respond to serial break over the serial > >> console using cu. This leads me to wonder two things: > >> > >> (1) Is serial break currently broken in -CURRENT > >> (2) Is serial break currently broken in 'cu'? > > > >I had similar experiences with tip trying to break into ddb on the > >AlphaStation DS10 with -current. I thought it was just me ;-) > > Hitting ~# in tip worked fine for me with a -current CVSup'd from > yesterday. However, it did stump me for a second until I realized I > was initially escaping into SSH and not tip. Let me clarify: the DS10 is running -current, the x86 that has tip running is on -stable. 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). Now that I followed Drew's suggestion to I suggest reverting rev 1.61 of alpha/alpha/interrupt.c (eg, disable interrupt thread preemption). I'm on the west coast right now, away from my alphas, but I had several buildworlds complete last week with ithread preemption disabled. Drew I have not seen a lockup anymore. I also had to take out options SMP in order to get the kernel link. W/ -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, the Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Serial break into debugger broken from 'cu' on -CURRENT?
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) login: Mar 9 21:35:57 stash savecore: reboot after panic: from debugger Mar 9 21:36:02 stash savecore: reboot after panic: from debugger lock order reversal 1st 0xc0468a40 allproc @ /usr/src/sys/kern/vfs_syscalls.c:452 2nd 0xc1423734 filedesc structure @ /usr/src/sys/kern/vfs_syscalls.c:457 [halt sent] Stopped at siointr1+0xb1: jmp siointr1+0x1b7 db> I don't have any directly connected ports, so can't coment on "cu". Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Serial break into debugger broken from 'cu' on -CURRENT?
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 switched to the 'alternative break' option >> in LINT, and things work fine. I assumed it was actually some issue with >> that particular batch of machines, since no one else had had a problem, >> and I didn't really have time to follow up. Yesterday, I brought online >> two more crash boxes via serial console, both older TeleNet servers, and >> noticed that neither of them respond to serial break over the serial >> console using cu. This leads me to wonder two things: >> >> (1) Is serial break currently broken in -CURRENT >> (2) Is serial break currently broken in 'cu'? > >I had similar experiences with tip trying to break into ddb on the >AlphaStation DS10 with -current. I thought it was just me ;-) Hitting ~# in tip worked fine for me with a -current CVSup'd from yesterday. However, it did stump me for a second until I realized I was initially escaping into SSH and not tip. Mark To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Serial break into debugger broken from 'cu' on -CURRENT?
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, hitting ~# in cu no longer > results in boxes dropping to the debugger. Enabling the alternative break > and using ~^B works fine, and Ctrl-Alt-Escape works fine on the real > console. I've been unable to send break using -current cu to some Cisco's which I had to configure recently. Ecu from ports did work however. As I was -stable user some weeks ago I know that cu in -stable did 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 that some time back uucp was shaken out of base system and cu also, cu's functionality was folded back to tip. Stable indeed has different tip and cu binaries, in -current there's hard link. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Serial break into debugger broken from 'cu' on -CURRENT?
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 LINT, and things work fine. I assumed it was actually some issue with > that particular batch of machines, since no one else had had a problem, > and I didn't really have time to follow up. Yesterday, I brought online > two more crash boxes via serial console, both older TeleNet servers, and > noticed that neither of them respond to serial break over the serial > console using cu. This leads me to wonder two things: > > (1) Is serial break currently broken in -CURRENT > (2) Is serial break currently broken in 'cu'? I had similar experiences with tip trying to break into ddb on the AlphaStation DS10 with -current. I thought it was just me ;-) -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, the Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Serial break into debugger broken from 'cu' on -CURRENT?
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 actually some issue with that particular batch of machines, since no one else had had a problem, and I didn't really have time to follow up. Yesterday, I brought online two more crash boxes via serial console, both older TeleNet servers, and noticed that neither of them respond to serial break over the serial console using cu. This leads me to wonder two things: (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, hitting ~# in cu no longer results in boxes dropping to the debugger. Enabling the alternative break and using ~^B works fine, and Ctrl-Alt-Escape works fine on the real console. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
