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)
- 2004-10-22 · Re: Many random crashes in 2.2.0 (and previous kernels) · Bill Fink <hidden>
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 Mendenhallquoted
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 ]]