[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: xen/evtchn: Dom0 boot hangs using preempt_rt kernel 5.10


  • To: Jason Andryuk <jandryuk@xxxxxxxxx>
  • From: Luca Fancellu <luca.fancellu@xxxxxxx>
  • Date: Tue, 23 Mar 2021 17:06:43 +0000
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2gJMI/JRdY9brm2ekNNIX6nBtQno/t7ociY5F+FOE74=; b=mj2Qw+ers3kZVjuhto9oz0lVSBsa1FtQkCuHATisObeR5ysInkMIJuUd3LVnu9q7teh7uRA48odhfnWxOfxJsDhPUGca0r8feK2ch2KMgEZ6/XOZD/FAG7uvhxgVUWO/cMhWHq4JvLN35HiKgCweeExviiQgwxnVoTsbjRVmlWq+zmxTXFYyczMHIHHomq2lM4k/7cuL1ObMEEHN3dPYus6Q2xOyElTrHSF4aC7KTjH+lvM1BsOfhnMSNbHpRvq3iOR6oObvZCxMsGWpXHvpn2cuMSqRtE6SPZG7aE06flsZYoK3Z/1gISeGeiJpdkeyICWNIvUjL+sdVpxFRvV86w==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KxT65rz1iufRP3FZMV84Yt2yR3UO/Y3V5AkI/QA+tk1CVhXlrjbcQ43XDxuhlOvl1wOYauxOe28BgJYSSrANKnT5bsvsg9h1vlNP+ZSVA2jb4oZ+bmuS2xkqixJv5oqQl8LkSoJwgrOCf5Hrw0VN2akNtDRGUN/mq5r2fAfJrlhCoQCtTbfqnLWj2lL3VenMRW3tJxeGYvmt49H5BzLrI2fWxdXXwuNzK01vmZXy4RPVMj98oYujlW9oO6TvkQz0bz9G7inweGyT3943PMdkC6QdsFhIfGPIr3r8Lf9fQDqxIDMBv4ylMDb6RZqM46F3tHXEzBDJhfAIk0pOmnG3NA==
  • Authentication-results-original: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=arm.com;
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Jürgen Groß <jgross@xxxxxxxx>
  • Delivery-date: Tue, 23 Mar 2021 17:07:13 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Nodisclaimer: true
  • Original-authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=arm.com;

Hi all,

I have an update, changing the lock introduced by the serie from spinlock_t to 
raw_spinlock_t, changing the lock/unlock function to use the raw_* version and 
keeping the BUG_ON(…) (now we can because raw_* implementation disable 
interrupts on preempt_rt) the kernel is booting correctly.
So seems that the BUG_ON(…) is needed and the unmask function should run with 
interrupt disabled, anyone knows why this change worked? 

> On 23 Mar 2021, at 15:39, Luca Fancellu <luca.fancellu@xxxxxxx> wrote:
> 
> Hi Jason,
> 
> Thanks for your hints, unfortunately seems not an init problem because in the 
> same init configuration I tried the 5.10.23 (preempt_rt) without the Juergen 
> patch but with the BUG_ON removed and it boots without problem. So seems that 
> applying the serie does something (on a preempt_rt kernel) and we are trying 
> to figure out what.
> 
> 
>> On 23 Mar 2021, at 12:36, Jason Andryuk <jandryuk@xxxxxxxxx> wrote:
>> 
>> On Mon, Mar 22, 2021 at 3:09 PM Luca Fancellu <luca.fancellu@xxxxxxx> wrote:
>>> 
>>> Hi Juergen,
>>> 
>>> Yes you are right it was my mistake, as you said to remove the BUG_ON(…) 
>>> this serie 
>>> (https://patchwork.kernel.org/project/xen-devel/cover/20210306161833.4552-1-jgross@xxxxxxxx/)
>>>  is needed, since I’m using yocto I’m able to build a preempt_rt kernel up 
>>> to the 5.10.23 and for this reason I’m applying that serie on top of this 
>>> version, then I’m removing the BUG_ON(…).
>>> 
>>> A thing that was not expected is that now the Dom0 kernel is stuck on 
>>> “Setting domain 0 name, domid and JSON config…” step and the system seems 
>>> unresponsive. Seems like a deadlock issue but looking into the serie we 
>>> can’t spot anything and that serie was also tested by others from the 
>>> community.
>>> Do you have any idea on that?
>> 
>> I think this can happen if xenstored isn't running.  Client access to
>> xenstore blocks until xenstored becomes available.  So check your init
>> scripts ordering.
>> 
>> Regards,
>> Jason
> 
> Cheers,
> Luca

Cheers,
Luca


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.