Thread (2 messages) 2 messages, 2 authors, 2018-09-28

RE: Many random crashes in 2.2.0 (and previous kernels)

From: <hidden>
Date: 2018-09-28 16:27:10

Possibly related (same subject, not in this thread)

Yeah thats the problem I have 1MB L2 cache.
Im not sure if it is the cache thats causing me problems,
but it cant be good that its there but not registered.
On 05-Feb-99 Marcus H. Mendenhall wrote:
OK, I checked.  On my machine the cache is fine,
according to cpuinfo :

here is cat /proc/cpuinfo:

processor     : 0
cpu           : 750
temperature   : 0 C
clock         : 300MHz
revision      : 2.2
bogomips      : 601.29
zero pages    : total 0 (0Kb) current: 0 (0Kb) hits: 0/148
(0%)
machine               : Power Macintosh
motherboard   : AAPL,Gossamer MacRISC
L2 cache      : 1024K unified pipelined-syncro-burst
memory                : 128MB

Does you machine actually have an L2 cache?  It seems as
if the cache
problem on your PCPro machine may be a red herring with
respect to the
crashing.

Has anyone else out these been having this problem?  From
the lack of any
other responses, it seems that I am almost the only one. 
Are other people
running on machines similar to this one (rev 2 G3 300
MHz) successfully?  I
would like some feed back from successes and failures so
that I can try to
isolate what it is that is different about my machine and
poke directly at
that part of the kernel.  The crashes are just infrequent
enough to make
debugging difficult (low data rate), but frequent enough
to make serious
use difficult.

Thanks.

Marcus Mendenhall

quoted
I have had the same craches on a PowerCenterPro. Looking
in
/proc/cpuinfo I see that the L2 cache is not registered.
I
was thinking it could have something to do with that
since
the I have virtually the same system on the pb3400c which
works just fine.


Im running the 2.2.0 kernel from kernel.org and R5


On
03-Feb-99 Marcus H. Mendenhall wrote:
quoted
To the list:

I have been experiencing many random kernel panics in
all
kernels since
sometime around the 2.1.100's.  The panics happen at
times of high disk
activity (process creation, termination, system startup
&
shutdown).
Kernels which have exhibited this have been both stock,
precompiled kernels
from samba.anu.edu.au and home built kernels, using
vger
and kernel.org
sources.  I have applied Loic Prylli's
arch/ppc/mm/init.c
patch, which made
no obvious difference.

Here is my system:
PowerMac G3 rev 2 300 MHz, BMAC ethernet, 128 MB RAM,
64
MB swap, using
internal IDE disk, Mac keyboard, 19" monitor on
ATY,Mach3DUPro display.
The machine shows no signs of instability running
MacOS.

The errors have happened using older non-fb video and
current fb video,
with or without X running, with or without atalkd &
papd
running.

The error often occurs as a bad object or bad area
panic.
Often, the bad
object is mm->pgd.  For the last few days I have been
looking into the
slices of the kernel from which most of these emanate.
Unfortunately, I
have only collected partial tracebacks since the 180
second autoreboot
doesn't give be time to write everything down.  I don't
have another
machine handy to use a serial console.  I may have to
lengthen the time
before autoreboot soon. :-(

One of the faults comes from mm/slab.c kmem_cache_free.
It is called from
mm_put, which is called from release_task.  This error
often occurs during
system shutdown.  I have turned on debugging features
in
slab.c, but
haven't gotten any useful information from it yet.

Another, which I generated today while trying to force
crashes with X off
so I could at least see the backtrace, was as quite
interesting.  I did
find / -type f -size -50 -exec grep "mm->pgd" \{\} \;
-print
which heavily excercises all kinds of i/o, especially
process creation and
destruction (since every file less than 50 blocks found
launches grep!).
The failure I got while running this generated two
backtraces.

The first backtrace started in (reading in most-recent
to
older order)
do_rw_proc, to sys_read, to syscall_ret_1, and then
into
user space in grep.

This backtrace was interrupted by other which went
(same
order)
instruction_dump, bad_page_fault, do_page_fault,
int_return, do_rw_proc,
sys_read, syscall_ret_1, and then again to userland.

This never happens on my home 7300/180, using the same
kernels, but happens
to frequently on my G3 at work as to make heavy use
very
difficult.  I can
certainly use LyX and other "light-duty" programs for
extended periods
without any problem, but as soon as I create a lot of
disk activity and
process creation/destruction activity, the system
melts.

I have in the past reported much smaller pieces of this
to the group,
thinking it might be related to the old "ide device i/o
slowdown" problem,
or the bad interrupts problem, but I see no sign of
these
happening
(although sometines at the time of the panic, I see a
message something of
order "in interrupt... not syncing".  This message is
sufficiently
infrequently observed that I can't provide
furtherinformation on it).

If anyone else is seeing this kind of behavior, or has
any idea of a
solution, please let me know.  At present I have looked
into just about
everything except an exorcist.

Thanks.

Marcus Mendenhall




[[ This message was sent via the linuxppc-user mailing
list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc
linuxppc-user  if your ]]
[[ reply is of general interest. To unsubscribe from
linuxppc-user, send ]]
[[ the message 'unsubscribe' to
linuxppc-user-request@lists.linuxppc.org ]]
----------------------------------
E-Mail: frank@cmc.uib.no
Phone(Private):55234679
Phone(Work):55589279
Mob.: 93289455
Date: 04-Feb-99
Time: 09:10:39

This message was sent by XFMail
----------------------------------
----------------------------------
E-Mail: frank@cmc.uib.no
Phone(Private):55234679
Phone(Work):55589279
Mob.: 93289455
Date: 01-Jan-04
Time: 02:11:09

This message was sent by XFMail
----------------------------------

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help