WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Crash during boot in Debian lenny default dom0 kernel (2

To: Jan Beulich <JBeulich@xxxxxxxxxx>
Subject: Re: [Xen-devel] Crash during boot in Debian lenny default dom0 kernel (2.6.26-2-xen-686)
From: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>
Date: Thu, 25 Feb 2010 12:13:43 +0000
Cc: Sander Eikelenboom <linux@xxxxxxxxxxxxxx>, Jeremy Fitzhardinge <jeremy@xxxxxxxx>, Yunhong Jiang <yunhong.jiang@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 25 Feb 2010 04:16:57 -0800
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=rFIShYw5ZeZpR8JnLrG6bGw5oGguu8EPKmFGwjgU+tA=; b=BLPvb/oR3YwgY6l16PovtbpwgFEZB41uT/AI3vUUkS4Mp9Pf9uLbvqFPYdtOmN3PBz Cs2jXdW1jD5xvkJ95FlUaw8jpZaXWLQ/LXBuVLAUZyOqjhx09sys9kcDnJ3ciRtgiCrr /NbhxxWJLhZw538zVE2/hPSdYAa60RSkUNIdc=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=jFekqbdGgALKu3PRwtBRGGLxMEEWGH58TrwBFfqSaMqx7vwi0npSoAaYTpR22sLY5d Ov1tuA36Sd7cAnHVjRbmTyZORKsR3fXodG0B9wR/th1dLeVg6+5hlPOiht66ZNzKXMaR bAjOGhDAqL4lwoPIzaZt59FFHIhtgelpxSXu0=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <de76405a1002250346q32cf093i58429407ccfb5f32@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <de76405a1002241047w4d138abbjc872c371c0e742ed@xxxxxxxxxxxxxx> <25841307.20100224200810@xxxxxxxxxxxxxx> <20100224202009.GE2761@xxxxxxxxxxx> <de76405a1002241557y4449110v37b811fd36c60c4d@xxxxxxxxxxxxxx> <C8EDE645B81E5141A8C6B2F73FD92651247A93D81D@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <de76405a1002250248wcc16101v644f409f73dd43b1@xxxxxxxxxxxxxx> <4B8665680200007800031406@xxxxxxxxxxxxxxxxxx> <de76405a1002250346q32cf093i58429407ccfb5f32@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
(Jeremy: Discussing the default Lenny dom0 package, 2.6.26-2-xen--686
crashing during boot if MSIs are available.)

Sure enough, the structure it's using looks like this:

struct physdev_map_pirq {
    domid_t domid;
    /* IN */
    int type;
    /* IN */
    int index;
    /* IN or OUT */
    int pirq;
    /* IN */
    struct {
        int bus, devfn, entry_nr;
        int msi;  /* 0 - MSIX    1 - MSI */
    } msi_info;
};

The code in question came from a patch called
suse-20080808143035.patch; reading the numbers as the timestamp "2008
August 8" would seem to match up with the 3.3 dev lifecycle.

Any suggestions for a simple fix I can try to push upstream?

 -George

On Thu, Feb 25, 2010 at 11:46 AM, George Dunlap
<George.Dunlap@xxxxxxxxxxxxx> wrote:
> I'm looking at the debian source package for this kernel to see if I
> can sort out where it got the header from.
>
> Given that this is already in a major distribution, is there any way
> we can fail gracefully if someone's running this kernel?  I'm not
> familiar enough with the MSI to know if this is possible, or what a
> good set of "sanity checks" would be for failing the hypercall.
>
>  -George
>
> On Thu, Feb 25, 2010 at 10:56 AM, Jan Beulich <JBeulich@xxxxxxxxxx> wrote:
>>>>> George Dunlap <George.Dunlap@xxxxxxxxxxxxx> 25.02.10 11:48 >>>
>>>Is it possible that there's actually a bug in the compat code, and
>>>that table_base actually *was* set to (uint32_t)1?  If a reasonable
>>>number for table_base is "1", giving it 64 bits in the structure would
>>>seem a bit like overkill...
>>
>> "1" definitely is not a reasonable value here. And it's also not the
>> compat code I'm sure - it is the kernel using a bad structure definition.
>>
>> Jan
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>> http://lists.xensource.com/xen-devel
>>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>