On Sat, Sep 29, 2001 at 10:47:54AM -0400, [EMAIL PROTECTED] wrote:
> Well if you didnt snip out the context you wouldnt have an argument at all,
> since I said to make it an option to shut down or issue a warning.
You mean this:
sysctl machdep.panic_on_nmi
But I still beleave it's not a good i
In a message dated 9/28/01 10:21:58 AM Eastern Daylight Time,
[EMAIL PROTECTED] writes:
> > I dont think this is "good". Back in the XT days we used to get a false
> > parity error every once on a while on an ISA card...taking the machine
> down
> > on a bit error (which XTs used to do) was
On Fri, Sep 28, 2001 at 09:46:19AM -0400, [EMAIL PROTECTED] wrote:
> In a message dated 9/25/01 1:05:21 PM Eastern Daylight Time, [EMAIL PROTECTED]
> writes:
>
> > > Well, at least we take the machine down, which is a heck of a lot
> > > better than ignoring the problem, which is really all tha
In a message dated 9/25/01 1:05:21 PM Eastern Daylight Time, [EMAIL PROTECTED]
writes:
> > Well, at least we take the machine down, which is a heck of a lot
> > better than ignoring the problem, which is really all that I was
> > hoping for.
I dont think this is "good". Back in the XT days w
Andrew Gallatin wrote:
>
> Peter Wemm writes:
>
>
> Thanks for your description of how ECC is reported on PCs. That was
> very, very helpful.
>
> > The Tyan Thunder 2510 BIOS even disables ECC -> NMI routing so you have to
> > go to quite a bit of trouble to reprogram the serverworks chipse
In message <[EMAIL PROTECTED]> Peter Wemm writes:
: - our NMI handlers are a festering pile of excretement. They dont have
: the code to 'ack' the NMI so it isn't possible to return after recovery.
I have code to do the ack, but people have complained in the past that
this code is too chipset sp
Thus spake Peter Wemm ([EMAIL PROTECTED]):
> Our NMI / ECC handling really really sucks in FreeBSD. Consider:
[...]
Is there any effort to fix this stuff?
Considering FreeBSD is still known as one of the best server platforms,
this is more important than a multi-threaded kernel or similar stuf
Peter Wemm writes:
Thanks for your description of how ECC is reported on PCs. That was
very, very helpful.
> The Tyan Thunder 2510 BIOS even disables ECC -> NMI routing so you have to
> go to quite a bit of trouble to reprogram the serverworks chipset to
> actually generate NMI's so that y
Andrew Gallatin wrote:
>
> Matt Dillon writes:
> >
> > :What happens on an ECC equipped PC when you have a multi-bit memory
> > :error that hardware scrubbing can't fix? Will there be some sort of
> > :NMI or something that will panic the box?
> > :
> > :I'm used to alphas (where you'll g
Andrew Gallatin wrote:
>
> What happens on an ECC equipped PC when you have a multi-bit memory
> error that hardware scrubbing can't fix? Will there be some sort of
> NMI or something that will panic the box?
>
> I'm used to alphas (where you'll get a fatal machine check panic) and
> I am just
Matt Dillon writes:
>
> :What happens on an ECC equipped PC when you have a multi-bit memory
> :error that hardware scrubbing can't fix? Will there be some sort of
> :NMI or something that will panic the box?
> :
> :I'm used to alphas (where you'll get a fatal machine check panic) and
>
:What happens on an ECC equipped PC when you have a multi-bit memory
:error that hardware scrubbing can't fix? Will there be some sort of
:NMI or something that will panic the box?
:
:I'm used to alphas (where you'll get a fatal machine check panic) and
:I am just wondering if PCs are as safe.
:
What happens on an ECC equipped PC when you have a multi-bit memory
error that hardware scrubbing can't fix? Will there be some sort of
NMI or something that will panic the box?
I'm used to alphas (where you'll get a fatal machine check panic) and
I am just wondering if PCs are as safe.
Thanks
13 matches
Mail list logo
