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] Build vmlinuz-2.6.29-rc5-tip

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: Re: [Xen-devel] Build vmlinuz-2.6.29-rc5-tip
From: Andrew Lyon <andrew.lyon@xxxxxxxxx>
Date: Fri, 20 Feb 2009 19:44:51 +0000
Cc: bderzhavets@xxxxxxxxx, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Marc - A. Dahlhaus \[ Administration | Westermann GmbH \]" <mad@xxxxxx>
Delivery-date: Fri, 20 Feb 2009 11:45:20 -0800
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=WUBvlq/WqGJyk2kT9CI9FcjphuJtAs3HNHIwgLv5ixY=; b=RXnz+qd9npPHvdDKeijiO+sbjqAraZFnd6wIJibTwAXFE6DvHZuP6VSPa1RZRbfbZf 6Le4atSm/bDDNo+8QdU/GwHjIC/aOQARBPZt1Nps3O2caM+CxnS59GPosl7RjyetIbcf s7uATCoOW7iZZPpKSzZLNCObICC3jDVqE0Ix4=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=eMYYTaOW8mPNgqhJXYXrTT9N3seji3zOuE0OaxYiwCmmRpQsrjdFBmVUn1qF/5XR9R RaYiCpSWRO/beUMI2ur+WqRREILLbBqRQflcerB65C2JLAy+2AZPL/Lc5Dwe0UPra5sZ U3w3z2VlQrqj9cpSlj81HKXA1CqPHs8uPEY+Q=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <f4527be0902200739s1d234567qf9ede85f917bfaf7@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: <310295.43521.qm@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <927395.41213.qm@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <f4527be0902181053kbcc1a03mc6ae385b805993cd@xxxxxxxxxxxxxx> <499D971C.7020304@xxxxxxxx> <f4527be0902200104u3e683de1he474b76e36be48f1@xxxxxxxxxxxxxx> <499EC52F.3080901@xxxxxxxx> <f4527be0902200739s1d234567qf9ede85f917bfaf7@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Fri, Feb 20, 2009 at 3:39 PM, Andrew Lyon <andrew.lyon@xxxxxxxxx> wrote:
> On Fri, Feb 20, 2009 at 2:58 PM, Jeremy Fitzhardinge <jeremy@xxxxxxxx> wrote:
>> Andrew Lyon wrote:
>>>
>>> Awesome, the kernel  booted and ahci is working normally, and piix
>>> isnt actually used on this system as all the devices are sata.
>>>
>>
>> Good to hear.
>>
>>> xend failed to start saying it was not a privileged domain, first
>>> thing I am going to try there is upgrading to Xen 3.3.1 final as I am
>>> still running rc4 on my test box, but what is the minimum Xen version
>>> to use pv_ops dom0?
>>>
>>
>> Did you forget to mount /proc/xen?
>
> Yes, I mounted it and now I can start xend.
>
>>
>>> root (hd0,0)
>>>  Filesystem type is ext2fs, partition type 0x83
>>> kernel /xen.gz com1=115200,8n1 console=com1,vga mem=3G dom0_mem=512M
>>>   [Multiboot-elf, <0x100000:0xfc6a8:0x98958>, shtab=0x295078,
>>> entry=0x100000]
>>> module /vmlinux.bin.gz-2.6.29-rc5-tip root=/dev/sda2 console=hvc0
>>> earlyprink=xe
>>> n pci=nomsi panic=5
>>>
>>
>> With current versions of Xen you can just use your bzImage for the kernel -
>> no need for vmlinuz-XXX.gz as well.
>
> noted.
>
>>
>>   J
>>
>
> I think I could not connect to hvm domain using vnc because of a bug
> Yuji Shimada has already found:
>
> "If we assign the device that doesn't have Power Management Capability
> Structure to guest domain, qemu accesses NULL pointer."
>
> I am getting the same error
> "xs_read(/local/domain/0/device-model/2/xen_extended_power_mgmt): read
> error"
>
> Yuji said "I'll submit the patch to fix the bug ASAP", I will try
> again once his patch is submitted.
>
> Andy
>

I have checked the ioemu-remote source that is downloaded when
building xen unstable, it seems to be missing this patch:

<snip>

This patch fixes the segmentation fault on assigning device without
Power Management Capability Structure.

Please apply this patch after applying the following patch I have
submitted.

   [PATCH] ioemu: Cleanup the code of PCI passthrough.

Thanks,
--
Yuji Shimada.


Signed-off-by: Yuji Shimada <shimada-yxb@xxxxxxxxxxxxxxx>


diff --git a/hw/pass-through.c b/hw/pass-through.c
index 855f69c..305ea59 100644
--- a/hw/pass-through.c
+++ b/hw/pass-through.c
@@ -1165,7 +1165,7 @@ static void pt_pci_write_config(PCIDevice *d,
uint32_t address, uint32_t val,
    }

    /* check power state transition flags */
-    if (pm_state->flags & PT_FLAG_TRANSITING)
+    if (pm_state != NULL && pm_state->flags & PT_FLAG_TRANSITING)
        /* can't accept untill previous power state transition is completed.
         * so finished previous request here.
         */
@@ -1280,7 +1280,7 @@ out:
    if (!ret)
        PT_LOG("Error: pci_write_block failed. return value[%d].\n", ret);

-    if (pm_state->flags & PT_FLAG_TRANSITING)
+    if (pm_state != NULL && pm_state->flags & PT_FLAG_TRANSITING)
        /* set QEMUTimer */
        qemu_mod_timer(pm_state->pm_timer,
            (qemu_get_clock(rt_clock) + pm_state->pm_delay));
@@ -1337,7 +1337,7 @@ static uint32_t pt_pci_read_config(PCIDevice *d,
uint32_t address, int len)
    }

    /* check power state transition flags */
-    if (pm_state->flags & PT_FLAG_TRANSITING)
+    if (pm_state != NULL && pm_state->flags & PT_FLAG_TRANSITING)
        /* can't accept untill previous power state transition is completed.
         * so finished previous request here.
         */

<snip>

I certainly get the same symptom as the user that originally reported this bug:

[2009-02-20 19:37:53 19273] WARNING (image:482) domain xptest: device
model failure: pid 19342: malfunctioning (closed sentinel), killed;
see /var/log/xen/qemu-dm-xptest.log


 cat /var/log/xen/qemu-dm-xptest.log
domid: 3
qemu: the number of cpus is 2
Watching /local/domain/0/device-model/3/logdirty/next-active
Watching /local/domain/0/device-model/3/command
qemu_map_cache_init nr_buckets = 10000 size 3145728
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = 46f22c82-8a3d-47e3-b9c5-3b5f6eaf7a12
Time offset set 0
populating video RAM at ff000000
mapping video RAM from ff000000
Register xen platform.
Done register platform.
xs_read(/local/domain/0/device-model/3/xen_extended_power_mgmt): read error
medium change watch on `hdc' (index: 1):
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
cirrus vga map change while on lfb mode


But the only strange thing is that I am not trying to assign a pci
device to the domain.

I tried manually applying the patch but it didnt seem to work, I had
the same issue when I tried to use James's gplpv device hiding patch,
what is the correct technique for applying patches to ioemu-remote ?
the source doesn't exist until the build process is started, is it
possible to manually pull the source and then tell the build process
not to download it?

Thanks
Andy

Andy

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

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