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
Re: ENABLE_SERIAL_BREAK_KEY...or something?
On Thu, 10 Jun 1999, Don Read wrote: > > Are you guys serious about dropping the box by powering off the console ? > > 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
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. Are you guys serious about dropping the box by powering off the console ? 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: 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: 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 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: 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: 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?
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: 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: 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