[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20091202132937.GA1564@elte.hu>
Date: Wed, 2 Dec 2009 14:29:37 +0100
From: Ingo Molnar <mingo@...e.hu>
To: npiggin@...e.de, mingo@...hat.com, hpa@...or.com,
linux-kernel@...r.kernel.org, jbeulich@...ell.com,
torvalds@...ux-foundation.org, a.p.zijlstra@...llo.nl,
tglx@...utronix.de
Cc: linux-tip-commits@...r.kernel.org
Subject: Re: [tip:core/locking] locking, x86: Slightly shorten
__ticket_spin_trylock()
* tip-bot for Jan Beulich <JBeulich@...ell.com> wrote:
> Commit-ID: 133ec7a235160dd44cbd4d82fff65a9983331df9
> Gitweb: http://git.kernel.org/tip/133ec7a235160dd44cbd4d82fff65a9983331df9
> Author: Jan Beulich <JBeulich@...ell.com>
> AuthorDate: Fri, 27 Nov 2009 15:09:16 +0000
> Committer: Ingo Molnar <mingo@...e.hu>
> CommitDate: Wed, 2 Dec 2009 11:11:11 +0100
>
> locking, x86: Slightly shorten __ticket_spin_trylock()
-tip testing found that this causes a boot regression (locking during
boot):
commit 133ec7a235160dd44cbd4d82fff65a9983331df9
Author: Jan Beulich <JBeulich@...ell.com>
Date: Fri Nov 27 15:09:16 2009 +0000
locking, x86: Slightly shorten __ticket_spin_trylock()
Since the callers generally expect a boolean value, there's no
need to zero-extend the outcome of the comparison. It just
requires that all of x86' trylock implementations return bo
After a couple of silent hangs in random places during bootup i got one
bootup that has a more telling output:
CPU1: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ stepping 02
Brought up 2 CPUs
Total of 2 processors activated (8041.67 BogoMIPS).
BUG: spinlock wrong owner on CPU#0, swapper/1
lock: 7b20b340, .magic: dead4ead, .owner: swapper/0, .owner_cpu: -1
Pid: 1, comm: swapper Not tainted 2.6.32-rc8-tip-02745-g401930b-dirty
#9729
Call Trace:
[<792a9959>] ? _raw_spin_unlock+0x46/0x76
[<79a8729c>] ? _spin_unlock_irqrestore+0x8/0x12
[<790268ae>] ? wait_task_inactive+0x73/0xa3
[<7902a0b5>] ? kthread_bind+0x1e/0x8a
[<79037b46>] ? start_workqueue_thread+0x13/0x1d
[<79037f99>] ? __create_workqueue_key+0x10b/0x165
[<7a02e26e>] ? init_workqueues+0x78/0x83
[<7a01d2f4>] ? kernel_init+0x12b/0x1ae
[<7a01d1c9>] ? kernel_init+0x0/0x1ae
[<79002dbf>] ? kernel_thread_helper+0x7/0x10
device: 'platform': device_add
khelper used greatest stack depth: 3336 bytes left
at first quick sight, this bit looks odd:
+ union { int i; bool b; } new;
+ return new.b;
shouldnt that be short based, to work correctly in the 0-255 CPUs case?
Ingo
--
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/
Powered by blists - more mailing lists