All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Iain Sandoe" <iain@sandoe.co.uk>
To: Takashi Oe <toe@unlserve.unl.edu>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linuxppc-dev@lists.linuxppc.org
Subject: Re: Occasional crash reports
Date: Tue, 14 Aug 2001 10:45:49 +0100	[thread overview]
Message-ID: <20010814094529.3E40EDBA11@atlas.valhalla.net> (raw)


On Tue, Aug 14, 2001, Takashi Oe wrote:
> On Mon, 13 Aug 2001, Benjamin Herrenschmidt wrote:
>
>> I'm getting regular crash reports for which I'm having trouble figuring
>> out what's going on exactly. Those are with my tree or bk 2_4_devel, but
>> the problem may be present elsewhere.
>>
>> So basically, the kernel tends to die in various locations where things
>> should be just fine, but I did notice one thing: In most of these cases,
>> I had softirq around in the backtrace (either running in softirqs, or
>> having do_softirq() in the backtrace). There is one case where I didn't
>> have it: it dies inside power_save(), so probably because an interrupt
>> that happened just before messed things up.
>>
>> I'm wondering if we might be running into some stack overflow...
>
> I don't really know, but I can confirm that both 2.2.x and 2.4.x kernels
> are unstable on a beige g3 and a bmac equipped b/w g3.  I can crash them
> rather easily with regular programs, given a day or two.

Can you point at which program reliably crashes beige/G3?
that's what I use as my dev/build machine and it seems to be stable (2.4.x)
except under the following circumstance:

If I boot using the BootX application - at which point something drops a
bomb which almost always ends up in the network stack and shows up as an
illegal instruction (usually an FP one).

If I hard-reboot this doesn't seem to happen.

I haven't had time to fiddle with making the kernel write-only or whatever
to find out who drops the bomb (although is may well be something that is
left over from MacOS that BootX application hasn't managed to stop).

Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

             reply	other threads:[~2001-08-14  9:45 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-08-14  9:45 Iain Sandoe [this message]
2001-08-14 12:18 ` Occasional crash reports Takashi Oe
  -- strict thread matches above, loose matches on Subject: below --
2001-08-18 11:16 Iain Sandoe
2001-08-20  2:51 ` Robert E Brose II
2001-08-18  1:28 Robert E Brose II
2001-08-14 16:02 Jiri Masik
2001-08-14 16:28 ` Benjamin Herrenschmidt
2001-08-14 16:45   ` Benjamin Herrenschmidt
2001-08-14 13:03 Iain Sandoe
2001-08-13 16:35 Benjamin Herrenschmidt
2001-08-14  2:59 ` Takashi Oe
2001-08-14 18:15   ` Mike Fedyk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20010814094529.3E40EDBA11@atlas.valhalla.net \
    --to=iain@sandoe.co.uk \
    --cc=benh@kernel.crashing.org \
    --cc=linuxppc-dev@lists.linuxppc.org \
    --cc=toe@unlserve.unl.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.