Re: ARC no console output (was Re: [PATCH 1/2] init/console: Use ttynull as a fallback when there is no console)
On Thu 2021-01-07 21:18:20, Vineet Gupta wrote:
> On 1/7/21 7:48 PM, Sergey Senozhatsky wrote:
> > On (21/01/07 09:58), Vineet Gupta wrote:
> > > On 1/7/21 9:04 AM, Petr Mladek wrote:
> > > > On Thu 2021-01-07 08:43:16, Vineet Gupta wrote:
> > > > > Hi John,
> > > > >
> > > > > On 1/7/21 1:02 AM, John Ogness wrote:
> > > > > > Hi Vineet,
> > > > > >
> > > > > > On 2021-01-06, Vineet Gupta wrote:
> > > > > > > This breaks ARC booting (no output on console).
> > > > > >
> > > > > > Could you provide the kernel boot arguments that you use? This
> > > > > > series is
> > > > > > partly about addressing users that have used boot arguments that are
> > > > > > technically incorrect (even if had worked). Seeing the boot
> > > > > > arguments of
> > > > > > users that are not experiencing problems may help to reveal some of
> > > > > > the
> > > > > > unusual console usages until now.
> > > > >
> > > > >
> > > > > Kernel command line: earlycon=uart8250,mmio32,0xf0005000,115200n8
> > > > > console=ttyS0,115200n8 debug print-fatal-signals=1
> > > >
> > > > This is strange, the problematic patch should use ttynull
> > > > only as a fallback. It should not be used when a particular console
> > > > is defined on the command line.
> > >
> > > What happens in my case is console_on_rootfs() doesn't find /dev/console
> > > and
> > > switching to ttynull. /dev is not present because devtmpfs doesn't
> > > automount
> > > for initramfs.
I see. I did not though about a possibility that /dev/console could
not be opened from other reasons.
> > I wonder if we'll move the nulltty fallback logic into printk code [1]
> > will it fix the problem?
> >
> > [1]
> > https://lore.kernel.org/lkml/X6x%2FAxD1qanC6evJ@jagdpanzerIV.localdomain/
>
> Your reasoning in the post above makes total sense.
>
> I tired the patch: adding register_ttynull_console() call in
> console_device(), removing from console_on_rootfs() band that works too.
IMHO, this worked because you removed the change in console_on_rootfs().
I guess that the change in console_device() did not make any
difference. It was likely not called because
filp_open("/dev/console", O_RDWR, 0) failed earlier because
/dev/ did not exists.
Anyway, the proposed change in console_device() has some
more problems that I realized this week:
+ It does not check whether console_drivers really contains
any console with tty binding.
+ register_ttynull_console() calls
add_preferred_console(ttynull_console.name, 0, NULL).
The ttynull console stays preferred even when any better
console gets registered later. As a result, it would
stay associated with /dev/console.
The right solution would be to enable ttynull console and
do _not_ modify the list of preferred consoles. And it makes
sense to add the console only there is no console with
tty binding at the moment.
I still have to think whether console_device() is a better or
worse location for adding tyynull as a fallback.
Anyway, it has to wait. The proper solution can't be done easily
with the existing register_console() code. We need to clean
it up first.
Best Regards,
Petr
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH] ARC: Regenerate ulps
Reinstate pass for FAIL: math/test-double-cosh FAIL: math/test-double-sinh FAIL: math/test-float32x-cosh FAIL: math/test-float32x-sinh FAIL: math/test-float64-cosh FAIL: math/test-float64-sinh FAIL: math/test-ldouble-cosh FAIL: math/test-ldouble-sinh --- sysdeps/arc/fpu/libm-test-ulps | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/sysdeps/arc/fpu/libm-test-ulps b/sysdeps/arc/fpu/libm-test-ulps index f7f98caa0d5e..1a7cd54b39d2 100644 --- a/sysdeps/arc/fpu/libm-test-ulps +++ b/sysdeps/arc/fpu/libm-test-ulps @@ -532,11 +532,11 @@ double: 3 float: 3 Function: "cosh_downward": -double: 2 +double: 3 float: 1 Function: "cosh_towardzero": -double: 2 +double: 3 float: 1 Function: "cosh_upward": @@ -548,7 +548,7 @@ double: 9 float: 8 Function: Imaginary part of "cpow": -double: 3 +double: 8 float: 6 Function: Real part of "cpow_downward": @@ -1036,7 +1036,7 @@ double: 3 float: 3 Function: "sinh_towardzero": -double: 2 +double: 3 float: 2 Function: "sinh_upward": -- 2.25.1 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[COMMITTED] ARC: Regenerate ulps
Reinstate pass for FAIL: math/test-double-cosh FAIL: math/test-double-sinh FAIL: math/test-float32x-cosh FAIL: math/test-float32x-sinh FAIL: math/test-float64-cosh FAIL: math/test-float64-sinh FAIL: math/test-ldouble-cosh FAIL: math/test-ldouble-sinh --- sysdeps/arc/fpu/libm-test-ulps | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/sysdeps/arc/fpu/libm-test-ulps b/sysdeps/arc/fpu/libm-test-ulps index f7f98caa0d5e..1a7cd54b39d2 100644 --- a/sysdeps/arc/fpu/libm-test-ulps +++ b/sysdeps/arc/fpu/libm-test-ulps @@ -532,11 +532,11 @@ double: 3 float: 3 Function: "cosh_downward": -double: 2 +double: 3 float: 1 Function: "cosh_towardzero": -double: 2 +double: 3 float: 1 Function: "cosh_upward": @@ -548,7 +548,7 @@ double: 9 float: 8 Function: Imaginary part of "cpow": -double: 3 +double: 8 float: 6 Function: Real part of "cpow_downward": @@ -1036,7 +1036,7 @@ double: 3 float: 3 Function: "sinh_towardzero": -double: 2 +double: 3 float: 2 Function: "sinh_upward": -- 2.25.1 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [patch V3 13/37] mips/mm/highmem: Switch to generic kmap atomic
On Fri, Jan 08, 2021 at 08:20:43PM +, 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 : 0001 0010 $ 4 : 0001 05cf 9e00059f $ 8 : 00118173 809e6db8 9e00059f $12 : 82023c00 0001 810da04c 0212422f $16 : 810da000 00027800 05cf 80b4bf9c $20 : 809e968c 82602400 810da000 000b $24 : 021558f9 $28 : 820e 820e3928 80b1 802710d0 Hi: 346c Lo: 02dd epc : 80271114 __kmap_local_pfn_prot+0x78/0x1c0 ra: 802710d0 __kmap_local_pfn_prot+0x34/0x1c0 Status: 1000a403KERNEL EXL IE Cause : 00800034 (ExcCode 0d) PrId : 0001a800 (MIPS P5600) Modules linked in: Process swapper/0 (pid: 1, threadinfo=(ptrval), task=(ptrval), tls=) Stack : 7fff 820c2408 820e3990 ff04 0a00 80518224 81a4 810da000 0001 05cf fff64000 8011c77c 820e3b26 ff04 0a00 80518440 80b3 80b4bf64 9e0005cf 05cf fff64000 80271188 820e3a60 80b1 80194478 005e 80954406 809e 810da000 0001 05cf fff68000 8011c77c 8088fd44 809f6074 00f4 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 2463 00021100 00431021 2403ffbf -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea.[ RFC1925, 2.3 ] ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [patch V3 13/37] mips/mm/highmem: Switch to generic kmap atomic
On Sat, Jan 09, 2021 at 12:58:05AM +0100, Thomas Bogendoerfer wrote: > On Fri, Jan 08, 2021 at 08:20:43PM +, 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. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea.[ RFC1925, 2.3 ] ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
