Re: ENABLE_SERIAL_BREAK_KEY...or something?
key to drop to the debugger? Say have it so that if a keystroke of ~b (as Would be most excellent if this could be done. A couple of boxen I have here have serial consoles attached to other machines which do a very good simulation of a break when the controlling process leaves them. Dropping to DDB every time you reboot the other machine is, uh, less than desirable behaviour. :-) Agreed, but this may be quite a project... doing a cd ~bob would be fun. :) You would pretty much have to implement some timing requirements, but I imagine that it could bulk up that section of the kernel pretty easily. One thing that might help (assuming you CAN generate a break) is to watch DCD (or some other control line(s)). Generally, when a break is sent intentionally, the DCD line is active -- when the kernel detects a break, wait until after it's finished, then check DCD. If it's high, drop to debugger. If it's low, somebody either turned the terminal off or dropped outta kermit. (I have the displeasure of maintaining an AIX box that does something similar to this. Before the upgrade that fixed this problem, turning off the serial console brought the whole machine down.) --Mike To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: GNU patch gone stale
TONY they just showed your obfuscated C entry in the COmpetitionhere.. Your'e crazy you know.. there were soma amazing entries but you came in near the top.. there was the 2K obfuscated X11 flight simulator that actually worked.. the 1500 byte program that produced gzip'd postscript of a 3 maze, and your 2k program that produces an 800K program that actually works.. as I said.. you're crazy (but wear it with pride!) julian On Wed, 9 Jun 1999, Tony Finch wrote: John Baldwin jobal...@vt.edu wrote: So it would seem that patch and cvs don't interact at all, unless it's a question of patch 2.5 being able to apply diffs generated by cvs diff. That is the main problem I have with patch 2.5 -- it completely fails to apply patches from `cvs diff` unless you have a really new cvs, and I usually don't. Tony. -- f.a.n.finch d...@dotat.at f...@demon.net black dog To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: IBM To Buy Whistle, Maker Of Web Servers
It makes no differnce.. we will continue to use FreeBSD and to contribute.. (maybe in a more financed manner) julian On Wed, 9 Jun 1999, Mikhail Teterin wrote: I'm sorry, if this is not the best place to ask, but I know several Whistle people are active FreeBSD contributors. Does the announcement in Subject, see also (I hate long URLs): http://dailynews.yahoo.com/headlines/tc/story.html?s=v/nm/19990609/tc/ibm_whistle_1.html mean, IBM is to offer FreeBSD on their machines? Perhaps, it will be a black box, but with FreeBSD inside it, secretly ;-) ? -mi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: GNU patch gone stale
Julian Elischer writes: TONY they just showed your obfuscated C entry in the COmpetitionhere.. Your'e crazy you know.. there were soma amazing entries but you came in near the top.. Wow. That's the first news I've had about this since submitting it. Now I can sit back and look smug. there was the 2K obfuscated X11 flight simulator that actually worked.. the 1500 byte program that produced gzip'd postscript of a 3 maze, ! and your 2k program that produces an 800K program that actually works.. Don't use -O unless you can cope with gigabyte-sized compiler processes (I never could get it to work). as I said.. you're crazy (but wear it with pride!) :-) Tony. -- f.a.n.finchd...@dotat.atf...@demon.net Winner of the International Obfuscated C Code Competition 1999 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: ENABLE_SERIAL_BREAK_KEY...or something?
Mike Nowlin wrote: Agreed, but this may be quite a project... doing a cd ~bob would be fun. :) You would pretty much have to implement some timing requirements, but I imagine that it could bulk up that section of the kernel pretty easily. Yep. I started to hack something like this into sio.c in the days of 2.1, then the need disappeared for a while and I never completed it. One thing that might help (assuming you CAN generate a break) is to watch DCD (or some other control line(s)). Yes. (DSR also jumps to mind.) Generally, when a break is sent intentionally, the DCD line is active -- when the kernel detects a break, wait until after it's finished, then check DCD. If it's high, drop to debugger. If it's low, somebody either turned the terminal off or dropped outta kermit. Excellent idea. (I have the displeasure of maintaining an AIX box that does something similar to this. Before the upgrade that fixed this problem, turning off the serial console brought the whole machine down.) Suns tend to do it too. Great fun when patch-monkeys disturb the cable to the console... :-) -- Phil Homewood DNRC email: ph...@mincom.com Postmaster and BOFH Mincom Pty Ltd phone: +61-7-3303-3524 Brisbane, QLD Australia fax:+61-7-3303-3269 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: ENABLE_SERIAL_BREAK_KEY...or something?
On Thu, 10 Jun 1999, Mike Nowlin wrote:
key to drop to the debugger? Say have it so that if a keystroke of ~b (as
Would be most excellent if this could be done. A couple of boxen I
have here have serial consoles attached to other machines which
do a very good simulation of a break when the controlling process
leaves them. Dropping to DDB every time you reboot the other machine
is, uh, less than desirable behaviour. :-)
Agreed, but this may be quite a project... doing a cd ~bob would be
the general idea is that this wouldn't only register as a 'break' when
issud over the serial console, nowhere else...I know, some ppl use the
serial console as a regular login, but my experience is that its painfully
slow and good for maintenance only
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scra...@hub.org secondary: scra...@{freebsd|postgresql}.org
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: MMAP() in STABLE/CURRENT ...
On Wed, 9 Jun 1999, The Hermit Hacker wrote: Did try this...actually went to the Livingston WWW site, and they fixed this bug around release 3.1.4 of ComOS :( The 'send break' just gets ignored... The bug they fixed was that sending a telnet BRK sequence during an administrative session (i.e. logged into a ComOS prompt) used to reboot the Portmaster. During administrative sessions now, BRK is ignored. However, you can still send BRK on sessions to individual serial ports. See: http://www.livingston.com/tech/technotes/200/220010.html Cheers, Mick The Reverend Jasper P. O'Malley dotdot:jo...@webnology.com Systems Administrator ringring:asktheadmiral Webnology, LLC woowoo:http://www.webnology.com/~jooji To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: ENABLE_SERIAL_BREAK_KEY...or something?
Would be most excellent if this could be done. A couple of boxen I
have here have serial consoles attached to other machines which
do a very good simulation of a break when the controlling process
leaves them. Dropping to DDB every time you reboot the other machine
is, uh, less than desirable behaviour. :-)
I had the same problem. Changing the sio code to require three breaks
inside a 10 seconds interval before dropping into the debugger reduced
the problem for me.
- Tor Egge
Index: sys/i386/conf/options.i386
===
RCS file: /home/ncvs/src/sys/i386/conf/options.i386,v
retrieving revision 1.116
diff -u -r1.116 options.i386
--- options.i3861999/06/06 22:45:04 1.116
+++ options.i3861999/06/08 00:27:17
@@ -24,6 +24,7 @@
AUTO_EOI_1 opt_auto_eoi.h
AUTO_EOI_2 opt_auto_eoi.h
BREAK_TO_DEBUGGER opt_comconsole.h
+TRIPLE_BREAK_TO_DEBUGGER opt_comconsole.h
CONSPEED opt_comconsole.h
I586_PMC_GUPROFopt_i586_guprof.h
WLCACHEopt_wavelan.h
Index: sys/isa/sio.c
===
RCS file: /home/ncvs/src/sys/isa/sio.c,v
retrieving revision 1.246
diff -u -r1.246 sio.c
--- sio.c 1999/05/31 06:57:31 1.246
+++ sio.c 1999/06/08 00:27:38
@@ -427,6 +427,16 @@
{ -1, -1 }
};
+#define DDB_BREAK_MASK (IER_ERXRDY | IER_ETXRDY | IER_ERLS | IER_EMSC)
+
+#ifdef TRIPLE_BREAK_TO_DEBUGGER
+#ifndef TRIPLE_BREAK_TIMEOUT
+#define TRIPLE_BREAK_TIMEOUT 10
+#endif
+int triple_break_count;/* number of breaks detected */
+int triple_break_time; /* time_second sampled at first break */
+#endif
+
#ifdef COM_ESP
/* XXX configure this properly. */
static Port_t likely_com_ports[] = { 0x3f8, 0x2f8, 0x3e8, 0x2e8, };
@@ -998,6 +1008,9 @@
com-lt_out.c_ispeed = com-lt_out.c_ospeed =
com-lt_in.c_ispeed = com-lt_in.c_ospeed =
com-it_in.c_ispeed = com-it_in.c_ospeed = comdefaultrate;
+#if defined(DDB) defined(BREAK_TO_DEBUGGER) defined(DDB_BREAK_MASK)
+ outb(iobase + com_ier, DDB_BREAK_MASK);
+#endif
} else
com-it_in.c_ispeed = com-it_in.c_ospeed = TTYDEF_SPEED;
if (siosetwater(com, com-it_in.c_ispeed) != 0) {
@@ -1404,7 +1417,12 @@
com-pps.ppsparam.mode = 0;
outb(iobase + com_cfcr, com-cfcr_image = ~CFCR_SBREAK);
{
- outb(iobase + com_ier, 0);
+#if defined(DDB) defined(BREAK_TO_DEBUGGER) defined(DDB_BREAK_MASK)
+ if (com-unit == comconsole)
+ outb(iobase + com_ier, DDB_BREAK_MASK);
+ else
+#endif
+ outb(iobase + com_ier, 0);
tp = com-tp;
if (tp-t_cflag HUPCL
/*
@@ -1704,7 +1722,23 @@
if (line_status LSR_BI) {
#if defined(DDB) defined(BREAK_TO_DEBUGGER)
if (com-unit == comconsole) {
+#ifdef TRIPLE_BREAK_TO_DEBUGGER
+ if (time_second
+ triple_break_time +
+ TRIPLE_BREAK_TIMEOUT)
+ triple_break_count = 0;
+ triple_break_count++;
+ if (triple_break_count == 1)
+ triple_break_time =
+ time_second;
+ else if (triple_break_count
+== 3) {
+ triple_break_count = 0;
+ breakpoint();
+ }
+#else
breakpoint();
+#endif
goto cont;
}
#endif
Re: 4-way SMP broken ?
On Wed, 09 Jun 1999, Luoqi Chen wrote: I've been trying to install 19990604-CURRENT on a couple of SC450NX boxes. It works fine with 2 cpu's, but an SMP kernel with 4 cpu's falls over very quickly (I think while it's setting up the APIC stuff, or very shortly after - the messages about APIC bus ids appear on the screen very briefly, then the machine reboots itself). Do you mean messages like these? FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfec08000 cpu1 (AP): apic id: 12, version: 0x00040011, at 0xfec08000 io0 (APIC): apic id: 13, version: 0x00170011, at 0xfec0 By the time you see these messages, all cpus should have been booted up successfully, any crash immediately follows is not likely to be SMP related. It's helpful to pinpoint the crash if you could include the last few lines from a verbose boot. I have added more debugging messages, and the crash appears to be inside mp_start(). I don't have a log because this is too early in the boot to get the messages saved anywhere, and they go by too quickly to write it down. The evidence that this is an SMP problem is simple - with 2 cpu's plugged in, it works fine; with 3 or 4 cpu's plugged in, it crashes. I believe the hardware is fine because I was previously running 19990421-CURRENT with all 4 cpu's without serious problems (it was a little unstable, but always booted ok). Does anyone know a) when was the last time it worked on 4 cpu's b) what's changed recently which might relate to this. So if anyone has an answer to these questions I'd still be interested. Also in trying to figure this out I looked at the DRAM probing code in /usr/src/sys/i386/i386/machdep.c:getmemsize(), and it looks as though it's not safe for 2GB (e.g. comparisons of byte addresses against signed int end). It would also be good if this probing I've tried various hacks to this code, but have not succeeded in making it work for 4GB. Changing int end to vm_offset_t end is not sufficient. It has a tendency to say Too many holes in address space ... Even defining MAXMEM does not solve the problem. Richard Cownie (t...@ma.ikos.com) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: 4-way SMP broken ?
I have added more debugging messages, and the crash appears to be inside mp_start(). I don't have a log because this is too early in the boot to get the messages saved anywhere, and they go by too quickly to write it down. The evidence that this is an SMP problem is simple - with 2 cpu's plugged in, it works fine; with 3 or 4 cpu's plugged in, it crashes. Could you narrow down the crash further inside mp_start()? I'd like to know whether the crash occurred inside start_all_aps(). One or two lines of debug messages would be really helpful, you don't have to write down the exact words. Do you have options DDB enabled in the kernel? It helps to stop the last few lines of console messages to scroll of the screen. I believe the hardware is fine because I was previously running 19990421-CURRENT with all 4 cpu's without serious problems (it was a little unstable, but always booted ok). If possible, could you try a kernel built from sources with the POST_SMP_VMSHARE tag? I may have broken something during the commit. -lq To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: 4-way SMP broken ?
On Thu, 10 Jun 1999, Luoqi Chen wrote: Could you narrow down the crash further inside mp_start()? I'd like to know whether the crash occurred inside start_all_aps(). One or two lines of debug messages would be really helpful, you don't have to write down the exact words. Do you have options DDB enabled in the kernel? It helps to stop the last few lines of console messages to scroll of the screen. Yes, I added more messages and it's inside start_all_aps() - it seems to start AP #1 ok, then crashes while starting AP #2. If possible, could you try a kernel built from sources with the POST_SMP_VMSHARE tag? I may have broken something during the commit. Have to get out the door right now, will try this either tomorrow morning or Monday. Thanks Richard Cownie To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: ENABLE_SERIAL_BREAK_KEY...or something?
On 10-Jun-99 The Hermit Hacker wrote: On Thu, 10 Jun 1999, Mike Nowlin wrote: key to drop to the debugger? Say have it so that if a keystroke of ~b (as Would be most excellent if this could be done. A couple of boxen I have here have serial consoles attached to other machines which do a very good simulation of a break when the controlling process leaves them. Dropping to DDB every time you reboot the other machine is, uh, less than desirable behaviour. :-) Agreed, but this may be quite a project... doing a cd ~bob would be the general idea is that this wouldn't only register as a 'break' when issud over the serial console, nowhere else...I know, some ppl use the serial console as a regular login, but my experience is that its painfully slow and good for maintenance only Agree also, my DG/UX (a SysV) sees a series of about twenty open-bracket, close-bracket [] on the console as a signal to jump into ROM. I've only had to use it once; the box was so far in the weeds that I couldn't get a login. boggle Are you guys serious about dropping the box by powering off the console ? /boggle Regards, --- Don Read dr...@calcasieu.com EDP Manager dr...@texas.net Calcasieu Lumber Co. Austin TX -- Meddle not in the affairs of dragons, for you are crunchy and taste good with ketchup. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: ENABLE_SERIAL_BREAK_KEY...or something?
On Thu, 10 Jun 1999, Don Read wrote: boggle Are you guys serious about dropping the box by powering off the console ? /boggle Suns do this. They sense the terminal power off as a break. One previous ork place had a bunch of rack mounted suns, sharing a serial console via a switch box. There was a problem that sometimes switching from one machine to another would cause a break. Someone wired it slightly different, and included a push button on the switch box to send a break. David Scheidt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
More NFS woes
Grabbed another -current, and are still seeing a few problems yet that Matt and others haven't solved. I'm not pushing anyone, just reminding that these are still here, and still problems. 1) The 'inode/vmopar' lockup that Matt is aware of, and apparently tracked down. 2) Processes starting to runaway doing this: nfs_getpages: error 70 vm_fault: pager read error, pid 1251 (eggdrop) nfs_getpages: error 70 vm_fault: pager read error, pid 1251 (eggdrop) nfs_getpages: error 70 vm_fault: pager read error, pid 1251 (eggdrop) nfs_getpages: error 70 vm_fault: pager read error, pid 1251 (eggdrop) nfs_getpages: error 70 No, i don't know what the user in question did to make this happen, if anything. The process was eating about 70% cpu when i killed it, syslogd was eating the other 30 logging all this. :) 3) Weirdly high load averages. I have two systems, of similar hardware, and similar jobs run on it. System A runs 2.2.8, and has about 300 processes running. System B runs -current, and has about 250 processes running. The processes are doing virtually the same things, and both are heavy NFS clients. System A's load average is about .10, Syetem B's load average hovers around 3.0-5.0. System A: last pid: 1933; load averages: 0.31, 0.10, 0.11 CPU states: 6.2% user, 0.0% nice, 1.9% system, 1.6% interrupt, 90.3% idle 302 processes: 1 running, 294 sleeping, 7 zombie System B: last pid: 77084; load averages: 3.64, 3.70, 4.00 CPU states: 7.0% user, 0.0% nice, 2.7% system, 0.4% interrupt, 89.9% idle 256 processes: 1 running, 254 sleeping, 1 zombie Has something changed in the load average calculation, between 2.x and -current, or is there something actually different going on here? The only hardware differences are that system A uses two de0 cards, and system B uses two fxp0 cards. System A is a PII, and sytem B is a K6-2. (similar speeds) Kevin To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
