> Batch of updates (with
> .Fedora-Minimal-Rawhide-20180401.n.0.aarch64.raw.xz image this time)
> Seems like issue which I've reported with frozen system after first
> boot after display last line with fb: switching to
> vc4drnfb from EFI VGA" message is somehow related to SELinux.
> Only when I've added to grug kernel parameters selinux=0 I was able to
> reach initial-setup propmt.
What if you do a "touch .autorelabel" in the root of the root
filesystem to force a relabel on the first boot before initial-setup
runs.
> Other found issue: sometimes before GRUB UEFI stub messages are
> displayed it takes more than half minute before grub passes control to
> the kerenel.
> On NanonPi Neo4 it takes sometimes up to 20s but on RPI3 it takes way
> longer, Looks like not everything iis OK in UEFI grub.
> I would be not surprised if ither aarch64 platforms will have simillar
> side effects.
>
> Oter issue: before initial-setup was able to start I had OOPS:
>
> [ 43.561850] Bluetooth: HCI UART driver ver 2.3
> [ 43.561870] Bluetooth: HCI UART protocol H4 registered
> [ 43.561880] Bluetooth: HCI UART protocol BCSP registered
> [ 43.565282] Bluetooth: HCI UART protocol LL registered
> [ 43.565297] Bluetooth: HCI UART protocol ATH3K registered
> [ 43.565306] Bluetooth: HCI UART protocol Three-wire (H5) registered
> [ 43.565780] Bluetooth: HCI UART protocol Intel registered
> [ 43.566496] Bluetooth: HCI UART protocol Broadcom registered
> [ 43.566508] Bluetooth: HCI UART protocol QCA registered
> [ 43.566519] Bluetooth: HCI UART protocol AG6XX registered
> [ 43.566529] Bluetooth: HCI UART protocol Marvell registered
> [ 43.570593] uart-pl011 3f201000.serial: no DMA platform data
>
> [ 43.826209] ======================================================
> [ 43.826215] WARNING: possible circular locking dependency detected
> [ 43.826225] 4.16.0-0.rc7.git1.1.fc29.aarch64 #1 Not tainted
> [ 43.826228] ------------------------------------------------------
> [ 43.826235] kworker/u8:0/5 is trying to acquire lock:
> [ 43.826240] (bcm_device_lock){+.+.}, at: [<000000006eeac6db>]
> bcm_recv+0xb4/0x180 [hci_uart]
> [ 43.826391]
> but task is already holding lock:
> [ 43.967141] (&buf->lock){+.+.}, at: [<0000000085c2f87e>]
> flush_to_ldisc+0x30/0xd0
> [ 43.967177]
> which lock already depends on the new lock.
>
> [ 44.033514]
> the existing dependency chain (in reverse order) is:
> [ 44.033526]
> -> #3 (&buf->lock){+.+.}:
> [ 44.033567] lock_acquire+0xdc/0x298
> [ 44.033580] __mutex_lock+0x84/0x848
> [ 44.033589] mutex_lock_nested+0x3c/0x50
> [ 44.033603] tty_buffer_flush+0x48/0xc8
> [ 44.033611] tty_ldisc_flush+0x30/0x50
> [ 44.033621] tty_port_close_start.part.2+0xfc/0x1e0
> [ 44.033630] tty_port_close+0x4c/0x90
> [ 44.033640] uart_close+0x38/0xa0
> [ 44.033652] tty_release+0x114/0x5f0
> [ 44.033663] __fput+0xb4/0x218
> [ 44.033670] ____fput+0x20/0x30
> [ 44.033680] task_work_run+0xa0/0xd0
> [ 44.033693] do_notify_resume+0x104/0x120
> [ 44.033702] work_pending+0x8/0x14
> [ 44.033706]
> -> #2 (&tty->ldisc_sem){++++}:
> [ 44.033731] lock_acquire+0xdc/0x298
> [ 44.033740] __ldsem_down_write_nested+0x50/0x228
> [ 44.033751] ldsem_down_write+0x44/0x50
> [ 44.033759] tty_ldisc_lock+0x28/0x50
> [ 44.033766] tty_init_dev+0x94/0x1e0
> [ 44.033773] tty_open+0x26c/0x400
> [ 44.033794] chrdev_open+0x98/0x1e8
> [ 44.436729] do_dentry_open+0x138/0x338
> [ 44.436743] vfs_open+0x54/0x80
> [ 44.436752] do_last+0x270/0x7e0
> [ 44.436760] path_openat+0x9c/0x2a8
> [ 44.436769] do_filp_open+0x70/0xd0
> [ 44.436776] do_sys_open+0x15c/0x1f0
> [ 44.436783] SyS_open+0x38/0x48
> [ 44.436794] kernel_init_freeable+0x24c/0x2b8
> [ 44.436805] kernel_init+0x18/0x110
> [ 44.436818] ret_from_fork+0x10/0x18
> [ 44.436823]
> -> #1 (&tty->legacy_mutex){+.+.}:
> [ 44.436850] lock_acquire+0xdc/0x298
> [ 44.436861] __mutex_lock+0x84/0x848
> [ 44.436870] mutex_lock_nested+0x3c/0x50
> [ 44.436881] tty_lock+0x40/0x68
> [ 44.436889] tty_init_dev+0x60/0x1e0
> [ 44.436898] ttyport_open+0x30/0x148
> [ 44.436911] serdev_device_open+0x30/0x48
> [ 44.437036] bcm_open+0x84/0x1f0 [hci_uart]
> [ 44.437142] hci_uart_register_device+0x3c/0x2d0 [hci_uart]
> [ 44.699931] bcm_serdev_probe+0x94/0xe8 [hci_uart]
> [ 44.699954] serdev_drv_probe+0x28/0x38
> [ 44.725800] really_probe+0x204/0x3c8
> [ 44.725824] driver_probe_device+0x54/0xd8
> [ 44.750985] __driver_attach+0x12c/0x130
> [ 44.750999] bus_for_each_dev+0x70/0xa8
> [ 44.751007] driver_attach+0x30/0x40
> [ 44.751015] driver_attach_async+0x20/0x60
> [ 44.751027] async_run_entry_fn+0x4c/0x188
> [ 44.751038] process_one_work+0x264/0x700
> [ 44.751045] worker_thread+0x4c/0x408
> [ 44.751055] kthread+0x134/0x138
> [ 44.751067] ret_from_fork+0x10/0x18
> [ 44.751073]
> -> #0 (bcm_device_lock){+.+.}:
> [ 44.751105] __lock_acquire+0xb14/0x1060
> [ 44.751114] lock_acquire+0xdc/0x298
> [ 44.751128] __mutex_lock+0x84/0x848
> [ 44.751137] mutex_lock_nested+0x3c/0x50
> [ 44.751263] bcm_recv+0xb4/0x180 [hci_uart]
> [ 44.751362] hci_uart_receive_buf+0x7c/0xa8 [hci_uart]
> [ 44.751371] ttyport_receive_buf+0x5c/0x108
> [ 44.751383] flush_to_ldisc+0xa8/0xd0
> [ 44.751392] process_one_work+0x264/0x700
> [ 44.751399] worker_thread+0x4c/0x408
> [ 44.751409] kthread+0x134/0x138
> [ 44.751417] ret_from_fork+0x10/0x18
> [ 44.751421]
> other info that might help us debug this:
>
> [ 44.751425] Chain exists of:
> bcm_device_lock --> &tty->ldisc_sem --> &buf->lock
>
> [ 44.751448] Possible unsafe locking scenario:
>
> [ 44.751451] CPU0 CPU1
> [ 44.751455] ---- ----
> [ 44.751457] lock(&buf->lock);
> [ 44.751467] lock(&tty->ldisc_sem);
> [ 44.751476] lock(&buf->lock);
> [ 44.751484] lock(bcm_device_lock);
> [ 44.751493]
> *** DEADLOCK ***
>
> [ 44.751500] 3 locks held by kworker/u8:0/5:
> [ 44.751503] #0: ((wq_completion)"events_unbound"){+.+.}, at:
> [<000000002d869021>] process_one_work+0x1a8/0x700
> [ 44.751529] #1: ((work_completion)(&buf->work)){+.+.}, at:
> [<000000002d869021>] process_one_work+0x1a8/0x700
> [ 44.751551] #2: (&buf->lock){+.+.}, at: [<0000000085c2f87e>]
> flush_to_ldisc+0x30/0xd0
> [ 44.751573]
> stack backtrace:
> [ 44.751584] CPU: 2 PID: 5 Comm: kworker/u8:0 Not tainted
> 4.16.0-0.rc7.git1.1.fc29.aarch64 #1
> [ 44.751589] Hardware name: raspberrypi rpi/rpi, BIOS 2018.03 03/20/2018
> [ 44.751605] Workqueue: events_unbound flush_to_ldisc
> [ 44.751614] Call trace:
> [ 44.751626] dump_backtrace+0x0/0x148
> [ 44.751636] show_stack+0x24/0x30
> [ 44.751650] dump_stack+0xb0/0xe8
> [ 44.751661] print_circular_bug.isra.18+0x270/0x2d8
> [ 44.751670] check_prev_add.constprop.24+0x48c/0x750
> [ 44.751679] __lock_acquire+0xb14/0x1060
> [ 44.751687] lock_acquire+0xdc/0x298
> [ 44.751696] __mutex_lock+0x84/0x848
> [ 44.751705] mutex_lock_nested+0x3c/0x50
> [ 44.751804] bcm_recv+0xb4/0x180 [hci_uart]
> [ 44.751901] hci_uart_receive_buf+0x7c/0xa8 [hci_uart]
> [ 44.751911] ttyport_receive_buf+0x5c/0x108
> [ 44.751919] flush_to_ldisc+0xa8/0xd0
> [ 44.751926] process_one_work+0x264/0x700
> [ 44.751933] worker_thread+0x4c/0x408
> [ 44.751942] kthread+0x134/0x138
> [ 44.751950] ret_from_fork+0x10/0x18
> [ 44.908450] Bluetooth: hci0: BCM: chip id 94
> [ 44.919635] Bluetooth: hci0: BCM: features 0x2e
>
> kloczek
> --
> Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
_______________________________________________
arm mailing list -- arm@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to arm-leave@xxxxxxxxxxxxxxxxxxxxxxx
