Bug 1643484 - installing mesa-dri-drivers is causing X to stop redrawing
Summary: installing mesa-dri-drivers is causing X to stop redrawing
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: mesa
Version: 29
Hardware: aarch64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Peter Robinson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: ARMTracker
TreeView+ depends on / blocked
 
Reported: 2018-10-26 11:10 UTC by jiri vanek
Modified: 2019-11-27 22:51 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-11-27 22:51:16 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
dmsg (39.70 KB, text/plain)
2018-10-28 10:06 UTC, jiri vanek
no flags Details
xorg.log (31.99 KB, text/plain)
2018-10-28 10:06 UTC, jiri vanek
no flags Details
journalctl (160.31 KB, text/plain)
2018-10-28 10:07 UTC, jiri vanek
no flags Details

Description jiri vanek 2018-10-26 11:10:02 UTC
Description of problem:
When  mesa-dri-drivers are installed on my raspberry pi 3b+, X stops to redraw surface

Version-Release number of selected component (if applicable):
   mesa-dri-drivers            aarch64   18.2.2-1.fc29 
   + kernel kernel-4.18.12-300.fc29   
on
   raspbery pi 3B+


Steps to Reproduce:
1. install (cli) any X environment like fluxbox or mate
2. remove mesa-dri-drivers
3. it will behave correclty
4. however all acceleration is gone
5. install mesa-dri-drivers
6. reboot?
7. environment will start, but after few seconds stops to redraw
7.1 mouse keep moving
7.2 environment is responding (just noting is shown)
7.2.1 when you open eg text editor, the mouse reacats and chnages shape form arrow to  | or to resize window. The inivisible window also correctly gain/lost focus
7.3 if you know your environment witout eyes, you can even log out

Comment 1 Peter Robinson 2018-10-26 12:29:53 UTC
Please attach output of logs and dmesg.

Basically by removing mesa-dri-drivers you're removing all acceleration and are just using a blitted framebuffer

Comment 2 jiri vanek 2018-10-28 10:06:11 UTC
Created attachment 1498243 [details]
dmsg

Comment 3 jiri vanek 2018-10-28 10:06:44 UTC
Created attachment 1498244 [details]
xorg.log

Comment 4 jiri vanek 2018-10-28 10:07:51 UTC
Created attachment 1498245 [details]
journalctl

Comment 5 jiri vanek 2018-10-28 10:12:37 UTC
Thanx for pointer. Notable is following:
Oct 28 10:43:28 cam.local kernel: alloc_contig_range: [391a9, 391aa) PFNs busy
Oct 28 10:43:32 cam.local kernel: [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
Oct 28 10:43:32 cam.local kernel: [drm]                         kernel:   8100kb BOs (1)
Oct 28 10:43:32 cam.local kernel: [drm]                            V3D:  88560kb BOs (101)
Oct 28 10:43:32 cam.local kernel: [drm]                     V3D shader:    244kb BOs (57)
Oct 28 10:43:32 cam.local kernel: [drm]                           dumb:     48kb BOs (3)
Oct 28 10:43:32 cam.local kernel: [drm]                total purged BO:  49312kb BOs (99)
Oct 28 10:43:32 cam.local kernel: vc4_v3d 3fc00000.v3d: Failed to allocate memory for tile binning: -12. You may need to enable CMA or give it more memory.
Oct 28 10:43:32 cam.local slim[766]: Draw call returned Cannot allocate memory.  Expect corruption.

followed by

[    70.127] (EE) modeset(0): Failed to get GBM bo for flip to new front.
[    70.127] (EE) modeset(0): present flip failed

As Fedora do not honour config.txt, I'm not sure what where modify to increase GPU ram.

Comment 6 Peter Robinson 2018-10-28 11:20:30 UTC
> As Fedora do not honour config.txt, I'm not sure what where modify to
> increase GPU ram.

Actually in this context it does honor the config.txt but the opensource vc4 driver doesn't use the values, as documented in out config.txt.

The way the vc4 driver uses memory is via the cma memory option as can be seen in the output above. You'll need to add cma=192MB to the kernel command line.

Comment 7 jiri vanek 2018-10-28 15:06:01 UTC
Hmm. That do not sound enoug:(

[   86.620224] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
[   86.627229] [drm]                         kernel:   8100kb BOs (1)
[   86.633617] [drm]                            V3D:  88460kb BOs (36)
[   86.640021] [drm]                     V3D shader:    176kb BOs (42)
[   86.646386] [drm]                           dumb:     48kb BOs (3)
[   86.652818] [drm]                total purged BO:    464kb BOs (29)


How had you come out with 192?
How is it related to gpu_mem?

First I tired to set only cma=192
 - it stopped drawing in same way, just a bit later (but that can be coincidence)

Then I set it to  256
 - get forzen in 1/2 of startup of mate session

Then I set cma to 256 and gpu_mem to 256
 - it frozen in 3/4 of  mate-session

Then I set cma to 192 and gpu_mem to 192
 - it behaved like "always" get frozen after some tie as usually

All frozen are in concept of this bug - thus ssh working,  mouse responsive, but nothing redrawed.

I set cma=XYZ in  /etc/default/grub  amd run grub2-mkconfig -o correct_file; verified in /proc/cmdline its being used.

Comment 8 Peter Robinson 2018-10-28 15:23:07 UTC
> How had you come out with 192?

For non 3D desktops it's been enough to date, for 3D such as GNOME we allocate 256.

> How is it related to gpu_mem?

It's not.

> First I tired to set only cma=192
>  - it stopped drawing in same way, just a bit later (but that can be
> coincidence)
> 
> Then I set it to  256
>  - get forzen in 1/2 of startup of mate session
>
> Then I set cma to 256 and gpu_mem to 256
>  - it frozen in 3/4 of  mate-session
> 
> Then I set cma to 192 and gpu_mem to 192
>  - it behaved like "always" get frozen after some tie as usually

All you do by setting gpu_mem to anything other than 16, the minimum, is take away memory from Linux, it's not used by the opensource vc4 driver at all as I mentioned above. The gpu_mem is for the legacy closed source driver.

> All frozen are in concept of this bug - thus ssh working,  mouse responsive,
> but nothing redrawed.
> 
> I set cma=XYZ in  /etc/default/grub  amd run grub2-mkconfig -o correct_file;
> verified in /proc/cmdline its being used.

Comment 9 jiri vanek 2018-10-29 09:26:56 UTC
Thax for detailed explanation.

Set gpu_mem to  16, cma=512 runnig vanila fluxbox+networkmanager
run firefox or 720p movie:

[  159.922694] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
[  159.929763] [drm]                         kernel:   8100kb BOs (1)
[  159.936044] [drm]                            V3D:  11788kb BOs (36)
[  159.942494] [drm]                     V3D shader:    128kb BOs (32)
[  159.948863] [drm]                           dumb:     48kb BOs (3)
[  159.955278] [drm]                total purged BO:    292kb BOs (7)
[  159.961633] vc4_v3d 3fc00000.v3d: Failed to allocate memory for tile binning: -12. You may need to enable CMA or give it more memory.

Was watching top in meantime, and never run out of actual meemory.

Kodi is running full had on  this board witout issues.

Comment 10 jiri vanek 2018-10-29 09:28:43 UTC
(In reply to jiri vanek from comment #9)
> Thax for detailed explanation.
> 
> Set gpu_mem to  16, cma=512 runnig vanila fluxbox+networkmanager
> run firefox or 720p movie:

tried vlc and parole. both behave moreover same.
> 
> [  159.922694] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
> [  159.929763] [drm]                         kernel:   8100kb BOs (1)
> [  159.936044] [drm]                            V3D:  11788kb BOs (36)
> [  159.942494] [drm]                     V3D shader:    128kb BOs (32)
> [  159.948863] [drm]                           dumb:     48kb BOs (3)
> [  159.955278] [drm]                total purged BO:    292kb BOs (7)
> [  159.961633] vc4_v3d 3fc00000.v3d: Failed to allocate memory for tile
> binning: -12. You may need to enable CMA or give it more memory.
> 
> Was watching top in meantime, and never run out of actual meemory.
> 
> Kodi is running full had on  this board witout issues.

Comment 11 Peter Robinson 2018-10-29 09:36:41 UTC
what kerenl is this?

Comment 12 jiri vanek 2018-10-29 11:22:59 UTC
In initial comment:

Version-Release number of selected component (if applicable):
   mesa-dri-drivers            aarch64   18.2.2-1.fc29 
   + kernel kernel-4.18.12-300.fc29   
on
   raspbery pi 3B+

   setting the
gpu_mem=16
  and
cma=512
  looks like it solved the issues...Crap. So much....

Comment 13 Peter Robinson 2018-10-29 13:22:30 UTC
There was a fix that went into a later kernel, 4.18.14 or maybe .15

I run Workstation without issues on 256 but the instance i have is 32 bit ARMv7, it could be that there's bugs in Desktop with 64 bit. You might want to report it upstream at https://github.com/anholt/linux/

Comment 14 jiri vanek 2018-10-30 12:15:19 UTC
Opened: https://github.com/anholt/linux/issues/144

Comment 15 jiri vanek 2018-11-14 11:01:43 UTC
Hi Peter, is it worthy/advised to update to most fresh fedora kernel? There is 4.20 for some time.  Can it solve the issue with the memory? How do you suggest usage of 4.18?

Comment 16 Ben Cotton 2019-10-31 19:08:30 UTC
This message is a reminder that Fedora 29 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '29'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 29 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 17 Ben Cotton 2019-11-27 22:51:16 UTC
Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.