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
next prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox