Re: [MPlayer-dev-eng] AMD E450 VDPAU GPU lockup triggered by r37367/r37368 changes.
- Date: Tue, 5 May 2015 00:59:42 +0200 (CEST)
- From: wallak@xxxxxxx
- Subject: Re: [MPlayer-dev-eng] AMD E450 VDPAU GPU lockup triggered by r37367/r37368 changes.
*r37368 is indeed cosmetic, but both r37367/r37368 must be combined to be removed on the last mplayer 'checkout'. I've removed the changes on my E450 board, and now no more crashes.
*This happens mainly on some 16/9 h264 1080p streams, the display is set to 1080p, and so no resize is required. I don't know if this happens on all video, but this happens on more than one video I've tested
A test that trigger the issue quite quickly: (the lockup happens only at the very first moment of the video initialization phase, and not afterward)
if true; then \
i=0;while true; do echo $i;\
nice -n -5 su -l videouser -c 'bash -c ". /etc/profile;DISPLAY=:0.0 xrandr --output HDMI-0 --mode "1920x1080-60";DISPLAY=:0.0 mplayer -fs -endpos 00:00:20 -vc "ffh264vdpau" -channels 6 -af pan=2:2.0:0:0:2.0:1.32:0:0:1.32:2.0:2.0:2.0:2.0 \
-ao "alsa:device=iec958=1" -cache 65536 \"/tmp/h1080p-stream.mkv\";"';\
I don't think my E450 motherboard is faulty, the 3d engine seems to be fine (e.g. under windows, 3dmark...).
A most complete list of the software version I've used:
* up-to-date Xorg - radeon (compiled for 1.16.4, module version = 7.5.0)
And I've tried on a E350 AMD motherboard (very similar to the E450) using the same software and libraries (hdd clone), without being able to trigger the issue;
This seems to be a radeon driver bug very specific.
----- Mail original -----
De: "Reimar Döffinger" <Reimar.Doeffinger@xxxxxx>
Envoyé: Vendredi 1 Mai 2015 20:30:10
Objet: Re: [MPlayer-dev-eng] AMD E450 VDPAU GPU lockup triggered by r37367/r37368 changes.
On Wed, Apr 29, 2015 at 12:42:33AM +0200, wallak@xxxxxxx wrote:
> Dear All,
> After extensive tests; I've found that the r37367/r37368 changes trigger a high likely GPU lock on my AMD E450 while using VDPAU. The machine may require a reboot once this happens.
Can you be specific? I mean, it must be either r37367 or r37368, so
r37368 should have been completely cosmetic.
Does this happen with all video files or only specific ones? (both
containers and codecs are interesting here)
How does the -v -v or so log printout change between those versions?
Basically this change mostly should avoid a double-initialization,
it could be that such a double-initialization prevented certain driver
issues from showing.
But it could also be that the aspect is not slightly different and this
causes an issue.
Or there was a mistake in that change and it e.g. caused some things
to not be properly initialized.
Also, is that compiled against the internal FFmpeg or possibly some
> Have you an idea about the underlying issue? Is there other configurations affected?
Probably not a useful answer for you, but strictly speaking the issue is absolutely clear:
Driver or hardware bug/issues. There is simple no other true underlying bug for
anything that causes hangs, kernel panics, crashes etc.
MPlayer-dev-eng mailing list
MPlayer-dev-eng mailing list