Hi Julien,
On 3/15/2024 6:58 PM, Julien Grall wrote:
On 14/03/2024 14:22, Henry Wang wrote:
Hi Julien,
Hi,
/* representing HT siblings of each logical CPU */
DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_sibling_mask);
/* representing HT and core siblings of each logical CPU */
@@
flight 185063 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185063/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit1 18 guest-start/debian.repeat fail REGR. vs. 184921
Tests which are
flight 185062 linux-linus real [real]
flight 185067 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/185062/
http://logs.test-lab.xenproject.org/osstest/logs/185067/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
On 13.03.24 09:14, Juergen Gross wrote:
Hello Juergen
> In bind_evtchn_to_irq_chip() don't increment the refcnt of the event
> channel blindly. In case the event channel is NOT refcounted, issue a
> warning instead.
>
> Add an additional safety net by doing the refcnt increment only if the
>
On 13.03.24 09:14, Juergen Gross wrote:
Hello Juergen
> When unbinding a user event channel, the related handler might be
> called a last time in case the kernel was built with
> CONFIG_DEBUG_SHIRQ. This might cause a WARN() in the handler.
>
> Avoid that by adding an "unbinding" flag to
flight 185061 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185061/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-libvirt-raw 17 guest-start/debian.repeat fail pass in 185057
Tests which did not succeed,
flight 185060 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185060/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 18 guest-start/debian.repeat fail REGR. vs. 184921
