[Bug 74539] [r600g] Memory leak when playing WoW with RV790
https://bugs.freedesktop.org/show_bug.cgi?id=74539 --- Comment #33 from Chris Rankin --- Created attachment 97325 --> https://bugs.freedesktop.org/attachment.cgi?id=97325&action=edit Xorg.0.log showing errors when exiting WoW One of the other errors that I've come to associate (rightly or wrongly) with the OOM problem is that it can take a long time to get keyboard/mouse control back after exiting WoW. This is the Xorg.0.log file from an instance where I didn't get keyboard/mouse control back at all, and Xorg just chewed up 100% of one CPU instead. -- 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/20140413/693ce8b3/attachment.html>
[Bug 25871] nearest neighbour samples wrong texel (precision/rounding problem)
https://bugs.freedesktop.org/show_bug.cgi?id=25871 --- Comment #14 from Marek Ol??k --- Thanks for the feedback. So it is a precision issue after all. If fglrx exhibits the same behavior, there is nothing I can do. I don't know of any hardware state which controls precision of texture addressing. -- 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/20140413/60f4ddfa/attachment.html>
[PATCH] drm/crtc-helper: gc usless connectro loop in disable_unused_functions
I've forgotten to clean this all up correctly in
commit e3d6ddb35f6221859b6054879d186e13a3af351e
Author: Daniel Vetter
Date: Tue Apr 1 22:15:00 2014 +0200
drm/crtc-helper: don't disable disconnected outputs
Reported-by: Russell King - ARM Linux
Cc: Russell King - ARM Linux
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc_helper.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index 1fbe8427c70e..163971fdee58 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -281,16 +281,10 @@ drm_encoder_disable(struct drm_encoder *encoder)
static void __drm_helper_disable_unused_functions(struct drm_device *dev)
{
struct drm_encoder *encoder;
- struct drm_connector *connector;
struct drm_crtc *crtc;
drm_warn_on_modeset_not_all_locked(dev);
- list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
- if (!connector->encoder)
- continue;
- }
-
list_for_each_entry(encoder, &dev->mode_config.encoder_list, head) {
if (!drm_helper_encoder_in_use(encoder)) {
drm_encoder_disable(encoder);
--
1.9.2
[Bug 25871] nearest neighbour samples wrong texel (precision/rounding problem)
https://bugs.freedesktop.org/show_bug.cgi?id=25871 --- Comment #13 from Pierre Ossman --- Hardly NOTABUG. There is no pixel at 0.5. The pixels are at 0.125, 0.375, 0.625 and 0.875. 0.4 should get rounded to the 0.375 pixel. That's the closest, not the 0.625 one. -- 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/20140413/4a4f9c91/attachment.html>
Kernel warning when mode setting with no connectors connected
On Sun, Apr 13, 2014 at 10:44:28AM +0200, Daniel Vetter wrote:
> On Sat, Apr 12, 2014 at 11:04:31PM +0100, Russell King - ARM Linux wrote:
> > So we try to set a mode on CRTC 3 using encoder 8 and connector 9.
> > However connector 9 is disconnected, so the connector has its
> > encoder disassociated. The encoder is now not used, so the encoder
> > is disabled. This then means that the CRTC is not being used by
> > any encoder, so the CRTC gets disabled.
>
> That's a bit strange since userspace normally shouldn't attempt to set a
> mode when nothing is connected, at least if you don't force a specific
> configuration. In any case it sounds like you want
>
> commit e3d6ddb35f6221859b6054879d186e13a3af351e
> Author: Daniel Vetter
> Date: Tue Apr 1 22:15:00 2014 +0200
>
> drm/crtc-helper: don't disable disconnected outputs
>
> I wonder whether we should put a cc: stable onto that one (maybe after a
> bit more testing) since apparently userspace can force the kernel to do
> stupid things if we auto-disable disconnected outputs.
BTW... that commit looks like this:
list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
if (!connector->encoder)
continue;
- if (connector->status == connector_status_disconnected)
- connector->encoder = NULL;
}
Would you like to comment about the use of this loop once those two lines
are deleted? ;-)
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
[PATCH] drm/crtc-helper: gc usless connectro loop in disable_unused_functions
On Sun, Apr 13, 2014 at 4:39 PM, Daniel Vetter wrote: > I've forgotten to clean this all up correctly in > > commit e3d6ddb35f6221859b6054879d186e13a3af351e > Author: Daniel Vetter > Date: Tue Apr 1 22:15:00 2014 +0200 > > drm/crtc-helper: don't disable disconnected outputs > > Reported-by: Russell King - ARM Linux > Cc: Russell King - ARM Linux > Signed-off-by: Daniel Vetter Typo in the Subject "useless connector"
[Bug 75005] "Upvoid" segfault in radeonsi/llvm
https://bugs.freedesktop.org/show_bug.cgi?id=75005 --- Comment #10 from Christoph Haag --- (In reply to comment #9) > I have tried to take an apitrace but apitrace segfaults (?) when replaying > it, so I can post that too when I can resolve that. That was actually just my failure to use it correctly. With apitrace replay --core it works: 64 Megabyte download, 101 Megabyte uncompressed: http://w3studi.informatik.uni-stuttgart.de/~haagch/UpvoidEngine.trace.bz2 Replaying this renders on intel without bigger problems, but on my HD 7970M it creates GPU faults (but not so much that it causes a lockup). -- 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/20140413/4c48f0d8/attachment.html>
[Bug 75005] "Upvoid" segfault in radeonsi/llvm
https://bugs.freedesktop.org/show_bug.cgi?id=75005 Christoph Haag changed: What|Removed |Added Attachment #95062|0 |1 is obsolete|| --- Comment #9 from Christoph Haag --- Created attachment 97308 --> https://bugs.freedesktop.org/attachment.cgi?id=97308&action=edit more recent R600_DEBUG=ps,vs,gs that triggers gpu fault Since there were some updates, maybe this should be updated too... I have tried to take an apitrace but apitrace segfaults (?) when replaying it, so I can post that too when I can resolve that. -- 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/20140413/de164ece/attachment.html>
[Bug 75005] "Upvoid" segfault in radeonsi/llvm
https://bugs.freedesktop.org/show_bug.cgi?id=75005 Christoph Haag changed: What|Removed |Added Attachment #94690|0 |1 is obsolete|| --- Comment #8 from Christoph Haag --- Created attachment 97307 --> https://bugs.freedesktop.org/attachment.cgi?id=97307&action=edit dmesg with patched llvm Sorry, I wasn't very active recently. I'm not sure what you're asking for. In comment #4 there is a whole dmesg, but I can add another one... I am using linux 3.14 by now and recent mesa git, but with your branch of llvm. I can maybe add a few details to the behavior: When starting upvoid it displays a menu over a view of the game world. The gpu faults start appearing in dmesg right when it starts displaying this. It doesn't directly lockup and keeps rendering relatively well. When starting the game I can walk and look around a bit and I noticed: When looking at the ground the messages stop, but when looking in the distance, the messages are again created, so I would think it's directly related to the complexity of the stuff it is rendering. After a while the game window stops reacting. At this point the game will take up 100% "red" cpu time in htop and shortly after that the whole machine will hard lockup. I can't say if the lockup is because of excessive error logging or not. dmesg --follow | pv > /dev/null says it's about 35 kilobyte/second. The dmesg here is from starting the game, waiting a few seconds and then killing it. When killing it early enough it doesn't seem to cause any problems, seems to recover nicely. -- 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/20140413/f882164c/attachment.html>
[Bug 75992] Display freezes & corruption with an r7 260x on 3.14-rc6
https://bugs.freedesktop.org/show_bug.cgi?id=75992 --- Comment #51 from nucrap at hotmail.com --- (In reply to comment #50) > Egon I would say this bug is dead. Its not smooth here but that could > easily be the new kernel - its not reached rc1 yet... IMHO IF there is too > much jitter we should open a new bug. What do you mean, I thought the bug is fixed now, and the fix will be included in future releases.. > Eventually??? "Eventually" means that it *will* reach the kernel firmware. Since you are probalby German (Egon is a German name), you might have misunderstood it for "maybe". "Eventually" has got a completely different meaning in English, see http://www.dict.cc/?s=eventually -- 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/20140413/b67eb7b8/attachment-0001.html>
[Bug 44365] Textures aligned/move wrongly in planeshift game
https://bugs.freedesktop.org/show_bug.cgi?id=44365 Marek Ol??k changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Marek Ol??k --- This looks like an issue with interpolation. I'm pretty sure it's been fixed, because interpolation qualifiers were reworked after the last feedback. Closing. -- 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/20140413/05897623/attachment.html>
[Bug 43426] gallium3d makes krita crash
https://bugs.freedesktop.org/show_bug.cgi?id=43426 Marek Ol??k changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #3 from Marek Ol??k --- This looks like a version mismatch between LLVM and Mesa. Updating LLVM and Mesa should fix this. There has been no feedback for 2.5 years. Closing. -- 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/20140413/757ddb2f/attachment.html>
[Bug 43405] Only horizontal lines (snow) display in google earth/glxgears using current r600g on RS780M
https://bugs.freedesktop.org/show_bug.cgi?id=43405 Marek Ol??k changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #17 from Marek Ol??k --- I think this has been fixed since the new surface allocator was added to libdrm. I haven't seen any issues with texture allocation for some time. -- 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/20140413/f6d17103/attachment.html>
[Bug 43395] Game running in wine stops rendering
https://bugs.freedesktop.org/show_bug.cgi?id=43395 Marek Ol??k changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #16 from Marek Ol??k --- (In reply to comment #15) > We can't help you with that without more information. Ideally a gdb > backtrace of the crash, or at least the full output. Right. Since there is no other feedback after 3 years, I'm closing this bug. -- 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/20140413/29c591eb/attachment.html>
[Bug 41060] r600g: "Failed to parse relocation -12!" followed by widespread texture corruption
https://bugs.freedesktop.org/show_bug.cgi?id=41060 Marek Ol??k changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTABUG --- Comment #2 from Marek Ol??k --- (In reply to comment #1) > That usually means the kernel cannot relocate all the buffers for the > submitted command stream due to lack of available memory. There is probably nothing we can do about it. I think the GTT size was increased some time ago, that should fix the error I guess. -- 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/20140413/8a59cbc3/attachment.html>
[Bug 40658] r600g-xorg: GPU lockup CP stall
https://bugs.freedesktop.org/show_bug.cgi?id=40658 Marek Ol??k changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #5 from Marek Ol??k --- The Xorg state tracker no longer exists in Mesa. Closing. -- 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/20140413/7ec8dbd5/attachment-0001.html>
[Bug 40531] [RADEON:KMS:R600G] Frets On Fire visual corruption in menu
https://bugs.freedesktop.org/show_bug.cgi?id=40531 Marek Ol??k changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTOURBUG --- Comment #6 from Marek Ol??k --- (In reply to comment #3) > Probably the driver can't do anything other than report the "out of memory" > error (error code -12 in your dmesg log). The game just shouldn't use such > huge textures, it shouldn't use MAX_TEXTURE_SIZE as the size for texture > (this result in 0.4 GB on r6xx/r7xx, 1.4 GB on evergreen, next step will be > >5 GB with future GPUs). I think it makes sense to tell the game developers > about this issue. With my patch it uses 1024x1024 texture (~5 MB) and runs > fine without artifacts or error messages in the logs (though I haven't > tested it much). I don't know exact requirements for this, the game > developers should know what size is really required. This explains it. Closing. -- 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/20140413/31f451cb/attachment.html>
[Bug 38753] Strange drawing around models in r600g in SC2
https://bugs.freedesktop.org/show_bug.cgi?id=38753 Marek Ol??k changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Marek Ol??k --- (In reply to comment #7) > For what it is worth, it seems to be working fine now. Think it was fixed > within the last two months. If you like I could bisect to find out where it > was fixed. Else we could just close this. Closing. -- 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/20140413/da9ff5f6/attachment.html>
[Bug 38547] r600g fails shader, tries to run with failed shader, freezes.
https://bugs.freedesktop.org/show_bug.cgi?id=38547 Marek Ol??k changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Marek Ol??k --- AFAIK, the driver can translate all shaders just fine, so this shouldn't occur anymore. -- 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/20140413/88e07f99/attachment.html>
[Bug 38473] [egl] When program ends, monitor is switched off leaving system unusable
https://bugs.freedesktop.org/show_bug.cgi?id=38473 Marek Ol??k changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Marek Ol??k --- Closing as per Michel's comment: > Not for me. I asked because it seems to work for me with upstream Git. I > just verified again it still does. -- 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/20140413/2ae4f8bf/attachment.html>
[Bug 77394] Desktop freezes often when KDE starts compositing or mplayer GL window changes
https://bugs.freedesktop.org/show_bug.cgi?id=77394 --- Comment #2 from nine at detonation.org --- Created attachment 97305 --> https://bugs.freedesktop.org/attachment.cgi?id=97305&action=edit Xorg.0.log of a session after a freeze -- 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/20140413/87653881/attachment.html>
[Bug 77394] Desktop freezes often when KDE starts compositing or mplayer GL window changes
https://bugs.freedesktop.org/show_bug.cgi?id=77394 --- Comment #1 from nine at detonation.org --- Created attachment 97304 --> https://bugs.freedesktop.org/attachment.cgi?id=97304&action=edit dmesg taken after desktop freeze -- 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/20140413/b8b2e10a/attachment-0001.html>
[Bug 38018] Implementation error: bad format in _mesa_pack_rgba_span
https://bugs.freedesktop.org/show_bug.cgi?id=38018 Marek Ol??k changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Marek Ol??k --- There has been tons of fixes to _mesa_pack_rgba_span since 2011. Feel free to reopen this if you still see errors. -- 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/20140413/bbe7ec9c/attachment.html>
[Bug 77394] New: Desktop freezes often when KDE starts compositing or mplayer GL window changes
https://bugs.freedesktop.org/show_bug.cgi?id=77394 Priority: medium Bug ID: 77394 Assignee: dri-devel at lists.freedesktop.org Summary: Desktop freezes often when KDE starts compositing or mplayer GL window changes Severity: major Classification: Unclassified OS: Linux (All) Reporter: nine at detonation.org Hardware: x86-64 (AMD64) Status: NEW Version: unspecified Component: DRM/Radeon Product: DRI When I turn on KDE compositing the desktop freezes more often than not. These freezes can also be provoked when configuring mplayer for GL output and opening a video file. If that alone is not enough, just change repeatedly from window to fullscreen and back. Attaching Xorg.0.log and dmesg of such a crash. I can reboot the system cleanly using alt+sysrq+r and ctrl+alt+del but any attempts to get a nice backtrace of the X server with gdb failed due to the process hanging in kernel space. Hardware: 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Curacao XT [Radeon R9 270X] Running: kernel 3.14, libdrm2-2.4.99~git20140411-1.1, xorg-x11-server-7.6_1.15.99.902-306.1 Mesa-10.2~git20140411-5.1 llvm-r600-3.5~svn20140408-1.1.x86_64 openSUSE 13.1 Downgrading components to openSUSE 13.1 stock versions did not help except for downgrading the kernel to 3.11. -- 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/20140413/aaa244db/attachment.html>
[Bug 37142] Too much vertex buffers uploads
https://bugs.freedesktop.org/show_bug.cgi?id=37142 Marek Ol??k changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #8 from Marek Ol??k --- Closing. Ian's comment explains it: > EXT_compiled_vertex_array is dead. It has been dead for almost 10 years. > No new applications should use it, and old applications that use it should > be fast enough on modern hardware. -- 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/20140413/04bb021a/attachment.html>
Kernel warning when mode setting with no connectors connected
On Sun, Apr 13, 2014 at 10:44:28AM +0200, Daniel Vetter wrote: > On Sat, Apr 12, 2014 at 11:04:31PM +0100, Russell King - ARM Linux wrote: > > So we try to set a mode on CRTC 3 using encoder 8 and connector 9. > > However connector 9 is disconnected, so the connector has its > > encoder disassociated. The encoder is now not used, so the encoder > > is disabled. This then means that the CRTC is not being used by > > any encoder, so the CRTC gets disabled. > > That's a bit strange since userspace normally shouldn't attempt to set a > mode when nothing is connected, at least if you don't force a specific > configuration. In any case it sounds like you want > > commit e3d6ddb35f6221859b6054879d186e13a3af351e > Author: Daniel Vetter > Date: Tue Apr 1 22:15:00 2014 +0200 > > drm/crtc-helper: don't disable disconnected outputs > > I wonder whether we should put a cc: stable onto that one (maybe after a > bit more testing) since apparently userspace can force the kernel to do > stupid things if we auto-disable disconnected outputs. Yes, adding that change makes the warning go away. Thanks. Tested-by: Russell King It may be worth including some extra information in the commit. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it.
[Bug 36455] Screen corruption when comeing back from powersave
https://bugs.freedesktop.org/show_bug.cgi?id=36455 Marek Ol??k changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #2 from Marek Ol??k --- Closing due to lack of feedback. -- 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/20140413/0f76fe09/attachment.html>
[Bug 36441] [RV620] Artefacts in launcher and dash (horizontal noise lines and color loss)
https://bugs.freedesktop.org/show_bug.cgi?id=36441 Marek Ol??k changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTABUG --- Comment #9 from Marek Ol??k --- Closing due to lack of feedback. -- 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/20140413/7b890225/attachment.html>
[Bug 33715] demo arbocclude regression since r600g: Implement asyncronous query results.
https://bugs.freedesktop.org/show_bug.cgi?id=33715 Marek Ol??k changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTABUG --- Comment #9 from Marek Ol??k --- (In reply to comment #5) > I don't think this is a bug, its just how the demo works, it paints red if > the results aren't ready when first asked, which is perfectly within spec > from what I can see. Closing as per the comment above. -- 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/20140413/9e7aa7bd/attachment-0001.html>
[Bug 32687] XBMC software video renderer is faster than OpenGL video renderer
https://bugs.freedesktop.org/show_bug.cgi?id=32687 Marek Ol??k changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #3 from Marek Ol??k --- Closing due to lack of feedback. -- 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/20140413/8abf777d/attachment.html>
[Bug 32557] [RADEON:KMS:R600G] z/stencil buffer too small error in dmesg
https://bugs.freedesktop.org/show_bug.cgi?id=32557 Marek Ol??k changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #4 from Marek Ol??k --- Closing due to lack of feedback. -- 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/20140413/1f80ba2e/attachment.html>
[Bug 28049] Failure observed while running piglit glean/pbo
https://bugs.freedesktop.org/show_bug.cgi?id=28049 Marek Ol??k changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Marek Ol??k --- It fails because of unimplemented polygon stippling. *** This bug has been marked as a duplicate of bug 25280 *** -- 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/20140413/087a4d6f/attachment.html>
[Bug 25280] r600: glPolygonStipple broken
https://bugs.freedesktop.org/show_bug.cgi?id=25280 Marek Ol??k changed: What|Removed |Added CC||hysvats at gmail.com --- Comment #8 from Marek Ol??k --- *** Bug 28049 has been marked as a duplicate of this bug. *** -- 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/20140413/feaf2f0b/attachment.html>
[Bug 25871] nearest neighbour samples wrong texel (precision/rounding problem)
https://bugs.freedesktop.org/show_bug.cgi?id=25871 Marek Ol??k changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTABUG --- Comment #12 from Marek Ol??k --- I think this is a normal behavior and it's not a precision issue. The coordinates are rounded to 0.5, because the filter is NEAREST (and 0.5 is the nearest pixel). Closing as NOTABUG. -- 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/20140413/1168d23b/attachment.html>
Kernel warning when mode setting with no connectors connected
On Sat, Apr 12, 2014 at 11:04:31PM +0100, Russell King - ARM Linux wrote: > On Sat, Apr 12, 2014 at 11:49:44PM +0200, Daniel Vetter wrote: > > On Sat, Apr 12, 2014 at 11:20 PM, Russell King - ARM Linux > > wrote: > > > So what happens is that a mode is attempted to be set with no connectors. > > > > That case is the other nonsense use of ->set_config I've curbed with > > all the fb helper fixes. > > > > BUG_ON(set->fb && set->num_connectors == 0); > > > > in drm_crtc_helper_set_config should catch this abuse of trying to set > > a mode with no connectors. So I'm still confused what exactly is going > > on in your box. > > Here's the DRM debug enabled: > > drm_mode_set_config_internal: pre: fb d8407080 mode dab0ab00 crtc dae72018 > crtc->fb (null) > [drm:drm_crtc_helper_set_config], > [drm:drm_crtc_helper_set_config], [CRTC:3] [FB:11] #connectors=1 (x y) (0 0) > [drm:drm_crtc_helper_set_config], crtc has no fb, full mode set > [drm:drm_crtc_helper_set_config], encoder changed, full mode switch > [drm:drm_crtc_helper_set_config], crtc changed, full mode switch > [drm:drm_crtc_helper_set_config], [CONNECTOR:9:HDMI-A-1] to [CRTC:3] > [drm:drm_crtc_helper_set_config], attempting to set mode from userspace > [drm:drm_mode_debug_printmodeline], Modeline 12:"1360x768" 0 84750 1360 1432 > 1568 1776 768 771 781 798 0x0 0x6 > [drm:drm_crtc_helper_set_mode], [CRTC:3] > [drm:drm_crtc_helper_set_mode], [ENCODER:8:TMDS-8] set [MODE:12:1360x768] > [drm:drm_calc_timestamping_constants], crtc 3: hwmode: htotal 1776, vtotal > 798, vdisplay 768 > [drm:drm_calc_timestamping_constants], crtc 3: clock 84750 kHz framedur > 16722690 linedur 20955, pixeldur 11 > [drm:drm_crtc_helper_set_config], Setting connector DPMS state to on > [drm:drm_crtc_helper_set_config],[CONNECTOR:9:HDMI-A-1] set DPMS on > drm_helper_disable_unused_functions: crtc dae72018 crtc->fb d8407080 > drm_helper_disable_unused_functions: crtc dae72418 crtc->fb (null) > drm_crtc_helper_set_config: success > drm_mode_set_config_internal: post: fb d8407080 mode dab0ab00 crtc->fb > (null) ret 0 > > This shows that the mode was being set with one connector present, and > seemed to be successful, but drm_helper_disable_unused_functions() still > tried to disable it. > > However, adding more debugging to drm_helper_disable_unused_functions() > reveals the problem: > > drm_helper_disable_unused_functions: connector 9 status 2 > drm_helper_disable_unused_functions: encoder 8 not in use > drm_helper_disable_unused_functions: crtc 3 crtc->fb da898500 > drm_helper_disable_unused_functions: crtc 6 crtc->fb (null) > > So we try to set a mode on CRTC 3 using encoder 8 and connector 9. > However connector 9 is disconnected, so the connector has its > encoder disassociated. The encoder is now not used, so the encoder > is disabled. This then means that the CRTC is not being used by > any encoder, so the CRTC gets disabled. That's a bit strange since userspace normally shouldn't attempt to set a mode when nothing is connected, at least if you don't force a specific configuration. In any case it sounds like you want commit e3d6ddb35f6221859b6054879d186e13a3af351e Author: Daniel Vetter Date: Tue Apr 1 22:15:00 2014 +0200 drm/crtc-helper: don't disable disconnected outputs I wonder whether we should put a cc: stable onto that one (maybe after a bit more testing) since apparently userspace can force the kernel to do stupid things if we auto-disable disconnected outputs. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 73931] New: rmmod radeon and kernel crash
https://bugzilla.kernel.org/show_bug.cgi?id=73931 Bug ID: 73931 Summary: rmmod radeon and kernel crash Product: Drivers Version: 2.5 Kernel Version: 3.14 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri at kernel-bugs.osdl.org Reporter: pali.rohar at gmail.com Regression: No Created attachment 132051 --> https://bugzilla.kernel.org/attachment.cgi?id=132051&action=edit rmmod_radeon_kernel_panic After calling rmmod radeon, kernel show lots of error lines and then crash. It looks like that radeon module does not cleanup hwmon interface at exit. After calling rmmod radeon there is still hwmon interface: $ readlink /sys/class/hwmon/hwmon1 ../../devices/pci:00/:00:01.0/:01:00.0/hwmon/hwmon1 And after calling ls, or cat in hwmon1 kernel crash... See attachment from syslog. $ lspci -nn 01:00.0 Display controller [0380]: Advanced Micro Devices, Inc. [AMD/ATI] Sun XT [Radeon HD 8670A/8670M/8690M] [1002:6660] -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 75992] Display freezes & corruption with an r7 260x on 3.14-rc6
https://bugs.freedesktop.org/show_bug.cgi?id=75992 --- Comment #50 from Ed Tomlinson --- Egon I would say this bug is dead. Its not smooth here but that could easily be the new kernel - its not reached rc1 yet... IMHO IF there is too much jitter we should open a new bug. -- 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/20140413/417fea93/attachment.html>
[Bug 77305] Compile error in pipe-loader files (pipe_r300.c pipe_r600.c pipe_radeonsi.c egl_pipe.c)
https://bugs.freedesktop.org/show_bug.cgi?id=77305 Marek Ol??k changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Marek Ol??k --- (In reply to comment #2) > Created attachment 97248 [details] [review] > patch for build failure with r600 and radeonsi > > The bug isn't fixed upstream for r600 and radeonsi. > > The attached patch solves the problem fixing these: > > egl_pipe.c: In function 'pipe_r600_create_screen': > egl_pipe.c:153:4: error: implicit declaration of function > 'radeon_drm_winsys_create' [-Werror=implicit-function-declaration] > egl_pipe.c:154:36: error: dereferencing pointer to incomplete type > > egl_pipe.c: In function 'pipe_radeonsi_create_screen': > egl_pipe.c:168:4: error: implicit declaration of function > 'radeon_drm_winsys_create' [-Werror=implicit-function-declaration] > egl_pipe.c:169:36: error: dereferencing pointer to incomplete type I pushed your patch. Closing. -- 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/20140413/82b2cd7a/attachment-0001.html>
