[<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
 
