Test report of xen 4.2.0-rc4

Test report of xen 4.2.0-rc4

[Fabio Fantoni]

[-- Attachment #1.1: Type: text/plain, Size: 1103 bytes --]

Dom0:
Wheezy 64 bit with kernel from package linux-image-3.2.0-3-amd64 version 
3.2.23-1, package blktap-dkms and all dependency packages for xen
hg clone http://xenbits.xen.org/hg/xen-unstable.hg (in this build 
changeset is 25822:ec23c2a11f6f)
-------------------------
vi Config.mk
------------
PYTHON_PREFIX_ARG =
-------------------------
Added some patches:
- tools: Improve make deb
-------------------------
./configure
-------------------------
make deb

-------------------------
Old issues not solved:
-------------
- IMPORTANT - On restore network is up but not working, tried with W7 
pro 64 bit with gplpv last build (357) on qemu-xen-traditional
- Cdrom hotswap is not working, tried with W7 pro 64 bit with gplpv last 
build (357) on qemu-xen-traditional
xl -vvv cd-eject W7 hdb
libxl: debug: libxl.c:2143:libxl_cdrom_insert: ao 0x1461980: create: 
how=(nil) callback=(nil) poller=0x14619e0
Errore di segmentazione
- Vnc is working but only with parameters not supplied as value to the 
vfb key, but with vfb key is not working
-------------------------


[-- Attachment #1.2: Firma crittografica S/MIME --]
[-- Type: application/pkcs7-signature, Size: 4510 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Test report of xen 4.2.0-rc4

[Ian Campbell]

Thanks for testing.

On Fri, 2012-09-07 at 13:44 +0100, Fabio Fantoni wrote:
> - IMPORTANT - On restore network is up but not working, tried with W7 
> pro 64 bit with gplpv last build (357) on qemu-xen-traditional

Our automated tests aren't seeing this, might it be a GPLPV issue? Can
you reproduce with e.g. PV Linux (or PVHVM Linux for that matter)?

> - Cdrom hotswap is not working, tried with W7 pro 64 bit with gplpv last 
> build (357) on qemu-xen-traditional
> xl -vvv cd-eject W7 hdb
> libxl: debug: libxl.c:2143:libxl_cdrom_insert: ao 0x1461980: create: 
> how=(nil) callback=(nil) poller=0x14619e0
> Errore di segmentazione

This doesn't happen for me. Please can you run this one under gdb and
when it fails type "bt" to get a backtrace.

> - Vnc is working but only with parameters not supplied as value to the 
> vfb key, but with vfb key is not working

Whether or not that works is very much a function of exactly what the
rest of your guest config looks like (it depends on PV for HVM for one
thing).

You've reported enough bugs now that I shouldn't need to remind you
about providing guest config files or link to
http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen again.

Ian.

Re: Test report of xen 4.2.0-rc4

[Fabio Fantoni]

[-- Attachment #1.1: Type: text/plain, Size: 6033 bytes --]

Il 07/09/2012 17:15, Ian Campbell ha scritto:
> Thanks for testing.
>
> On Fri, 2012-09-07 at 13:44 +0100, Fabio Fantoni wrote:
>> - IMPORTANT - On restore network is up but not working, tried with W7
>> pro 64 bit with gplpv last build (357) on qemu-xen-traditional
> Our automated tests aren't seeing this, might it be a GPLPV issue? Can
> you reproduce with e.g. PV Linux (or PVHVM Linux for that matter)?
>
>> - Cdrom hotswap is not working, tried with W7 pro 64 bit with gplpv last
>> build (357) on qemu-xen-traditional
>> xl -vvv cd-eject W7 hdb
>> libxl: debug: libxl.c:2143:libxl_cdrom_insert: ao 0x1461980: create:
>> how=(nil) callback=(nil) poller=0x14619e0
>> Errore di segmentazione
> This doesn't happen for me. Please can you run this one under gdb and
> when it fails type "bt" to get a backtrace.
>
>> - Vnc is working but only with parameters not supplied as value to the
>> vfb key, but with vfb key is not working
> Whether or not that works is very much a function of exactly what the
> rest of your guest config looks like (it depends on PV for HVM for one
> thing).
>
> You've reported enough bugs now that I shouldn't need to remind you
> about providing guest config files or link to
> http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen again.
>
> Ian.
>
>
>
>
> -----
> Nessun virus nel messaggio.
> Controllato da AVG - www.avg.com
> Versione: 2012.0.2197 / Database dei virus: 2437/5254 -  Data di rilascio: 07/09/2012
>
>
Thanks for reply, here the xl configuration file:

-------------------------
W7.cfg
------
name='W7'
builder="hvm"
memory=2048
vcpus=2
vif=['bridge=xenbr0']
#vfb=['vnc=1,vncunused=1,vnclisten="0.0.0.0",keymap=it']
disk=['/mnt/vm/disks/W7.disk1.xm,raw,hda,rw','/mnt/vm/iso/XPSP3PRO.iso,raw,hdb,ro,cdrom']
#disk=['/mnt/vm/disks/W7.disk1.xm,raw,hda,rw','/dev/sr0,raw,hdb,ro,cdrom']
boot='cd'
device_model_version="qemu-xen-traditional"
vnc=1
vncunused=1
vnclisten="0.0.0.0"
keymap="it"
#on_poweroff="destroy"
on_reboot="restart"
on_crash="destroy"
stdvga=1
-------------------------

I don't know exactly how to use gdbsx, tried with:
gdbsx -a 1 64 9999
Listening on port 9999
doesn't show nothing also after cd-eject

I not found howto about gdbsx, can you tell me how to use it please?

xl -vvv cd-eject W7 hdb
libxl: debug: libxl.c:2143:libxl_cdrom_insert: ao 0x7b4980: create: 
how=(nil) callback=(nil) poller=0x7b49e0
libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk 
vdev=hdb spec.backend=unknown
libxl: debug: libxl_device.c:175:disk_try_backend: Disk vdev=hdb, 
backend phy unsuitable as phys path not a block device
libxl: debug: libxl_device.c:210:disk_try_backend: Disk vdev=hdb, 
backend tap unsuitable due to format empty
libxl: debug: libxl_device.c:265:libxl__device_disk_set_backend: Disk 
vdev=hdb, using backend qdisk
libxl: debug: libxl_event.c:1497:libxl__ao_complete: ao 0x7b4980: 
complete, rc=0
libxl: debug: libxl.c:2236:libxl_cdrom_insert: ao 0x7b4980: inprogress: 
poller=0x7b49e0, flags=ic
libxl: debug: libxl_event.c:1469:libxl__ao__destroy: ao 0x7b4980: destroy
xc: debug: hypercall buffer: total allocations:4 total releases:4
xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
xc: debug: hypercall buffer: cache current size:2
xc: debug: hypercall buffer: cache hits:1 misses:2 toobig:1

This time domU seem also freeze

-------------------------
qemu-dm-W7.log
----------
domid: 1
Using file /dev/xen/blktap-2/tapdev0 in read-write mode
Using file /dev/xen/blktap-2/tapdev1 in read-only mode
Watching /local/domain/0/device-model/1/logdirty/cmd
Watching /local/domain/0/device-model/1/command
Watching /local/domain/1/cpu
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = dfc1d327-23c4-4cf1-9683-4b92a7ca2eb1
populating video RAM at ff000000
mapping video RAM from ff000000
Register xen platform.
Done register platform.
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw 
state.
xs_read(/local/domain/0/device-model/1/xen_extended_power_mgmt): read error
xs_read(): vncpasswd get error. 
/vm/dfc1d327-23c4-4cf1-9683-4b92a7ca2eb1/vncpasswd.
medium change watch on `hdb' (index: 1): /dev/xen/blktap-2/tapdev1
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
Log-dirty: no command yet.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
vcpu-set: watch node error.
xs_read(/local/domain/1/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/1/log-throttling'
medium change watch on `/local/domain/1/log-throttling' - unknown 
device, ignored
vga s->lfb_addr = f1000000 s->lfb_end = f1800000
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw 
state.
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is ro 
state.
mapping vram to f1000000 - f1800000
Unknown PV product 2 loaded in guest
PV driver build 1
region type 1 at [c100,c200).
region type 0 at [f1800000,f1800100).
squash iomem [f1800000, f1800100).
vga s->lfb_addr = f1000000 s->lfb_end = f1800000
vga s->lfb_addr = f1000000 s->lfb_end = f1800000
xc: error: linux_gnttab_set_max_grants: ioctl SET_MAX_GRANTS failed (22 
= Invalid argument): Internal error
xen be: qdisk-832: xen be: qdisk-832: xc_gnttab_set_max_grants failed: 
Invalid argument
xc_gnttab_set_max_grants failed: Invalid argument
xen be: qdisk-832: xen be: qdisk-832: reading backend state failed
reading backend state failed
xen be: qdisk-832: xen be: qdisk-832: reading backend state failed
reading backend state failed
-------------------------

-------------------------
xl-W7.log
----------
Waiting for domain W7 (domid 1) to die [pid 4029]
-------------------------

Can you post me details and versions  of your system installation (dom0 
domU GPLPV) with which you have cd-eject and network on restore working, 
please?


[-- Attachment #1.2: Firma crittografica S/MIME --]
[-- Type: application/pkcs7-signature, Size: 4510 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Test report of xen 4.2.0-rc4

[Ian Campbell]

On Mon, 2012-09-10 at 10:22 +0100, Fabio Fantoni wrote:
> Il 07/09/2012 17:15, Ian Campbell ha scritto:
> > Thanks for testing.
> >
> > On Fri, 2012-09-07 at 13:44 +0100, Fabio Fantoni wrote:
> >> - IMPORTANT - On restore network is up but not working, tried with W7
> >> pro 64 bit with gplpv last build (357) on qemu-xen-traditional
> > Our automated tests aren't seeing this, might it be a GPLPV issue? Can
> > you reproduce with e.g. PV Linux (or PVHVM Linux for that matter)?
> >
> >> - Cdrom hotswap is not working, tried with W7 pro 64 bit with gplpv last
> >> build (357) on qemu-xen-traditional
> >> xl -vvv cd-eject W7 hdb
> >> libxl: debug: libxl.c:2143:libxl_cdrom_insert: ao 0x1461980: create:
> >> how=(nil) callback=(nil) poller=0x14619e0
> >> Errore di segmentazione
> > This doesn't happen for me. Please can you run this one under gdb and
> > when it fails type "bt" to get a backtrace.
> >
> >> - Vnc is working but only with parameters not supplied as value to the
> >> vfb key, but with vfb key is not working
> > Whether or not that works is very much a function of exactly what the
> > rest of your guest config looks like (it depends on PV for HVM for one
> > thing).
> >
> > You've reported enough bugs now that I shouldn't need to remind you
> > about providing guest config files or link to
> > http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen again.
> >
> > Ian.
> >
> >
> >
> >
> > -----
> > Nessun virus nel messaggio.
> > Controllato da AVG - www.avg.com
> > Versione: 2012.0.2197 / Database dei virus: 2437/5254 -  Data di rilascio: 07/09/2012
> >
> >
> Thanks for reply, here the xl configuration file:
> 
> -------------------------
> W7.cfg
> ------
> name='W7'
> builder="hvm"
> memory=2048
> vcpus=2
> vif=['bridge=xenbr0']
> #vfb=['vnc=1,vncunused=1,vnclisten="0.0.0.0",keymap=it']

I don't think it is expected that this line (even if uncommented) would
do anything for Windows unless you have a PV FB frontend driver, which
I'm fairly certain doesn't exist. So I think:
> Vnc is working but only with parameters not supplied as value to the 
> vfb key, but with vfb key is not working

is entirely expected.

The vfb line is for use with PV guests which have a PVFB driver.

[...]
> -------------------------
> 
> I don't know exactly how to use gdbsx,

You just need regular gdb not gdbsx.

Run it as eg.g.
	gdb --args xl cd-eject <aprams>

then when it crashes type "bt".

> Can you post me details and versions  of your system installation (dom0 
> domU GPLPV) with which you have cd-eject and network on restore working, 
> please?

I tested this with Linux HVM. I don't have any Windows domUs.

Does this work without GPLPV drivers? The CDROM device should be
emulated even if those are installed anyway.

Ian.

Re: Test report of xen 4.2.0-rc4

[Fabio Fantoni]

[-- Attachment #1.1: Type: text/plain, Size: 3791 bytes --]

Il 10/09/2012 11:29, Ian Campbell ha scritto:
> On Mon, 2012-09-10 at 10:22 +0100, Fabio Fantoni wrote:
>> Il 07/09/2012 17:15, Ian Campbell ha scritto:
>>> Thanks for testing.
>>>
>>> On Fri, 2012-09-07 at 13:44 +0100, Fabio Fantoni wrote:
>>>> - IMPORTANT - On restore network is up but not working, tried with W7
>>>> pro 64 bit with gplpv last build (357) on qemu-xen-traditional
>>> Our automated tests aren't seeing this, might it be a GPLPV issue? Can
>>> you reproduce with e.g. PV Linux (or PVHVM Linux for that matter)?
>>>
>>>> - Cdrom hotswap is not working, tried with W7 pro 64 bit with gplpv last
>>>> build (357) on qemu-xen-traditional
>>>> xl -vvv cd-eject W7 hdb
>>>> libxl: debug: libxl.c:2143:libxl_cdrom_insert: ao 0x1461980: create:
>>>> how=(nil) callback=(nil) poller=0x14619e0
>>>> Errore di segmentazione
>>> This doesn't happen for me. Please can you run this one under gdb and
>>> when it fails type "bt" to get a backtrace.
>>>
>>>> - Vnc is working but only with parameters not supplied as value to the
>>>> vfb key, but with vfb key is not working
>>> Whether or not that works is very much a function of exactly what the
>>> rest of your guest config looks like (it depends on PV for HVM for one
>>> thing).
>>>
>>> You've reported enough bugs now that I shouldn't need to remind you
>>> about providing guest config files or link to
>>> http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen again.
>>>
>>> Ian.
>>>
>>>
>>>
>>>
>>> -----
>>> Nessun virus nel messaggio.
>>> Controllato da AVG - www.avg.com
>>> Versione: 2012.0.2197 / Database dei virus: 2437/5254 -  Data di rilascio: 07/09/2012
>>>
>>>
>> Thanks for reply, here the xl configuration file:
>>
>> -------------------------
>> W7.cfg
>> ------
>> name='W7'
>> builder="hvm"
>> memory=2048
>> vcpus=2
>> vif=['bridge=xenbr0']
>> #vfb=['vnc=1,vncunused=1,vnclisten="0.0.0.0",keymap=it']
> I don't think it is expected that this line (even if uncommented) would
> do anything for Windows unless you have a PV FB frontend driver, which
> I'm fairly certain doesn't exist. So I think:
>> Vnc is working but only with parameters not supplied as value to the
>> vfb key, but with vfb key is not working
> is entirely expected.
>
> The vfb line is for use with PV guests which have a PVFB driver.
>
> [...]
>> -------------------------
>>
>> I don't know exactly how to use gdbsx,
> You just need regular gdb not gdbsx.
>
> Run it as eg.g.
> 	gdb --args xl cd-eject <aprams>
>
> then when it crashes type "bt".
>
>> Can you post me details and versions  of your system installation (dom0
>> domU GPLPV) with which you have cd-eject and network on restore working,
>> please?
> I tested this with Linux HVM. I don't have any Windows domUs.
>
> Does this work without GPLPV drivers? The CDROM device should be
> emulated even if those are installed anyway.
>
> Ian.
>
>
>
> -----
> Nessun virus nel messaggio.
> Controllato da AVG - www.avg.com
> Versione: 2012.0.2197 / Database dei virus: 2437/5259 -  Data di rilascio: 09/09/2012
>
>
Tried without GPLPV, same result with cd-eject
Tried also gdb but probably somethink is missing

gdb --args xl -vvv cd-eject W7 hdb
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/sbin/xl...done.
(gdb) bt
No stack.


[-- Attachment #1.2: Firma crittografica S/MIME --]
[-- Type: application/pkcs7-signature, Size: 4510 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Test report of xen 4.2.0-rc4

[Ian Campbell]

On Mon, 2012-09-10 at 14:36 +0100, Fabio Fantoni wrote:
> gdb --args xl -vvv cd-eject W7 hdb
> GNU gdb (GDB) 7.4.1-debian
> Copyright (C) 2012 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from /usr/sbin/xl...done.

Oops, sorry I forget to say:

Enter "run" at this point to actually run the command.

> (gdb) bt
> No stack.
> 

Re: Test report of xen 4.2.0-rc4

[Fabio Fantoni]

[-- Attachment #1.1: Type: text/plain, Size: 5784 bytes --]

Il 10/09/2012 15:41, Ian Campbell ha scritto:
> On Mon, 2012-09-10 at 14:36 +0100, Fabio Fantoni wrote:
>> gdb --args xl -vvv cd-eject W7 hdb
>> GNU gdb (GDB) 7.4.1-debian
>> Copyright (C) 2012 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later
>> <http://gnu.org/licenses/gpl.html>
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
>> and "show warranty" for details.
>> This GDB was configured as "x86_64-linux-gnu".
>> For bug reporting instructions, please see:
>> <http://www.gnu.org/software/gdb/bugs/>...
>> Reading symbols from /usr/sbin/xl...done.
> Oops, sorry I forget to say:
>
> Enter "run" at this point to actually run the command.
>
>> (gdb) bt
>> No stack.
>>
>
>
>
> -----
> Nessun virus nel messaggio.
> Controllato da AVG - www.avg.com
> Versione: 2012.0.2197 / Database dei virus: 2437/5259 -  Data di rilascio: 09/09/2012
>
>
gdb --args xl -vvv cd-eject W7 hdb
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/sbin/xl...done.
(gdb) run
Starting program: /usr/sbin/xl -vvv cd-eject W7 hdb
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
libxl: debug: libxl.c:2143:libxl_cdrom_insert: ao 0x623980: create: 
how=(nil) callback=(nil) poller=0x6239e0
libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk 
vdev=hdb spec.backend=unknown
libxl: debug: libxl_device.c:175:disk_try_backend: Disk vdev=hdb, 
backend phy unsuitable as phys path not a block device
libxl: debug: libxl_device.c:210:disk_try_backend: Disk vdev=hdb, 
backend tap unsuitable due to format empty
libxl: debug: libxl_device.c:265:libxl__device_disk_set_backend: Disk 
vdev=hdb, using backend qdisk
libxl: debug: libxl_event.c:1497:libxl__ao_complete: ao 0x623980: 
complete, rc=0
libxl: debug: libxl.c:2236:libxl_cdrom_insert: ao 0x623980: inprogress: 
poller=0x6239e0, flags=ic
libxl: debug: libxl_event.c:1469:libxl__ao__destroy: ao 0x623980: destroy
xc: debug: hypercall buffer: total allocations:4 total releases:4
xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
xc: debug: hypercall buffer: cache current size:2
xc: debug: hypercall buffer: cache hits:1 misses:2 toobig:1
[Inferior 1 (process 5581) exited normally]
(gdb) bt
No stack.

I also tried Precise hvm domU, on restore give update-manager crash, 
tried firefox and work, on restore with Precise PV domU network not work 
but after yes, tried ping, first failed other ok.
Seem that also Linux domU have network not working on restore but 
resolved itself after some seconds.

I also tried cd-eject on Precise hvm domU, same result:
gdb --args xl -vvv cd-eject PRECISEHVM hdb
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/sbin/xl...done.
(gdb) run
Starting program: /usr/sbin/xl -vvv cd-eject PRECISEHVM hdb
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
libxl: debug: libxl.c:2143:libxl_cdrom_insert: ao 0x623980: create: 
how=(nil) callback=(nil) poller=0x6239e0
libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk 
vdev=hdb spec.backend=unknown
libxl: debug: libxl_device.c:175:disk_try_backend: Disk vdev=hdb, 
backend phy unsuitable as phys path not a block device
libxl: debug: libxl_device.c:210:disk_try_backend: Disk vdev=hdb, 
backend tap unsuitable due to format empty
libxl: debug: libxl_device.c:265:libxl__device_disk_set_backend: Disk 
vdev=hdb, using backend qdisk
libxl: debug: libxl_event.c:1497:libxl__ao_complete: ao 0x623980: 
complete, rc=0
libxl: debug: libxl.c:2236:libxl_cdrom_insert: ao 0x623980: inprogress: 
poller=0x6239e0, flags=ic
libxl: debug: libxl_event.c:1469:libxl__ao__destroy: ao 0x623980: destroy
xc: debug: hypercall buffer: total allocations:4 total releases:4
xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
xc: debug: hypercall buffer: cache current size:2
xc: debug: hypercall buffer: cache hits:1 misses:2 toobig:1
[Inferior 1 (process 6522) exited normally]
(gdb) bt
No stack.

----------------------------------------------
PRECISEHVM.cfg
-----------------------
name='PRECISEHVM'
builder="hvm"
memory=1024
vcpus=2
hap=1
pae=1
acpi=1
apic=1
nx=1
vif=['bridge=xenbr0']
#vfb=['vnc=1,vncunused=1,vnclisten="0.0.0.0",keymap="it"']
#disk=['/mnt/vm/disks/PRECISEHVM.disk1.xm,raw,hda,rw', 
'/dev/sr0,raw,hdb,ro,cdrom']
disk=['/mnt/vm/disks/PRECISEHVM.disk1.xm,raw,hda,rw','/mnt/vm/iso/XPSP3PRO.iso,raw,hdb,ro,cdrom']
boot='c'
xen_platform_pci=1
device_model_version='qemu-xen-traditional'
vnc=1
vncunused=1
vnclisten="0.0.0.0"
keymap="it"
stdvga=0
#videoram=16
----------------------------------------------


[-- Attachment #1.2: Firma crittografica S/MIME --]
[-- Type: application/pkcs7-signature, Size: 4510 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Test report of xen 4.2.0-rc4

[Ian Campbell]

On Mon, 2012-09-10 at 15:26 +0100, Fabio Fantoni wrote:
> gdb --args xl -vvv cd-eject W7 hdb
> GNU gdb (GDB) 7.4.1-debian
> Copyright (C) 2012 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from /usr/sbin/xl...done.
> (gdb) run
> Starting program: /usr/sbin/xl -vvv cd-eject W7 hdb
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> libxl: debug: libxl.c:2143:libxl_cdrom_insert: ao 0x623980: create: 
> how=(nil) callback=(nil) poller=0x6239e0
> libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk 
> vdev=hdb spec.backend=unknown
> libxl: debug: libxl_device.c:175:disk_try_backend: Disk vdev=hdb, 
> backend phy unsuitable as phys path not a block device
> libxl: debug: libxl_device.c:210:disk_try_backend: Disk vdev=hdb, 
> backend tap unsuitable due to format empty
> libxl: debug: libxl_device.c:265:libxl__device_disk_set_backend: Disk 
> vdev=hdb, using backend qdisk
> libxl: debug: libxl_event.c:1497:libxl__ao_complete: ao 0x623980: 
> complete, rc=0
> libxl: debug: libxl.c:2236:libxl_cdrom_insert: ao 0x623980: inprogress: 
> poller=0x6239e0, flags=ic
> libxl: debug: libxl_event.c:1469:libxl__ao__destroy: ao 0x623980: destroy
> xc: debug: hypercall buffer: total allocations:4 total releases:4
> xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
> xc: debug: hypercall buffer: cache current size:2
> xc: debug: hypercall buffer: cache hits:1 misses:2 toobig:1
> [Inferior 1 (process 5581) exited normally]
> (gdb) bt
> No stack.

That's because it seems to be working for you now... There is no crash
here.

Ian.

Re: Test report of xen 4.2.0-rc4

[Fabio Fantoni]

[-- Attachment #1.1: Type: text/plain, Size: 3939 bytes --]

Il 10/09/2012 16:27, Ian Campbell ha scritto:
> On Mon, 2012-09-10 at 15:26 +0100, Fabio Fantoni wrote:
>> gdb --args xl -vvv cd-eject W7 hdb
>> GNU gdb (GDB) 7.4.1-debian
>> Copyright (C) 2012 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later
>> <http://gnu.org/licenses/gpl.html>
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
>> and "show warranty" for details.
>> This GDB was configured as "x86_64-linux-gnu".
>> For bug reporting instructions, please see:
>> <http://www.gnu.org/software/gdb/bugs/>...
>> Reading symbols from /usr/sbin/xl...done.
>> (gdb) run
>> Starting program: /usr/sbin/xl -vvv cd-eject W7 hdb
>> [Thread debugging using libthread_db enabled]
>> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
>> libxl: debug: libxl.c:2143:libxl_cdrom_insert: ao 0x623980: create:
>> how=(nil) callback=(nil) poller=0x6239e0
>> libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk
>> vdev=hdb spec.backend=unknown
>> libxl: debug: libxl_device.c:175:disk_try_backend: Disk vdev=hdb,
>> backend phy unsuitable as phys path not a block device
>> libxl: debug: libxl_device.c:210:disk_try_backend: Disk vdev=hdb,
>> backend tap unsuitable due to format empty
>> libxl: debug: libxl_device.c:265:libxl__device_disk_set_backend: Disk
>> vdev=hdb, using backend qdisk
>> libxl: debug: libxl_event.c:1497:libxl__ao_complete: ao 0x623980:
>> complete, rc=0
>> libxl: debug: libxl.c:2236:libxl_cdrom_insert: ao 0x623980: inprogress:
>> poller=0x6239e0, flags=ic
>> libxl: debug: libxl_event.c:1469:libxl__ao__destroy: ao 0x623980: destroy
>> xc: debug: hypercall buffer: total allocations:4 total releases:4
>> xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
>> xc: debug: hypercall buffer: cache current size:2
>> xc: debug: hypercall buffer: cache hits:1 misses:2 toobig:1
>> [Inferior 1 (process 5581) exited normally]
>> (gdb) bt
>> No stack.
> That's because it seems to be working for you now... There is no crash
> here.
>
> Ian.
>
>
>
> -----
> Nessun virus nel messaggio.
> Controllato da AVG - www.avg.com
> Versione: 2012.0.2197 / Database dei virus: 2437/5259 -  Data di rilascio: 09/09/2012
>
>
After issuing the command:
xl -vvv cd-eject PRECISEHVM hdb
libxl: debug: libxl.c:2143:libxl_cdrom_insert: ao 0x1812980: create: 
how=(nil) callback=(nil) poller=0x18129e0
libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk 
vdev=hdb spec.backend=unknown
libxl: debug: libxl_device.c:175:disk_try_backend: Disk vdev=hdb, 
backend phy unsuitable as phys path not a block device
libxl: debug: libxl_device.c:210:disk_try_backend: Disk vdev=hdb, 
backend tap unsuitable due to format empty
libxl: debug: libxl_device.c:265:libxl__device_disk_set_backend: Disk 
vdev=hdb, using backend qdisk
libxl: debug: libxl_event.c:1497:libxl__ao_complete: ao 0x1812980: 
complete, rc=0
libxl: debug: libxl.c:2236:libxl_cdrom_insert: ao 0x1812980: inprogress: 
poller=0x18129e0, flags=ic
libxl: debug: libxl_event.c:1469:libxl__ao__destroy: ao 0x1812980: destroy
xc: debug: hypercall buffer: total allocations:4 total releases:4
xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
xc: debug: hypercall buffer: cache current size:2
xc: debug: hypercall buffer: cache hits:1 misses:2 toobig:1

The cdrom remain in domU and working

I also tried with insert:
root@vfarm:~# xl -vvv cd-insert PRECISEHVM hdb 
raw:/mnt/vm/iso/Clonezilla.iso
libxl: debug: libxl.c:2143:libxl_cdrom_insert: ao 0xedd980: create: 
how=(nil) callback=(nil) poller=0xedd9e0
Errore di segmentazione

But give segmentation error and nothing change on domU (remain the old 
cdrom working)

Can you tell me datails about your dom0 configuration please?


[-- Attachment #1.2: Firma crittografica S/MIME --]
[-- Type: application/pkcs7-signature, Size: 4510 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Test report of xen 4.2.0-rc4

[Fabio Fantoni]

[-- Attachment #1.1.1: Type: text/plain, Size: 4504 bytes --]

Il 11/09/2012 09:56, Fabio Fantoni ha scritto:
> Il 10/09/2012 16:27, Ian Campbell ha scritto:
>> On Mon, 2012-09-10 at 15:26 +0100, Fabio Fantoni wrote:
>>> gdb --args xl -vvv cd-eject W7 hdb
>>> GNU gdb (GDB) 7.4.1-debian
>>> Copyright (C) 2012 Free Software Foundation, Inc.
>>> License GPLv3+: GNU GPL version 3 or later
>>> <http://gnu.org/licenses/gpl.html>
>>> This is free software: you are free to change and redistribute it.
>>> There is NO WARRANTY, to the extent permitted by law.  Type "show 
>>> copying"
>>> and "show warranty" for details.
>>> This GDB was configured as "x86_64-linux-gnu".
>>> For bug reporting instructions, please see:
>>> <http://www.gnu.org/software/gdb/bugs/>...
>>> Reading symbols from /usr/sbin/xl...done.
>>> (gdb) run
>>> Starting program: /usr/sbin/xl -vvv cd-eject W7 hdb
>>> [Thread debugging using libthread_db enabled]
>>> Using host libthread_db library 
>>> "/lib/x86_64-linux-gnu/libthread_db.so.1".
>>> libxl: debug: libxl.c:2143:libxl_cdrom_insert: ao 0x623980: create:
>>> how=(nil) callback=(nil) poller=0x6239e0
>>> libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk
>>> vdev=hdb spec.backend=unknown
>>> libxl: debug: libxl_device.c:175:disk_try_backend: Disk vdev=hdb,
>>> backend phy unsuitable as phys path not a block device
>>> libxl: debug: libxl_device.c:210:disk_try_backend: Disk vdev=hdb,
>>> backend tap unsuitable due to format empty
>>> libxl: debug: libxl_device.c:265:libxl__device_disk_set_backend: Disk
>>> vdev=hdb, using backend qdisk
>>> libxl: debug: libxl_event.c:1497:libxl__ao_complete: ao 0x623980:
>>> complete, rc=0
>>> libxl: debug: libxl.c:2236:libxl_cdrom_insert: ao 0x623980: inprogress:
>>> poller=0x6239e0, flags=ic
>>> libxl: debug: libxl_event.c:1469:libxl__ao__destroy: ao 0x623980: 
>>> destroy
>>> xc: debug: hypercall buffer: total allocations:4 total releases:4
>>> xc: debug: hypercall buffer: current allocations:0 maximum 
>>> allocations:2
>>> xc: debug: hypercall buffer: cache current size:2
>>> xc: debug: hypercall buffer: cache hits:1 misses:2 toobig:1
>>> [Inferior 1 (process 5581) exited normally]
>>> (gdb) bt
>>> No stack.
>> That's because it seems to be working for you now... There is no crash
>> here.
>>
>> Ian.
>>
>>
>>
>> -----
>> Nessun virus nel messaggio.
>> Controllato da AVG - www.avg.com
>> Versione: 2012.0.2197 / Database dei virus: 2437/5259 -  Data di 
>> rilascio: 09/09/2012
>>
>>
> After issuing the command:
> xl -vvv cd-eject PRECISEHVM hdb
> libxl: debug: libxl.c:2143:libxl_cdrom_insert: ao 0x1812980: create: 
> how=(nil) callback=(nil) poller=0x18129e0
> libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk 
> vdev=hdb spec.backend=unknown
> libxl: debug: libxl_device.c:175:disk_try_backend: Disk vdev=hdb, 
> backend phy unsuitable as phys path not a block device
> libxl: debug: libxl_device.c:210:disk_try_backend: Disk vdev=hdb, 
> backend tap unsuitable due to format empty
> libxl: debug: libxl_device.c:265:libxl__device_disk_set_backend: Disk 
> vdev=hdb, using backend qdisk
> libxl: debug: libxl_event.c:1497:libxl__ao_complete: ao 0x1812980: 
> complete, rc=0
> libxl: debug: libxl.c:2236:libxl_cdrom_insert: ao 0x1812980: 
> inprogress: poller=0x18129e0, flags=ic
> libxl: debug: libxl_event.c:1469:libxl__ao__destroy: ao 0x1812980: 
> destroy
> xc: debug: hypercall buffer: total allocations:4 total releases:4
> xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
> xc: debug: hypercall buffer: cache current size:2
> xc: debug: hypercall buffer: cache hits:1 misses:2 toobig:1
>
> The cdrom remain in domU and working
>
> I also tried with insert:
> root@vfarm:~# xl -vvv cd-insert PRECISEHVM hdb 
> raw:/mnt/vm/iso/Clonezilla.iso
> libxl: debug: libxl.c:2143:libxl_cdrom_insert: ao 0xedd980: create: 
> how=(nil) callback=(nil) poller=0xedd9e0
> Errore di segmentazione
>
> But give segmentation error and nothing change on domU (remain the old 
> cdrom working)
>
> Can you tell me datails about your dom0 configuration please?
>
I have redone a clean install of Wheezy 64 bit with xen 4.2.0-rc5.
The problem about network not working on restore is now solved.
Cdrom hotplug is not solved, it has the same problem, retried with 
Windows 7 and Precise HVM.
I'm also attaching logs of Precise HVM with cd-insert and cd-eject, 
qemu-dm...log seems to contain error logs that may be useful.

[-- Attachment #1.1.2: qemu-dm-PRECISEHVM.log --]
[-- Type: text/plain, Size: 2235 bytes --]

domid: 6
-videoram option does not work with cirrus vga device model. Videoram set to 4M.
Using file /dev/xen/blktap-2/tapdev0 in read-write mode
Using file /dev/xen/blktap-2/tapdev1 in read-only mode
Watching /local/domain/0/device-model/6/logdirty/cmd
Watching /local/domain/0/device-model/6/command
Watching /local/domain/6/cpu
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = 44dde305-e139-4eb6-bac6-e4526b3f027a
populating video RAM at ff000000
mapping video RAM from ff000000
Register xen platform.
Done register platform.
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw state.
xs_read(/local/domain/0/device-model/6/xen_extended_power_mgmt): read error
xs_read(): vncpasswd get error. /vm/44dde305-e139-4eb6-bac6-e4526b3f027a/vncpasswd.
medium change watch on `hdb' (index: 1): /dev/xen/blktap-2/tapdev1
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
Log-dirty: no command yet.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
vcpu-set: watch node error.
xs_read(/local/domain/6/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/6/log-throttling'
medium change watch on `/local/domain/6/log-throttling' - unknown device, ignored
cirrus vga map change while on lfb mode
mapping vram to f0000000 - f0400000
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw state.
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is ro state.
Unknown PV product 3 loaded in guest
PV driver build 1
region type 1 at [c100,c200).
region type 0 at [f3001000,f3001100).
squash iomem [f3001000, f3001100).
xc: error: linux_gnttab_set_max_grants: ioctl SET_MAX_GRANTS failed (22 = Invalid argument): Internal error
xen be: qdisk-832: xen be: qdisk-832: xc_gnttab_set_max_grants failed: Invalid argument
xc_gnttab_set_max_grants failed: Invalid argument
xen be: qdisk-832: xen be: qdisk-832: reading backend state failed
reading backend state failed
xen be: qdisk-832: xen be: qdisk-832: reading backend state failed
reading backend state failed
Time offset set 1, added offset 1
shutdown requested in cpu_handle_ioreq
Issued domain 6 poweroff

[-- Attachment #1.1.3: xl-PRECISEHVM.log --]
[-- Type: text/plain, Size: 218 bytes --]

Waiting for domain PRECISEHVM (domid 6) to die [pid 4853]
Domain 6 has shut down, reason code 0 0x0
Action for shutdown reason code 0 is destroy
Domain 6 needs to be cleaned up: destroying the domain
Done. Exiting now

[-- Attachment #1.2: Firma crittografica S/MIME --]
[-- Type: application/pkcs7-signature, Size: 4510 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel