Ok so, it's official that with 512MB you have to downgrade the CMA to 128MB:
https://git.launchpad.net/~ubuntu- kernel/ubuntu/+source/linux/+git/xenial/tree/arch/arm/boot/dts/overlays/README?h=raspi2#n1317 so the dtoverlay line should go from: dtoverlay=vc4-kms-v3d to: dtoverlay=vc4-kms-v3d,cma-128 and with this setup, the board works fine. Still, i agree that it should fail gracefully if the wrong cma size is specified - i fixed the OOPS on boot here: https://bugs.launchpad.net/ubuntu/+source/linux-raspi2/+bug/1805117 but once the board is running, we later hit another problem: [ 360.269693] INFO: task kworker/1:2:101 blocked for more than 120 seconds. [ 360.276605] Not tainted 4.4.0-1101-raspi2 #109~vc4dbg5 [ 360.282360] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 360.290316] kworker/1:2 D 80895384 0 101 2 0x00000000 [ 360.290338] Workqueue: events dbs_timer [ 360.290356] [<80895384>] (__schedule) from [<8089589c>] (schedule+0x50/0xa8) [ 360.290366] [<8089589c>] (schedule) from [<80898c80>] (schedule_timeout+0x218/0x2a0) [ 360.290376] [<80898c80>] (schedule_timeout) from [<80896668>] (wait_for_common+0xc8/0x1a0) [ 360.290384] [<80896668>] (wait_for_common) from [<80896760>] (wait_for_completion+0x20/0x24) [ 360.290395] [<80896760>] (wait_for_completion) from [<8073f0d4>] (rpi_firmware_transaction+0x78/0xd0) [ 360.290406] [<8073f0d4>] (rpi_firmware_transaction) from [<8073f20c>] (rpi_firmware_property_list+0xe0/0x24c) [ 360.290415] [<8073f20c>] (rpi_firmware_property_list) from [<8073f3ec>] (rpi_firmware_property+0x74/0xec) [ 360.290425] [<8073f3ec>] (rpi_firmware_property) from [<80712c80>] (bcm2835_cpufreq_clock_property.constprop.1+0x58/0x80) [ 360.290437] [<80712c80>] (bcm2835_cpufreq_clock_property.constprop.1) from [<80712d00>] (bcm2835_cpufreq_driver_target_index+0x58/0xdc) [ 360.290446] [<80712d00>] (bcm2835_cpufreq_driver_target_index) from [<8070bb94>] (__cpufreq_driver_target+0x234/0x3b4) [ 360.290456] [<8070bb94>] (__cpufreq_driver_target) from [<807101e8>] (od_check_cpu+0xdc/0xe0) [ 360.290465] [<807101e8>] (od_check_cpu) from [<80712170>] (dbs_check_cpu+0x1d0/0x22c) [ 360.290474] [<80712170>] (dbs_check_cpu) from [<8071045c>] (od_dbs_timer+0x60/0xf4) [ 360.290483] [<8071045c>] (od_dbs_timer) from [<807124f4>] (dbs_timer+0x15c/0x1a8) [ 360.290494] [<807124f4>] (dbs_timer) from [<80140ed0>] (process_one_work+0x160/0x50c) [ 360.290504] [<80140ed0>] (process_one_work) from [<801412dc>] (worker_thread+0x60/0x5d0) [ 360.290513] [<801412dc>] (worker_thread) from [<80147808>] (kthread+0x118/0x130) [ 360.290525] [<80147808>] (kthread) from [<80108ebc>] (ret_from_fork+0x14/0x38) [ 360.290533] INFO: task kworker/3:2:135 blocked for more than 120 seconds. [ 360.297430] Not tainted 4.4.0-1101-raspi2 #109~vc4dbg5 [ 360.303176] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 360.311129] kworker/3:2 D 80895384 0 135 2 0x00000000 [ 360.311141] Workqueue: events dbs_timer [ 360.311151] [<80895384>] (__schedule) from [<8089589c>] (schedule+0x50/0xa8) [ 360.311160] [<8089589c>] (schedule) from [<80895c78>] (schedule_preempt_disabled+0x18/0x1c) [ 360.311169] [<80895c78>] (schedule_preempt_disabled) from [<808975c4>] (__mutex_lock_slowpath+0xcc/0x184) [ 360.311177] [<808975c4>] (__mutex_lock_slowpath) from [<808976dc>] (mutex_lock+0x60/0x64) [ 360.311186] [<808976dc>] (mutex_lock) from [<807123e0>] (dbs_timer+0x48/0x1a8) [ 360.311195] [<807123e0>] (dbs_timer) from [<80140ed0>] (process_one_work+0x160/0x50c) [ 360.311204] [<80140ed0>] (process_one_work) from [<801412dc>] (worker_thread+0x60/0x5d0) [ 360.311212] [<801412dc>] (worker_thread) from [<80147808>] (kthread+0x118/0x130) [ 360.311221] [<80147808>] (kthread) from [<80108ebc>] (ret_from_fork+0x14/0x38) ... the reason why that happens is because it takes a mutex: drivers/cpufreq/cpufreq_governor.c::dbs_timer() ... mutex_lock(&shared->timer_mutex); ... and then calls into the firmware: drivers/firmware/raspberrypi.c::rpi_firmware_transaction() ... ret = mbox_send_message(fw->chan, &message); if (ret >= 0) { wait_for_completion(&fw->c); ret = 0; } ... the call into the firmwate is asyncrhnous, so it writes the message into the mailbox and then wait for an answer (while still holding the mutex in dbs_timer()). In the mean time, the other cpus/workqueue take the same path to change frequency, and try to take the same mutex in dbs_timer(), but since it's already taken, they stop there and go to sleep - basically we are in deadlock waiting for an aswer from the firmware on CPU0/workqueue0, and all the other CPUs/workqueues queue there and wait indefinitely. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1805174 Title: Xenial/raspi2 and RaspberryPi3A+: video not working To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-raspi2/+bug/1805174/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
