6 messages, 4 authors, 2021-01-11 · open the first message on its own page
From: Paul Cercueil <paul@crapouillou.net>
Date: 2021-01-08 21:00:44
Hi Thomas, 5.11 does not boot anymore on Ingenic SoCs, I bisected it to this commit. Any idea what could be happening? Cheers, -Paul
From: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Date: 2021-01-08 23:59:21
On Fri, Jan 08, 2021 at 08:20:43PM +0000, Paul Cercueil wrote:
Hi Thomas, 5.11 does not boot anymore on Ingenic SoCs, I bisected it to this commit. Any idea what could be happening?
not yet, kernel crash log of a Malta QEMU is below.
Thomas.
Kernel bug detected[#1]:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.11.0-rc1-00017-gccb21774863a #2
$ 0 : 00000000 00000001 00000000 00000010
$ 4 : 00000001 000005cf 9e00059f 00000000
$ 8 : 00118173 809e6db8 9e00059f 00000000
$12 : 82023c00 00000001 810da04c 0212422f
$16 : 810da000 00027800 000005cf 80b4bf9c
$20 : 809e968c 82602400 810da000 0000000b
$24 : 021558f9 00000000
$28 : 820e0000 820e3928 80b10000 802710d0
Hi : 0000346c
Lo : 000002dd
epc : 80271114 __kmap_local_pfn_prot+0x78/0x1c0
ra : 802710d0 __kmap_local_pfn_prot+0x34/0x1c0
Status: 1000a403 KERNEL EXL IE
Cause : 00800034 (ExcCode 0d)
PrId : 0001a800 (MIPS P5600)
Modules linked in:
Process swapper/0 (pid: 1, threadinfo=(ptrval), task=(ptrval), tls=00000000)
Stack : 7fffffff 820c2408 820e3990 ffffff04 ffff0a00 80518224 000081a4 810da000
00000001 000005cf fff64000 8011c77c 820e3b26 ffffff04 ffff0a00 80518440
80b30000 80b4bf64 9e0005cf 000005cf fff64000 80271188 00000000 820e3a60
80b10000 80194478 0000005e 80954406 809e0000 810da000 00000001 000005cf
fff68000 8011c77c 8088fd44 809f6074 000000f4 00000000 00000000 80b4bf68
...
Call Trace:
[<80271114>] __kmap_local_pfn_prot+0x78/0x1c0
[<8011c77c>] __update_cache+0x16c/0x174
[<80271188>] __kmap_local_pfn_prot+0xec/0x1c0
[<8011c77c>] __update_cache+0x16c/0x174
[<80271188>] __kmap_local_pfn_prot+0xec/0x1c0
[<8011c77c>] __update_cache+0x16c/0x174
[<80271188>] __kmap_local_pfn_prot+0xec/0x1c0
[<8011c77c>] __update_cache+0x16c/0x174
[<80271188>] __kmap_local_pfn_prot+0xec/0x1c0
[<8011c77c>] __update_cache+0x16c/0x174
[<80271188>] __kmap_local_pfn_prot+0xec/0x1c0
[<8011c77c>] __update_cache+0x16c/0x174
[<80271188>] __kmap_local_pfn_prot+0xec/0x1c0
[<8011c77c>] __update_cache+0x16c/0x174
[<80271188>] __kmap_local_pfn_prot+0xec/0x1c0
[<8011c77c>] __update_cache+0x16c/0x174
[<80271188>] __kmap_local_pfn_prot+0xec/0x1c0
[<8011c77c>] __update_cache+0x16c/0x174
[<80271188>] __kmap_local_pfn_prot+0xec/0x1c0
[<8011c77c>] __update_cache+0x16c/0x174
[<80271188>] __kmap_local_pfn_prot+0xec/0x1c0
[<8011c77c>] __update_cache+0x16c/0x174
[<80271188>] __kmap_local_pfn_prot+0xec/0x1c0
[<8011c77c>] __update_cache+0x16c/0x174
[<80271188>] __kmap_local_pfn_prot+0xec/0x1c0
[<8011c77c>] __update_cache+0x16c/0x174
[<80271188>] __kmap_local_pfn_prot+0xec/0x1c0
[<8011c77c>] __update_cache+0x16c/0x174
[<80271188>] __kmap_local_pfn_prot+0xec/0x1c0
[<8011c77c>] __update_cache+0x16c/0x174
[<80271188>] __kmap_local_pfn_prot+0xec/0x1c0
[<802c49a0>] copy_string_kernel+0x168/0x264
[<802c5d18>] kernel_execve+0xd0/0x164
[<801006cc>] try_to_run_init_process+0x18/0x5c
[<80859e0c>] kernel_init+0xd0/0x120
[<801037f8>] ret_from_kernel_thread+0x14/0x1c
Code: 8c630564 28640010 38840001 <00040336> 8f82000c 2463ffff 00021100 00431021 2403ffbf
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
From: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Date: 2021-01-09 00:35:23
On Sat, Jan 09, 2021 at 12:58:05AM +0100, Thomas Bogendoerfer wrote:
On Fri, Jan 08, 2021 at 08:20:43PM +0000, Paul Cercueil wrote:quoted
Hi Thomas, 5.11 does not boot anymore on Ingenic SoCs, I bisected it to this commit. Any idea what could be happening?not yet, kernel crash log of a Malta QEMU is below.
update: This dirty hack lets the Malta QEMU boot again:
diff --git a/mm/highmem.c b/mm/highmem.c
index c3a9ea7875ef..190cdda1149d 100644
--- a/mm/highmem.c
+++ b/mm/highmem.c@@ -515,7 +515,7 @@ void *__kmap_local_pfn_prot(unsigned long pfn, pgprot_t prot) vaddr = __fix_to_virt(FIX_KMAP_BEGIN + idx); BUG_ON(!pte_none(*(kmap_pte - idx))); pteval = pfn_pte(pfn, prot); - set_pte_at(&init_mm, vaddr, kmap_pte - idx, pteval); + set_pte(kmap_pte - idx, pteval); arch_kmap_local_post_map(vaddr, pteval); current->kmap_ctrl.pteval[kmap_local_idx()] = pteval; preempt_enable();
set_pte_at() tries to update cache and could do an kmap_atomic() there. Not sure, if this is allowed at this point. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea. [ RFC1925, 2.3 ]
From: Paul Cercueil <paul@crapouillou.net>
Date: 2021-01-10 11:36:34
Hi Thomas, Le sam. 9 janv. 2021 à 1:33, Thomas Bogendoerfer [off-list ref] a écrit :
On Sat, Jan 09, 2021 at 12:58:05AM +0100, Thomas Bogendoerfer wrote:quoted
On Fri, Jan 08, 2021 at 08:20:43PM +0000, Paul Cercueil wrote: > Hi Thomas, > > 5.11 does not boot anymore on Ingenic SoCs, I bisected it to this commit. > > Any idea what could be happening? not yet, kernel crash log of a Malta QEMU is below.update: This dirty hack lets the Malta QEMU boot again:diff --git a/mm/highmem.c b/mm/highmem.c index c3a9ea7875ef..190cdda1149d 100644 --- a/mm/highmem.c +++ b/mm/highmem.c@@ -515,7 +515,7 @@ void *__kmap_local_pfn_prot(unsigned long pfn,pgprot_t prot) vaddr = __fix_to_virt(FIX_KMAP_BEGIN + idx); BUG_ON(!pte_none(*(kmap_pte - idx))); pteval = pfn_pte(pfn, prot); - set_pte_at(&init_mm, vaddr, kmap_pte - idx, pteval); + set_pte(kmap_pte - idx, pteval); arch_kmap_local_post_map(vaddr, pteval); current->kmap_ctrl.pteval[kmap_local_idx()] = pteval; preempt_enable(); set_pte_at() tries to update cache and could do an kmap_atomic() there. Not sure, if this is allowed at this point.
Yes, I can confirm that your workaround works here too. Cheers, -Paul
From: H. Nikolaus Schaller <hidden>
Date: 2021-01-10 12:07:01
Am 10.01.2021 um 12:35 schrieb Paul Cercueil [off-list ref]: Hi Thomas, Le sam. 9 janv. 2021 à 1:33, Thomas Bogendoerfer [off-list ref] a écrit :quoted
On Sat, Jan 09, 2021 at 12:58:05AM +0100, Thomas Bogendoerfer wrote:quoted
On Fri, Jan 08, 2021 at 08:20:43PM +0000, Paul Cercueil wrote:quoted
Hi Thomas, 5.11 does not boot anymore on Ingenic SoCs, I bisected it to this commit.
Just for completeness, I have no such problems booting CI20/jz4780 or Skytone400/jz4730 (unpublished work) with 5.11-rc2. But may depend on board capabilites (ram size, memory layout or something else).
quoted
quoted
quoted
Any idea what could be happening?not yet, kernel crash log of a Malta QEMU is below.update: This dirty hack lets the Malta QEMU boot again:diff --git a/mm/highmem.c b/mm/highmem.c index c3a9ea7875ef..190cdda1149d 100644 --- a/mm/highmem.c +++ b/mm/highmem.c@@ -515,7 +515,7 @@ void *__kmap_local_pfn_prot(unsigned long pfn, pgprot_t prot)vaddr = __fix_to_virt(FIX_KMAP_BEGIN + idx); BUG_ON(!pte_none(*(kmap_pte - idx))); pteval = pfn_pte(pfn, prot); - set_pte_at(&init_mm, vaddr, kmap_pte - idx, pteval); + set_pte(kmap_pte - idx, pteval); arch_kmap_local_post_map(vaddr, pteval); current->kmap_ctrl.pteval[kmap_local_idx()] = pteval; preempt_enable(); set_pte_at() tries to update cache and could do an kmap_atomic() there. Not sure, if this is allowed at this point.Yes, I can confirm that your workaround works here too. Cheers, -Paul
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date: 2021-01-11 09:18:00
On 2021-01-09 01:33:52 [+0100], Thomas Bogendoerfer wrote:
On Sat, Jan 09, 2021 at 12:58:05AM +0100, Thomas Bogendoerfer wrote:quoted
On Fri, Jan 08, 2021 at 08:20:43PM +0000, Paul Cercueil wrote:quoted
Hi Thomas, 5.11 does not boot anymore on Ingenic SoCs, I bisected it to this commit. Any idea what could be happening?not yet, kernel crash log of a Malta QEMU is below.update: This dirty hack lets the Malta QEMU boot again:diff --git a/mm/highmem.c b/mm/highmem.c index c3a9ea7875ef..190cdda1149d 100644 --- a/mm/highmem.c +++ b/mm/highmem.c@@ -515,7 +515,7 @@ void *__kmap_local_pfn_prot(unsigned long pfn, pgprot_t prot) vaddr = __fix_to_virt(FIX_KMAP_BEGIN + idx); BUG_ON(!pte_none(*(kmap_pte - idx))); pteval = pfn_pte(pfn, prot); - set_pte_at(&init_mm, vaddr, kmap_pte - idx, pteval); + set_pte(kmap_pte - idx, pteval); arch_kmap_local_post_map(vaddr, pteval); current->kmap_ctrl.pteval[kmap_local_idx()] = pteval; preempt_enable();set_pte_at() tries to update cache and could do an kmap_atomic() there.
So the old implementation used set_pte() while the new one uses set_pte_at().
Not sure, if this is allowed at this point.
The problem is the recursion
kmap_atomic() -> __update_cache() -> kmap_atomic()
and kmap_local_idx_push() runs out if index space before stack space.
I'm not sure if the __update_cache() worked for highmem. It has been
added for that in commit
f4281bba81810 ("MIPS: Handle highmem pages in __update_cache")
but it assumes that the address returned by kmap_atomic() is the same or
related enough for flush_data_cache_page() to work.
Thomas.
Sebastian