Xen devel - Jun 2012 - grant table errors with qemu-xen-traditional

I''m not sure if thats guest or host related, but current xen-unstable
with device_model_version="qemu-xen-traditional" fail to access the
block device properly, both PV and HVM are affected. The guest runs the
upcoming 12.2 kernel, which is based on forward ported xenlinux sources.

I added f7f8c33cd49885d69efc2e5f7f9a613d631762e2 to
qemu-xen-traditional, but that does not seem to help.

Any idea whats wrong?

Olaf

/var/log/xen/qemu-dm-Factory_para_default.log

domid: 29
Warning: vlan 0 is not connected to host network
-videoram option does not work with cirrus vga device model. Videoram set to 4M.
/usr/src/packages/BUILD/xen-4.2.25485/non-dbg/tools/qemu-xen-traditional-dir/hw/xen_blktap.c:628:
Init blktap pipes
Could not open /var/run/tap/qemu-read-29
xs_read(): target get error. /local/domain/29/target.
xs_read(): vncpasswd get error.
/vm/766033e3-17f7-4803-aab5-055e5360439e/vncpasswd.
xen be: qdisk-5632: xen be: qdisk-5632: error: unknown operation (4)
error: unknown operation (4)
xc: error: linux_gnttab_grant_map: ioctl MAP_GRANT_REF failed (12 = Cannot
allocate memory): Internal error
xen be: qdisk-768: xen be: qdisk-768: can''t map 11 grant refs (Cannot
allocate memory, 118 maps)
can''t map 11 grant refs (Cannot allocate memory, 118 maps)
Key lost : keysym=0x1008ff02(269025026)


/var/log/xen/qemu-dm-Factory_full_bug694863.log

domid: 3
-videoram option does not work with cirrus vga device model. Videoram set to 4M.
Strip off blktap sub-type prefix to
/local_vminages/vdisk-Factory_full_bug694863-disk0 (drv ''aio'')
Using file /local_vminages/vdisk-Factory_full_bug694863-disk0 in read-write mode
Watching /local/domain/0/device-model/3/logdirty/cmd
Watching /local/domain/0/device-model/3/command
Watching /local/domain/3/cpu
char device redirected to /dev/pts/5
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = 78136f56-5614-4006-a24e-c73c6a3dc29e
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/3/xen_extended_power_mgmt): read error
xs_read(): vncpasswd get error.
/vm/78136f56-5614-4006-a24e-c73c6a3dc29e/vncpasswd.
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/3/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/3/log-throttling''
medium change watch on `/local/domain/3/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 65535 loaded in guest
PV driver build 50593792
xc: error: linux_gnttab_grant_map: ioctl MAP_GRANT_REF failed (12 = Cannot
allocate memory): Internal error
xen be: qdisk-768: xen be: qdisk-768: can''t map 11 grant refs (Cannot
allocate memory, 119 maps)
can''t map 11 grant refs (Cannot allocate memory, 119 maps)
xc: error: linux_gnttab_grant_map: ioctl MAP_GRANT_REF failed (12 = Cannot
allocate memory): Internal error
xen be: qdisk-768: xen be: qdisk-768: can''t map 4 grant refs (Cannot
allocate memory, 126 maps)
can''t map 4 grant refs (Cannot allocate memory, 126 maps)
xc: error: linux_gnttab_grant_map: ioctl MAP_GRANT_REF failed (12 = Cannot
allocate memory): Internal error
xen be: qdisk-768: xen be: qdisk-768: can''t map 4 grant refs (Cannot
allocate memory, 126 maps)
can''t map 4 grant refs (Cannot allocate memory, 126 maps)
xc: error: linux_gnttab_grant_map: ioctl MAP_GRANT_REF failed (12 = Cannot
allocate memory): Internal error
xen be: qdisk-768: xen be: qdisk-768: can''t map 4 grant refs (Cannot
allocate memory, 126 maps)
can''t map 4 grant refs (Cannot allocate memory, 126 maps)
xc: error: linux_gnttab_grant_map: ioctl MAP_GRANT_REF failed (12 = Cannot
allocate memory): Internal error
xen be: qdisk-768: xen be: qdisk-768: can''t map 4 grant refs (Cannot
allocate memory, 126 maps)
can''t map 4 grant refs (Cannot allocate memory, 126 maps)
xc: error: linux_gnttab_grant_map: ioctl MAP_GRANT_REF failed (12 = Cannot
allocate memory): Internal error
xen be: qdisk-768: xen be: qdisk-768: can''t map 2 grant refs (Cannot
allocate memory, 127 maps)
can''t map 2 grant refs (Cannot allocate memory, 127 maps)
xc: error: linux_gnttab_grant_map: ioctl MAP_GRANT_REF failed (12 = Cannot
allocate memory): Internal error
xen be: qdisk-768: xen be: qdisk-768: can''t map 3 grant refs (Cannot
allocate memory, 127 maps)
can''t map 3 grant refs (Cannot allocate memory, 127 maps)
xc: error: linux_gnttab_grant_map: ioctl MAP_GRANT_REF failed (12 = Cannot
allocate memory): Internal error
xen be: qdisk-768: xen be: qdisk-768: can''t map 5 grant refs (Cannot
allocate memory, 127 maps)
can''t map 5 grant refs (Cannot allocate memory, 127 maps)

>>> On 20.06.12 at 14:15, Olaf Hering <olaf@aepfle.de> wrote:
> I''m not sure if thats guest or host related, but current
xen-unstable
> with device_model_version="qemu-xen-traditional" fail to access
the
> block device properly, both PV and HVM are affected. The guest runs the
> upcoming 12.2 kernel, which is based on forward ported xenlinux sources.
> 
> I added f7f8c33cd49885d69efc2e5f7f9a613d631762e2 to
> qemu-xen-traditional, but that does not seem to help.
> 
> Any idea whats wrong?
Did you verify that the added code actually gets executed? The
log messages provided suggest that the limit didn''t really get
raised from its default of 128.

Jan

On Wed, Jun 20, Jan Beulich wrote:
> >>> On 20.06.12 at 14:15, Olaf Hering <olaf@aepfle.de>
wrote:
> 
> > I''m not sure if thats guest or host related, but current
xen-unstable
> > with device_model_version="qemu-xen-traditional" fail to
access the
> > block device properly, both PV and HVM are affected. The guest runs
the
> > upcoming 12.2 kernel, which is based on forward ported xenlinux
sources.
> > 
> > I added f7f8c33cd49885d69efc2e5f7f9a613d631762e2 to
> > qemu-xen-traditional, but that does not seem to help.
> > 
> > Any idea whats wrong?
> 
> Did you verify that the added code actually gets executed? The
> log messages provided suggest that the limit didn''t really get
> raised from its default of 128.
The patch applied with fuzz, so patch decided to put the change into
blk_disconnect() instead of blk_alloc(). With a correctly refreshed
patch qemu-xen-traditional works again.

Olaf