lkml.org 
[lkml]   [2022]   [Jun]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [BUG] rockpro64 board hangs in console_init() after commit 10e14073107d
    On (22/06/13 17:54), Alexandru Elisei wrote:
    [..]
    > [ 0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x588fe9dc0, max_idle_ns: 440795202592 ns
    > [ 0.000001] sched_clock: 56 bits at 24MHz, resolution 41ns, wraps every 4398046511097ns
    > [ 0.005107] Console: colour dummy device 80x25
    > [ 0.005549] printk: console [tty0] enabled
    > [ 0.005956] printk: bootconsole [uart0] disabled
    >
    > Config can be found at [1] (expires after 6 months). I've also built the
    > kernel with gcc 10.3.1 [2] (aarch64-none-linux-gnu), same issue.
    >
    > I've bisected the build failure to commit 10e14073107d ("writeback: Fix
    > inode->i_io_list not be protected by inode->i_lock error"); I've confirmed
    > that that commit is responsible by successfully booting the board with a
    > kernel built from v5.19-rc2 + the above commit reverted.

    Hmm, interesting and puzzling.

    If you disable console kthreads (__printk_fallback_preferred_direct) and
    keep 10e14073107d, are you able to successfully boot the board or does it
    boot to a panic?

    > I tried to do some investigating, it seems that the kernel is stuck at
    > printk.c::console_init() -> drivers/tty/vt/vt.c::con_init() ->
    > printk.c::register_console() -> unregister_console() -> console_lock().

    Is it console lock (console_kthreads_block() -> mutex_lock(&con->lock))
    that we cannot grab or is it console semaphore?

    \
     
     \ /
      Last update: 2022-06-14 05:01    [W:4.126 / U:0.116 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site