Re: Xen 4.10 breakage with buster (was Re: [xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved)

[Jan Beulich <jbeulich@xxxxxxxx>]

On 12.06.2020 18:47, Ian Jackson wrote:
> Ian Jackson writes ("Xen 4.10 breakage with buster (was Re: [xen-4.10-testing 
> test] 151033: regressions - trouble: blocked/fail/pass/starved)"):
>>>  test-amd64-amd64-xl-qcow2    10 debian-di-install        fail REGR. vs. 
>>> 150039
>>>  test-amd64-amd64-pygrub      10 debian-di-install        fail REGR. vs. 
>>> 150039
>>>  test-amd64-i386-xl-raw       10 debian-di-install        fail REGR. vs. 
>>> 150039
>>
>>   domainbuilder: detail: xc_dom_find_loader: trying Linux bzImage loader ... 
>>   domainbuilder: detail: XZ: Saw data stream end
>>   domainbuilder: detail: _xc_try_lzma_decode: XZ decompress OK, 0x4cd8f0 -> 
>> 0x1a7779c
>>   domainbuilder: detail: loader probe OK
>>   ...
>>   domainbuilder: detail: xc_dom_alloc_segment:   module0      : 
>> 0xffffffff82c00000 -> 0xffffffff82c02000  (pfn 0x2c00 + 0x2 pages)
>>   xc: error: panic: xc_dom_core.c:387: xc_dom_do_gunzip: inflate failed 
>> (rc=-5): Internal error
>>   libxl: error: libxl_dom.c:744:libxl__build_dom: xc_dom_build_image failed: 
>> No such file or directory
>>
>> http://logs.test-lab.xenproject.org/osstest/logs/151033/test-amd64-amd64-pygrub/10.ts-debian-di-install.log
>>
>> ????  Anyone have any ideas ?  I would have guessed that this was an
>> incompatibility between pygrub and the boot config made by the new
>> pygrub but
>>    git-log origin/staging-4.10..origin/stable-4.11 tools/pygrub/
>> suggests not.
> 
> Andy suggested on IRC that there were some compression fixes which had
> perhaps not been backported far enough.
> 
> I think that's
> 
>    lz4: fix system halt at boot kernel on x86_64
>    14b62ab3e5a79816edfc6dd3afce1bb68c106ac5
>    master commit: 5d90ff79542ab9c6eebe5c315c68c196bcf353b9
> 
>    lz4: refine commit 9143a6c55ef7 for the 64-bit case
>    6561994b87af3e9cd28ee99c42e8b2697621687d
>    master commit: 2d7572cdfa4d481c1ca246aa1ce5239ccae7eb59
> 
> Anyone have any objection to me sending those to 4.10 and maybe 4.9 ?
> They apply cleanly in both cases.

Seeing the other pieces that have been put onto these old branches
recently, it's probably fine to add the two ones here as well. In
general, as mentioned before, I view it as wrong to put non-
security fixes onto the security-only branches. But since I can see
why changes to address newer compilers' changed behavior may be
wanted/needed, I guess the ones here fall into a pretty similar
group.

Jan