On 30/04/2019 15:02, Ian Jackson wrote:
> osstest service owner writes ("[linux-4.19 test] 135420: regressions - FAIL"):
>> flight 135420 linux-4.19 real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/135420/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>
>> test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail REGR. vs.
>> 129313
>
> This seems to be a kernel bug.
>
> The guest creation failed. The toolstack reports
>
> 2019-04-30 04:11:17.521+0000: libxl:
> libxl_device.c:397:libxl__device_disk_set_backend: Disk vdev=xvda
> spec.backend=qdisk
> ...
> 2019-04-30 04:11:27.600+0000: libxl:
> libxl_device.c:1418:libxl__wait_for_backend: Backend
> /local/domain/0/backend/qdisk/0/51712 not ready
>
> 2019-04-30 04:11:27.600+0000: libxl:
> libxl_bootloader.c:417:bootloader_disk_attached_cb: Domain 5:failed
> to attach local disk for bootloader execution
>
> Looking at the code in libxl, it is polling the specified xenstore
> path hoping for a ready state to turn up. It waits 10 seconds and
> then gives up. (Unfortunately it doesn't print the state it found.)
>
> The backend is qemu. qemu does not seem to have reported anything
> untoward. However, looking at the kernel log (full log below):
>
> Apr 30 04:11:17 chardonnay1 kernel: [ 1393.403311] xenwatch: page
> allocation failure: order:5,
> mode:0x60c0c0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO), nodemask=(null)
Doing an order=5 allocation for the ring is not necessary here, a
virtual contiguous area via vmalloc() should work, too.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
