linux-kernel - Re: PROBLEM with 2.6.18: BUG: scheduling while atomic

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 27 Sep 2006 12:49:04 -0700
From:	Andrew Morton <akpm@...l.org>
To:	Markus Schoder <lists@...marayburst.de>
Cc:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>
Subject: Re: PROBLEM with 2.6.18: BUG: scheduling while atomic

On Wed, 27 Sep 2006 14:44:20 +0200
Markus Schoder <lists@...marayburst.de> wrote:

> Twice within the last 4 days the kernel started generating
> 
> BUG: scheduling while atomic: swapper/0x00000001/0
> 
> messages like crazy (several hundreds per second) and would not stop until
> rebooted.  I have no idea what triggered it.
> 
> Did not have this problem with the 2.6.17 series which I am back to
> using now.
> 
> I am using the proprietary nvidia module so if people think it helps I can try
> to recreate the problem without this module (might take a few days though).
> 
> The logged call traces are not always completely identical here are some
> examples:
> 
> Sep 24 13:29:24 gondolin kernel: Call Trace:
> Sep 24 13:29:24 gondolin kernel:  [<ffffffff80268ca5>] thread_return+0x0/0xeb
> Sep 24 13:29:24 gondolin kernel:  [<ffffffff802684fa>] __sched_text_start+0x7a/0x825
> Sep 24 13:29:24 gondolin kernel:  [<ffffffff88000000>] :unix:unix_poll+0x0/0xb0
> Sep 24 13:29:24 gondolin kernel:  [<ffffffff88000000>] :unix:unix_poll+0x0/0xb0
> Sep 24 13:29:24 gondolin kernel:  [<ffffffff8026ef30>] default_idle+0x0/0x60
> Sep 24 13:29:24 gondolin kernel:  [<ffffffff8024f276>] cpu_idle+0x96/0xb0
> Sep 24 13:29:24 gondolin kernel:  [<ffffffff805e5641>] start_secondary+0x4f1/0x500

This might indicate that some code somewhere forgot to do
spin_unlock/preempt_enable/kunmap_atomic/whatever.

Ingo, do you have a current version of the patch which allows us to locate
the culprit?

Thanks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/