crash on accessing /proc/xenomai/sched/Â

crash on accessing /proc/xenomai/sched/Â

[Lowell Gilbert]

I was trying to update to 3.0.8, and looking at stat or acct in the
sched branch of the proc tree gives me an instant kernel crash, usually
with a null pointer access from a bogus code address, although the
locations aren't always the same. This is without even having my kernel
module or application loaded.

The system is a dual-core Cortex-A9.

Any idea what might be going on? Details follow.

[  121.205418] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[  121.213493] pgd = ee7e0000
[  121.216198] [00000000] *pgd=3f8ff831
[  121.219787] Internal error: Oops: 80000007 [#1] SMP ARM
[  121.225000] Modules linked in:
[  121.228066] CPU: 0 PID: 1113 Comm: cat Not tainted 4.14.73-ltsi-09035-gb67570c09362-dirty #2
[  121.236474] Hardware name: Altera SOCFPGA
[  121.240475] I-pipe domain: Linux
[  121.243699] task: ef302e00 task.stack: ee656000
[  121.248221] PC is at 0x0
[  121.250776] LR is at __ipipe_ack_hrtimer_irq+0x48/0x80
[  121.255901] pc : [<00000000>]    lr : [<c01be9cc>]    psr: a0060193
[  121.262149] sp : ee657c60  ip : ee657c60  fp : ee657c74
[  121.267360] r10: 00000001  r9 : 00000012  r8 : ee657ce8
[  121.272571] r7 : 00000011  r6 : 00000000  r5 : ef004900  r4 : ef7c01b0
[  121.279077] r3 : 00000000  r2 : c0c919c0  r1 : 00000001  r0 : ef004900
[  121.285587] Flags: NzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment none
[  121.292786] Control: 10c5387d  Table: 2e7e004a  DAC: 00000051
[  121.298517] Process cat (pid: 1113, stack limit = 0xee656220)

and

[  121.727414] Unable to handle kernel NULL pointer dereference at virtual address 00000024
[  121.735477] pgd = c0004000
[  121.738183] [00000024] *pgd=00000000
[  121.741763] Internal error: Oops: 17 [#2] SMP ARM
[  121.746455] Modules linked in:
[  121.749517] CPU: 0 PID: 1113 Comm: cat Tainted: G      D         4.14.73-ltsi-09035-gb67570c09362-dirty #2
[  121.759134] Hardware name: Altera SOCFPGA
[  121.763133] I-pipe domain: Linux
[  121.766356] task: ef302e00 task.stack: ee656000
[  121.770880] PC is at unmap_page_range+0x6c/0x624
[  121.775488] LR is at unmap_single_vma+0x8c/0x94
[  121.780008] pc : [<c026a678>]    lr : [<c026acbc>]    psr: 20060113
[  121.786255] sp : ee657920  ip : c026a624  fp : ee6579a4
[  121.791464] r10: ee657a08  r9 : c0939688  r8 : 00010000
[  121.796675] r7 : ee657a08  r6 : 00010000  r5 : eea41f00  r4 : 00000001
[  121.803181] r3 : 00000000  r2 : 00000000  r1 : 00018000  r0 : c0ccb3c0
[  121.809689] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
[  121.816800] Control: 10c5387d  Table: 2e7e004a  DAC: 00000051
[  121.822530] Process cat (pid: 1113, stack limit = 0xee656220)
[  121.828259] Stack: (0xee657920 to 0xee658000)

Re: crash on accessing /proc/xenomai/sched/Â

[Jan Kiszka]

On 29.01.19 22:06, Lowell Gilbert via Xenomai wrote:
> I was trying to update to 3.0.8, and looking at stat or acct in the
> sched branch of the proc tree gives me an instant kernel crash, usually
> with a null pointer access from a bogus code address, although the
> locations aren't always the same. This is without even having my kernel
> module or application loaded.
> 
> The system is a dual-core Cortex-A9.
> 
> Any idea what might be going on? Details follow.
> 
> [  121.205418] Unable to handle kernel NULL pointer dereference at virtual address 00000000
> [  121.213493] pgd = ee7e0000
> [  121.216198] [00000000] *pgd=3f8ff831
> [  121.219787] Internal error: Oops: 80000007 [#1] SMP ARM
> [  121.225000] Modules linked in:
> [  121.228066] CPU: 0 PID: 1113 Comm: cat Not tainted 4.14.73-ltsi-09035-gb67570c09362-dirty #2
> [  121.236474] Hardware name: Altera SOCFPGA
> [  121.240475] I-pipe domain: Linux
> [  121.243699] task: ef302e00 task.stack: ee656000
> [  121.248221] PC is at 0x0
> [  121.250776] LR is at __ipipe_ack_hrtimer_irq+0x48/0x80
> [  121.255901] pc : [<00000000>]    lr : [<c01be9cc>]    psr: a0060193
> [  121.262149] sp : ee657c60  ip : ee657c60  fp : ee657c74
> [  121.267360] r10: 00000001  r9 : 00000012  r8 : ee657ce8
> [  121.272571] r7 : 00000011  r6 : 00000000  r5 : ef004900  r4 : ef7c01b0
> [  121.279077] r3 : 00000000  r2 : c0c919c0  r1 : 00000001  r0 : ef004900
> [  121.285587] Flags: NzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment none
> [  121.292786] Control: 10c5387d  Table: 2e7e004a  DAC: 00000051
> [  121.298517] Process cat (pid: 1113, stack limit = 0xee656220)
> 
> and
> 
> [  121.727414] Unable to handle kernel NULL pointer dereference at virtual address 00000024
> [  121.735477] pgd = c0004000
> [  121.738183] [00000024] *pgd=00000000
> [  121.741763] Internal error: Oops: 17 [#2] SMP ARM
> [  121.746455] Modules linked in:
> [  121.749517] CPU: 0 PID: 1113 Comm: cat Tainted: G      D         4.14.73-ltsi-09035-gb67570c09362-dirty #2
> [  121.759134] Hardware name: Altera SOCFPGA
> [  121.763133] I-pipe domain: Linux
> [  121.766356] task: ef302e00 task.stack: ee656000
> [  121.770880] PC is at unmap_page_range+0x6c/0x624
> [  121.775488] LR is at unmap_single_vma+0x8c/0x94
> [  121.780008] pc : [<c026a678>]    lr : [<c026acbc>]    psr: 20060113
> [  121.786255] sp : ee657920  ip : c026a624  fp : ee6579a4
> [  121.791464] r10: ee657a08  r9 : c0939688  r8 : 00010000
> [  121.796675] r7 : ee657a08  r6 : 00010000  r5 : eea41f00  r4 : 00000001
> [  121.803181] r3 : 00000000  r2 : 00000000  r1 : 00018000  r0 : c0ccb3c0
> [  121.809689] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
> [  121.816800] Control: 10c5387d  Table: 2e7e004a  DAC: 00000051
> [  121.822530] Process cat (pid: 1113, stack limit = 0xee656220)
> [  121.828259] Stack: (0xee657920 to 0xee658000)
> 
> 

Does this patch happen to help?

https://gitlab.denx.de/Xenomai/xenomai/commit/02500efff060c293a74fa4c914c19b8e1504b9a3

It's in next only so far but scheduled for stable.

Otherwise: Is your I-pipe patch from upstream or self-developed. I suspect the 
latter as your kernel claims to be LTSI-based.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: crash on accessing /proc/xenomai/sched/Â

[Lowell Gilbert]

Jan Kiszka <jan.kiszka@siemens.com> writes:

> On 29.01.19 22:06, Lowell Gilbert via Xenomai wrote:
>> I was trying to update to 3.0.8, and looking at stat or acct in the
>> sched branch of the proc tree gives me an instant kernel crash, usually
>> with a null pointer access from a bogus code address, although the
>> locations aren't always the same. This is without even having my kernel
>> module or application loaded.
>>
>> The system is a dual-core Cortex-A9.
>
> Does this patch happen to help?
>
> https://gitlab.denx.de/Xenomai/xenomai/commit/02500efff060c293a74fa4c914c19b8e1504b9a3

No. I didn't expect it to: I only hook interrupts with rtdm_irq_request() 

> Otherwise: Is your I-pipe patch from upstream or self-developed. I
> suspect the latter as your kernel claims to be LTSI-based.

I'm just using the  ipipe-core-4.14.71-arm-4.patch, with a couple of
very minor changes related to handling ARM errata. I compared the
original source tree to the official linux-4.14.71 release, and the
differences were minor. I can't seem to reproduce that now, though, so I
applied the official patch against the official linux-4.14.71 tree, and
still see the same panics. I'm going to try that again to make sure I'm
not crazy.

Be well.