All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ralf Baechle <ralf@linux-mips.org>
To: Steve Scott <steve.scott@pioneer-pdt.com>
Cc: jsun@mvista.com, linux-mips@linux-mips.org,
	craig.mautner@pioneer-pdt.com
Subject: Re: schedule() BUG
Date: Wed, 8 Oct 2003 18:29:59 +0200	[thread overview]
Message-ID: <20031008162959.GB19102@linux-mips.org> (raw)
In-Reply-To: <017601c38c77$6d7225a0$2256fea9@janelle>

On Mon, Oct 06, 2003 at 07:05:06PM -0700, Steve Scott wrote:

> We tried the fault.c patch Jun suggested, but it didn't solve the problem we were
> having with the BUG() in schedule(). The patch at the beginning of
> except_vec3_generic for the Vr5432 bug had previously been installed.
> 
> While chasing the BUG() in schedule(), though, we ran across another BUG() in
> alloc_skb() in ...linux/net/core/skbuff.c. :
> 
>     alloc_skb called nonatomically from interrupt 80117acc
>     kernel BUG at skbuff.c:179!
> 
> We changed the way sock_init_data initializes the 'allocation' field and
> were able to get past this one (see attached sock.c.patch). We're not sure
> if this fix needs to be permanent, or if it's just a temporary workaround.
> 
> For the schedule() BUG(), all evidence that we collected pointed to some
> interrupt causing us to reenter schedule() (i.e., somehow schedule() was
> called during an interrupt handler). We suspected something being run
> from the timer interrupt bottom half, but were never able to prove it. We
> also thought a remote possibility might be a pipeline hazard in the MIPS
> causing the EPC register not to update on a nested exception, but NEC says
> that can't happen on the Vr5432 that we're using...

Can't happen on any MIPS.

> We finally worked around the schedule BUG() by disabling interrupts
> during the context switch in schedule(). This workaround required changes
> in linux/kernel/sched.c and linux/arch/mips/kernel/r4k_switch.S (see attached
> patches).

Ouch.  Forgive but if I'd not already ignore these patches for being
ed-style I'd ignore them for being completly broken - these
patches are harmful for performance and probably not going to achieve
stability by anything other than luck ...

  Ralf

  reply	other threads:[~2003-10-08 16:30 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <FJEIIOCBFAIOIDNKLPFJCECODAAA.koji.kawachi@pioneer-pdt.com>
2003-10-07  2:05 ` schedule() BUG Steve Scott
2003-10-07  2:05   ` Steve Scott
2003-10-08 16:29   ` Ralf Baechle [this message]
2003-09-12 18:04 Craig Mautner
2003-09-12 18:04 ` Craig Mautner
2003-09-13 16:30 ` Craig Mautner
2003-09-13 16:30   ` Craig Mautner
2003-09-15 18:59 ` Craig Mautner
2003-09-15 18:59   ` Craig Mautner
2003-10-01 23:50 ` Jun Sun
2003-10-02  0:09   ` Ralf Baechle
2003-10-02  0:39     ` Jun Sun
2003-10-02  4:28   ` Daniel Jacobowitz

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=20031008162959.GB19102@linux-mips.org \
    --to=ralf@linux-mips.org \
    --cc=craig.mautner@pioneer-pdt.com \
    --cc=jsun@mvista.com \
    --cc=linux-mips@linux-mips.org \
    --cc=steve.scott@pioneer-pdt.com \
    /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.