> Please try out this patch to aid the above problem with hang instead of > dump: > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/i386/i386/trap.c.diff?r1=1.275&r2=1.276This patch wouldn't go through.... I tried patching against: __FBSDID("$FreeBSD: src/sys/i386/i386/trap.c,v 1.267.2.3 2005/05/01 05:34:46 dwhite Exp $"); which is -STABLE
>> Please try out this patch to aid the above problem with hang instead of >> dump: >> >> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/i386/i386/trap.c.diff?r1=1.275&r2=1.276This box is now crashing once every 12 hours. I can't apply this patch :-(. Does anyone have any suggestions on how I can work around this? Some have said its an SMP problem and some have said its a 4 GB RAM problem and some have said its an IPF problem .... if I disabled all three of those things would that help this box be stable until code could be fixed? Thanks, Matt
> Matt, > > Sadly the FreeBSD guys will need more info before a fix is possible. I would > suggest you revert back to FreeBSD 5.3, if you can. Even if you get a patch > you'd want to do a whole lot of regression testing before putting it in > production as it might break something else.Gary, Do you know what the chances are that this problem I'm experiencing is SMP related? I don't mind turning off SMP, and I guess I could for now to see if that runs stable. Otherwise, I think we're going to switch to OpenBSD, because these crashes are occuring so frequently (twice a day)... and as far as the patch and regression testing, if someone sent me a patch right now I would put it on the server, because the server already crashes daily, so a faulty patch wouldn't change much :-(. I appreciate your response. I'm going to do a little more research today before i make my decision on a platform switch. -Matt
Hi, I have something like 20 boxes (Dell Power Edge 370, Fujitsu-Siemens PRIMERGY 200 and couple of dual AMD64 Fujitsu-Siemens) servers running 5.4-STABLE. So far, only machine that I have experienced freezing and was unable to get droped into KDB or to get any sort of vmcore was Dell Power Edge 1600SC (dual Xeon 2.4GHz with 4Gb). I have noticed that since it was running squid-2.5 linked to pthread when I have switched to oops which was compiled on 5.2.1 and linked to libc_r that machine stoped crashing (HTT disabled, IPFILTER also disabled configuration GENERIC). However, I have decided to experiment and upgraded to 6.0-CURRENT and so far I haven't experienced any problems - except one panic caused by linux.ko and running edonkeyclc for linux (it was just experiment to see if it will work on 6.0-CURRENT). I suppose that there might be some problems related to SMP on 5.4 and I don't know what for are you using problematic servers and I don't know if it is smart to use 6.0-CURRENT but so far I have positive experince with it on problematic server and would rather stay with FBSD then switching to NetBSD or OpenBSD. Regards, gg.
On Tue, Jun 28, 2005 at 01:50:48PM -0400, Matt Juszczak wrote:
M> >Please try out this patch to aid the above problem with hang instead
of
M> >dump:
M> >
M>
>http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/i386/i386/trap.c.diff?r1=1.275&r2=1.276
M> This patch wouldn't go through....
M> I tried patching against:
M> __FBSDID("$FreeBSD: src/sys/i386/i386/trap.c,v 1.267.2.3 2005/05/01
M> 05:34:46 dwhite Exp $");
M> which is -STABLE
Here is attached patch. It should work for STABLE. It should fix problem
with frozen kdb, and give you ability to obtain a crashdump.
--
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE
-------------- next part --------------
Index: trap.c
==================================================================RCS file:
/home/ncvs/src/sys/i386/i386/trap.c,v
retrieving revision 1.267.2.3
diff -u -r1.267.2.3 trap.c
--- trap.c 1 May 2005 05:34:46 -0000 1.267.2.3
+++ trap.c 29 Jun 2005 14:27:04 -0000
@@ -809,8 +809,15 @@
}
#ifdef KDB
- if (kdb_trap(type, 0, frame))
- return;
+ {
+ register_t eflags;
+ eflags = intr_disable();
+ if (kdb_trap(type, 0, frame)) {
+ intr_restore(eflags);
+ return;
+ }
+ intr_restore(eflags);
+ }
#endif
printf("trap number = %d\n", type);
if (type <= MAX_TRAP_MSG)