[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20081106211639.GA24579@elte.hu>
Date: Thu, 6 Nov 2008 22:16:39 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Jeremy Fitzhardinge <jeremy@...p.org>
Cc: Ian Campbell <Ian.Campbell@...rix.com>,
"Christopher S. Aker" <caker@...shore.net>,
xen devel <xen-devel@...ts.xensource.com>,
Jan Beulich <jbeulich@...ell.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [Xen-devel] 2.6.27 - SMP enabled, but only 1 CPU
* Jeremy Fitzhardinge <jeremy@...p.org> wrote:
> Ian Campbell wrote:
>> On Wed, 2008-11-05 at 10:31 -0500, Christopher S. Aker wrote:
>>
>>> 2.6.28-rc3 - Brought up 1 CPUs, eventually dies with:
>>> http://p.linode.com/1408
>>>
>>
>> I've been seeing this too. I bisected it down to:
>>
>> ab00fee30cddf975200b3c97aef25bea144a0d89 is first bad commit
>> commit ab00fee30cddf975200b3c97aef25bea144a0d89
>> Author: Jan Beulich <jbeulich@...ell.com>
>> Date: Thu Oct 30 10:37:21 2008 +0000
>> i386/PAE: fix pud_page()
>> Impact: cleanup
>> To the unsuspecting user it is quite annoying
>> that this broken and
>> inconsistent with x86-64 definition still exists.
>> Signed-off-by: Jan Beulich
>> <jbeulich@...ell.com>
>> Signed-off-by: Ingo Molnar <mingo@...e.hu>
>> :040000 040000 3b49a9d3792e9f02dd799ad4deb69922d2a085d0
>> f0136498ef53b36172dca595f11a784f43bebcea M arch
>>
>> It's late so figuring out how it broke can wait for tomorrow.
>>
>> The interesting bit from the link given is below.
>>
>
> Ah, OK.
>
> Ingo, Jan:
>
> Did this patch actually fix anything, or was it just a cleanup? It
> seems to have broken 32-bit Xen in some way, so if its just a cleanup it
> would be best to drop it until we've worked out what's going on.
no, it was pure cleanup. The impact line shows this:
>> Impact: cleanup
a "cleanup" impact line is only added if the change is not intended to
have any side-effects whatsoever.
We can drop it but it would be really nice to figure out what's going
on. In a very quick late-night look i cannot see anything particularly
weird about it, but based on the type of changes it does there are
three leading candidates: lost high 32 bits, zero extend problem, or
incorrect types.
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