Bug 51579 - [NVA8] Xv shows black image on ION chipset
Summary: [NVA8] Xv shows black image on ION chipset
Status: REOPENED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/nouveau (show other bugs)
Version: git
Hardware: x86-64 (AMD64) All
: medium critical
Assignee: Nouveau Project
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-06-29 23:22 UTC by Boris Reisig
Modified: 2014-11-21 11:55 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Dmesg of my system. (9.68 KB, text/plain)
2012-06-30 12:56 UTC, Boris Reisig
no flags Details
Xorg log (41.42 KB, text/plain)
2012-06-30 12:57 UTC, Boris Reisig
no flags Details
Fix for Xv against the latest xf86-video-nouveau from git. (3.11 KB, text/plain)
2012-07-28 07:20 UTC, Boris Reisig
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Boris Reisig 2012-06-29 23:22:58 UTC
I have one of the Zotac all-in-one PC's with the Nvidia ION chipset (NOUVEAU(0): Chipset: "NVIDIA NVa8") and it seems the latest xf86-nouveau driver from GIT is broken when trying to use Xv support for video playback. All it shows is a black screen. The GPU is not locked up as I can hear the audio during playback but the video is black. The last working version from git was commit 5ac2ca8c56ec8b055878c8ac4cbc8ca74379abda - "works implement and use PUSH_DATAu" and then starts failing at commit b48bcc094beecf521899dd63c8fdbccfd534e5cd - "nv50/exa: perform texcoord transformations in vertex program" all the way up to the latest git version from today. The Xorg.0.log seems to be fine. (snippet)

[    21.780] (II) NOUVEAU driver Date:   Thu Apr 19 09:52:24 2012 +1000
[    21.780] (II) NOUVEAU driver for NVIDIA chipset families :
[    21.780]    RIVA TNT        (NV04)
[    21.780]    RIVA TNT2       (NV05)
[    21.780]    GeForce 256     (NV10)
[    21.780]    GeForce 2       (NV11, NV15)
[    21.780]    GeForce 4MX     (NV17, NV18)
[    21.780]    GeForce 3       (NV20)
[    21.780]    GeForce 4Ti     (NV25, NV28)
[    21.780]    GeForce FX      (NV3x)
[    21.780]    GeForce 6       (NV4x)
[    21.780]    GeForce 7       (G7x)
[    21.780]    GeForce 8       (G8x)
[    21.780]    GeForce GTX 200 (NVA0)
[    21.780]    GeForce GTX 400 (NVC0)
[    21.780] (--) using VT number 2

[    21.784] drmOpenDevice: node name is /dev/dri/card0
[    21.784] drmOpenDevice: open result is 9, (OK)
[    21.784] drmOpenByBusid: Searching for BusID pci:0000:03:00.0
[    21.784] drmOpenDevice: node name is /dev/dri/card0
[    21.784] drmOpenDevice: open result is 9, (OK)
[    21.785] drmOpenByBusid: drmOpenMinor returns 9
[    21.785] drmOpenByBusid: drmGetBusid reports pci:0000:03:00.0
[    21.785] (II) [drm] nouveau interface version: 1.0.0
[    21.785] (II) Loading sub module "dri"
[    21.785] (II) LoadModule: "dri"
[    21.785] (II) Loading /usr/X11/lib/xorg/modules/extensions/libdri.so
[    21.785] (II) Module dri: vendor="X.Org Foundation"
[    21.785]    compiled for 1.12.99, module version = 1.0.0
[    21.785]    ABI class: X.Org Server Extension, version 6.0
[    21.785] (II) NOUVEAU(0): Loaded DRI module
[    21.785] drmOpenDevice: node name is /dev/dri/card0
[    21.786] drmOpenDevice: open result is 10, (OK)
[    21.786] drmOpenDevice: node name is /dev/dri/card0
[    21.786] drmOpenDevice: open result is 10, (OK)
[    21.786] drmOpenByBusid: Searching for BusID pci:0000:03:00.0
[    21.786] drmOpenDevice: node name is /dev/dri/card0
[    21.786] drmOpenDevice: open result is 10, (OK)
[    21.786] drmOpenByBusid: drmOpenMinor returns 10
[    21.786] drmOpenByBusid: drmGetBusid reports pci:0000:03:00.0
[    21.786] (II) [drm] DRM interface version 1.4
[    21.786] (II) [drm] DRM open master succeeded.
[    21.786] (--) NOUVEAU(0): Chipset: "NVIDIA NVa8"
[    21.786] (**) NOUVEAU(0): Depth 24, (--) framebuffer bpp 32
[    21.786] (==) NOUVEAU(0): RGB weight 888
[    21.786] (==) NOUVEAU(0): Default visual is TrueColor
[    21.786] (==) NOUVEAU(0): Using HW cursor
[    21.786] (==) NOUVEAU(0): GLX sync to VBlank disabled.

[    22.198] (II) NOUVEAU(0): Opened GPU channel 2
[    22.226] (II) NOUVEAU(0): [DRI2] Setup complete
[    22.226] (II) NOUVEAU(0): [DRI2]   DRI driver: nouveau
[    22.226] (II) NOUVEAU(0): [DRI2]   VDPAU driver: nouveau
[    22.232] (II) NOUVEAU(0): GART: 512MiB available
[    22.246] (II) NOUVEAU(0): GART: Allocated 16MiB as a scratch buffer
[    22.246] (II) EXA(0): Driver allocated offscreen pixmaps
[    22.246] (II) EXA(0): Driver registered support for the following operations:
[    22.246] (II)         Solid
[    22.246] (II)         Copy
[    22.246] (II)         Composite (RENDER acceleration)
[    22.246] (II)         UploadToScreen
[    22.246] (II)         DownloadFromScreen
[    22.246] (==) NOUVEAU(0): Backing store disabled
[    22.246] (==) NOUVEAU(0): Silken mouse enabled
[    22.246] (II) NOUVEAU(0): [XvMC] Associated with Nouveau GeForce 8/9 Textured Video.
[    22.246] (II) NOUVEAU(0): [XvMC] Extension initialized.
[    22.246] (==) NOUVEAU(0): DPMS enabled
[    22.246] (II) NOUVEAU(0): RandR 1.2 enabled, ignore the following RandR disabled message.
[    22.247] (--) RandR disabled
[    22.247] (II) Initializing built-in extension Generic Event Extension
[    22.247] (II) Initializing built-in extension SHAPE
[    22.247] (II) Initializing built-in extension MIT-SHM
[    22.247] (II) Initializing built-in extension XInputExtension
[    22.247] (II) Initializing built-in extension XTEST
[    22.247] (II) Initializing built-in extension BIG-REQUESTS
[    22.247] (II) Initializing built-in extension SYNC
[    22.247] (II) Initializing built-in extension XKEYBOARD
[    22.247] (II) Initializing built-in extension XC-MISC
[    22.247] (II) Initializing built-in extension XINERAMA
[    22.247] (II) Initializing built-in extension XFIXES
[    22.247] (II) Initializing built-in extension RENDER
[    22.247] (II) Initializing built-in extension RANDR
[    22.247] (II) Initializing built-in extension COMPOSITE
[    22.247] (II) Initializing built-in extension DAMAGE
[    22.328] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer
[    22.328] (II) AIGLX: enabled GLX_INTEL_swap_event
[    22.328] (II) AIGLX: enabled GLX_SGI_swap_control and GLX_MESA_swap_control
[    22.328] (II) AIGLX: GLX_EXT_texture_from_pixmap backed by buffer objects
[    22.328] (II) AIGLX: Loaded and initialized nouveau
[    22.328] (II) GLX: Initialized DRI2 GL provider for screen 0
Comment 1 Boris Reisig 2012-06-30 12:56:44 UTC
Created attachment 63652 [details]
Dmesg of my system.
Comment 2 Boris Reisig 2012-06-30 12:57:17 UTC
Created attachment 63653 [details]
Xorg log
Comment 3 Boris Reisig 2012-06-30 13:01:28 UTC
I did some additional tests with mplayer.

mplayer -vo X11 Test.avi = Works
mplayer -vo Xv Test.avi = Black screen
mplayer -vo gl Test.avi = Works
mplayer -vo gl2 Test.avi = Works

I wonder if it's something specific to nva+ chipsets?
Comment 4 Boris Reisig 2012-07-12 03:23:01 UTC
I downloaded the latest git (both kernel and nouveau driver) and still has the same issue. BTW: This is the AIO PC. ( http://www.zotacusa.com/zbox-hd-id34-blu-ray.html )
Comment 5 Younes Manton 2012-07-14 15:09:11 UTC
Works fine on my NVA8 using mplayer. Have you tried a different video? Have you tried a different player?
Comment 6 Russ Dill 2012-07-18 06:26:18 UTC
Yes, same here:

[    29.786] (--) NOUVEAU(0): Chipset: "NVIDIA NV50"
01:00.0 VGA compatible controller: NVIDIA Corporation G80 [GeForce 8800 GTS] (rev a2)

I have not tested git revisions, but I also get black video on Xvideo playback. I first noticed with mythtv, but Xvideo also does not work under mplayer. However, X11, gl, and gl2 work.

I'm not sure if this is of interest:

Starting playback...
Unsupported PixelFormat 61
Unsupported PixelFormat 53
Unsupported PixelFormat 81
Movie-Aspect is 1.85:1 - prescaling to correct movie aspect.
VO: [xv] 720x464 => 858x464 Planar YV12
Comment 7 Russ Dill 2012-07-18 06:48:43 UTC
I verified that with a build of 5ac2ca8c5 (the parent commit of b48bcc09), xvideo under mplayer does work. Before I had been using 1.0.1.

Unfortunately for me, xvideo under mythtv still produces a black screen. But I can verify Boris's original report.
Comment 8 Russ Dill 2012-07-18 06:54:31 UTC
And now I can verify that under b48bcc094b, mplayer with -vo xv gives a black screen, just like 1.0.1.
Comment 9 Boris Reisig 2012-07-18 17:07:58 UTC
I downloaded the latest nouveau from git today and it's still black when using Xv. I tried with both mplayer AND now vdr and it still black.

03:00.0 VGA compatible controller: NVIDIA Corporation GT218 [ION] (rev a2)
Comment 10 Emil Velikov 2012-07-18 19:21:40 UTC
It may be useful to compare the xorg-server version as well as the output of mplayer
Comment 11 Boris Reisig 2012-07-18 22:07:58 UTC
I am using the latest libdrm, Xorg+drivers and Mesa from git as of yesterday evening.


X -version

X.Org X Server 1.12.99.902 (1.13.0 RC 2)
Release Date: 2012-07-17
X Protocol Version 11, Revision 0
Build Operating System: Linux 3.5.0-rc7 x86_64
Current Operating System: Linux server 3.5.0-rc7 #2 SMP Sun Jul 15 02:03:55 CDT 2012 x86_64
Build Date: 17 July 2012  10:28:24PM

Current version of pixman: 0.26.0
        Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.
Comment 12 Marcin Slusarz 2012-07-19 19:06:17 UTC
Does enabling/disabling compositing change anything?
Is there anything (new) in dmesg during video playback?
Comment 13 Younes Manton 2012-07-19 22:04:58 UTC
I was using 1.12, so I built 1.13 and indeed the screen is black. I don't see how b48bcc could work with 1.12 and not 1.13 though at first glance.
Comment 14 Marcin Slusarz 2012-07-21 13:18:07 UTC
Weird, I can't reproduce it on xserver 1.13.0 RC 2 (NV92 here)
Comment 15 Boris Reisig 2012-07-21 18:34:02 UTC
I tried enabling/disabling compositing and no difference. I wonder if its something specific to the NVAx series?
Comment 16 Boris Reisig 2012-07-28 07:20:35 UTC
Created attachment 64812 [details]
Fix for Xv against the latest xf86-video-nouveau from git.
Comment 17 Boris Reisig 2012-07-28 07:33:48 UTC
I have spent the last day debugging and checking what was different between the two revisions and working against the latest xf86-video-nouveau from git and I have come with a fix (atleast for me) that now shows Xv again. Mplayer and vdr using Xv now works.
Comment 18 Marcin Slusarz 2012-07-31 16:16:59 UTC
Please send it (with a changelog) to Nouveau mailing list.
Comment 19 Ben Skeggs 2012-08-17 04:52:55 UTC
(In reply to comment #16)
> Created attachment 64812 [details]
> Fix for Xv against the latest xf86-video-nouveau from git.
NACK to this patch in its current form.  We need to find out what exactly is wrong rather than revert to a passthrough shader.

That said, I *still* can't reproduce the issue on *either* of my NVA8 boards using the following config:

kernel-3.6.0-0.rc1.git6.1.fc18.x86_64
libdrm-2.4.38-2.fc18.x86_64
xorg-x11-drv-nouveau-1.0.1-4.fc18.x86_64
xorg-x11-server-Xorg-1.12.99.904-1.20120808.fc18.x86_64

Tested using GNOME 3 in normal and fallback mode to test composited vs non-composited.  All good in both cases.

Can you give more information on your environment so I can try and see the issue here?
Comment 20 Boris Reisig 2012-11-17 21:03:08 UTC
If it's not effecting your NVa8 board, maybe its something specific to the GT218 [ION] nvidia cards or NVaX chipsets? (NVIDIA Corporation GT218 [ION] (rev a2)). I just rebuilt the following packages from git today (11/17/2012) to see if it helped and nothing.

linux kernel 3.7.0rc6
libdrm 2.4.40+ (mesa/drm git)
nouveau/xf86-video-nouveau (1.0.4+ git)
xorg (X.Org X Server 1.13.99)

Is their any other info or details I can do to provide you any extra information?
Comment 21 Duane Robertson 2013-04-11 19:01:15 UTC
I'm using version 1.13 of the gentoo xorg-driver package with nouveau selected, and I get exactly the same issue. My card is an ASUS 210. Of course, the nvidia driver works perfectly. Mplayer shows videos in gl, gl2, and x11, but not xv.

Oddly, the problem did not occur when I first installed the card. I put it in and booted with the nvidia driver, then changed over to the nouveau driver, then removed nvidia and continued to test, restarting at each step. Mplayer worked normally at every stage. Then I shut down to put the box back together, restarted, and... black video.

Next I reinstalled the nvidia driver, loaded it, and saw normal video. The nouveau still has the same issue.
Comment 22 Ilia Mirkin 2013-09-26 22:58:53 UTC
Please confirm that this is still an issue with the latest kernel (3.11+) and ddx (1.0.9).
Comment 23 Duane Robertson 2014-03-04 23:48:06 UTC
I no longer have the hardware to confirm this.
Comment 24 Boris Reisig 2014-03-04 23:49:50 UTC
It's working fine now running linux kernel 3.14.0-rc4+ (from git), latest nouveau from git and the latest Mesa 10.1rc3. You can close this bug.
Comment 25 lameventanas 2014-04-21 13:05:27 UTC
I have exaclty the same problem but on different hardware, its a 9400 GT.

06:00.0 VGA compatible controller: NVIDIA Corporation C79 [GeForce 9400] (rev b1)

I am using kernel 3.14.1, mesa3d 10.1.1 and xorg-xf86-video-nouveau 1.0.10.

mplayer -vo xv = black
mplayer -vo vdpau = black
mplayer -vo gl = ok
mplayer -vo gl2 = ok

Please help! I'm so close to ditching nvidia's closed source driver for nouveau.
Comment 26 Ilia Mirkin 2014-04-21 14:37:04 UTC
(In reply to comment #25)
> I have exaclty the same problem but on different hardware, its a 9400 GT.
> 
> 06:00.0 VGA compatible controller: NVIDIA Corporation C79 [GeForce 9400]
> (rev b1)

Actually I'm reasonably sure that this is the same hardware as the original bug reporter. Can you attach dmesg and xorg logs?

> 
> I am using kernel 3.14.1, mesa3d 10.1.1 and xorg-xf86-video-nouveau 1.0.10.
> 
> mplayer -vo xv = black
> mplayer -vo vdpau = black
> mplayer -vo gl = ok
> mplayer -vo gl2 = ok

Odd. VDPAU is a lot more like GL than like Xv.
Comment 27 lameventanas 2014-05-05 03:46:56 UTC
(In reply to comment #26)
> (In reply to comment #25)
> > I have exaclty the same problem but on different hardware, its a 9400 GT.
> > 
> > 06:00.0 VGA compatible controller: NVIDIA Corporation C79 [GeForce 9400]
> > (rev b1)
> 
> Actually I'm reasonably sure that this is the same hardware as the original
> bug reporter. Can you attach dmesg and xorg logs?

Can I send them to you privately via email?

> > 
> > I am using kernel 3.14.1, mesa3d 10.1.1 and xorg-xf86-video-nouveau 1.0.10.
> > 
> > mplayer -vo xv = black
> > mplayer -vo vdpau = black
> > mplayer -vo gl = ok
> > mplayer -vo gl2 = ok
> 
> Odd. VDPAU is a lot more like GL than like Xv.

Finally I could get Xv working, but vdpau is still not.

I had a problem with /dev/dri/* permissions, after fixing that, and changing mplayer's configuration as documented in various forums, its still not working.  But now I don't get a black screen, mplayer just stops after a few frames.
Comment 28 Ilia Mirkin 2014-05-05 11:36:40 UTC
(In reply to comment #27)
> (In reply to comment #26)
> > (In reply to comment #25)
> > > I have exaclty the same problem but on different hardware, its a 9400 GT.
> > > 
> > > 06:00.0 VGA compatible controller: NVIDIA Corporation C79 [GeForce 9400]
> > > (rev b1)
> > 
> > Actually I'm reasonably sure that this is the same hardware as the original
> > bug reporter. Can you attach dmesg and xorg logs?
> 
> Can I send them to you privately via email?

Please attach them here. Feel free to scrub out the lines that you don't want to make public. I mainly want to see the kernel cmdline + nouveau/drm log lines + most of the Xorg log would be nice.

> 
> > > 
> > > I am using kernel 3.14.1, mesa3d 10.1.1 and xorg-xf86-video-nouveau 1.0.10.
> > > 
> > > mplayer -vo xv = black
> > > mplayer -vo vdpau = black
> > > mplayer -vo gl = ok
> > > mplayer -vo gl2 = ok
> > 
> > Odd. VDPAU is a lot more like GL than like Xv.
> 
> Finally I could get Xv working, but vdpau is still not.
> 
> I had a problem with /dev/dri/* permissions, after fixing that, and changing
> mplayer's configuration as documented in various forums, its still not
> working.  But now I don't get a black screen, mplayer just stops after a few
> frames.

Does OpenGL work? What does glxinfo say? How about vdpauinfo? I'm not aware of any hangs. (I assume you have the fw installed... if you didn't it wouldn't hang, just put up lots of errors.) Have you tried multiple videos? mplayer's output would be good too.
Comment 29 lameventanas 2014-05-08 03:31:15 UTC
(In reply to comment #28)
> (In reply to comment #27)
> > (In reply to comment #26)
> > > (In reply to comment #25)
> > > > I am using kernel 3.14.1, mesa3d 10.1.1 and xorg-xf86-video-nouveau 1.0.10.
> > > > 
> > > > mplayer -vo xv = black
> > > > mplayer -vo vdpau = black
> > > > mplayer -vo gl = ok
> > > > mplayer -vo gl2 = ok
> > > 
> > > Odd. VDPAU is a lot more like GL than like Xv.
> > 
> > Finally I could get Xv working, but vdpau is still not.
> > 
> > I had a problem with /dev/dri/* permissions, after fixing that, and changing
> > mplayer's configuration as documented in various forums, its still not
> > working.  But now I don't get a black screen, mplayer just stops after a few
> > frames.
> 
> Does OpenGL work? What does glxinfo say? How about vdpauinfo? I'm not aware
> of any hangs. (I assume you have the fw installed... if you didn't it
> wouldn't hang, just put up lots of errors.) Have you tried multiple videos?
> mplayer's output would be good too.


Sorry, I was not very descriptive, I didn't mean that mplayer hangs, it just stopped after less than a second (no video, just a few audio frames).  So I guess it was decoding, but not able to output any video.

After spending some time, and thanks to your valuable pointers, it is more or less working.

I didn't even have the firmware before, I found out when running vdpauinfo.

Right now it works in about 10% of the cases.  For some files it doesn't work at all.  The ones that work break with some video filters (for example, -vf pp=de).  It this documented somewhere? I would like a list of what works and what doesn't.

Unfortunately, mplayer doesn't fall back to a different video-output when vdpau doesn't work (eg: mplayer -vo vdpau,xv ...).  Some people use a wrapper script to achieve this, I guess I'll do the same.
But at the same time, I didn't notice a big difference in CPU usage between Xv and vdpau, so maybe I'll just stick with Xv.

Overall I'm very happy with nouveau now.  In fact, I just built it into my kernel to get KMS, and ditched nvidia's driver for good, after so many years of being stuck with it.

Not so happy with mplayer issues though, I guess that is why there are so many forks.

Thanks a lot for your invaluable help!
Comment 30 Ilia Mirkin 2014-05-08 11:53:25 UTC
(In reply to comment #29)
> (In reply to comment #28)
> > (In reply to comment #27)
> > > (In reply to comment #26)
> > > > (In reply to comment #25)
> > > > > I am using kernel 3.14.1, mesa3d 10.1.1 and xorg-xf86-video-nouveau 1.0.10.
> > > > > 
> > > > > mplayer -vo xv = black
> > > > > mplayer -vo vdpau = black
> > > > > mplayer -vo gl = ok
> > > > > mplayer -vo gl2 = ok
> > > > 
> > > > Odd. VDPAU is a lot more like GL than like Xv.
> > > 
> > > Finally I could get Xv working, but vdpau is still not.
> > > 
> > > I had a problem with /dev/dri/* permissions, after fixing that, and changing
> > > mplayer's configuration as documented in various forums, its still not
> > > working.  But now I don't get a black screen, mplayer just stops after a few
> > > frames.
> > 
> > Does OpenGL work? What does glxinfo say? How about vdpauinfo? I'm not aware
> > of any hangs. (I assume you have the fw installed... if you didn't it
> > wouldn't hang, just put up lots of errors.) Have you tried multiple videos?
> > mplayer's output would be good too.
> 
> 
> Sorry, I was not very descriptive, I didn't mean that mplayer hangs, it just
> stopped after less than a second (no video, just a few audio frames).  So I
> guess it was decoding, but not able to output any video.
> 
> After spending some time, and thanks to your valuable pointers, it is more
> or less working.
> 
> I didn't even have the firmware before, I found out when running vdpauinfo.
> 
> Right now it works in about 10% of the cases.  For some files it doesn't
> work at all.  The ones that work break with some video filters (for example,
> -vf pp=de).  It this documented somewhere? I would like a list of what works
> and what doesn't.

vf + vdpau generally don't work. If you're looking for deinterlacing, the latest mesa (10.2-rc1) should have support for it (via DEINTERLACE_TEMPORAL), you can turn it on with "mplayer -vo vdpau:deint=3" IIRC. I do recall the black bars being weird when you do that though, but that is an mplayer-only artifact, apparently.

Note that VDPAU is Video Decoding + Presentation. So if you're seeing high cpu usage, it's probably just doing the presentation and not the decoding (for which you don't need firmware, btw). Make sure you're using the appropriate codec (e.g. -vc ffh264vdpau). See http://nouveau.freedesktop.org/wiki/VideoAcceleration/#usingvdpau
Comment 31 lameventanas 2014-11-21 11:51:08 UTC
I'm sorry to say this, but the bug is still there, it comes at goes at random between reboots.

Now I am running:
kernel 3.15.0
xorg-xf86-video-nouveau 1.0.11

And mplayer -vo xv was working fine a minute ago.  Then I rebooted the computer and now the video plays (can hear audio), but a black screen again.

I tested again several times after restarting X, and still get a black window.
Unfortunately I can't test rmmod nouveau, because I built it in the kernel.

I see this in my Xorg log:

bash$ egrep 'WW|EE' /var/log/Xorg.0.log.old 
[  1057.575] Current Operating System: Linux hostname 3.15.0 #8 SMP PREEMPT Thu Nov 20 10:00:10 JST 2014 x86_64
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[  1057.576] (WW) The directory "/usr/share/fonts/X11/OTF/" does not exist.
[  1057.577] (EE) systemd-logind: failed to get session: The name org.freedesktop.login1 was not provided by any .service files
[  1057.746] (EE) NOUVEAU(0): [COPY] failed to allocate class.
[  1117.476] (EE) Server terminated successfully (0). Closing log file.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.