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

Re: Dom0 hangs after enable KROBE_EVENTS and/or UPROBE_EVENTS in kernel config

(+ Stefano)

On 21/07/2021 12:44, Oleksii Moisieiev wrote:


Thanks for the report.

I nearly miss this e-mail because the title doesn't suggest this is an Arm and I wasn't CCed. In future, would you be able to CC the Arm maintainers (you can find them in MAINTAINERS) and mention arm in the title?

I've got a problem that Dom0 hangs without any output from kernel once I enable CONFIG_KPROBE_EVENTS and/or CONFIG_UPROBE_EVENTS in dom0 kernel.
Everything works fine when kprobe/uprobe events are disabled.

By disabled, do you mean compile out?

My setup:
Board: H3ULCB Kinfisher board
Xen: revision dba774896f7dd74773c14d537643b7d7477fefcd (stable-4.15) https://github.com/xen-project/xen.git <https://github.com/xen-project/xen.git>;
Kernel: revision 09162bc32c880a791c6c0668ce0745cf7958f576 (v5.10-rc4)

Hmmm... 5.10 was released a few months ago and there are probably a few stable release for the version. Can you try the latest 5.10 stable?

https://github.com/torvalds/linux.git <https://github.com/torvalds/linux.git>;

kernel config: see attached;

dtb: see attached;

Please avoid large attachment as they will be duplicated on every mailbox. Instead, in the future, please upload them somewhere (your own webserve, pastebin...) and provide a link in the e-mail.

If kprobe/uprobe events are enabled - I see no output after xen switched input to Dom0, if disabled - system boots up successfully.
The console subsystem tends to be enabled quite late in the boot process. So this may mean a panic during early boot.

If you haven't done yet, I would suggest to add earlycon=xenboot on the dom0 command line. This will print some messages during early boot.

Both configs work fine when I boot without xen.

Dom0 information from Xen console shows that only one CPU works, and PC stays in "__arch_counter_get_cntvct" function on read_sysreg call. //

I did further investigation and found that kernel 5.4 doesn't have such kind of issues. After bisecting kernel,between 5.10 and 5.4, I found that output disappeared on commit:


From the information you provided so far, I am a bit confused how this could be the source of the problem. But given this is not the latest 5.10, I will wait for you to confirm the bug is still present before providing more input.

Another issue, which was revealed after I got kernel output was kernel oops with message that CPU is in inconsistent state.

[0.415612] EFI services will not be available.

[0.420267] smp: Bringing up secondary CPUs ...

[0.425185] Detected PIPT I-cache on CPU1

[0.425267] Xen: initializing cpu1

[0.425292] CPU1: Booted secondary processor 0x0000000001 [0x411fd073]

[0.425815] Detected PIPT I-cache on CPU2

[0.425879] Xen: initializing cpu2

[0.425899] CPU2: Booted secondary processor 0x0000000002 [0x411fd073]

[0.426362] Detected PIPT I-cache on CPU3

[0.426425] Xen: initializing cpu3

[0.426444] CPU3: Booted secondary processor 0x0000000003 [0x411fd073]

[0.426537] smp: Brought up 1 node, 4 CPUs

[0.472807] SMP: Total of 4 processors activated.

[0.477551] CPU features: detected: 32-bit EL0 Support

[0.482745] CPU features: detected: CRC32 instructions

[0.499470] ------------[ cut here ]------------

[0.504034] CPU: CPUs started in inconsistent modes

Looking at Linux 5.7 code, this is printed when not all the CPUs are booted in the same mode (i.e. EL1 or EL2).

This is quite odd. So let me ask a question first, did you see this error during the bisection or on the latest 5.7?


Julien Grall



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