Hi,
we have a bunch of Zotac ZBOX NANO-AQ01 with this APU:
[ 2.234372] [drm] initializing kernel modesetting (KABINI 0x1002:0x9832 0x1002:0x0123).
For our application, we force 1440x900 resolution via this modeline ("cvt 1440 900"):
Modeline "1440x900" 106.50 1440 1528 1672 1904 900 903 909 934 -hsync +vsync
The application is Chromium in kiosk mode. The problem is that sometimes the screen stays black after KMS kicks in.
Currently the kernel is 4.5 with or without the DAL WIP patchset, i.e. a "git diff" between b562e44f507e863c6792946e4e1b1449fbbac85d from Linus's GIT and 629edeae23ba531f6f5ceacf3f1fa71ba5132303 from git://people.freedesktop.org/~agd5f/linux :
commit 629edeae23ba531f6f5ceacf3f1fa71ba5132303 Author: Eric Yang eric.yang2@amd.com Date: Wed Mar 16 16:38:28 2016 -0400
drm/amd/dal: fix division by 0 on boot for dce80
DCE80 used to have bandwidth parameters initialized with the dce110 numbers. This was taken out a while ago, leaving the parameters to be uninitialized. This causes division by 0 on boot. This change resolves this by skipping bandwidth calculation and displaymark programming. For now, we will have dce80 always running safemark
Reviewed-by: Eagle Yeh eagle.yeh@amd.com Signed-off-by: Eric Yang eric.yang2@amd.com Signed-off-by: Alex Deucher alexander.deucher@amd.com
We use Xorg 1.16.4 and xf86-video-ati GIT with TearFree, commit ID 10b7c3def58bb34acc38f076bc230e25b454ab79. The same behaviour is present with 4693b1bd5b5c381e8b7b68a6f7f0c6696d6a68df.
Attached is the dmesg and Xorg logs from both good and bad booting with the DAL kernel, with "drm.debug=0x1e log_buf_len=1M" kernel options.
Our extra xorg.conf to force the 1440x900 is this:
Section "Monitor" Identifier "HDMI-0" Option "AutoServerLayout" "on" Option "Position" "0 0" Modeline "1440x900" 106.50 1440 1528 1672 1904 900 903 909 934 -hsync +vsync EndSection
Section "Monitor" Identifier "DisplayPort-0" Option "AutoServerLayout" "on" Option "Position" "0 0" Modeline "1440x900" 106.50 1440 1528 1672 1904 900 903 909 934 -hsync +vsync EndSection
Section "Device" Identifier "RADEON" Driver "radeon" Option "AutoServerLayout" "on" Option "Monitor-HDMI-0" "HDMI-0" Option "Monitor-DisplayPort-0" "DisplayPort-0" Option "TearFree" "on" EndSection Section "Screen" Identifier "SCREEN" Option "AutoServerLayout" "on" SubSection "Display" Viewport 0 0 Modes "1440x900" Depth 24 EndSubSection EndSection
Can someone fix this black screen problem?
Thanks in advance, Zoltán Böszörményi
On 05.04.2016 00:25, Boszormenyi Zoltan wrote:
we have a bunch of Zotac ZBOX NANO-AQ01 with this APU:
[ 2.234372] [drm] initializing kernel modesetting (KABINI 0x1002:0x9832 0x1002:0x0123).
For our application, we force 1440x900 resolution via this modeline ("cvt 1440 900"):
Modeline "1440x900" 106.50 1440 1528 1672 1904 900 903 909 934-hsync +vsync
The application is Chromium in kiosk mode. The problem is that sometimes the screen stays black after KMS kicks in.
So the problem occurs even without X? Does it affect HDMI or DisplayPort, or both?
2016-04-05 05:40 keltezéssel, Michel Dänzer írta:
On 05.04.2016 00:25, Boszormenyi Zoltan wrote:
we have a bunch of Zotac ZBOX NANO-AQ01 with this APU:
[ 2.234372] [drm] initializing kernel modesetting (KABINI 0x1002:0x9832 0x1002:0x0123).
For our application, we force 1440x900 resolution via this modeline ("cvt 1440 900"):
Modeline "1440x900" 106.50 1440 1528 1672 1904 900 903 909 934-hsync +vsync
The application is Chromium in kiosk mode. The problem is that sometimes the screen stays black after KMS kicks in.
So the problem occurs even without X? Does it affect HDMI or DisplayPort, or both?
It occurs on both but not without X. Ctrl-Alt-F2 gives me the console login prompt. My phrasing was not what I wanted to write and didn't finish the sentence really. X is started very early during boot so I can see the console message only momentarily while the screen is still in 80x25 VGA text mode. Restarting Xorg via systemctl makes it working most of the time.
Apparently, it's not Radeon specific. We were also able to reproduce it on an Intel machine, too, with internal LVDS and external VGA outputs.
Is Xorg 1.16.4 still a supported version with new kernels? I think I will try to upgrade to 1.18.x.
Thanks in advance, Zoltán Böszörményi
On 05.04.2016 13:07, Boszormenyi Zoltan wrote:
2016-04-05 05:40 keltezéssel, Michel Dänzer írta:
On 05.04.2016 00:25, Boszormenyi Zoltan wrote:
The application is Chromium in kiosk mode. The problem is that sometimes the screen stays black after KMS kicks in.
So the problem occurs even without X? Does it affect HDMI or DisplayPort, or both?
It occurs on both but not without X. Ctrl-Alt-F2 gives me the console login prompt. My phrasing was not what I wanted to write and didn't finish the sentence really. X is started very early during boot so I can see the console message only momentarily while the screen is still in 80x25 VGA text mode. Restarting Xorg via systemctl makes it working most of the time.
Apparently, it's not Radeon specific. We were also able to reproduce it on an Intel machine, too, with internal LVDS and external VGA outputs.
I suspect it's a client side problem then. Comparing the good and bad dmesg output shows that Xorg is busily updating the screen in the good case (visible as radeon_crtc_page_flip gets called by TearFree) but not so in the bad case. Since the default Xorg startup behaviour is a black screen, it sounds like simply no client connects to Xorg / draws anything to the screen in the bad case. Maybe there's a race which can result in the client(s) starting up before Xorg, failing to establish the display connection, or something like that.
Is Xorg 1.16.4 still a supported version with new kernels?
There's no direct version inter-dependency between Xorg and the kernel.
2016-04-05 08:27 keltezéssel, Michel Dänzer írta:
On 05.04.2016 13:07, Boszormenyi Zoltan wrote:
2016-04-05 05:40 keltezéssel, Michel Dänzer írta:
On 05.04.2016 00:25, Boszormenyi Zoltan wrote:
The application is Chromium in kiosk mode. The problem is that sometimes the screen stays black after KMS kicks in.
So the problem occurs even without X? Does it affect HDMI or DisplayPort, or both?
It occurs on both but not without X. Ctrl-Alt-F2 gives me the console login prompt. My phrasing was not what I wanted to write and didn't finish the sentence really. X is started very early during boot so I can see the console message only momentarily while the screen is still in 80x25 VGA text mode. Restarting Xorg via systemctl makes it working most of the time.
Apparently, it's not Radeon specific. We were also able to reproduce it on an Intel machine, too, with internal LVDS and external VGA outputs.
I suspect it's a client side problem then.
I have upgraded a bunch of Xorg libraries, the server to 1.18.3 and rebuilt all the drivers for the new server and the problem doesn't occur anymore. It may be possible that we have hit some race problems (like the one fixed in libxcb-1.11.1) but I didn't have the time to test every piece separately. I would have done this mass upgrade sooner or later anyway.
Comparing the good and bad dmesg output shows that Xorg is busily updating the screen in the good case (visible as radeon_crtc_page_flip gets called by TearFree) but not so in the bad case. Since the default Xorg startup behaviour is a black screen, it sounds like simply no client connects to Xorg / draws anything to the screen in the bad case. Maybe there's a race which can result in the client(s) starting up before Xorg, failing to establish the display connection, or something like that.
Is Xorg 1.16.4 still a supported version with new kernels?
There's no direct version inter-dependency between Xorg and the kernel.
Noted.
Thanks for looking into it, Zoltán Böszörményi
dri-devel@lists.freedesktop.org
-
Boszormenyi Zoltan -
Michel Dänzer