From: Zilvinas Valinskas <zilvinas@gemtek.lt>
To: Helge Hafting <helge.hafting@hist.no>
Cc: Jeff Garzik <jgarzik@pobox.com>,
Lee Revell <rlrevell@joe-job.com>,
Ricky Beam <jfbeam@bluetronic.net>,
Erik Tews <erik@debian.franken.de>,
linux-kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: 2.6.9 rc2 freezing
Date: Fri, 17 Sep 2004 16:21:57 +0300 [thread overview]
Message-ID: <20040917132157.GA13966@gemtek.lt> (raw)
In-Reply-To: <20040917080503.GA7634@gemtek.lt>
On Fri, Sep 17, 2004 at 11:05:04AM +0300, Zilvinas Valinskas wrote:
> On Thu, Sep 16, 2004 at 10:39:10AM +0200, Helge Hafting wrote:
> > Jeff Garzik wrote:
> >
> > >Lee Revell wrote:
> > >
> > >>Interesting. Still, this looks like a specific bug that needs fixing,
> > >>it doesn't imply that preemption is a hack. For many workloads
> > >>preemption is a necessity.
> > >
> > >
> > >
> > >For any workload that you feel preemption is a necessity, that
> > >indicates a latency problem in the kernel that should be solved.
> > >
> > >Preemption is a hack that hides broken drivers, IMHO.
> > >
> > >I would rather directly address any latency problems that appear.
> >
> > Current preempt is broken, sure. But having robust preempt
> > would allow code simplification. Long loops outside critical
> > sections would be ok - no time or code spent testing for a need for
> > rescheduling because you'll be preempted when necessary anyway.
>
> Could be the case. This morning I've turned off PREEMPT support in
> linux 2.6.9-rc2 kernel, booted just fine, ran apt-get update ... it
> seemed everything is ok.
>
> Then setup IPsec policies, ping remote end, racoon has tried to negotiate
> with a remote end and ... laptop freezes again (this time without
> PREEMPT).
>
> At a time I was in X, couldn't capture the OOPS, after reboot
> /var/log/kern.log is empty ... :(
Here is backtrace (with PREEMPT turned off) :
bad: scheduling while atomic!
[<c030cd3e>] schedule+-0x446/0x44b
[<c010595b>] do_IRQ+0xdd/0x14b
[<c0103d36>] work_resched+0x5/0x16
this backtrace is repeated 4x times
bad: scheduling while atomic!
[<c030cd3e>] schedule+0x446/0x44b
[<c0112f82>] sys_sched_yield+0x45/0x57
[<c014ceaa>] coredump_wait+0x32/0x97
[<c014cfd7>] do_coredump+0xc8/0x189
[<c0256b44>] complement_pos+0x1e/0x16e
[<c011cb13>] __dequeue_signal+0xc2/0x154
[<c011cbc8>] dequeue_signal+0x23/0x75
[<c011e12e>] get_signal_to_deliver+0x1d4/0x2c0
[<c0103b04>] do_signal+0x8e/0x10d
[<c010595b>] do_IRQ+0xdd/0x14b
[<c0103e7c>] common_interrupt+0x18/0x20
[<c030cb76>] schedule+0x27e/0x44b
[<c010595b>] do_IRQ+0xdd/0x14b
[<c0110f98>] do_page_fault+0x0/0x544
[<c0103bb8>] do_notify_resume+0x35/0x39
[<c0103d5a>] work_notifysig+0x13/0x15
Kernel panic - not syncing: Aiee, killing interrupt handler!
Any ideas ?
>
> Doesn't seem it is PREEMPT related I think now.
> >
> > Or am I missing something? Other than that current preempt isn't up to
> > this and might be hard to get there?
> >
> > Helge Hafting
> >
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2004-09-17 13:23 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-13 16:55 2.6.9 rc2 freezing Zilvinas Valinskas
2004-09-13 17:12 ` Jeff Garzik
2004-09-13 17:16 ` Zilvinas Valinskas
2004-09-15 8:25 ` Erik Tews
2004-09-15 9:58 ` Zilvinas Valinskas
2004-09-15 14:55 ` Ricky Beam
2004-09-15 15:48 ` Lee Revell
2004-09-15 15:58 ` Jeff Garzik
2004-09-15 16:06 ` Lee Revell
2004-09-15 16:11 ` Jeff Garzik
2004-09-15 16:58 ` Ricky Beam
2004-09-15 17:49 ` Lee Revell
2004-09-15 17:52 ` Jeff Garzik
2004-09-15 17:59 ` Lee Revell
2004-09-16 8:39 ` Helge Hafting
2004-09-17 8:05 ` Zilvinas Valinskas
2004-09-17 13:21 ` Zilvinas Valinskas [this message]
2004-09-15 16:59 ` Dave Jones
2004-09-13 17:19 ` Zilvinas Valinskas
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=20040917132157.GA13966@gemtek.lt \
--to=zilvinas@gemtek.lt \
--cc=erik@debian.franken.de \
--cc=helge.hafting@hist.no \
--cc=jfbeam@bluetronic.net \
--cc=jgarzik@pobox.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rlrevell@joe-job.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