[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1326214407.19095.11.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
Date: Tue, 10 Jan 2012 17:53:27 +0100
From: Eric Dumazet <eric.dumazet@...il.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Martin Schwidefsky <schwidefsky@...ibm.com>,
linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [BUG] kernel freezes with latest tree
Le mardi 10 janvier 2012 à 08:49 -0800, Linus Torvalds a écrit :
> On Tue, Jan 10, 2012 at 8:37 AM, Eric Dumazet <eric.dumazet@...il.com> wrote:
> >
> > Just to make sure I understood well, here is what I tested :
>
> Yup, that was it.
>
> That was the obvious thing about the merge to check.
>
> I suspect that what remains is now the sparse cleanups and
> usecs_to_cputime64() interaction. I note that you are running on a
> 32-bit setup, which is where such problems would show up (because any
> new casts to "unsigned long" due to the forced sparse casting would
> now actually truncate a 64-bit value down.
>
> Just to test that theory, can you try this attached patch that simply
> removes the casts? That's what we used to have before adding the
> stricter type-checking (other things changed too, so this may not make
> any difference, but this is a "test a small change to *maybe* narrow
> things down")
>
> Martin - mind re-running sparse on the 32-bit case to see if that
> shows some messed-up case?
>
> Linus
I am compiling your patch, but I want to point out that I got also
lockups on my 64bit dev machine.
(But alas, my git bisect attempt on it stopped on un bootable kernels)
--
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