reliability of SMP on alpha
Ray Phillips
one CPU now, please? I'm wondering since a quad 667 MHz ES40 has
appeared on ebay. There were some messages in late July last year
saying Michael and Jason had fixed the stability problems it had, so
I suppose it's rock solid by now? Are the fixes in NetBSD 3.0.1?
Ray
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de
Brian L.Stuart
> one CPU now, please? I'm wondering since a quad 667 MHz ES40 has
> appeared on ebay. There were some messages in late July last year
> saying Michael and Jason had fixed the stability problems it had, so
> I suppose it's rock solid by now? Are the fixes in NetBSD 3.0.1?
I can't really comment on NetBSD 3 because I've been swamped and
haven't done much updating for a while. But I did apply the patches
(and July last year sounds about right) and it's been rock solid for me
on my DS5300 (white box version of the AS1200) with 2 processors.
To be honest though, I haven't really stressed it that much so I can't
promise there are no gotchas under heavy load though.
BLS
Greg A. Woods
Ray Phillips wrote:
>
> Can anyone comment on how well NetBSD runs on alphas with more than
> one CPU now, please? I'm wondering since a quad 667 MHz ES40 has
> appeared on ebay. There were some messages in late July last year
> saying Michael and Jason had fixed the stability problems it had, so
> I suppose it's rock solid by now? Are the fixes in NetBSD 3.0.1?
1.6.x, with the various stability patches, is very solid, though still
not 100% perfect, on the various multi-processor boxes I'm running (4000
(off now, but had 2 cpus), 4100 with 3 cpus, ES40 with 4 cpus). The
ES40 has run for as long as 140 days under constant moderate load with
Cyrus IMAP, Smail SMTP, and Apache HTTP being the primary applications.
I'm still working on integrating my changes with the netbsd-3 tree and
so I'm not sure yet if all the stability patches are in there already or
not (or had missed the netbsd-3 branch and haven't been pulled up), but
I'm assuming they are there since most (though perhaps not all) of the
ones I applied to my local netbsd-1-6 tree were taken from CVS and that
would have happened sometime before the netbsd-3 branch. However if any
of the related PRs are still open then the latest changes suggested in
those PRs may not yet be committed. Michael and Jason are probably the
two people who'll know the most about any as-yet uncommitted changes.
--
Greg A. Woods
H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack <wo...@robohack.ca>
Planix, Inc. <wo...@planix.com> Secrets of the Weird <wo...@weird.com>
Jason Thorpe
On Sep 18, 2006, at 12:11 PM, Greg A. Woods wrote:
> Michael and Jason are probably the
> two people who'll know the most about any as-yet uncommitted changes.
I have no un-committed changes in this area.
-- thorpej
Greg A. Woods
now, and the second crash coincided exactly with the removal of power
from one of its three (full N+1) power supplies, and now there's a good
deal of certainty that the last machine check panic also coincided with
power problems (they've been rebuilding their datacentre UPS and moving
machines back and forth between power sources):
fatal machine check or error (unknown type):
mces = 0x0
vector = 0x680
param = 0xfffffc0000006148
pc = 0xfffffc00003bde04
ra = 0xfffffc00003d3e14
code = 0x100000206
curproc = 0xfffffc00f5000008
pid = 29554, comm = pop3d
panic: machine check
Stopped in pid 29554 (pop3d) at cpu_Debugger+0x4: ret zero,(ra)
db{0}>
As you can see though the mces value is zero, leaving the code nothing
to decode to determine the cause of the interrupt.
Is it possible there's some other value, besides what alpha_pal_rdmces()
returns, which should also be examined on these newer machines?
--
Greg A. Woods
Planix, Inc.
<wo...@planix.com> +1 416 489-5852 x122 http://www.planix.com/