[Bug 85107] A10-7800: Boot problems (CPU stuck) and dpm not working correctly
https://bugs.freedesktop.org/show_bug.cgi?id=85107 --- Comment #9 from Marcel Witte --- Today I tried to use radeon.dpm=0 to get the full performance, but I noticed that with radeon.dpm=0 I get the CPU stuck errors again, even with radeon.bapm=0. So the only way to boot without these errors is "radeon.bapm=0" or "radeon.bapm=0 radeon.dpm=1". -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141019/8dc7cd07/attachment.html>
[Bug 85207] agd5f drm-next-3.19-wip + Unreal Elemental sometimes = list_add corruption/hung task
https://bugs.freedesktop.org/show_bug.cgi?id=85207 --- Comment #1 from Andy Furniss --- Also noticed in that dmesg and searching kern log that I sometimes get apparently without effect - kernel: [drm:radeon_gem_va_update_vm] *ERROR* Couldn't update BO_VA (-512) With this kernel. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141019/c75354f3/attachment-0001.html>
[Bug 85207] New: agd5f drm-next-3.19-wip + Unreal Elemental sometimes = list_add corruption/hung task
https://bugs.freedesktop.org/show_bug.cgi?id=85207 Bug ID: 85207 Summary: agd5f drm-next-3.19-wip + Unreal Elemental sometimes = list_add corruption/hung task Product: DRI Version: XOrg CVS Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel at lists.freedesktop.org Reporter: adf.lists at gmail.com Created attachment 108075 --> https://bugs.freedesktop.org/attachment.cgi?id=108075&action=edit dmesg when Unreal Elemental hangs on start R9270X Sometime running unreal elemental demo it hangs at startup with errors in dmesg attached. This doesn't always happen. Mesa is currently on winsys/radeon: Use a single buffer cache manager again, previously produced with slightly older. Haven't seen on drm-next-3.18-wip (but really need to test more with current mesa) Possibly unrelated, but new for drm-next-3.19-wip I get below when running Unigine Valley - it runs OK. Oct 17 11:15:35 ph4 kernel: radeon :01:00.0: GPU fault detected: 146 0x0af03504 Oct 17 11:15:35 ph4 kernel: radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00010E57 Oct 17 11:15:35 ph4 kernel: radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x10035004 Oct 17 11:15:35 ph4 kernel: VM fault (0x04, vmid 8) at page 69207, read from VGT (53) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141019/4e253876/attachment.html>
[Bug 84662] Long pauses with Unreal demo Elemental on R9270X since : Always flush the HDP cache before submitting a CS to the GPU
https://bugs.freedesktop.org/show_bug.cgi?id=84662 --- Comment #45 from Andy Furniss --- (In reply to Andy Furniss from comment #43) > (In reply to Michel D?nzer from comment #42) > > (In reply to Andy Furniss from comment #40) > > > It's still not right for me and never has been. > > > > Define 'right'. What's the target we're aiming for here? > > > > > > > Last night I updated kernel to agd5f 3.19-wip and current mesa, after > > > applying the mesa patches I got a lockup/crash. > > > > Please file another report about that. > > Haven't had much time, but I have failed to reproduce so far with updated > mesa (and I am making sure to restart X now so glamor is not running > different code) Ignore that, I just reproduced it, will file a new bug, though I am a few days old on mesa/kernel now. -- You are receiving this mail because: You are the assignee for the bug. -- next part ------ An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141019/74719f1c/attachment.html>
[Bug 84500] [radeonsi] radeon 0000:01:00.0: Packet0 not allowed!
https://bugs.freedesktop.org/show_bug.cgi?id=84500 --- Comment #28 from Christian K?nig --- (In reply to Alexandre Demers from comment #27) > (In reply to Christian K?nig from comment #22) > > Keep in mind that this might actually be a user space problem and that > > different kernel versions work or don't work only be coincident. > > > > If you can get me an SSH access to the box I could take a look as well. > > Attaching a debugger to the process in question shouldn't be to hard. > > By the way, if I understand correctly, if the bug is in userspace and was > introduced around the same time kernel 3.17-rcX went out, would it appears > when using a previous kernel version? I'm trying to figure out a way to > distinguish one from the other because from where I am in the bisection, I > was unable to reproduce the bug with a 3.16 kernel, but it does appear > before 3.17-rc1... It is possible that a new kernel let this problem surface by coincident. E.g. a slightly different memory layout or allocation timing and instead of changing two random pixel on the screen we change the command buffer and the whole box crashes and/or shows this error. All you can do is to try to figure out when the corruption happens. The kernel copies the command buffer content from userspace to a kernel buffer and then checks the content of the kernel buffer. Might be a good idea to print the content of the userspace buffer as well and compare both? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141019/1fd1ae97/attachment.html>
[Bug 84662] Long pauses with Unreal demo Elemental on R9270X since : Always flush the HDP cache before submitting a CS to the GPU
https://bugs.freedesktop.org/show_bug.cgi?id=84662 --- Comment #44 from Andy Furniss --- (In reply to Michel D?nzer from comment #42) > (In reply to Andy Furniss from comment #40) > > It's still not right for me and never has been. > > Define 'right'. What's the target we're aiming for here? It's still stuttery, but it could be my 4G mem/the way the game loads. If I run from clean most of the stutters/long start time correspond with "vmstat 1" showing disk activity. It seems having 4 gig (swap is off to avoid extra disk use) it seems I don't have enough ram to disk cache the whole demo. If I stop it after a while I can get the first bit cached (ie. I can run it without vmstat 1 showing anything), but it's still stuttery in the places where it would be loading from disk were it first run. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141019/887c8df7/attachment.html>
[Bug 84662] Long pauses with Unreal demo Elemental on R9270X since : Always flush the HDP cache before submitting a CS to the GPU
https://bugs.freedesktop.org/show_bug.cgi?id=84662 --- Comment #43 from Andy Furniss --- (In reply to Michel D?nzer from comment #42) > (In reply to Andy Furniss from comment #40) > > It's still not right for me and never has been. > > Define 'right'. What's the target we're aiming for here? > > > > Last night I updated kernel to agd5f 3.19-wip and current mesa, after > > applying the mesa patches I got a lockup/crash. > > Please file another report about that. Haven't had much time, but I have failed to reproduce so far with updated mesa (and I am making sure to restart X now so glamor is not running different code) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141019/52cf24d3/attachment.html>
[Bug 84944] tearing on radeonsi vdpau deinterlacer
https://bugs.freedesktop.org/show_bug.cgi?id=84944 --- Comment #3 from warpme at o2.pl --- It is seen in upper part of screen as classical division between to parts of content shifted horizontally. This picture looks almost exactly like issue I'm experiencing: http://en.wikipedia.org/wiki/Screen_tearing#mediaviewer/File:Tearing_(simulated).jpg Difference is that tearing line is in upper part of screen (approx at 20% of screen height) br -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141019/58df9a18/attachment-0001.html>
[Bug 83461] hdmi screen flicker/unusable
https://bugzilla.kernel.org/show_bug.cgi?id=83461 --- Comment #8 from kb at spatium.org --- Also, I've noticed that when X boots, the "good" kernels give this sequence: 1) TV blanks with "No signal" message briefly 2) Desktop shows normally And the "bad" kernels give: 1) TV blanks with "Mode not supported" message for a longer time 2) Desktop shows, blinking and/or flickering -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 83461] hdmi screen flicker/unusable
https://bugzilla.kernel.org/show_bug.cgi?id=83461 --- Comment #7 from kb at spatium.org --- 32167016076f714f0e35e287fbead7de0f1fb179 is the first bad commit commit 32167016076f714f0e35e287fbead7de0f1fb179 Author: Christian K?nig Date: Fri Mar 28 18:55:10 2014 +0100 drm/radeon: rework finding display PLL numbers v2 This completely reworks how the PLL parameters are generated and should result in better matching dot clock frequencies. Probably needs quite a bit of testing. bugs: https://bugs.freedesktop.org/show_bug.cgi?id=76564 v2: more cleanup and comments. Signed-off-by: Christian K?nig Reviewed-by: Alex Deucher :04 04 1a91914271fc3761ec6961fa0cc4bded879bd05c c0ab21500dcb8d2876f4744e4465c9aa7203a113 Mdrivers -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 85204] [Radeon HD 5650] return from sleep state failed
https://bugs.freedesktop.org/show_bug.cgi?id=85204 --- Comment #2 from Rafael Pereira --- Created attachment 108071 --> https://bugs.freedesktop.org/attachment.cgi?id=108071&action=edit lspci graphic card infos lspci output for video card -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141019/31f7c04d/attachment.html>
[Bug 85204] [Radeon HD 5650] return from sleep state failed
https://bugs.freedesktop.org/show_bug.cgi?id=85204 --- Comment #1 from Rafael Pereira --- Created attachment 108070 --> https://bugs.freedesktop.org/attachment.cgi?id=108070&action=edit Kernel Config Kernel config - 3.17.1 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141019/88d51673/attachment.html>
[Bug 85204] New: [Radeon HD 5650] return from sleep state failed
3 succeeded in 1 usecs -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141019/c4219573/attachment.html>
[Bug 84500] [radeonsi] radeon 0000:01:00.0: Packet0 not allowed!
https://bugs.freedesktop.org/show_bug.cgi?id=84500 --- Comment #27 from Alexandre Demers --- (In reply to Christian K?nig from comment #22) > Keep in mind that this might actually be a user space problem and that > different kernel versions work or don't work only be coincident. > > If you can get me an SSH access to the box I could take a look as well. > Attaching a debugger to the process in question shouldn't be to hard. By the way, if I understand correctly, if the bug is in userspace and was introduced around the same time kernel 3.17-rcX went out, would it appears when using a previous kernel version? I'm trying to figure out a way to distinguish one from the other because from where I am in the bisection, I was unable to reproduce the bug with a 3.16 kernel, but it does appear before 3.17-rc1... -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141019/56b346ed/attachment.html>
[Bug 79980] Random radeonsi crashes
https://bugs.freedesktop.org/show_bug.cgi?id=79980 --- Comment #165 from Marti Raudsepp --- After upgrading to kernel 3.17.1, these GPU hangs/crashes still occur, but now it doesn't hang the whole machine any more. Sometimes it recovers from the GPU hang completely, sometimes it just drops me into a text console. Thanks, that's an improvement. I am using Radeon R9 270 on Arch Linux. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141019/3aaee0ea/attachment.html>
[Bug 79980] Random radeonsi crashes
https://bugs.freedesktop.org/show_bug.cgi?id=79980 --- Comment #164 from Jacob --- So after testing 3.15-rc2 for about 3 days without any crashes, I decided to once again test 3.15-rc3 to see if it would crash on me again, which it did. The OS just stopped responding to anything, then my monitors went black, just like it has done for me on 3.16 and 3.17 as well. I ran a bisection between the two releases, and the result was the following: Bisecting: 120 revisions left to test after this (roughly 7 steps) [3fe89d2e768792a924d3c1e9310ba0b4448cb78e] Merge tag 'fixes-3.15-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc Seems weird that arm got anything to do with this issue, but even after running "git bisect bad" until the end, it doesn't pick out anything committed to drm/radeon. Nonetheless, I compiled the kernel, and I'll now test it to see if it'll crash or not, then run git bisect bad until the kernel gets stable once again. I'll report back if I either manage to compile a kernel which is stable, or if I don't -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141019/8f0b5a62/attachment.html>
[Bug 85311] radeon 0000:01:00.0: Max Payload Size 16384, but upstream 0000:00:01.0 set to 128; if necessary, use "pci=pcie_bus_safe" and report a bug
https://bugzilla.kernel.org/show_bug.cgi?id=85311 --- Comment #4 from Pali Roh?r --- Ok, so to who or where to report this problem? -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH] drm/i915/vlv: don't try to enable a crtc without fb
On Sat, Oct 18, 2014 at 03:56:38PM +0300, Ville Syrj?l? wrote:
> On Fri, Oct 17, 2014 at 06:53:34PM -0400, Rob Clark wrote:
> > On valleyview, all enabled pipes get added to the prepare mask. However
> > if you did state readout to find that the crtc is enabled, but failed to
> > map stolen mem and wrap it in a bo (and fb), you could end up in a
> > scenario where crtc->primary->fb is still null on first modeset. So
> > lets check for this rather than exploding.
> >
> > Signed-off-by: Rob Clark
> > ---
> > As with
> > http://lists.freedesktop.org/archives/dri-devel/2014-September/069341.html
> > the root cause is issues with stolen region. But it would be nice if
> > i915 was a bit less fragile when things don't go as planned.
> >
> > This could have the side effect that, at first modeset, the crtc's which
> > were enabled by BIOS but not yet set (by fbcon or userspace) get disabled.
> > This is a somewhat lesser inconvenience compared to opps'ing under
> > console_lock.
> >
> > drivers/gpu/drm/i915/intel_display.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index d8324c6..9f85033 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -10895,6 +10895,9 @@ static int __intel_set_mode(struct drm_crtc *crtc,
> >
> > /* Now enable the clocks, plane, pipe, and connectors that we set up. */
> > for_each_intel_crtc_masked(dev, prepare_pipes, intel_crtc) {
> > + if (!intel_crtc->base.primary->fb)
> > + continue;
> > +
>
> I think the right fix would be to turn off the primary plane during
> the sanitize phase. Although our primary plane code isn't quite up to
> the task yet since we'd still try to turn it back on during
> .crtc_enable(). The code is somewhat in flux currently and hopefully
> soon we'd be able to handle that case correctly.
>
> In the meantime we could potentially disable the whole crtc in
> intel_sanitize_crtc() or we could stick a hack into
> intel_enable_primary_hw_plane() so that it won't try to enable the plane
> w/o an fb (with a comment stating that it's a temporary kludge).
Yeah, I think whacking a temporary hack into sanitize_crtc is the better
option. Long term we really want what Ville said and just disable the
primary plane. But until we've fully untangled that mess in prep for
atomic modesets we can't do that just yet.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Intel-gfx] v3.17, i915 vs nouveau: possible recursive locking detected
On Sat, Oct 18, 2014 at 12:04:32PM +0200, Jesse Barnes wrote: > On Thu, 16 Oct 2014 13:47:38 +0200 > Daniel Vetter wrote: > > > We need ww mutexes and need to rewrite i915 a bit fo fix this all. > > I.e. known issue. As long as your userspace isn't nasty nothing bad > > will ever happen though. > > So do we already have a bug open with a good description of the issue? > Eventually the streets will run with blood and we'll enter the 6th > republic of i915, so it would be good to have it on the hit list for > when the time comes... https://bugzilla.kernel.org/show_bug.cgi?id=60534 I've updated the bug with latest status. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Intel-gfx] [RFC PATCH 2/3] drm/ipvr: drm driver for vxd392
On Thu, Oct 16, 2014 at 03:47:08PM +0200, David Herrmann wrote: > Hi > > On Thu, Oct 16, 2014 at 3:39 PM, Cheng, Yao wrote: > > Accepted :) I will update the patch to implement the mmap interface and > > remove the legacy MMAP_IOCTL. > > BTW I didn't see a field to get mmap_offset in struct drm_gem_open, I guess > > something like a new "GET_MMAP_OFFSET_IOCTL" need be added to support > > mapping flinked/primed BO, is it? > > Yes. There is currently no generic interface to get mmap offsets for > any gem bo (because some of them may not be mapped from user-space or > require extra parameters). > > So, either support dumb-buffers (if you don't need any advanced > parameters like tiling or cache constraints), or add an > MMAP_OFFSET_IOCTL like you proposed (and most drivers do so). Dave Airlie _really_ doesn't like it if userspace abuses the dumb buffer interface for rendering. That really should only be used for sw rendering for boot splash and similar. Some armsoc drivers don't really follow that though. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Intel-gfx] [RFC PATCH 1/3] drm/i915: add vxd392 bridge in i915
On Thu, Oct 16, 2014 at 03:05:07PM +, Cheng, Yao wrote:
> > Ok, bunch of comments. First a high-level one: I think this qualifies as a
> > new
> > subsystem of i915, and so it would be good to extract this into a new file
> > (i915_ved.c maybe), including adding kerneldoc for the setup function, a
> > short DOC: overview section and pulling it all into the drm kerneldoc
> > (probably a new subsection in the driver core section).
> >
> > Aside from the lack of documentation just a few small comments below.
> > Overall I really like how cleanly we can integrate vxd support into i915, so
> > good work.
>
> I915_ved.c sounds to be a good place for these code, thx for this suggestion!
>
> For the kerneldoc, I'll add a subsection in the core section for your review.
Yeah, i915 driver core section sounds like the right place. Btw there's a
small blog post from me with some tips for how to go about this:
http://blog.ffwll.ch/2014/06/documentation-for-drmi915.html
> > > +
> > > +static void valleyview_ved_cleanup(struct drm_device *dev) {
> > > + int irq;
> > > + struct drm_i915_private *dev_priv = dev->dev_private;
> > > +
> > > + irq = platform_get_irq(dev_priv->ved_platdev, 0);
> > > + if (irq >= 0)
> > > + irq_free_desc(irq);
> > > +
> > > + platform_device_unregister(dev_priv->ved_platdev);
> >
> > I think you should unregister the platform device _before_ you free the irq.
> > Otherwise the driver cleanup might freak out. Aside: Does the module reload
> > test for i915 in i-g-t still work with the vxd driver loaded on vlv? Iirc
> > you need
> > to manually unload the vxd driver first to avoid inherit races in the
> > platform
> > device support code, so if that's the case you need to supply a patch for
> > igt,
> > too.
>
> Sorry, what is i-g-t? I'll follow your suggestion, test i-g-t, and patch it
> if needed.
i-g-t is the i915 kernel driver regression test suite. For a quick intro
see:
http://blog.ffwll.ch/2013/08/recent-drmi915-testsuite-improvements.html
The igt repo is at
http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/
The README file in there also has some good information.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 84500] [radeonsi] radeon 0000:01:00.0: Packet0 not allowed!
https://bugs.freedesktop.org/show_bug.cgi?id=84500 --- Comment #26 from Erich Seifert --- I'm also getting "Packet0 not allowed!" messages with a Radeon HD 7770 (Cape Verde XT) video card on kernel 3.17.0 and 3.17.1. I experienced several random crashes with 3.17.0, but I'm not sure they are related to this problem yet. I'll apply the patch and report back soon. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141019/7287bc75/attachment.html>
[Bug 25618] Cairo-Dock's Switcher applet not displayed with OpenGL
https://bugs.freedesktop.org/show_bug.cgi?id=25618 Fabio Pedretti changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #8 from Fabio Pedretti --- No feedback after 4+ years, closing. Feel free to reopen if the problem still happens with mesa 10.3.1 or later. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141019/26cdbc59/attachment-0001.html>
[Bug 84500] [radeonsi] radeon 0000:01:00.0: Packet0 not allowed!
https://bugs.freedesktop.org/show_bug.cgi?id=84500 --- Comment #25 from Zolt?n B?sz?rm?nyi --- I see "Packet0 not allowed" messages on 3.17.0 / 3.17.1 under Fedora 21. The video card is R9 270X, also Pitcairn. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141019/a637cff0/attachment.html>
[Bug 82109] Firefox crashes Google Maps, likely related to graphics driver
https://bugs.freedesktop.org/show_bug.cgi?id=82109 --- Comment #4 from Fabrizio Gennari --- Correction: Ubuntu 14.04 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141019/6e729c1b/attachment.html>
[Bug 82109] Firefox crashes Google Maps, likely related to graphics driver
https://bugs.freedesktop.org/show_bug.cgi?id=82109 --- Comment #3 from Fabrizio Gennari --- Same problem with Firefox 33.0, on Ubuntu 14.10. This is a call stack, taken from Mozilla's crash report 1 r600_dri.so r600_dri.so at 0x168a34 2 libgallium.so.0.0.0 libgallium.so.0.0.0 at 0x327e3 3 r600_dri.so r600_dri.so at 0x5cba3f 4 r600_dri.so r600_dri.so at 0x5cbaa7 5 r600_dri.so r600_dri.so at 0x164a26 6 r600_dri.so r600_dri.so at 0x16b7fe 7 r600_dri.so r600_dri.so at 0xf73f3 Package: libgl1-mesa-dri Architecture: amd64 Version: 10.1.3-0ubuntu0.1 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141019/0ac3e0b6/attachment-0001.html>
[Bug 82889] [drm:si_dpm_set_power_state] *ERROR* si_disable_ulv failed
https://bugs.freedesktop.org/show_bug.cgi?id=82889 --- Comment #20 from Alexandre Demers --- Sadly, I won't be able to test this patch, I had an opportunity to sell my hd 7950. We can keep it open if someone else can test it. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141019/7715428e/attachment.html>
[Bug 81644] Random crashes on RadeonSI with Chromium.
https://bugs.freedesktop.org/show_bug.cgi?id=81644 --- Comment #144 from Aaron B --- Is it possible at all that the problem is related to using DDR3-1866 RAM? I mean I'm trying to think of why you guys at AMD can't encounter it, while I can't stay away from it. That is basically the only piece of hardware that would be "overclocked" by any means. But I don't know. You guys still haven't encountered these problems? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141019/19eb461c/attachment.html>
