RE: ipipe 4.19: spurious APIC interrupt when setting rt_igp to up
> -Original Message- > From: Jan Kiszka > Sent: Dienstag, 9. Juli 2019 19:54 > To: Lange Norbert ; Xenomai > (xenomai@xenomai.org) ; Philippe Gerum > > Subject: Re: ipipe 4.19: spurious APIC interrupt when setting rt_igp to up > > E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE > EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR > ATTACHMENTS. > > > On 09.07.19 18:33, Jan Kiszka wrote: > > On 09.07.19 18:21, Lange Norbert wrote: > >> Hello, > >> > >> maxcpus=1 still causes the spurious int, this time fully locking up. > >> > >> I attached the debug/irq directory after the cause. > >>> Some things that might be relevant: > >> - the SOC would use PINCTRL_BROXTON under linux, but this is disabled > (not fixed up for Xenomai) > >> - I have the regular igb driver in use, and am unbinding the network card > prior to binding the rt_igp driver > >> > > > > Thanks. What's the interrupt number that Xenomai is using? Should be > > the same that the Linux driver is using as well. > > Found already: Should be IRQ 130-132 for device 00:03.0. If the directory > state was like that while Xenomai was still holding those interrupts, the > problem it that there are no vectors assigned to them. Can you confirm that > rt_igb was still loaded and the interface was up? Well, the bug happens when bringing up the interface. # modprobe rt_igb [ 117.274639] rt_igb :03:00.0: Intel(R) Gigabit Ethernet Network Connection [ 117.281800] rt_igb :03:00.0: enp3s0: (PCIe:2.5Gb/s:Width x1) 22:20:47:8d:0f:c9 [ 117.289397] rt_igb :03:00.0: enp3s0: PBA No: FF-0FF [ 117.294997] rt_igb :03:00.0: Using MSI-X interrupts. 1 rx queue(s), 1 tx queue(s) [ 117.303500] [Xenomai] HIPASE PPS on SDP0 [ 117.307529] sdhci-pci :00:1b.0: SDHCI controller found [8086:5aca] (rev b) # rtifconfig enp3s0 up [ 166.503855] spurious APIC interrupt through vector ff on CPU#0, should never happen. > Are those interrupts MSI or MSI-X? Can't read that from the logs. MSI-X from the kernel log. > > I probably need to get some rt_igb running somewhere... > > Jan > > -- > Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate > Competence Center Embedded Linux This message and any attachments are solely for the use of the intended recipients. They may contain privileged and/or confidential information or other information protected from disclosure. If you are not an intended recipient, you are hereby notified that you received this email in error and that any review, dissemination, distribution or copying of this email and any attachment is strictly prohibited. If you have received this email in error, please contact the sender and delete the message and any attachment from your system. ANDRITZ HYDRO GmbH Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / Corporation Firmensitz/ Registered seat: Wien Firmenbuchgericht/ Court of registry: Handelsgericht Wien Firmenbuchnummer/ Company registration: FN 61833 g DVR: 0605077 UID-Nr.: ATU14756806 Thank You
RE: Best way to detect if a filedescriptor is a cobalt filedescriptor (/socket)
> -Original Message- > From: Jan Kiszka > Sent: Mittwoch, 10. Juli 2019 08:13 > To: Lange Norbert ; Xenomai > (xenomai@xenomai.org) ; Philippe Gerum > > Subject: Re: Best way to detect if a filedescriptor is a cobalt filedescriptor > (/socket) > > E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE > EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR > ATTACHMENTS. > > > On 09.07.19 16:49, Lange Norbert via Xenomai wrote: > > Hi, > > > > I am opening a packetsocket, which is supposed to be realtime. > > Unfortunatly if the rtpacket (rtnet?) module is not loaded, then this will > just silently fall back to a linux packet socket. Then later demote thread > during accesses. > > > > How would I be able to detect this early during startup? I could > __STD(close) the descriptor and check the returncode for EBADF I suppose... > > > > Yeah, looks this is some feature we lost while embedding the RTDM file > descriptor range into the regular Linux space. My scheme does not work either, __STD(close) seems to return 0 for the cobalt fd, But doesn’t seem to do anything beyond that. Note: I am using Philippe's "cobalt: switch hand over status to -ENODEV for non-RTDM fd" patch, so potential it’s a regression of this patch. > We could either add a compile-time or runtime feature to libcobalt that > permits to disable this silent fallback again or introduce alternative open > and > socket implementations that do not expose this behavior. Spontaneously, I > would be in favor or a runtime switch for the existing implementations. I assumed that __RT(open) would call the __cobalt_open function (without fallback), __STD(open) would call libc' open, and __wrap_open would be the only function trying both. Turns out that __wrap and __cobalt are identical, but I don’t understand the reasoning behind it. Norbert This message and any attachments are solely for the use of the intended recipients. They may contain privileged and/or confidential information or other information protected from disclosure. If you are not an intended recipient, you are hereby notified that you received this email in error and that any review, dissemination, distribution or copying of this email and any attachment is strictly prohibited. If you have received this email in error, please contact the sender and delete the message and any attachment from your system. ANDRITZ HYDRO GmbH Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / Corporation Firmensitz/ Registered seat: Wien Firmenbuchgericht/ Court of registry: Handelsgericht Wien Firmenbuchnummer/ Company registration: FN 61833 g DVR: 0605077 UID-Nr.: ATU14756806 Thank You
[Xenomai] c++11 issue
Hi all, I have a problem similar to the one described in https://xenomai.org/pipermail/xenomai/2018-February/038373.html. Compiling with -std=c++11 and adding the headers: #include #include Error extract: In file included from /usr/xenomai/include/xenomai/tunables.h:21:0, from myApplication.cpp: /usr/xenomai/include/boilerplate/tunables.h:72:15: error: variable or field ‘__assign_cpu_affinity_config’ declared void static inline define_config_tunable(cpu_affinity, cpu_set_t, cpus) ^ /usr/xenomai/include/boilerplate/tunables.h:72:15: error: expected primary-expression before ‘)’ token static inline define_config_tunable(cpu_affinity, cpu_set_t, cpus) ... Do you have any ideas how to solve the issue? I noticed that there is no answer for the previous mail. Thank you in advance and best regards, Cristina. System configuration: Xenomai 3.0.9 Core Mercury CentOS 7.4
[PATCH] boilerplate: Fix bogus "typeof(type)" in macros
From: Jan Kiszka This was ignored by most compilers so far, but it breaks at least under c++11. Reported-by: Stéphane Ancelot Reported-by: Cris Almaraz Signed-off-by: Jan Kiszka --- Thanks for reporting (and sorry for the long patch delay). This should fix it. include/boilerplate/tunables.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/boilerplate/tunables.h b/include/boilerplate/tunables.h index db8523be67..38f414e455 100644 --- a/include/boilerplate/tunables.h +++ b/include/boilerplate/tunables.h @@ -37,10 +37,10 @@ static inline int __may_change_config_tunable(void) __read_ ## __name ## _ ## __scope #define __define_tunable(__name, __type, __val, __scope) \ - void __tunable_set_call(__name, __scope)(typeof(__type) __val) + void __tunable_set_call(__name, __scope)(__type __val) #define __read_tunable(__name, __type, __scope)\ - typeof(__type) __tunable_get_call(__name, __scope)(void) + __type __tunable_get_call(__name, __scope)(void) #define define_config_tunable(__name, __type, __val) \ __define_tunable(__name, __type, __val, config) -- 2.16.4
AW: use of posix function clock_gettime
> First of all, all in-kernel APIs have been deprecated and removed in favor of > RTDM driver APIs. However, RTDM does not expose this clock directly. You can > only do rtdm_clock_read (realtime) or rtdm_clock_read_monotonic(). This was also my recognising after reading the code and the information was not really new. Anyway in meantime I have found a workaround/ solution for our problem. >We could add a host_realtime API to RTDM if there is a good use case. And that >would include a reason why the timestamp adjustment (monotonic -> >host-realtime) cannot be done in the userspace application that consumes the >driver data. >From my point of view make this always sense if a measurement value needs an >accurate Timestamp by the creating. The other applications which could need >this are fieldbus application. Our measurement system gets her measurement value in the Kernel-Space in a Xenomia-IRQ and in this case was the old Functionality very smart. A new Functionality RTDM_ host_realtime would be close this gap and would by also make the RTDM Clock-service completely. Mario HBK
Re: [PATCH] boilerplate: Fix bogus "typeof(type)" in macros
On 7/10/19 9:39 PM, Jan Kiszka via Xenomai wrote:
> From: Jan Kiszka
>
> This was ignored by most compilers so far, but it breaks at least under
> c++11.
This was hardly ignored since this evaluates to a required type
information, the issue is rather with typeof() belonging to the GNU
extension set. Building with -std=gnu++11 solves that issue with the
current implementation which generally assumes those extensions are enabled.
>
> Reported-by: Stéphane Ancelot
> Reported-by: Cris Almaraz
> Signed-off-by: Jan Kiszka
> ---
>
> Thanks for reporting (and sorry for the long patch delay). This should
> fix it.
>
> include/boilerplate/tunables.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/boilerplate/tunables.h b/include/boilerplate/tunables.h
> index db8523be67..38f414e455 100644
> --- a/include/boilerplate/tunables.h
> +++ b/include/boilerplate/tunables.h
> @@ -37,10 +37,10 @@ static inline int __may_change_config_tunable(void)
> __read_ ## __name ## _ ## __scope
>
> #define __define_tunable(__name, __type, __val, __scope) \
> - void __tunable_set_call(__name, __scope)(typeof(__type) __val)
> + void __tunable_set_call(__name, __scope)(__type __val)
>
> #define __read_tunable(__name, __type, __scope) \
> - typeof(__type) __tunable_get_call(__name, __scope)(void)
> + __type __tunable_get_call(__name, __scope)(void)
>
> #define define_config_tunable(__name, __type, __val) \
> __define_tunable(__name, __type, __val, config)
> --
That won't work with non-trivial type expr like this one:
int (*foo_handler)(void);
define_config_tunable(foobar, int (*)(void), handler)
{
foo_handler = handler;
}
And we have those in the field already.
--
Philippe.
Re: ipipe 4.19: spurious APIC interrupt when setting rt_igp to up
On 09.07.19 19:54, Jan Kiszka wrote: > On 09.07.19 18:33, Jan Kiszka wrote: >> On 09.07.19 18:21, Lange Norbert wrote: >>> Hello, >>> >>> maxcpus=1 still causes the spurious int, this time fully locking up. >>> >>> I attached the debug/irq directory after the cause. >>>> Some things that might be relevant: >>> - the SOC would use PINCTRL_BROXTON under linux, but this is disabled >>> (not fixed up for Xenomai) >>> - I have the regular igb driver in use, and am unbinding the network card >>> prior to binding the rt_igp driver >>> >> >> Thanks. What's the interrupt number that Xenomai is using? Should be the same >> that the Linux driver is using as well. > > Found already: Should be IRQ 130-132 for device 00:03.0. If the directory > state > was like that while Xenomai was still holding those interrupts, the problem it > that there are no vectors assigned to them. Can you confirm that rt_igb was > still loaded and the interface was up? > > Are those interrupts MSI or MSI-X? Can't read that from the logs. > > I probably need to get some rt_igb running somewhere... > Still no luck, even on a box with a igb-driven NIC (I350): [ 667.928036] rt_igb :06:00.1: Intel(R) Gigabit Ethernet Network Connection [ 667.928064] rt_igb :06:00.1: rteth0: (PCIe:5.0Gb/s:Width x4) 00:25:90:5d:10:19 [ 667.928149] rt_igb :06:00.1: rteth0: PBA No: 010A00-000 [ 667.928153] rt_igb :06:00.1: Using MSI-X interrupts. 1 rx queue(s), 1 tx queue(s) xeon-d:~ # cat /proc/xenomai/irq IRQ CPU0...CPU15 47: 0... 79 rteth0-TxRx-0 I'm currently using the two attached patches on top of ipipe-core-4.19.57-x86-3. Did you cross-check if the running kernel contains the fix(es)? Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux -- next part -- A non-text attachment was scrubbed... Name: 0001-ipipe-Activate-IRQ-in-ipipe_enable_irq.patch Type: text/x-patch Size: 1011 bytes Desc: not available URL: <http://xenomai.org/pipermail/xenomai/attachments/20190710/55e16f8f/attachment.bin> -- next part -- A non-text attachment was scrubbed... Name: 0002-x86-ipipe-Make-sure-IRQs-are-active-when-setting-aff.patch Type: text/x-patch Size: 1391 bytes Desc: not available URL: <http://xenomai.org/pipermail/xenomai/attachments/20190710/55e16f8f/attachment-0001.bin>
Re: [PATCH] boilerplate: Fix bogus "typeof(type)" in macros
On 10.07.19 22:50, Philippe Gerum wrote:
> On 7/10/19 9:39 PM, Jan Kiszka via Xenomai wrote:
>> From: Jan Kiszka
>>
>> This was ignored by most compilers so far, but it breaks at least under
>> c++11.
>
> This was hardly ignored since this evaluates to a required type
> information, the issue is rather with typeof() belonging to the GNU
> extension set. Building with -std=gnu++11 solves that issue with the
> current implementation which generally assumes those extensions are enabled.
If these two cases are the only ones that prevent standard-conforming builds ouf
our external headers, I would be in favor of overcoming that limitation. But if
it should be just the tip of the iceberg, it's likely not worth it.
>
>>
>> Reported-by: Stéphane Ancelot
>> Reported-by: Cris Almaraz
>> Signed-off-by: Jan Kiszka
>> ---
>>
>> Thanks for reporting (and sorry for the long patch delay). This should
>> fix it.
>>
>> include/boilerplate/tunables.h | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/boilerplate/tunables.h b/include/boilerplate/tunables.h
>> index db8523be67..38f414e455 100644
>> --- a/include/boilerplate/tunables.h
>> +++ b/include/boilerplate/tunables.h
>> @@ -37,10 +37,10 @@ static inline int __may_change_config_tunable(void)
>> __read_ ## __name ## _ ## __scope
>>
>> #define __define_tunable(__name, __type, __val, __scope)\
>> -void __tunable_set_call(__name, __scope)(typeof(__type) __val)
>> +void __tunable_set_call(__name, __scope)(__type __val)
>>
>> #define __read_tunable(__name, __type, __scope) \
>> -typeof(__type) __tunable_get_call(__name, __scope)(void)
>> +__type __tunable_get_call(__name, __scope)(void)
>>
>> #define define_config_tunable(__name, __type, __val)\
>> __define_tunable(__name, __type, __val, config)
>> --
>
>
> That won't work with non-trivial type expr like this one:
>
> int (*foo_handler)(void);
>
> define_config_tunable(foobar, int (*)(void), handler)
> {
> foo_handler = handler;
> }
>
> And we have those in the field already.
>
Out of tree? I didn't find any in-tree build issues.
Jan
[PATCH 1/2] demo/alchemy/altency: Use sigdebug_reason()
Since cobalt adds 0xfccf to si_value we can no longer
use the raw value.
Signed-off-by: Richard Weinberger
---
demo/alchemy/altency.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/demo/alchemy/altency.c b/demo/alchemy/altency.c
index 83cc806b5d7f..4b49755edaba 100644
--- a/demo/alchemy/altency.c
+++ b/demo/alchemy/altency.c
@@ -461,7 +461,7 @@ static void sigdebug(int sig, siginfo_t *si, void *context)
{
const char fmt[] = "%s, aborting.\n"
"(enabling CONFIG_XENO_OPT_DEBUG_TRACE_RELAX may help)\n";
- unsigned int reason = si->si_value.sival_int;
+ unsigned int reason = sigdebug_reason(si);
int n __attribute__ ((unused));
static char buffer[256];
--
2.16.4
[PATCH 2/2] alchemy/mutex: Fix typo in comment
s/rt_mutex_acquite/rt_mutex_acquire
Signed-off-by: Richard Weinberger
---
lib/alchemy/mutex.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/alchemy/mutex.c b/lib/alchemy/mutex.c
index ffdc2dbea323..42cd1375b34b 100644
--- a/lib/alchemy/mutex.c
+++ b/lib/alchemy/mutex.c
@@ -182,7 +182,7 @@ out:
*
* - -EBUSY is returned upon an attempt to destroy the object
* referenced by @a mutex while it is referenced (for example, while
- * being used in a rt_mutex_acquite(), rt_mutex_acquire_timed() or
+ * being used in a rt_mutex_acquire(), rt_mutex_acquire_timed() or
* rt_mutex_acquire_until() by another task).
*
* @apitags{mode-unrestricted, switch-secondary}
--
2.16.4
[PATCH v2] boilerplate: Fix non-conforming usage of typeof in interface, headers
From: Jan Kiszka This fixes build breakages when using standard-conforming build, e.g. -std=c++11. Reported-by: Stéphane Ancelot Reported-by: Cris Almaraz Signed-off-by: Jan Kiszka --- This should make everyone happy. include/boilerplate/tunables.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/boilerplate/tunables.h b/include/boilerplate/tunables.h index db8523be67..397ffc8939 100644 --- a/include/boilerplate/tunables.h +++ b/include/boilerplate/tunables.h @@ -37,10 +37,10 @@ static inline int __may_change_config_tunable(void) __read_ ## __name ## _ ## __scope #define __define_tunable(__name, __type, __val, __scope) \ - void __tunable_set_call(__name, __scope)(typeof(__type) __val) + void __tunable_set_call(__name, __scope)(__typeof__(__type) __val) #define __read_tunable(__name, __type, __scope)\ - typeof(__type) __tunable_get_call(__name, __scope)(void) + __typeof__(__type) __tunable_get_call(__name, __scope)(void) #define define_config_tunable(__name, __type, __val) \ __define_tunable(__name, __type, __val, config) -- 2.16.4
Enable/Disable of ftrace events crashes kernel
Hi! I can reliable kill Linux on qemu by writing a few times 1 and 0 to /sys/kernel/debug/tracing/events/cobalt_core/enable Didn't test on real hardware so far. The following splat happened on ipipe-core-4.19.57-x86-3 plus xenomai-git as of today. [ 33.664656] Kernel panic - not syncing: Machine halted. [ 33.665323] CPU: 2 PID: 2088 Comm: bash Not tainted 4.19.57 #1 [ 33.666142] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.0-0-g63451fc-prebuilt.qemu-project.org 04/01/2014 [ 33.667524] I-pipe domain: Linux [ 33.667895] Call Trace: [ 33.668354] <#DF> [ 33.668695] dump_stack+0x8e/0xb3 [ 33.669104] panic+0xdd/0x238 [ 33.669456] df_debug+0x24/0x30 [ 33.669834] do_double_fault+0x95/0x120 [ 33.670323] double_fault+0x3f/0x60 [ 33.670794] RIP: 0010:xnintr_core_clock_handler+0xad/0x370 [ 33.671426] Code: c0 48 09 c2 49 89 96 80 1a 00 00 49 8d ae 88 1a 00 00 48 8d 59 08 48 87 5d 00 48 c7 c0 d0 e3 02 00 48 83 01 01 cc 1f 44 00 00 <41> 8b 86 10 03 00 00 49 81 4e 08 00 40 00 00 83 c0 01 41 89 86 10 [ 33.673615] RSP: 0018:964ebbb03f58 EFLAGS: 00010002 [ 33.674235] RAX: 0002e3d0 RBX: 964ebbb315c0 RCX: 964ebbb3bb00 [ 33.675079] RDX: 0013d41dbbce RSI: fc25fc34 RDI: 964ebbb315c0 [ 33.675923] RBP: 964ebbb31748 R08: 964ebb000249 R09: 0002e320 [ 33.676761] R10: 0040 R11: R12: 0002 [ 33.677600] R13: 0002fcc0 R14: 964ebbb2fcc0 R15: 964ebbb2fcc0 [ 33.678444] [ 33.678704] [ 33.678955] dispatch_irq_head+0x84/0x110 [ 33.679437] __ipipe_handle_irq+0x7c/0x1d0 [ 33.679927] apic_timer_interrupt+0x12/0x40 [ 33.680448] [ 33.680805] RIP: 0010:smp_call_function_many+0x1e0/0x250 [ 33.681505] Code: 5f 97 00 3b 05 d5 70 47 01 0f 83 99 fe ff ff 48 63 c8 48 8b 13 48 03 14 cd 00 b7 c9 ac 8b 4a 18 83 e1 01 74 0a f3 90 8b 4a 18 <83> e1 01 75 f6 eb c8 48 c7 c2 20 b9 f5 ac 48 89 ee 89 df e8 b8 5f [ 33.684312] RSP: 0018:a2478079bc00 EFLAGS: 0202 ORIG_RAX: ff13 [ 33.685347] RAX: 0001 RBX: 964ebbb35a00 RCX: 0003 [ 33.686198] RDX: 964ebbab9c80 RSI: RDI: 964ebbb35a08 [ 33.687044] RBP: 964ebbb35a08 R08: 000b R09: aba22300 [ 33.687883] R10: a2478079bc20 R11: f000 R12: aba22200 [ 33.688725] R13: R14: 0001 R15: 0040 [ 33.689577] ? optimize_nops+0xe0/0xe0 [ 33.690055] ? alternatives_text_reserved+0x60/0x60 [ 33.690643] ? optimize_nops+0xe0/0xe0 [ 33.691092] ? xnintr_core_clock_handler+0xa9/0x370 [ 33.691657] ? trace_event_raw_event_irq_event+0xa0/0xa0 [ 33.692489] on_each_cpu+0x23/0x50 [ 33.692902] ? xnintr_core_clock_handler+0xa8/0x370 [ 33.693464] text_poke_bp+0x63/0xe0 [ 33.693875] __jump_label_transform.isra.0+0x12f/0x140 [ 33.694466] arch_jump_label_transform+0x26/0x40 [ 33.695093] __jump_label_update+0x78/0xb0 [ 33.695567] static_key_slow_inc_cpuslocked+0x83/0x90 [ 33.696147] static_key_slow_inc+0x11/0x20 [ 33.696622] tracepoint_probe_register_prio+0x214/0x290 [ 33.697241] __ftrace_event_enable_disable+0x96/0x260 [ 33.697905] __ftrace_set_clr_event_nolock+0xe8/0x130 [ 33.698488] system_enable_write+0xb3/0xf0 [ 33.698537] BUG: Unhandled exception over domain Xenomai at 0xabb5413d - switching to ROOT [ 33.699032] __vfs_write+0x31/0x180 [ 33.700443] ? selinux_file_permission+0x118/0x130 [ 33.700979] ? security_file_permission+0x27/0xb0 [ 33.701491] vfs_write+0xa8/0x190 [ 33.701856] ksys_write+0x55/0xd0 [ 33.702220] do_syscall_64+0x64/0x160 [ 33.702644] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 33.703210] RIP: 0033:0x7fcc38f5bd04 [ 33.703603] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 80 00 00 00 00 8b 05 2a fb 2c 00 48 63 ff 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 55 53 48 89 d5 48 89 f3 48 83 [ 33.705712] RSP: 002b:7ffd5b051008 EFLAGS: 0246 ORIG_RAX: 0001 [ 33.706673] RAX: ffda RBX: 0002 RCX: 7fcc38f5bd04 [ 33.707552] RDX: 0002 RSI: 564c21421700 RDI: 0001 [ 33.708399] RBP: 564c21421700 R08: 000a R09: [ 33.709264] R10: 000a R11: 0246 R12: 0002 [ 33.710197] R13: 0001 R14: 7fcc39227720 R15: 0002 [ 33.711080] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.19.57 #1 [ 33.711974] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.0-0-g63451fc-prebuilt.qemu-project.org 04/01/2014 [ 33.715226] I-pipe domain: Linux [ 33.715730] Call Trace: [ 33.716176] <#DF> [ 33.716529] dump_stack+0x8e/0xb3 [ 33.717053] __ipipe_trap_prologue+0x1cd/0x220 [ 33.717578] double_fault+0x24/0x60 [ 33.717993] RIP: 0010:xnintr_core_clock_handler+0xad/0x370 [ 33.718672] C
