* Your System ate a SPARC! Gah! in map_pages()
@ 2021-12-05 19:33 John David Anglin
2021-12-05 20:46 ` Helge Deller
0 siblings, 1 reply; 12+ messages in thread
From: John David Anglin @ 2021-12-05 19:33 UTC (permalink / raw)
To: linux-parisc; +Cc: Helge Deller
I'm seeing this on rp3440 fairly frequently. Must have something to do with memory as it
doesn't seem to happen on my c8000.
Freeing initrd memory: 20980K
_______________________________
< Your System ate a SPARC! Gah! >
-------------------------------
\ ^__^
(__)\ )\/\
U ||----w |
|| ||
swapper/0 (pid 1): Protection id trap (code 7)
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.14.21+ #1
Hardware name: 9000/800/rp3440
YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00001000000001101111111100001111 Not tainted
r00-03 000000ff0806ff0f 0000000040bf9180 0000000040ab40b8 000000004b618280
r04-07 0000000040b5c980 0000000000194000 0000000040f8c800 0000000040193000
r08-11 0000000040f90000 0000000000000800 0000000000200000 0000000000100000
r12-15 0000000000e00000 0000000000200000 0000000040b79180 0000000000000001
r16-19 0000000040bf9980 0000000040b79180 0000000000000001 0000000000000000
r20-23 0000000000000008 0000000000000323 0000000000193323 0000000000000323
r24-27 0000000000000001 0000000000000400 0000000040100000 0000000040b5c980
r28-31 0000000040f8fca0 000000004b618250 000000004b618390 0000000040f8e000
sr00-03 0000000000000000 0000000000000000 0000000000000000 0000000000000000
sr04-07 0000000000000000 0000000000000000 0000000000000000 0000000000000000
IASQ: 0000000000000000 0000000000000000 IAOQ: 000000004010765c 0000000040107660
IIR: 43ffff40 ISR: 0000000000000000 IOR: 0000000000000000
CPU: 0 CR30: 000000004b618000 CR31: ffffffffffffffff
ORIG_R28: 000000004b618570
IAOQ[0]: map_pages+0x2fc/0x378
IAOQ[1]: map_pages+0x300/0x378
RP(r2): free_initmem+0xf8/0x210
Backtrace:
[<0000000040ab40b8>] free_initmem+0xf8/0x210
[<0000000040ab3d28>] kernel_init+0xa0/0x338
[<0000000040202020>] ret_from_kernel_thread+0x20/0x28
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.14.21+ #1
Hardware name: 9000/800/rp3440
Backtrace:
[<000000004020a3a0>] show_stack+0x70/0x90
[<0000000040aadf98>] dump_stack_lvl+0xd8/0x128
[<0000000040aae01c>] dump_stack+0x34/0x48
[<000000004020a5e4>] die_if_kernel+0x204/0x430
[<000000004020afd8>] handle_interruption+0x550/0xc78
[<0000000040203080>] intr_check_sig+0x0/0x3c
10574: 43 ff ff 40 ldb 1fa0(sr3,r31),r31
4010765c: bd 1c 3e 7d cmpb,*<> ret0,r8,401075a0 <map_pages+0x240>
40107660: 34 e7 20 00 ldo 1000(r7),r7
0000000040ab3fc0 <free_initmem>:
40ab3fc0: 08 03 02 41 copy r3,r1
40ab3fc4: 0f c2 12 c1 std rp,-10(sp)
40ab3fc8: 08 1e 02 43 copy sp,r3
40ab3fcc: 73 c1 01 68 std,ma r1,b0(sp)
40ab3fd0: 2b 6e a0 00 addil L%9d000,dp,r1
40ab3fd4: 08 01 02 5c copy r1,ret0
40ab3fd8: 2b 6e a0 00 addil L%9d000,dp,r1
40ab3fdc: 70 66 00 50 std r6,28(r3)
40ab3fe0: 50 26 09 00 ldd 480(r1),r6
40ab3fe4: 70 65 00 60 std r5,30(r3)
40ab3fe8: 2b 6e a0 00 addil L%9d000,dp,r1
40ab3fec: 53 85 01 e0 ldd f0(ret0),r5
40ab3ff0: 08 01 02 5c copy r1,ret0
40ab3ff4: 0c 6a 12 d0 std r10,8(r3)
40ab3ff8: 34 1f 00 02 ldi 1,r31
40ab3ffc: 2b 6e 10 00 addil L%1c800,dp,r1
40ab4000: 70 69 00 20 std r9,10(r3)
40ab4004: 34 0a 06 46 ldi 323,r10
40ab4008: 08 06 02 5a copy r6,r26
40ab400c: 70 68 00 30 std r8,18(r3)
40ab4010: 53 88 08 80 ldd 440(ret0),r8
40ab4014: 08 0a 02 57 copy r10,r23
40ab4018: 08 c8 04 18 sub r8,r6,r24
40ab401c: 70 67 00 40 std r7,20(r3)
40ab4020: 50 3c 03 90 ldd 1c8(r1),ret0
40ab4024: 37 dd 3f a1 ldo -30(sp),ret1
40ab4028: 20 e0 08 01 ldil L%-40000000,r7
40ab402c: 70 64 00 70 std r4,38(r3)
40ab4030: 08 e6 0a 19 add,l r6,r7,r25
40ab4034: 08 1b 02 44 copy dp,r4
40ab4038: 0f 9f 12 00 stb r31,0(ret0)
40ab403c: 34 16 00 00 ldi 0,r22
40ab4040: 00 00 14 a1 mfia r1
40ab4044: 28 29 6f ed addil L%-9ad000,r1,r1
40ab4048: 34 21 06 40 ldo 320(r1),r1
40ab404c: e8 20 f0 00 bve,l (r1),rp
40ab4050: 08 a6 04 09 sub r6,r5,r9
40ab4054: 08 e5 0a 07 add,l r5,r7,r7
40ab4058: 08 04 02 5b copy r4,dp
40ab405c: 08 05 02 5a copy r5,r26
40ab4060: 08 09 02 58 copy r9,r24
40ab4064: 08 07 02 59 copy r7,r25
40ab4068: 37 dd 3f a1 ldo -30(sp),ret1
40ab406c: 08 1b 02 44 copy dp,r4
40ab4070: 34 16 00 02 ldi 1,r22
40ab4074: 00 00 14 a1 mfia r1
40ab4078: 28 29 6f ed addil L%-9ad000,r1,r1
40ab407c: 34 21 05 d8 ldo 2ec(r1),r1
40ab4080: e8 20 f0 00 bve,l (r1),rp
40ab4084: 34 17 06 4e ldi 327,r23
40ab4088: 34 16 00 02 ldi 1,r22
40ab408c: 08 0a 02 57 copy r10,r23
40ab4090: 08 04 02 5b copy r4,dp
40ab4094: 08 05 02 5a copy r5,r26
40ab4098: 08 09 02 58 copy r9,r24
40ab409c: 08 07 02 59 copy r7,r25
40ab40a0: 37 dd 3f a1 ldo -30(sp),ret1
40ab40a4: 00 00 14 a1 mfia r1
40ab40a8: 28 29 6f ed addil L%-9ad000,r1,r1
40ab40ac: 34 21 05 78 ldo 2bc(r1),r1
40ab40b0: e8 20 f0 00 bve,l (r1),rp
40ab40b4: 08 1b 02 44 copy dp,r4
40ab40b8: 08 04 02 5b copy r4,dp
Looks like fault occurs in third call to map_pages():
void __ref free_initmem(void)
{
unsigned long init_begin = (unsigned long)__init_begin;
unsigned long init_end = (unsigned long)__init_end;
unsigned long kernel_end = (unsigned long)&_end;
/* Remap kernel text and data, but do not touch init section yet. */
kernel_set_to_readonly = true;
map_pages(init_end, __pa(init_end), kernel_end - init_end,
PAGE_KERNEL, 0);
/* The init text pages are marked R-X. We have to
* flush the icache and mark them RW-
*
* This is tricky, because map_pages is in the init section.
* Do a dummy remap of the data section first (the data
* section is already PAGE_KERNEL) to pull in the TLB entries
* for map_kernel */
map_pages(init_begin, __pa(init_begin), init_end - init_begin,
PAGE_KERNEL_RWX, 1);
/* now remap at PAGE_KERNEL since the TLB is pre-primed to execute
* map_pages */
map_pages(init_begin, __pa(init_begin), init_end - init_begin,
PAGE_KERNEL, 1);
/* force the kernel to see the new TLB entries */
__flush_tlb_range(0, init_begin, kernel_end);
/* finally dump all the instructions which were cached, since the
* pages are no-longer executable */
flush_icache_range(init_begin, init_end);
free_initmem_default(POISON_FREE_INITMEM);
/* set up a new led state on systems shipped LED State panel */
pdc_chassis_send_status(PDC_CHASSIS_DIRECT_BCOMPLETE);
}
Dave
--
John David Anglin dave.anglin@bell.net
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Your System ate a SPARC! Gah! in map_pages()
2021-12-05 19:33 Your System ate a SPARC! Gah! in map_pages() John David Anglin
@ 2021-12-05 20:46 ` Helge Deller
2021-12-05 21:00 ` John David Anglin
2021-12-07 22:07 ` John David Anglin
0 siblings, 2 replies; 12+ messages in thread
From: Helge Deller @ 2021-12-05 20:46 UTC (permalink / raw)
To: John David Anglin, linux-parisc
On 12/5/21 20:33, John David Anglin wrote:
> I'm seeing this on rp3440 fairly frequently. Must have something to do with memory as it
> doesn't seem to happen on my c8000.
>
> Freeing initrd memory: 20980K
> _______________________________
> < Your System ate a SPARC! Gah! >
> -------------------------------
> \ ^__^
> (__)\ )\/\
> U ||----w |
> || ||
> swapper/0 (pid 1): Protection id trap (code 7)
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.14.21+ #1
> Hardware name: 9000/800/rp3440
>
> YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
> PSW: 00001000000001101111111100001111 Not tainted
> r00-03 000000ff0806ff0f 0000000040bf9180 0000000040ab40b8 000000004b618280
> r04-07 0000000040b5c980 0000000000194000 0000000040f8c800 0000000040193000
> r08-11 0000000040f90000 0000000000000800 0000000000200000 0000000000100000
> r12-15 0000000000e00000 0000000000200000 0000000040b79180 0000000000000001
> r16-19 0000000040bf9980 0000000040b79180 0000000000000001 0000000000000000
> r20-23 0000000000000008 0000000000000323 0000000000193323 0000000000000323
> r24-27 0000000000000001 0000000000000400 0000000040100000 0000000040b5c980
> r28-31 0000000040f8fca0 000000004b618250 000000004b618390 0000000040f8e000
> sr00-03 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> sr04-07 0000000000000000 0000000000000000 0000000000000000 0000000000000000
>
> IASQ: 0000000000000000 0000000000000000 IAOQ: 000000004010765c 0000000040107660
> IIR: 43ffff40 ISR: 0000000000000000 IOR: 0000000000000000
> CPU: 0 CR30: 000000004b618000 CR31: ffffffffffffffff
> ORIG_R28: 000000004b618570
> IAOQ[0]: map_pages+0x2fc/0x378
> IAOQ[1]: map_pages+0x300/0x378
> RP(r2): free_initmem+0xf8/0x210
> Backtrace:
> [<0000000040ab40b8>] free_initmem+0xf8/0x210
> [<0000000040ab3d28>] kernel_init+0xa0/0x338
> [<0000000040202020>] ret_from_kernel_thread+0x20/0x28
>
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.14.21+ #1
> Hardware name: 9000/800/rp3440
> Backtrace:
> [<000000004020a3a0>] show_stack+0x70/0x90
> [<0000000040aadf98>] dump_stack_lvl+0xd8/0x128
> [<0000000040aae01c>] dump_stack+0x34/0x48
> [<000000004020a5e4>] die_if_kernel+0x204/0x430
> [<000000004020afd8>] handle_interruption+0x550/0xc78
> [<0000000040203080>] intr_check_sig+0x0/0x3c
>
> 10574: 43 ff ff 40 ldb 1fa0(sr3,r31),r31
This IIR is strange. We most likely don't touch userspace at this stage
when the kernel boots, and...
> 4010765c: bd 1c 3e 7d cmpb,*<> ret0,r8,401075a0 <map_pages+0x240>
> 40107660: 34 e7 20 00 ldo 1000(r7),r7
it doesn't fit with this dump at IAOQ.
Does it boot if you remove the __init in front of map_pages?
Helge
> 0000000040ab3fc0 <free_initmem>:
> 40ab3fc0: 08 03 02 41 copy r3,r1
> 40ab3fc4: 0f c2 12 c1 std rp,-10(sp)
> 40ab3fc8: 08 1e 02 43 copy sp,r3
> 40ab3fcc: 73 c1 01 68 std,ma r1,b0(sp)
> 40ab3fd0: 2b 6e a0 00 addil L%9d000,dp,r1
> 40ab3fd4: 08 01 02 5c copy r1,ret0
> 40ab3fd8: 2b 6e a0 00 addil L%9d000,dp,r1
> 40ab3fdc: 70 66 00 50 std r6,28(r3)
> 40ab3fe0: 50 26 09 00 ldd 480(r1),r6
> 40ab3fe4: 70 65 00 60 std r5,30(r3)
> 40ab3fe8: 2b 6e a0 00 addil L%9d000,dp,r1
> 40ab3fec: 53 85 01 e0 ldd f0(ret0),r5
> 40ab3ff0: 08 01 02 5c copy r1,ret0
> 40ab3ff4: 0c 6a 12 d0 std r10,8(r3)
> 40ab3ff8: 34 1f 00 02 ldi 1,r31
> 40ab3ffc: 2b 6e 10 00 addil L%1c800,dp,r1
> 40ab4000: 70 69 00 20 std r9,10(r3)
> 40ab4004: 34 0a 06 46 ldi 323,r10
> 40ab4008: 08 06 02 5a copy r6,r26
> 40ab400c: 70 68 00 30 std r8,18(r3)
> 40ab4010: 53 88 08 80 ldd 440(ret0),r8
> 40ab4014: 08 0a 02 57 copy r10,r23
> 40ab4018: 08 c8 04 18 sub r8,r6,r24
> 40ab401c: 70 67 00 40 std r7,20(r3)
> 40ab4020: 50 3c 03 90 ldd 1c8(r1),ret0
> 40ab4024: 37 dd 3f a1 ldo -30(sp),ret1
> 40ab4028: 20 e0 08 01 ldil L%-40000000,r7
> 40ab402c: 70 64 00 70 std r4,38(r3)
> 40ab4030: 08 e6 0a 19 add,l r6,r7,r25
> 40ab4034: 08 1b 02 44 copy dp,r4
> 40ab4038: 0f 9f 12 00 stb r31,0(ret0)
> 40ab403c: 34 16 00 00 ldi 0,r22
> 40ab4040: 00 00 14 a1 mfia r1
> 40ab4044: 28 29 6f ed addil L%-9ad000,r1,r1
> 40ab4048: 34 21 06 40 ldo 320(r1),r1
> 40ab404c: e8 20 f0 00 bve,l (r1),rp
> 40ab4050: 08 a6 04 09 sub r6,r5,r9
> 40ab4054: 08 e5 0a 07 add,l r5,r7,r7
> 40ab4058: 08 04 02 5b copy r4,dp
> 40ab405c: 08 05 02 5a copy r5,r26
> 40ab4060: 08 09 02 58 copy r9,r24
> 40ab4064: 08 07 02 59 copy r7,r25
> 40ab4068: 37 dd 3f a1 ldo -30(sp),ret1
> 40ab406c: 08 1b 02 44 copy dp,r4
> 40ab4070: 34 16 00 02 ldi 1,r22
> 40ab4074: 00 00 14 a1 mfia r1
> 40ab4078: 28 29 6f ed addil L%-9ad000,r1,r1
> 40ab407c: 34 21 05 d8 ldo 2ec(r1),r1
> 40ab4080: e8 20 f0 00 bve,l (r1),rp
> 40ab4084: 34 17 06 4e ldi 327,r23
> 40ab4088: 34 16 00 02 ldi 1,r22
> 40ab408c: 08 0a 02 57 copy r10,r23
> 40ab4090: 08 04 02 5b copy r4,dp
> 40ab4094: 08 05 02 5a copy r5,r26
> 40ab4098: 08 09 02 58 copy r9,r24
> 40ab409c: 08 07 02 59 copy r7,r25
> 40ab40a0: 37 dd 3f a1 ldo -30(sp),ret1
> 40ab40a4: 00 00 14 a1 mfia r1
> 40ab40a8: 28 29 6f ed addil L%-9ad000,r1,r1
> 40ab40ac: 34 21 05 78 ldo 2bc(r1),r1
> 40ab40b0: e8 20 f0 00 bve,l (r1),rp
> 40ab40b4: 08 1b 02 44 copy dp,r4
> 40ab40b8: 08 04 02 5b copy r4,dp
>
> Looks like fault occurs in third call to map_pages():
>
> void __ref free_initmem(void)
> {
> unsigned long init_begin = (unsigned long)__init_begin;
> unsigned long init_end = (unsigned long)__init_end;
> unsigned long kernel_end = (unsigned long)&_end;
>
> /* Remap kernel text and data, but do not touch init section yet. */
> kernel_set_to_readonly = true;
> map_pages(init_end, __pa(init_end), kernel_end - init_end,
> PAGE_KERNEL, 0);
>
> /* The init text pages are marked R-X. We have to
> * flush the icache and mark them RW-
> *
> * This is tricky, because map_pages is in the init section.
> * Do a dummy remap of the data section first (the data
> * section is already PAGE_KERNEL) to pull in the TLB entries
> * for map_kernel */
> map_pages(init_begin, __pa(init_begin), init_end - init_begin,
> PAGE_KERNEL_RWX, 1);
> /* now remap at PAGE_KERNEL since the TLB is pre-primed to execute
> * map_pages */
> map_pages(init_begin, __pa(init_begin), init_end - init_begin,
> PAGE_KERNEL, 1);
>
> /* force the kernel to see the new TLB entries */
> __flush_tlb_range(0, init_begin, kernel_end);
>
> /* finally dump all the instructions which were cached, since the
> * pages are no-longer executable */
> flush_icache_range(init_begin, init_end);
>
> free_initmem_default(POISON_FREE_INITMEM);
>
> /* set up a new led state on systems shipped LED State panel */
> pdc_chassis_send_status(PDC_CHASSIS_DIRECT_BCOMPLETE);
> }
>
> Dave
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Your System ate a SPARC! Gah! in map_pages()
2021-12-05 20:46 ` Helge Deller
@ 2021-12-05 21:00 ` John David Anglin
2021-12-05 23:05 ` John David Anglin
2021-12-07 22:07 ` John David Anglin
1 sibling, 1 reply; 12+ messages in thread
From: John David Anglin @ 2021-12-05 21:00 UTC (permalink / raw)
To: Helge Deller, linux-parisc
On 2021-12-05 3:46 p.m., Helge Deller wrote:
> On 12/5/21 20:33, John David Anglin wrote:
>> I'm seeing this on rp3440 fairly frequently. Must have something to do with memory as it
>> doesn't seem to happen on my c8000.
>>
>> Freeing initrd memory: 20980K
>> _______________________________
>> < Your System ate a SPARC! Gah! >
>> -------------------------------
>> \ ^__^
>> (__)\ )\/\
>> U ||----w |
>> || ||
>> swapper/0 (pid 1): Protection id trap (code 7)
>> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.14.21+ #1
>> Hardware name: 9000/800/rp3440
>>
>> YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
>> PSW: 00001000000001101111111100001111 Not tainted
>> r00-03 000000ff0806ff0f 0000000040bf9180 0000000040ab40b8 000000004b618280
>> r04-07 0000000040b5c980 0000000000194000 0000000040f8c800 0000000040193000
>> r08-11 0000000040f90000 0000000000000800 0000000000200000 0000000000100000
>> r12-15 0000000000e00000 0000000000200000 0000000040b79180 0000000000000001
>> r16-19 0000000040bf9980 0000000040b79180 0000000000000001 0000000000000000
>> r20-23 0000000000000008 0000000000000323 0000000000193323 0000000000000323
>> r24-27 0000000000000001 0000000000000400 0000000040100000 0000000040b5c980
>> r28-31 0000000040f8fca0 000000004b618250 000000004b618390 0000000040f8e000
>> sr00-03 0000000000000000 0000000000000000 0000000000000000 0000000000000000
>> sr04-07 0000000000000000 0000000000000000 0000000000000000 0000000000000000
>>
>> IASQ: 0000000000000000 0000000000000000 IAOQ: 000000004010765c 0000000040107660
>> IIR: 43ffff40 ISR: 0000000000000000 IOR: 0000000000000000
>> CPU: 0 CR30: 000000004b618000 CR31: ffffffffffffffff
>> ORIG_R28: 000000004b618570
>> IAOQ[0]: map_pages+0x2fc/0x378
>> IAOQ[1]: map_pages+0x300/0x378
>> RP(r2): free_initmem+0xf8/0x210
>> Backtrace:
>> [<0000000040ab40b8>] free_initmem+0xf8/0x210
>> [<0000000040ab3d28>] kernel_init+0xa0/0x338
>> [<0000000040202020>] ret_from_kernel_thread+0x20/0x28
>>
>> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.14.21+ #1
>> Hardware name: 9000/800/rp3440
>> Backtrace:
>> [<000000004020a3a0>] show_stack+0x70/0x90
>> [<0000000040aadf98>] dump_stack_lvl+0xd8/0x128
>> [<0000000040aae01c>] dump_stack+0x34/0x48
>> [<000000004020a5e4>] die_if_kernel+0x204/0x430
>> [<000000004020afd8>] handle_interruption+0x550/0xc78
>> [<0000000040203080>] intr_check_sig+0x0/0x3c
>>
>> 10574: 43 ff ff 40 ldb 1fa0(sr3,r31),r31
> This IIR is strange. We most likely don't touch userspace at this stage
> when the kernel boots, and...
Yes. I think mapping for map_pages() must be corrupt. It's a bit strange that the code ran as
far as it did into map_pages().
>
>> 4010765c: bd 1c 3e 7d cmpb,*<> ret0,r8,401075a0 <map_pages+0x240>
>> 40107660: 34 e7 20 00 ldo 1000(r7),r7
> it doesn't fit with this dump at IAOQ.
Yes.
>
>
> Does it boot if you remove the __init in front of map_pages?
I'll try. I thought of trying it but wasn't sure if map_pages() had to be an init routine or not.
I should have said this fault occurs randomly. Sometimes kernel boots and runs okay.
Dave
--
John David Anglin dave.anglin@bell.net
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Your System ate a SPARC! Gah! in map_pages()
2021-12-05 21:00 ` John David Anglin
@ 2021-12-05 23:05 ` John David Anglin
2021-12-06 18:41 ` Helge Deller
0 siblings, 1 reply; 12+ messages in thread
From: John David Anglin @ 2021-12-05 23:05 UTC (permalink / raw)
To: Helge Deller, linux-parisc
On 2021-12-05 4:00 p.m., John David Anglin wrote:
>> Does it boot if you remove the __init in front of map_pages?
> I'll try. I thought of trying it but wasn't sure if map_pages() had to be an init routine or not.
This appears to fix boot. System booted okay about six times.
Dave
--
John David Anglin dave.anglin@bell.net
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Your System ate a SPARC! Gah! in map_pages()
2021-12-05 23:05 ` John David Anglin
@ 2021-12-06 18:41 ` Helge Deller
2021-12-06 19:07 ` John David Anglin
0 siblings, 1 reply; 12+ messages in thread
From: Helge Deller @ 2021-12-06 18:41 UTC (permalink / raw)
To: John David Anglin, linux-parisc
On 12/6/21 00:05, John David Anglin wrote:
> On 2021-12-05 4:00 p.m., John David Anglin wrote:
>>> Does it boot if you remove the __init in front of map_pages?
>> I'll try. I thought of trying it but wasn't sure if map_pages() had to be an init routine or not.
> This appears to fix boot. System booted okay about six times.
Do you have huge pages enabled?
If so you could try this patch (instead of markung map_pages __init):
diff --git a/arch/parisc/mm/init.c b/arch/parisc/mm/init.c
index 1ae31db9988f..a9a510338ced 100644
--- a/arch/parisc/mm/init.c
+++ b/arch/parisc/mm/init.c
@@ -405,7 +405,7 @@ static void __init map_pages(unsigned long start_vaddr,
} else if (!kernel_set_to_readonly) {
/* still initializing, allow writing to RO memory */
prot = PAGE_KERNEL_RWX;
- huge = true;
+ huge = false;
} else if (address >= ro_start) {
/* Code (ro) and Data areas */
prot = (address < ro_end) ?
Maybe the whole kernel is initially mapped via one/multiple huge pages(s), and
then we suddenly turn huge pages partly off. Therefore maybe not all TLB entries for the code of
map_pages() is already loaded?
On the other side the problem is somewhat similar to what I see with patching
the kernel code in the fixmap code on PA1.x CPUs... it showed strange asm statements too..
Helge
^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: Your System ate a SPARC! Gah! in map_pages()
2021-12-06 18:41 ` Helge Deller
@ 2021-12-06 19:07 ` John David Anglin
2021-12-07 15:36 ` John David Anglin
0 siblings, 1 reply; 12+ messages in thread
From: John David Anglin @ 2021-12-06 19:07 UTC (permalink / raw)
To: Helge Deller, linux-parisc
On 2021-12-06 1:41 p.m., Helge Deller wrote:
> On 12/6/21 00:05, John David Anglin wrote:
>> On 2021-12-05 4:00 p.m., John David Anglin wrote:
>>>> Does it boot if you remove the __init in front of map_pages?
>>> I'll try. I thought of trying it but wasn't sure if map_pages() had to be an init routine or not.
>> This appears to fix boot. System booted okay about six times.
> Do you have huge pages enabled?
Yes. It's enabled on both mx3210 (rp3440) and atlas (c8000).
> If so you could try this patch (instead of markung map_pages __init):
I'll try it.
Dave
--
John David Anglin dave.anglin@bell.net
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Your System ate a SPARC! Gah! in map_pages()
2021-12-06 19:07 ` John David Anglin
@ 2021-12-07 15:36 ` John David Anglin
0 siblings, 0 replies; 12+ messages in thread
From: John David Anglin @ 2021-12-07 15:36 UTC (permalink / raw)
To: Helge Deller, linux-parisc
On 2021-12-06 2:07 p.m., John David Anglin wrote:
> On 2021-12-06 1:41 p.m., Helge Deller wrote:
>> On 12/6/21 00:05, John David Anglin wrote:
>>> On 2021-12-05 4:00 p.m., John David Anglin wrote:
>>>>> Does it boot if you remove the __init in front of map_pages?
>>>> I'll try. I thought of trying it but wasn't sure if map_pages() had to be an init routine or not.
>>> This appears to fix boot. System booted okay about six times.
>> Do you have huge pages enabled?
> Yes. It's enabled on both mx3210 (rp3440) and atlas (c8000).
>> If so you could try this patch (instead of markung map_pages __init):
> I'll try it.
The patch made things worse on rp3440 (8 GB). Going back to removing __init marking.
Dave
--
John David Anglin dave.anglin@bell.net
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Your System ate a SPARC! Gah! in map_pages()
2021-12-05 20:46 ` Helge Deller
2021-12-05 21:00 ` John David Anglin
@ 2021-12-07 22:07 ` John David Anglin
2021-12-08 8:14 ` Helge Deller
1 sibling, 1 reply; 12+ messages in thread
From: John David Anglin @ 2021-12-07 22:07 UTC (permalink / raw)
To: Helge Deller, linux-parisc
On 2021-12-05 3:46 p.m., Helge Deller wrote:
>> 10574: 43 ff ff 40 ldb 1fa0(sr3,r31),r31
> This IIR is strange. We most likely don't touch userspace at this stage
> when the kernel boots, and...
I'm thinking IIR is sometimes unreliable. I see the same value printed for the tst-minsigstksz-5 fault
yet the actual fault instruction was "ldi 1,r25".
Dave
--
John David Anglin dave.anglin@bell.net
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Your System ate a SPARC! Gah! in map_pages()
2021-12-07 22:07 ` John David Anglin
@ 2021-12-08 8:14 ` Helge Deller
2021-12-10 19:53 ` Sven Schnelle
0 siblings, 1 reply; 12+ messages in thread
From: Helge Deller @ 2021-12-08 8:14 UTC (permalink / raw)
To: John David Anglin, linux-parisc
On 12/7/21 23:07, John David Anglin wrote:
> On 2021-12-05 3:46 p.m., Helge Deller wrote:
>>> 10574: 43 ff ff 40 ldb 1fa0(sr3,r31),r31
>> This IIR is strange. We most likely don't touch userspace at this stage
>> when the kernel boots, and...
> I'm thinking IIR is sometimes unreliable. I see the same value
> printed for the tst-minsigstksz-5 fault yet the actual fault
> instruction was "ldi 1,r25".
Good finding.
It seems to be at least always unreliable if we get a trap 7 (Instruction access rights).
In that case the CPU couldn't execute the instruction due to missing
execute permissions. I believe the CPU simply didn't fetched the
instruction and as such has stale content in IIR.
I'm sending a patch to the list which marks IIR with a magic value in that case.
Helge
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Your System ate a SPARC! Gah! in map_pages()
2021-12-08 8:14 ` Helge Deller
@ 2021-12-10 19:53 ` Sven Schnelle
2021-12-10 21:14 ` Helge Deller
0 siblings, 1 reply; 12+ messages in thread
From: Sven Schnelle @ 2021-12-10 19:53 UTC (permalink / raw)
To: Helge Deller; +Cc: John David Anglin, linux-parisc
Helge Deller <deller@gmx.de> writes:
> On 12/7/21 23:07, John David Anglin wrote:
>> On 2021-12-05 3:46 p.m., Helge Deller wrote:
>>>> 10574: 43 ff ff 40 ldb 1fa0(sr3,r31),r31
>>> This IIR is strange. We most likely don't touch userspace at this stage
>>> when the kernel boots, and...
>> I'm thinking IIR is sometimes unreliable. I see the same value
>> printed for the tst-minsigstksz-5 fault yet the actual fault
>> instruction was "ldi 1,r25".
>
> Good finding.
> It seems to be at least always unreliable if we get a trap 7 (Instruction access rights).
> In that case the CPU couldn't execute the instruction due to missing
> execute permissions. I believe the CPU simply didn't fetched the
> instruction and as such has stale content in IIR.
>
> I'm sending a patch to the list which marks IIR with a magic value in that case.
The same might happen with ISR and IOR - i wonder whether we should take
a few bit in struct pt_regs, store the interruption code there, and only
display the fields that are valid for a certain code? pt_regs has an
unused pad0 field (at least i think it's unused...) which we could use.
What's your take on this? I would prefer this over some magic values in
the oops output...
Sven
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Your System ate a SPARC! Gah! in map_pages()
2021-12-10 19:53 ` Sven Schnelle
@ 2021-12-10 21:14 ` Helge Deller
2021-12-10 21:18 ` John David Anglin
0 siblings, 1 reply; 12+ messages in thread
From: Helge Deller @ 2021-12-10 21:14 UTC (permalink / raw)
To: Sven Schnelle; +Cc: John David Anglin, linux-parisc
On 12/10/21 20:53, Sven Schnelle wrote:
> Helge Deller <deller@gmx.de> writes:
>
>> On 12/7/21 23:07, John David Anglin wrote:
>>> On 2021-12-05 3:46 p.m., Helge Deller wrote:
>>>>> 10574: 43 ff ff 40 ldb 1fa0(sr3,r31),r31
>>>> This IIR is strange. We most likely don't touch userspace at this stage
>>>> when the kernel boots, and...
>>> I'm thinking IIR is sometimes unreliable. I see the same value
>>> printed for the tst-minsigstksz-5 fault yet the actual fault
>>> instruction was "ldi 1,r25".
>>
>> Good finding.
>> It seems to be at least always unreliable if we get a trap 7 (Instruction access rights).
>> In that case the CPU couldn't execute the instruction due to missing
>> execute permissions. I believe the CPU simply didn't fetched the
>> instruction and as such has stale content in IIR.
>>
>> I'm sending a patch to the list which marks IIR with a magic value in that case.
>
> The same might happen with ISR and IOR - i wonder whether we should take
> a few bit in struct pt_regs, store the interruption code there, and only
> display the fields that are valid for a certain code? pt_regs has an
> unused pad0 field (at least i think it's unused...) which we could use.
> What's your take on this? I would prefer this over some magic values in
> the oops output...
It's a good idea, but do we really want to see such errors often?
So, I think it's not worth the efforts. Showing some magic "baadfood" is ok for me.
But if you like you can code it...
Helge
Btw, it seems I currently have vDSO (32bit) working with signal return code :-)
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Your System ate a SPARC! Gah! in map_pages()
2021-12-10 21:14 ` Helge Deller
@ 2021-12-10 21:18 ` John David Anglin
0 siblings, 0 replies; 12+ messages in thread
From: John David Anglin @ 2021-12-10 21:18 UTC (permalink / raw)
To: Helge Deller, Sven Schnelle; +Cc: linux-parisc
On 2021-12-10 4:14 p.m., Helge Deller wrote:
> Btw, it seems I currently have vDSO (32bit) working with signal return code:-)
Awesome. Will you post change?
Dave
--
John David Anglin dave.anglin@bell.net
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2021-12-10 21:18 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-12-05 19:33 Your System ate a SPARC! Gah! in map_pages() John David Anglin
2021-12-05 20:46 ` Helge Deller
2021-12-05 21:00 ` John David Anglin
2021-12-05 23:05 ` John David Anglin
2021-12-06 18:41 ` Helge Deller
2021-12-06 19:07 ` John David Anglin
2021-12-07 15:36 ` John David Anglin
2021-12-07 22:07 ` John David Anglin
2021-12-08 8:14 ` Helge Deller
2021-12-10 19:53 ` Sven Schnelle
2021-12-10 21:14 ` Helge Deller
2021-12-10 21:18 ` John David Anglin
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.