VC4 still cause weston hang every time I use it #1354
Comments
|
Starting a Qt 4 embedded application that just wants to use the framebuffer (/dev/fb0) directly (without any acceleration or anything fancy) also hangs the system instantly when vc4 overlay is active. No kernel messages or other errors, just complete hang (serial console no longer responds, cannot turn numlock on/off on keyboard) |
|
I updated kernel to latest build from firmware repository and retried vc4, after short time rpi2 become unusable, this is a short cut from kern.log: Jun 16 15:12:52 jessie-rpi kernel: [ 8944.211575] [drm:vc4_bo_create [vc4]] ERROR Failed to allocate from CMA: from a fast search one related problem seems solved in latest vc4 bugfix patches upstream but missed here in actual rpi production branch (4.4): http://www.spinics.net/lists/dri-devel/msg109520.html @pelwell @anholt Can someone backports all missed fixes if possible please? Thanks for any reply and sorry for my bad english |
|
The upstream commit that I could find (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/drm_gem_cma_helper.c?id=afe705be38f1e65b173868486944377186b9f206) is a different solution to the same problem, but if Eric points us at the required commits or creates a PR we'll merge it. |
|
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/drm_gem_cma_helper.c?id=afe705be38f1e65b173868486944377186b9f206 should only be relevant if you've got the change that triggered the gem_free_object calls and NULL pointer derefs. I don't see those in the logs here. Given:
you've completely exhausted your CMA. If this is how much weston has allocated, then you're going to need to wait for me to implement swapping objects out of CMA. However, given:
we've either screwed up our stats or you've failed your allocation before we've purged the cache. vc4_bo_create() should be trying to purge the cache to get the job done. This is suspicious. Printing the current emit/finished_seqnos during stats dumping might be interesting to see if we've screwed up our wait somehow. |
|
@anholt Question about swapping out of CMA. Would this to be a SWAP partition or compressing of objects? |
|
Closing due to lack of activity. Reopen if you feel this issue is still relevant. |
|
This issue is still relevant, I'm running raspbian/stretch with kernel and it crashes frequently when running certain applications (firefox, gcompris, etc.). Checking /var/log/syslog shows the exact some entries. |
|
Looks like rpi-4.9.y never got the backport of a fix from April. I've tacked it onto my rpi-4.9.y PR. |
|
Latest rpi-update kernel includes the latest vc4 backports referred to by @anholt - does it help? |
|
Thanks for the hint. I run rpi-update and rebooted. After putting some load on it which requires a lot of memory (firefox, and gcompris, and working with it for some time, the machine crash eventually, again. Looking at the syslog, it does not seem to be the same error. I noticed the following issues
eventually, the screen went black, on open ssh connection to the raspi still accepted input, but the first command never finished, and the machine had to be rebooted. In a second attempt, the machine crashes, it means it does not accept any input form mouse and keyboard, or the screen goes black. An open ssh terminal session, does still accept input, but when exiting a command (htop), it did not finish. however ping to the rasp still did respond. Again, syslog contained `Aug 26 21:28:48 raspi3 kernel: [ 1502.204578] ------------[ cut here ]------------ ` |
|
OK, looks like the original problem here is fixed.
|
Hi, I did many tests time ago with vc4 having always hang problem.
Now I did another fast test updating to latest kernel 4.4.6 downloaded from firmware next branch but the problem persist.
After rpi boot I also had this calltrace about drm if can be useful:
Jan 31 15:34:40 jessie-rpi kernel: [ 11.771346] WARNING: CPU: 3 PID: 0 at drivers/gpu/drm/drm_irq.c:287 drm_update_vblank_count+0x188/0x368 drm
Jan 31 15:34:40 jessie-rpi kernel: [ 11.781765] Modules linked in: binfmt_misc vc4 drm_kms_helper drm syscopyarea sysfillrect sysimgblt fb_sys_fops bcm2835_gpiomem i2c_bcm2708 bcm2835_wdt uio_pdrv_genirq uio evdev snd_bcm2835 snd_pcm snd_timer snd
Jan 31 15:34:40 jessie-rpi kernel: [ 11.801559] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.4.6-v7+ #861
Jan 31 15:34:40 jessie-rpi kernel: [ 11.808119] Hardware name: BCM2709
Jan 31 15:34:40 jessie-rpi kernel: [ 11.811672] <80018734> from <80014068>
Jan 31 15:34:40 jessie-rpi kernel: [ 11.819684] <80014068> from <8031f364>
Jan 31 15:34:40 jessie-rpi kernel: [ 11.827250] <8031f364> from <80025300>
Jan 31 15:34:40 jessie-rpi kernel: [ 11.835620] <80025300> from <800253ec>
Jan 31 15:34:40 jessie-rpi kernel: [ 11.844766] <800253ec> from [<7f08aa9c>](drm_update_vblank_count+0x188/0x368 [drm])
Jan 31 15:34:40 jessie-rpi kernel: [ 11.854953] [<7f08aa9c>](drm_update_vblank_count [drm]) from [<7f08acec>](vblank_disable_and_save+0x70/0x80 [drm])
Jan 31 15:34:40 jessie-rpi kernel: [ 11.865935] [<7f08acec>](vblank_disable_and_save [drm]) from [<7f08ad70>](vblank_disable_fn+0x74/0xa0 [drm])
Jan 31 15:34:40 jessie-rpi kernel: [ 11.876328] [<7f08ad70>](vblank_disable_fn [drm]) from <80081b10>
Jan 31 15:34:40 jessie-rpi kernel: [ 11.885319] <80081b10> from <80081e30>
Jan 31 15:34:40 jessie-rpi kernel: [ 11.893860] <80081e30> from <80029040>
Jan 31 15:34:40 jessie-rpi kernel: [ 11.902312] <80029040> from <80029620>
Jan 31 15:34:40 jessie-rpi kernel: [ 11.909871] <80029620> from <80070fd4>
Jan 31 15:34:40 jessie-rpi kernel: [ 11.917969] <80070fd4> from <80010a74>
Jan 31 15:34:40 jessie-rpi kernel: [ 11.926245] <80010a74> from <8000951c>
Jan 31 15:34:40 jessie-rpi kernel: [ 11.935506] <8000951c> from <805ed284>
Jan 31 15:34:40 jessie-rpi kernel: [ 11.944664] Exception stack(0xba141f48 to 0xba141f90)
Jan 31 15:34:40 jessie-rpi kernel: [ 11.949889] 1f40: 00000000 ba706348 00000000 00000000 ba140000 8089e5dc
Jan 31 15:34:40 jessie-rpi kernel: [ 11.958337] 1f60: 10c0387d 8089e580 805f1e54 80903758 00000000 ba141fa4 8089f4f8 ba141f98
Jan 31 15:34:40 jessie-rpi kernel: [ 11.966779] 1f80: 80010b34 80010b38 600b0013 ffffffff
Jan 31 15:34:40 jessie-rpi kernel: [ 11.972012] <805ed284> from <80010b38>
Jan 31 15:34:40 jessie-rpi kernel: [ 11.979662] <80010b38> from <80063dbc>
Jan 31 15:34:40 jessie-rpi kernel: [ 11.988028] <80063dbc> from <80063fe4>
Jan 31 15:34:40 jessie-rpi kernel: [ 11.996929] <80063fe4> from <80015c98>
Jan 31 15:34:40 jessie-rpi kernel: [ 12.006271] <80015c98> from <000095ac>
I saw recently bugfix backport in 4.4 branch but some seems missed or I'm wrong?
Probably a check here can be useful:
https://github.com/anholt/linux/commits/drm-vc4-4.5
Seems all vc4 commits (including some fixes) applied to kernel 4.5, probably apply the missed ones also to rpi branch can be useful and if possible also backport them to kernel 4.4.
I don't have time to try backport them, rebuild kernel and test it today but if can be useful I can try it next weekend.
Any advice is appreciated.
Thanks for any reply and sorry for my bad english.
The text was updated successfully, but these errors were encountered: