2002-01-23 10:11:33

by John Covici

[permalink] [raw]
Subject: Re: reading a file in emacs crashes 2.4.17 and 18-pre4

Well, I have worked around this problem by getting rid of the Athlon
optimizations so I guess there is still more work to do on those.

on Mon, 21 Jan 2002 21:28:47 -0500 John Covici <[email protected]> wrote:

> Its a small file and was actually an accident, but you get all sorts
> of unable to handle kernel paging ... and eventually a kernel panic
> because it was trying to kill the idle process.
>
> I am using emacs version "21.2.50.1" and I have 1.4ghz Athlon and 256
> m of memory.

--
John Covici
[email protected]

2002-01-23 10:17:53

by Eli Zaretskii

[permalink] [raw]
Subject: Re: reading a file in emacs crashes 2.4.17 and 18-pre4


On Wed, 23 Jan 2002, John Covici wrote:

> Well, I have worked around this problem by getting rid of the Athlon
> optimizations so I guess there is still more work to do on those.

Could you please tell what did you change, exactly? It might be that
this information should be in etc/PROBLEMS, in case other users bump into
the same problem.

2002-01-23 11:46:37

by John Covici

[permalink] [raw]
Subject: Re: reading a file in emacs crashes 2.4.17 and 18-pre4

I reconfigured my kernel to lie to it and say k6 for the processor
family instead of k7.

On Wed, 23 Jan 2002, Eli Zaretskii wrote:

>
> On Wed, 23 Jan 2002, John Covici wrote:
>
> > Well, I have worked around this problem by getting rid of the Athlon
> > optimizations so I guess there is still more work to do on those.
>
> Could you please tell what did you change, exactly? It might be that
> this information should be in etc/PROBLEMS, in case other users bump into
> the same problem.
>

--
John Covici
[email protected]

2002-01-23 16:29:24

by Mark Hahn

[permalink] [raw]
Subject: Re: reading a file in emacs crashes 2.4.17 and 18-pre4

> I reconfigured my kernel to lie to it and say k6 for the processor
> family instead of k7.

right. and just for posterity, let me note here that
the K7-specific kernel code IS NOT KNOWN TO BE BUGGY.

the best and so far only explanation is that since CONFIG_MK7
can *triple* the bandwidth that Linux demands of dram,
marginal hardware is pushed over the edge. stable hardware
has no problem with the code, and the code follows AMD's specs.

turning off the optimizations is just de-tuning the kernel
to pander to (work around) flakey hardware.

> > > Well, I have worked around this problem by getting rid of the Athlon
> > > optimizations so I guess there is still more work to do on those.
> >
> > Could you please tell what did you change, exactly? It might be that
> > this information should be in etc/PROBLEMS, in case other users bump into
> > the same problem.