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.fance...@arm.com> 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 <jandr...@gmail.com> wrote: >> >> On Mon, Mar 22, 2021 at 3:09 PM Luca Fancellu <luca.fance...@arm.com> 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-jgr...@suse.com/) >>> 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
