|
Description
Oleksij Rempel
2009-10-04 23:09:42 UTC
Hi *, I also reported the same issue in: http://bugzilla.kernel.org/show_bug.cgi?id=14312 but Gordon Jin said to track it here. Basically it is the same but with: 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07) 00:02.1 Display controller [0380]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a43] (rev 07) and that I bisected down to v2.6.31-rc9-145-g74dff28. Thanks, Santi Created attachment 30351 [details] [review] fbc suspend/resume fix Does this patch help? I'm afraid FBC might have been enabled across suspend/resume but without a valid base register, which may have clobbered memory. No, this patch do not solve this problem. I also noticed, after resume intel_gpu_top show "Framebuffer Compression 100%", before suspend you don't see "Framebuffer Compression" with gpu_top at all. (In reply to comment #2) > Created an attachment (id=30351) [details] > fbc suspend/resume fix > > Does this patch help? I'm afraid FBC might have been enabled across > suspend/resume but without a valid base register, which may have clobbered > memory. > No, there is no difference with this patch in my case. Thanks, Santi How about this one? It's upstream now I think, so maybe your problem has gone away? commit 629598da932cfa5ff398fe10bc123282a6f3049e Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Tue Oct 20 07:37:32 2009 +0900 drm/i915: update watermarks before enabling PLLs no, this patch do not fix it for me. Can you load the drm module with debugging enabled? I think you can load it with debug=0x06 to get the messages I want, just attach the output of dmesg after doing that and suspending & resuming here. Created attachment 31362 [details]
dmesg with drm.debug=0x06
(In reply to comment #5) > How about this one? It's upstream now I think, so maybe your problem has gone > away? > > commit 629598da932cfa5ff398fe10bc123282a6f3049e > Author: Jesse Barnes <jbarnes@virtuousgeek.org> > Date: Tue Oct 20 07:37:32 2009 +0900 > > drm/i915: update watermarks before enabling PLLs > I don't know for the submiter but for me (see Comment #1) it is already fixed. I don't know exactly the commit but for sure it works with the -rc after the commits: http://bugzilla.kernel.org/show_bug.cgi?id=14312#c3 Thanks, Santi @Santi, this is different bug. FBC is brocken after resume and use 100% GPU. After some time GPU freeze. My question is, are all 945GME affected? I don't think so, but I'm building the latest bits on my 945GME test machine to verify. FWIW: I also get 100% FBC in intel_gpu_top after resume, followed by the a freeze. Please let me know if I can help debugging this any further. In the meantime: is there an easy way of disabling FBC (sorry if this is a stupid question). Some possibly relevant output. Let me know if I should post anything else. > uname -a Linux x60 2.6.32-rc8 #17 SMP PREEMPT Sat Nov 21 18:18:43 CET 2009 x86_64 Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz GenuineIntel GNU/Linux > lspci 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03) 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03) 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02) 00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02) 00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 02) 00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 (rev 02) 00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 (rev 02) 00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 02) 00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 02) 00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 02) 00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 02) 00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 02) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2) 00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02) 00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 02) 00:1f.2 SATA controller: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA AHCI Controller (rev 02) 00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 02) 02:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet Controller 03:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02) 15:00.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b4) 15:00.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C552 IEEE 1394 Controller (rev 09) 15:00.2 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 18) My machine suspends & resumes just fine with FBC enabled. I'm able to play video after resume and I haven't seen any flicker yet. Your logs don't have the info I needed, can you build a kernel from Eric's drm-intel-next branch (at git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel.git)? That should give me the messages I'm looking for with debug=6. I'm particularly interested in seeing your dmesg after resume, it should have FBC and FIFO info. Created attachment 31717 [details]
drm-intel-next with debug=6 after resume
I hope this dmesg will tell you something.
I might have messed up a bit as I merged drm-intel-next into v2.6.32 from linus, which I later realised was not the correct thing to do. If you want, I might have time to do it properly tomorrow.
I notice that my dmesg is truncated, is there a way to avoid this (in case you need all of it)?
Let me know if there is something else I could do to provide you with more info,
-t
Created attachment 31727 [details]
dmesg with drm.debug=6 video briocken on start
@Jesse,
latest drm-next do not working for me at all.
but here is some news, i was able to reproduce this issue without suspend. After i started my netbook with attached video projector, it got same symptoms - random flickering and intel-gpu-top show FBC use 100%.
With latest drm-next kernel, with normal start i can see console cursor blinking, probably Xserver can't start. With attached external monitor, i can't see anything...
Created attachment 31729 [details]
dmesg drm.debug=6 with external display
ok, latest working drm-next is 2.6.32-rc6-00278-gf40d681. I can reproduce this issue on suspend or without suspend, just start with external display.
Arg, sorry to ask for another dmesg. :) But drm debug=6 is way too verbose, I'm losing the messages I want. Can you try debug=4 instead of 6? That should get me just the KMS related msgs and not all the "add request" ones. Created attachment 31749 [details]
drm-intel-next with debug=4 after resume
Is this better?
Created attachment 31750 [details]
dmesg; debug=4; external display
Created attachment 31751 [details]
dmesg; debug=4; local display after resume
Created attachment 31753 [details] [review] Unlock self-refresh bits on 945 The FIFO settings look identical between suspend and resume, so I guess that's not the issue if things were working fine before suspending. But on 945 there are some unlock bits Li Peng recently posted a fix for. Can you try this patch to see if it helps? No, still the same :( Ah, just thought of something... maybe at resume time we set FBC to use the wrong fence reg? We should reset it as part of the resume mode set, but it's possible things get out of sync. That might explain the bad behavior... I'll check on that, it should be easy to verify if you can capture a post-resume register dump along with the dmesg. Created attachment 31787 [details]
intel_reg_dumper output before suspend (EeePC 901)
Created attachment 31788 [details]
intel_reg_dumper output after resume (EeePC 901)
Created attachment 31789 [details]
intel_reg_dumper output before suspend (EeePC 901, running X)
Created attachment 31790 [details]
intel_reg_dumper output after resume (EeePC 901, running X)
Created attachment 31803 [details]
reg dump, eeepc 1005ha, clean start
To make your live more complicated i add my dumps too :)
1. dump is after clean start.
2. dump after resume
3. dump on start with external display
Created attachment 31804 [details]
reg dump, eeepc 1005ha, after resume
Created attachment 31805 [details]
reg dump, eeepc 1005ha, start with external display
Does the current drm-intel-next branch still have this issue? (In reply to comment #31) > Does the current drm-intel-next branch still have this issue? > At least for me and my Samsung NC10 I still have this problem. My HP mini netbook also seemed to be affected by this bug while testing .32 kernel (so I'm still on .31). The bug is IMHO correctly marked as critical, and since .33 final is approaching and there seems to be no fix for this yet, I wanted to ask if it wouldn't be better to revert this feature on 945G chips before .33 final comes out and then try again for .34? (I don't know Intel's exact policy in these cases, so I'm just asking). This appears to be the same bug as Bug #15043 on bugzilla.kernel.org: Display goes off with i915.powersave=1 after suspend-resume http://bugzilla.kernel.org/show_bug.cgi?id=15043 BTW, I have an Acer Aspire One (ZG5) with 945GSE graphics and I get this problem too. The latest intel-drm-next kernel I have tried was from January 31st. *** Bug 24928 has been marked as a duplicate of this bug. *** Can you try this patch? http://patchwork.kernel.org/patch/75423/ There's another patch in the current drm-intel-next tree that might help as well: commit 72ddbd39f39b3cc5f1f661f97e67f2a497c4d57a Author: Li Peng <peng.li@linux.intel.com> Date: Tue Jan 19 21:32:57 2010 +0800 drm/i915: enable memory self refresh on 9xx Can you test? (In reply to comment #36) > Can you try this patch? http://patchwork.kernel.org/patch/75423/ > > There's another patch in the current drm-intel-next tree that might help as > well: > commit 72ddbd39f39b3cc5f1f661f97e67f2a497c4d57a > Author: Li Peng <peng.li@linux.intel.com> > Date: Tue Jan 19 21:32:57 2010 +0800 > > drm/i915: enable memory self refresh on 9xx > > Can you test? > When attempting to patch drm-intel-next with "Disable SR when more than one pipe is enabled" (http://patchwork.kernel.org/patch/75423/) The following hunk is rejected: --- drivers/gpu/drm/i915/intel_display.c +++ drivers/gpu/drm/i915/intel_display.c @@ -2638,6 +2646,10 @@ if (srwm < 0) srwm = 1; I915_WRITE(FW_BLC_SELF, FW_BLC_SELF_EN | (srwm & 0x3f)); + } else { + /* Turn off self refresh if both pipes are enabled */ + I915_WRITE(FW_BLC_SELF, I915_READ(FW_BLC_SELF) + & ~FW_BLC_SELF_EN); } DRM_DEBUG_KMS("Setting FIFO watermarks - A: %d, B: %d, C: %d, SR %d\n", This is due to: > commit 72ddbd39f39b3cc5f1f661f97e67f2a497c4d57a > Author: Li Peng <peng.li@linux.intel.com> > Date: Tue Jan 19 21:32:57 2010 +0800 > > drm/i915: enable memory self refresh on 9xx Ah that patch needs to be fixed up a little. For 945 you can just add the hunk to the end (as an else for the if (HAS_FW_BLC...) conditional). If you have an I915, you'll have to add a path to disable SR in INSTPM just like the enable path has. Don't know if this will help, but FBC in UMS worked fine (xf86-video-intel 2.9.1, kernel 2.6.32.7 vanilla) That's a good data point, it means we should be able to get it working here. Though there were some cases in the UMS driver where it would get silently disabled... Nope patches do not fix. Same symptoms: A) During "intense" graphics operations, such as window resize, playing videos, or scrolling stuff, there will be the occasional screen "jump" occurring every few minutes. Examples of screen jump include the screen getting offset to the left by several pixels for a fraction of a second, the same but offset vertically, etc. B) Finally, after several tens of minutes (in this case, 20), the screen goes black (but backlight still on). VT switch doesn't do anything. Had to ssh in to get logs & reboot. Hardware is a Acer Aspire One (ZG5 Model) with 945GSE But this only happens after a suspend/resume cycle? After a fresh boot things are fine? When I first encountered this bug during normal use, this didn't happen from a fresh boot. I didn't check this time though, I just suspended right after I finished booting. Another couple of hunks to try. On the off chance this works, it would be good
to know whether it's the FBC change or the SR change that fixes it.
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 3dd8018..01c2b95 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -341,6 +341,7 @@
#define FBC_CTL_EN (1<<31)
#define FBC_CTL_PERIODIC (1<<30)
#define FBC_CTL_INTERVAL_SHIFT (16)
+#define FBC_C3_IDLE (1<<13)
#define FBC_CTL_UNCOMPRESSIBLE (1<<14)
#define FBC_CTL_STRIDE_SHIFT (5)
#define FBC_CTL_FENCENO (1<<0)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_d
index 06761e4..c0861e0 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -913,7 +913,7 @@ static void i8xx_enable_fbc(struct drm_crtc *crtc, unsigned
I915_WRITE(FBC_FENCE_OFF, crtc->y);
/* enable it... */
- fbc_ctl = FBC_CTL_EN | FBC_CTL_PERIODIC;
+ fbc_ctl = FBC_CTL_EN | FBC_C3_IDLE | FBC_CTL_PERIODIC;
fbc_ctl |= (dev_priv->cfb_pitch & 0xff) << FBC_CTL_STRIDE_SHIFT;
fbc_ctl |= (interval & 0x2fff) << FBC_CTL_INTERVAL_SHIFT;
if (obj_priv->tiling_mode != I915_TILING_NONE)
@@ -2631,7 +2631,9 @@ static void i9xx_update_wm(struct drm_device *dev, int
pla
if (srwm < 0)
srwm = 1;
if (IS_I945G(dev) || IS_I945GM(dev))
- I915_WRITE(FW_BLC_SELF, FW_BLC_SELF_FIFO_MASK | (srwm &
+ I915_WRITE(FW_BLC_SELF, FW_BLC_SELF_EN_MASK |
+ FW_BLC_SELF_FIFO_MASK | FW_BLC_SELF_EN |
+ (srwm & 0xff));
else if (IS_I915GM(dev)) {
/* 915M has a smaller SRWM field */
I915_WRITE(FW_BLC_SELF, srwm & 0x3f);
(In reply to comment #43) > When I first encountered this bug during normal use, this didn't happen from a > fresh boot. I didn't check this time though, I just suspended right after I > finished booting. > Can you test if you can trigger it by enabling/disabling an external display? Or by just playing around with xrandr? I can't test it at the moment but I think I could trigger it that way. (In reply to comment #44) > Another couple of hunks to try. On the off chance this works, it would be good > to know whether it's the FBC change or the SR change that fixes it. > > diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h > index 3dd8018..01c2b95 100644 > --- a/drivers/gpu/drm/i915/i915_reg.h > +++ b/drivers/gpu/drm/i915/i915_reg.h > @@ -341,6 +341,7 @@ > #define FBC_CTL_EN (1<<31) > #define FBC_CTL_PERIODIC (1<<30) > #define FBC_CTL_INTERVAL_SHIFT (16) > +#define FBC_C3_IDLE (1<<13) > #define FBC_CTL_UNCOMPRESSIBLE (1<<14) > #define FBC_CTL_STRIDE_SHIFT (5) > #define FBC_CTL_FENCENO (1<<0) > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_d > index 06761e4..c0861e0 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -913,7 +913,7 @@ static void i8xx_enable_fbc(struct drm_crtc *crtc, unsigned > I915_WRITE(FBC_FENCE_OFF, crtc->y); > > /* enable it... */ > - fbc_ctl = FBC_CTL_EN | FBC_CTL_PERIODIC; > + fbc_ctl = FBC_CTL_EN | FBC_C3_IDLE | FBC_CTL_PERIODIC; > fbc_ctl |= (dev_priv->cfb_pitch & 0xff) << FBC_CTL_STRIDE_SHIFT; > fbc_ctl |= (interval & 0x2fff) << FBC_CTL_INTERVAL_SHIFT; > if (obj_priv->tiling_mode != I915_TILING_NONE) > @@ -2631,7 +2631,9 @@ static void i9xx_update_wm(struct drm_device *dev, int > pla > if (srwm < 0) > srwm = 1; > if (IS_I945G(dev) || IS_I945GM(dev)) > - I915_WRITE(FW_BLC_SELF, FW_BLC_SELF_FIFO_MASK | (srwm & > + I915_WRITE(FW_BLC_SELF, FW_BLC_SELF_EN_MASK | > + FW_BLC_SELF_FIFO_MASK | FW_BLC_SELF_EN | > + (srwm & 0xff)); > else if (IS_I915GM(dev)) { > /* 915M has a smaller SRWM field */ > I915_WRITE(FW_BLC_SELF, srwm & 0x3f); > > > This works! (I suspended-resumed it, then left it on overnight while looping a movie trailer). I am in the process of testing which part of the patch fixed it. (In reply to comment #44) > diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h > index 3dd8018..01c2b95 100644 > --- a/drivers/gpu/drm/i915/i915_reg.h > +++ b/drivers/gpu/drm/i915/i915_reg.h > @@ -341,6 +341,7 @@ > #define FBC_CTL_EN (1<<31) > #define FBC_CTL_PERIODIC (1<<30) > #define FBC_CTL_INTERVAL_SHIFT (16) > +#define FBC_C3_IDLE (1<<13) > #define FBC_CTL_UNCOMPRESSIBLE (1<<14) > #define FBC_CTL_STRIDE_SHIFT (5) > #define FBC_CTL_FENCENO (1<<0) > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_d > index 06761e4..c0861e0 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -913,7 +913,7 @@ static void i8xx_enable_fbc(struct drm_crtc *crtc, unsigned > I915_WRITE(FBC_FENCE_OFF, crtc->y); > > /* enable it... */ > - fbc_ctl = FBC_CTL_EN | FBC_CTL_PERIODIC; > + fbc_ctl = FBC_CTL_EN | FBC_C3_IDLE | FBC_CTL_PERIODIC; > fbc_ctl |= (dev_priv->cfb_pitch & 0xff) << FBC_CTL_STRIDE_SHIFT; > fbc_ctl |= (interval & 0x2fff) << FBC_CTL_INTERVAL_SHIFT; > if (obj_priv->tiling_mode != I915_TILING_NONE) This fixes it. :D Yay, I was starting to get worried. I'll send that patch upstream now. *** Bug 25371 has been marked as a duplicate of this bug. *** Fix pushed to drm-intel-next: commit ee25df2bc379728c45d81e04cf87984db1425edf drm/i915: handle FBC and self-refresh better On 945, we need to avoid entering self-refresh if the compressor is busy, or we may cause display FIFO underruns leading to ugly flicker. Fixes fdo bug #24314, kernel bug #15043. Err I mean for-linus. (In reply to comment #44) > Another couple of hunks to try. On the off chance this works, it would be good > to know whether it's the FBC change or the SR change that fixes it. > > diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h > index 3dd8018..01c2b95 100644 > --- a/drivers/gpu/drm/i915/i915_reg.h > +++ b/drivers/gpu/drm/i915/i915_reg.h > @@ -341,6 +341,7 @@ > #define FBC_CTL_EN (1<<31) > #define FBC_CTL_PERIODIC (1<<30) > #define FBC_CTL_INTERVAL_SHIFT (16) > +#define FBC_C3_IDLE (1<<13) > #define FBC_CTL_UNCOMPRESSIBLE (1<<14) > #define FBC_CTL_STRIDE_SHIFT (5) > #define FBC_CTL_FENCENO (1<<0) > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_d > index 06761e4..c0861e0 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -913,7 +913,7 @@ static void i8xx_enable_fbc(struct drm_crtc *crtc, unsigned > I915_WRITE(FBC_FENCE_OFF, crtc->y); > > /* enable it... */ > - fbc_ctl = FBC_CTL_EN | FBC_CTL_PERIODIC; > + fbc_ctl = FBC_CTL_EN | FBC_C3_IDLE | FBC_CTL_PERIODIC; > fbc_ctl |= (dev_priv->cfb_pitch & 0xff) << FBC_CTL_STRIDE_SHIFT; > fbc_ctl |= (interval & 0x2fff) << FBC_CTL_INTERVAL_SHIFT; > if (obj_priv->tiling_mode != I915_TILING_NONE) > @@ -2631,7 +2631,9 @@ static void i9xx_update_wm(struct drm_device *dev, int > pla > if (srwm < 0) > srwm = 1; > if (IS_I945G(dev) || IS_I945GM(dev)) > - I915_WRITE(FW_BLC_SELF, FW_BLC_SELF_FIFO_MASK | (srwm & > + I915_WRITE(FW_BLC_SELF, FW_BLC_SELF_EN_MASK | > + FW_BLC_SELF_FIFO_MASK | FW_BLC_SELF_EN | > + (srwm & 0xff)); > else if (IS_I915GM(dev)) { > /* 915M has a smaller SRWM field */ > I915_WRITE(FW_BLC_SELF, srwm & 0x3f); > > > After building a 2.6.33-r5 kernel from here (Snapshot): http://git.kernel.org/?p=linux/kernel/git/anholt/drm-intel.git;a=commit;h=0f318cd689ef0758e7ebf0f92d3a21e711e18950 And changing the i915_debugfs.c to this: http://git.kernel.org/?p=linux/kernel/git/anholt/drm-intel.git;a=blob_plain;f=drivers/gpu/drm/i915/i915_debugfs.c;hb=0f318cd689ef0758e7ebf0f92d3a21e711e18950 I still have this issue, although the flickering is improved. If I did this wrong, please tell me. Running Debian sid on an eeepc 1005ha Yeah, that's the wrong commit. You want this one: http://git.kernel.org/?p=linux/kernel/git/anholt/drm-intel.git;a=commit; h=ee25df2bc379728c45d81e04cf87984db1425edf I'm still experiencing same issues (although, less frequently) under 2.6.33-rc8. Should I reopen this bug or start a new one on either kernel bugzilla or here? Card info: (--) PCI:*(0:0:2:0) 8086:27a2:17aa:201a Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller rev 3, Mem @ 0xee100000/524288, 0xd0000000/268435456, 0xee200000/262144, I/O @ 0x00001800/8 (--) PCI: (0:0:2:1) 8086:27a6:17aa:201a Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller rev 3, Mem @ 0xee180000/524288 Closing really old resolved+fixed. |
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.