From: "Kowalsky, Clara" <clara.kowalsky@siemens.com>
To: JerryJun <jerryjun123@163.com>, "Kiszka, Jan" <jan.kiszka@siemens.com>
Cc: xenomai <xenomai@lists.linux.dev>
Subject: Re: Re:Re: NX-protected page
Date: Wed, 10 Apr 2024 07:46:48 +0000 [thread overview]
Message-ID: <AS5PR10MB817389FE4D3AE120BC80E6D393062@AS5PR10MB8173.EURPRD10.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <40cc100b.12313.18de5d67bf5.Coremail.jerryjun123@163.com>
Hi,
just so you know, we're looking at this issue.
Which cmdline did you use? Was xenomai.supported_cpus set?
In the meantime, if you have more information or if you have been able to create a simplified application where the bug still occurs, please let us know.
Best
Clara
> -----Original Message-----
> From: JerryJun <jerryjun123@163.com>
> Sent: Montag, 26. Februar 2024 15:34
> To: Kiszka, Jan (T CED) <jan.kiszka@siemens.com>
> Cc: xenomai <xenomai@lists.linux.dev>
> Subject: Re:Re: NX-protected page
>
> hi, Jan, if you have reproducted it after trying to run the case for hours in
> qemu？ or is there any doubt？
>
> 2024-02-02 16:37:59, "Jan Kiszka" <jan.kiszka@siemens.com> wrote:
> >On 02.02.24 08:49, JerryJun wrote:
> >>
> >> how long did you run it？it will take a while for this crash but not more than
> 12 hours at mostly.
> >> ok，i will try to run it without get /proc…… thank you very much.
> >>
> >
> >Not for hours, but one setup was running for about 30 min. at least.
> >
> >Jan
> >
> >>
> >> At 2024-02-02 14:49:53, "Jan Kiszka" <jan.kiszka@siemens.com> wrote:
> >>> On 01.02.24 08:09, Jan Kiszka wrote:
> >>>> On 31.01.24 08:25, JerryJun wrote:
> >>>>> yet， you just do make in the project to product the binary of oop-test,
> run kill_test.sh , and finally wait kernel oop .
> >>>>> we get the same results of kernel oop in the qemu-amd64, which use
> the config from xenomai-images
> ,"https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsou
> rce.denx.de%2FXenomai%2Fxenomai-images%2F-
> %2Fblob%2Fmaster%2Frecipes-
> kernel%2Flinux%2Ffiles%2Famd64_defconfig%3Fref_type%3Dheads&data=0
> 5%7C02%7Cclara.kowalsky%40siemens.com%7C494bca636f6c48566cc208d
> c36d843eb%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C6384
> 45549672638180%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
> AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&s
> data=xOckYYYOkjKZ3yKchy4B7kkX2eth%2Bqe88Mrd7XjldFw%3D&reserved=
> 0", as follow.
> >>>>> [ 6191.671953] BUG: kernel NULL pointer dereference, address:
> >>>>> 0000000000000000 [ 6191.671955] #PF: supervisor instruction fetch
> >>>>> in kernel mode [ 6191.671956] #PF: error_code(0x0010) -
> >>>>> not-present page [ 6191.671956] PGD 0 P4D 0 [ 6191.671958] Oops:
> >>>>> 0010 [#1] PREEMPT SMP PTI IRQ_PIPELINE [ 6191.671959] CPU: 3 PID:
> >>>>> 7047 Comm: oop-test Kdump: loaded Not tainted
> >>>>> 5.10.199-devo-3.2.4-20240130 #1 [ 6191.671960] Hardware name:
> QEMU
> >>>>> Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 [
> >>>>> 6191.671961] IRQ stage: Linux [ 6191.671961] RIP: 0010:0x0 [
> >>>>> 6191.671962] Code: Unable to access opcode bytes at RIP
> 0xffffffffffffffd6.
> >>>>> [ 6191.671962] RSP: 0018:ffffc90000118f80 EFLAGS: 00010246 [
> >>>>> 6191.671963] RAX: 0000000000000000 RBX: ffff888108d3d730 RCX:
> >>>>> 0000000000000000 [ 6191.671964] RDX: ffff888108d3d738 RSI:
> >>>>> ffffffff82516284 RDI: ffff888108d3d730 [ 6191.671965] RBP:
> >>>>> 0000000000000000 R08: 0000000000000000 R09:
> 0000000000000001 [
> >>>>> 6191.671965] R10: 0000000000000000 R11: 0000000000000001
> R12:
> >>>>> 0000000000000000 [ 6191.671966] R13: 0000000000000018 R14:
> >>>>> ffffffff811d37e0 R15: 0000000000000000 [ 6191.671967] FS:
> >>>>> 00007fc6e83ea780(0000) GS:ffff88813bd80000(0000)
> >>>>> knlGS:0000000000000000 [ 6191.671967] CS: 0010 DS: 0000 ES:
> 0000 CR0: 0000000080050033 [ 6191.671968] CR2: ffffffffffffffd6 CR3:
> 0000000106750005 CR4: 0000000000170ee0 [ 6191.671968] Call Trace:
> >>>>> [ 6191.671968] <IRQ>
> >>>>> [ 6191.671969] ? show_trace_log_lvl+0x1c2/0x2c9 [ 6191.671969] ?
> >>>>> irq_work_single+0x42/0x80 [ 6191.671969] ?
> >>>>> __die_body.cold+0x8/0xd [ 6191.671970] ? no_context+0x13a/0x270
> [
> >>>>> 6191.671970] ? exc_page_fault+0x6f/0x200 [ 6191.671970] ?
> >>>>> asm_exc_page_fault+0x1e/0x30 [ 6191.671970] ?
> >>>>> handle_oob_irq+0x90/0x90 [
> 6191.671971] irq_work_single+0x42/0x80
> >>>>> [ 6191.671971] irq_work_run_list+0x2d/0x40 [ 6191.671971]
> >>>>> irq_work_run+0x26/0x40 [ 6191.671972]
> >>>>> inband_work_interrupt+0xa/0x20 [ 6191.671972]
> >>>>> handle_synthetic_irq+0xb1/0x210 [ 6191.671972]
> >>>>> asm_call_irq_on_stack+0x12/0x20 [ 6191.671973] </IRQ> [
> >>>>> 6191.671973] arch_do_IRQ_pipelined+0x15d/0x2a0 [ 6191.671973]
> >>>>> sync_current_irq_stage+0x157/0x1f0
> >>>>> [ 6191.671974] __inband_irq_enable+0x4b/0x70 [ 6191.671974]
> >>>>> _raw_spin_unlock_irqrestore+0x35/0x70
> >>>>> [ 6191.671974] __set_cpus_allowed_ptr+0xbf/0x230 [
> 6191.671975]
> >>>>> sched_setaffinity+0x383/0x6b0 [ 6191.671975]
> >>>>> __x64_sys_sched_setaffinity+0x45/0x80
> >>>>> [ 6191.671975] do_syscall_64+0x39/0x50 [ 6191.671978]
> >>>>> entry_SYSCALL_64_after_hwframe+0x62/0xc7
> >>>>> [ 6191.671979] RIP: 0033:0x7fc6e84d6617 [ 6191.671979] Code: 1f
> 40
> >>>>> 00 48 8b 15 79 c8 0e 00 f7 d8 41 b9 ff ff ff ff 64 89 02 44 89 c8
> >>>>> c3 66 2e 0f 1f 84 00 00 00 00 00 b8 cb 00 00 00 0f 05 <48> 3d 00
> >>>>> f0 ff ff 77 29 41 89 c0 83 f8 ff 74 18 64 c7 04 25 38 00 [
> >>>>> 6191.671980] RSP: 002b:00007ffd574dfde8 EFLAGS: 00000206
> ORIG_RAX:
> >>>>> 00000000000000cb [ 6191.671981] RAX: ffffffffffffffda RBX:
> >>>>> 00007fc6e7b985c8 RCX: 00007fc6e84d6617 [ 6191.671982] RDX:
> >>>>> 00007fc6e7b985f0 RSI: 0000000000000080 RDI:
> 0000000000001b8d [
> >>>>> 6191.671982] RBP: 00007ffd574dfe70 R08: 00007fc6e83ea780 R09:
> 00000000ffffffff [ 6191.671983] R10: fffffffffffffdca R11:
> 0000000000000206 R12: 000055a818eb61c0 [ 6191.671983] R13:
> 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [
> 6191.671984] Modules linked in:
> >>>>> [ 6191.671985] CR2: 0000000000000000
> >>>>>
> >>>>
> >>>> Okay... that is "good" news - looking for some time slot to
> >>>> reproduce and debug myself now.
> >>>>
> >>>
> >>> I've tried to reproduce, using the .config.yaml below for
> >>> xenomai-images, but it does not trigger here. Do I need to run this
> >>> for hours? What exactly did you do to trigger it in the qemu image
> >>> of xenomai-images?
> >>>
> >>> BTW, I assume the access of /proc/xenomai/sched/stat plays an
> >>> important role in causing the crash, right? You don't get it without them?
> >>>
> >>> Jan
> >>>
> >>> #
> >>> # Automatically generated by kas 4.2 #
> >>> _source_dir: /repo
> >>> build_system: isar
> >>> header:
> >>> includes:
> >>> - kas.yml
> >>> - board-qemu-amd64.yml
> >>> - opt-linux-latest-5.10.yml
> >>> version: 16
> >>> menu_configuration:
> >>> DEBUG: false
> >>> KERNEL_4_19: false
> >>> KERNEL_4_19_LATEST: false
> >>> KERNEL_5_10: false
> >>> KERNEL_5_10_LATEST: true
> >>> KERNEL_5_15: false
> >>> KERNEL_5_15_LATEST: false
> >>> KERNEL_5_4: false
> >>> KERNEL_5_4_LATEST: false
> >>> KERNEL_6_1: false
> >>> KERNEL_6_1_LATEST: false
> >>> TARGET_BBB: false
> >>> TARGET_HIKEY: false
> >>> TARGET_QEMU_AMD64: true
> >>> TARGET_QEMU_ARM: false
> >>> TARGET_QEMU_ARM64: false
> >>> TARGET_X86_64_EFI: false
> >>> XENOMAI3: true
> >>> XENOMAI4: false
> >>> XENOMAI_3_0_LATEST: false
> >>> XENOMAI_3_1_LATEST: false
> >>> XENOMAI_3_2: true
> >>> XENOMAI_3_2_LATEST: false
> >>> XENOMAI_LATEST: false
> >>>
> >>> --
> >>> Siemens AG, Technology
> >>> Linux Expert Center
> >
> >--
> >Siemens AG, Technology
> >Linux Expert Center
next prev parent reply other threads:[~2024-04-10 7:46 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-22 3:10 NX-protected page JerryJun
2024-01-25 9:50 ` Jan Kiszka
2024-01-31 7:25 ` JerryJun
2024-02-01 7:09 ` Jan Kiszka
2024-02-02 6:49 ` Jan Kiszka
2024-02-02 7:49 ` JerryJun
2024-02-02 8:37 ` Jan Kiszka
2024-02-02 10:03 ` JerryJun
2024-02-26 14:34 ` JerryJun
2024-04-10 7:46 ` Kowalsky, Clara [this message]
2024-04-15 23:37 ` JerryJun
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AS5PR10MB817389FE4D3AE120BC80E6D393062@AS5PR10MB8173.EURPRD10.PROD.OUTLOOK.COM \
--to=clara.kowalsky@siemens.com \
--cc=jan.kiszka@siemens.com \
--cc=jerryjun123@163.com \
--cc=xenomai@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.