[Bug 80141] Fails to page flip multiple time, queue overflows waiting for one to finish that never does crashing entire system.
https://bugs.freedesktop.org/show_bug.cgi?id=80141 --- Comment #14 from Aaron B --- (In reply to comment #12) > (In reply to comment #11) > > Anything needs tested [...] > > It would be very interesting if those patches help for your problem as well. OKay, after some more testing, I have one bug still present in this version, and also one problem which may not be related. Bug #1: Cinnamon restarted when moused over the top panel. Made login sound, and lost my BG preferences and icons went to GNOME-style icons. I don't think this is related, but just noting it. Bug #2: This was triggered by Chromium, when resizing the window/dragging with the mouse on the top of the screen. This one particular time made the screen jump, like I've also seen in Steam, but this one triggers a black scanline, (very very rarely) accompanied by a slight (1px vertical) tear upwards at the scanline the black line is on. They happen more towards the bottom and middle of the screen, although they start at the top. It happened once every 10 seconds or so when it started, but now is happening 1-2 times a second sometimes with multiple black lines in the same frame it seems. The black line occurence is increasing as time goes on. This was VERY common in 3.14 kernel, so the issue probably is just being put off by the new dri implementation I was given to test, but still exists. I don't really know weather to make a new bug report or not specifically for that, I don't really know what components to look at either. Any ideas, tests, etc. I can do them. But still, this has seemed to fix the random complete failure crashes. Or, maybe with the black lines, has just delayed them. I can't really tell. -- 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/20140629/fc4b639a/attachment.html>
[Bug 80141] Fails to page flip multiple time, queue overflows waiting for one to finish that never does crashing entire system.
https://bugs.freedesktop.org/show_bug.cgi?id=80141 --- Comment #15 from Aaron B --- > Bug #2: This was triggered by Chromium, when resizing the window/dragging > with the mouse on the top of the screen. This one particular time made the > screen jump, like I've also seen in Steam, but this one triggers a black > scanline, (very very rarely) accompanied by a slight (1px vertical) tear > upwards at the scanline the black line is on. They happen more towards the > bottom and middle of the screen, although they start at the top. It happened > once every 10 seconds or so when it started, but now is happening 1-2 times > a second sometimes with multiple black lines in the same frame it seems. The > black line occurence is increasing as time goes on. This was VERY common in > 3.14 kernel, so the issue probably is just being put off by the new dri > implementation I was given to test, but still exists. I don't really know > weather to make a new bug report or not specifically for that, I don't > really know what components to look at either. Any ideas, tests, etc. I can > do them. But still, this has seemed to fix the random complete failure > crashes. Or, maybe with the black lines, has just delayed them. I can't > really tell. This seems to be caused by Chromium, BUT. I believe the colors being sent to the screen were affecting it. Looking at my desktop, the lines were not on the screen. They used to be in 3.14, though, even on the desktop. But, with this glitch they were not. I opened Libreoffice, with mainly white pixels on the left side, flipped the screen 180 degrees, and...turning off the on HDMI, or whatever it does to the display when it flipped, fixed it, and now it's back to normal. But, like I said, I would wager the glitch was caused by pixel colors, or maybe colors were looked at as commands and the pixel clock frequency is a tad off. I'm not 100% sure on any of it, just saying what fixed it for me so if it's looked in to, it can help. If I could make a new bug report just for that, I will. -- 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/20140629/f1025f80/attachment.html>
[Bug 80419] XCOM: Enemy Unknown Causes lockup
https://bugs.freedesktop.org/show_bug.cgi?id=80419 --- Comment #21 from theamazingjanet at googlemail.com --- (In reply to comment #20) > The crash looks like a complete GPU hang that locks up the entire card. If > it helps I can look into getting exact instructions on how to attach > apitrace to the Steam release. That would certainly help. Thanks for taking the time to do this. -- 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/20140629/2f439edb/attachment.html>
[PATCH] drm/radeon: stop poisoning the GART TLB v2
From: Christian K?nig When we set the valid bit on invalid GART entries they are loaded into the TLB when an adjacent entry is loaded. This poisons the TLB with invalid entries which are sometimes not correctly removed on TLB flush. v2: rebased on 3.15 for stable inclusion Signed-off-by: Christian K?nig Cc: stable at vger.kernel.org Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/rs600.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/rs600.c b/drivers/gpu/drm/radeon/rs600.c index 72d3616..95b693c 100644 --- a/drivers/gpu/drm/radeon/rs600.c +++ b/drivers/gpu/drm/radeon/rs600.c @@ -646,8 +646,10 @@ int rs600_gart_set_page(struct radeon_device *rdev, int i, uint64_t addr) return -EINVAL; } addr = addr & 0xF000ULL; - addr |= R600_PTE_VALID | R600_PTE_SYSTEM | R600_PTE_SNOOPED; - addr |= R600_PTE_READABLE | R600_PTE_WRITEABLE; + if (addr != rdev->dummy_page.addr) + addr |= R600_PTE_VALID | R600_PTE_READABLE | + R600_PTE_WRITEABLE; + addr |= R600_PTE_SYSTEM | R600_PTE_SNOOPED; writeq(addr, ptr + (i * 8)); return 0; } -- 1.9.1
[Bug 70409] Discrete GPU fails to initialize and X segfaults on dual-GPU r600/radeonsi laptop
https://bugs.freedesktop.org/show_bug.cgi?id=70409 --- Comment #6 from dimitris --- I have the same exact problem with the latest stuff from git ( mesa, xorg-server, ddx for intel and radeon from git, llvm-3.5 (from svn), all relevant libs from git etc...). Glamor is always enabled for radeon. Kernel-3.15.2 My dgpu is a hd8000M (oland chip) with an integrated Ivybrigde gpu. -- 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/20140629/045c255d/attachment.html>
[Bug 80673] New: XCOM: Enemy Unknown - Wrong read access when starting the game
https://bugs.freedesktop.org/show_bug.cgi?id=80673 Priority: medium Bug ID: 80673 Assignee: dri-devel at lists.freedesktop.org Summary: XCOM: Enemy Unknown - Wrong read access when starting the game Severity: normal Classification: Unclassified OS: Linux (All) Reporter: freedesktop at psydk.org Hardware: x86-64 (AMD64) Status: NEW Version: 10.1 Component: Drivers/Gallium/r600 Product: Mesa Created attachment 101971 --> https://bugs.freedesktop.org/attachment.cgi?id=101971&action=edit callstack of the wrong read access Some background: I am trying to understand why "XCOM: Enemy Uknown" (a game that was released for Linux x64 last week on Steam), leads to crashes when running with the open source Radeon driver. The people who did the port do not officialy support the open source driver but seems to be open to the idea of making it run on it. My system: Ubuntu 14.04 x64 Readon HD 4870 Mesa 10.1.3 Unfortunately that Radeon model is not supported by AMD's closed source driver. However, the game runs very well with the open source driver, with the exception of several random crashes. This bug report is one of the problem I have found and for which I have some information. The main crash I was experimenting was corrupting the heap, so I used a tool to detect illegal read and write accesses. The first problem it found is an illegal read access at the start of the game, after the different logos, when the main menu is about to appear. What is happening is that a memcpy with a size of 1360 bytes is made with a source buffer of only 1280 bytes in u_upload_data(). I will attach the callstack to this ticket. In that context, the entry point in the driver is: vbo_exec_DrawRangeElementsBaseVertex(GLenum mode, GLuint start, GLuint end, GLsizei count, GLenum type, const GLvoid *indices, GLint basevertex) Here are the values of the parameters: --- mode: 4 (GL_TRIANGLES) start: 0 end: 16 count: 24 type: 5123 (GL_UNSIGNED_SHORT) indices: 72 bytes: 00 00 02 00 03 00 00 00 01 00 02 00 04 00 06 00 07 00 04 00 05 00 06 00 08 00 0a 00 0b 00 08 00 09 00 0a 00 0c 00 0e 00 0f 00 0c 00 0d 00 0e 00 00 00 04 00 06 00 00 00 06 00 02 00 01 00 03 00 07 00 01 00 07 00 05 00 reordered as 36 u16: 0002 0003 0001 0002 0004 0006 0007 0004 0005 0006 0008 000a 000b 0008 0009 000a 000c 000e 000f 000c 000d 000e 0004 0006 0006 0002 0001 0003 0007 0001 0007 0005 basevertex: 0 --- Now I'm no expert in OpenGL and it is the first time I look at Mesa code, so I can't identify the main reason for the error. Hopefully you will have a clue. A tip to debug the game: if you have Steam and the game, I renamed the main exectuable in ".../Steam/SteamApps/common/XCom-Enemy-Unknown/binaries/linux/" named "game.x86_64" as "game.x86_64_real" and created a shell script named "game.x86_64" that performs necessary settings for debugging and then launch "game.x86_64_real". In my case I am setting LD_PRELOAD with a library that catches malloc() calls and fences the buffer before returning 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/20140629/1c037235/attachment.html>
[Bug 80673] XCOM: Enemy Unknown - Wrong read access when starting the game
https://bugs.freedesktop.org/show_bug.cgi?id=80673 --- Comment #1 from Hadrien --- Created attachment 101972 --> https://bugs.freedesktop.org/attachment.cgi?id=101972&action=edit glxinfo -- 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/20140629/ec4cc7dc/attachment.html>
[Bug 80678] New: xrandr scaling / transform does not work with radeon
https://bugs.freedesktop.org/show_bug.cgi?id=80678 Priority: medium Bug ID: 80678 Assignee: dri-devel at lists.freedesktop.org Summary: xrandr scaling / transform does not work with radeon Severity: normal Classification: Unclassified OS: Linux (All) Reporter: h.judt at gmx.at Hardware: x86-64 (AMD64) Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI Scaling doesn't work with radeon. Screen rotation does work, though. On a laptop with intel driver, the following works fine, except the mouse pointer is confined to the mode area, but I believe that is a known xorg-server bug to which a patch is available in bug #39949: xrandr --fb 1920x1080 --output eDP1 --mode 1600x900 --scale-from 1920x1080 The same command, adapted to the radeon output device doesn't work. Same software configuration (xorg-1.15.99.903, libdrm-git, mesa-git, xf86-video-ati-git, various kernel versions (at the moment 3.15.2)). lspci -vvv: 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Cayman PRO [Radeon HD 6950] (prog-if 00 [VGA controller]) Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] Device 0b00 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Capabilities: [150 v1] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn- Kernel driver in use: radeon Is scaling not implemented in radeon? -- 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/20140629/52c39092/attachment-0001.html>
[Bug 80673] XCOM: Enemy Unknown - Wrong read access when starting the game
https://bugs.freedesktop.org/show_bug.cgi?id=80673 --- Comment #2 from Hohahiu --- Hi, your Mesa seems to be rather old. Did you try to update it to the newer version 10.2.x or even to git-master? It could be the case that your crash was already resolved. For ubuntu you could use oibaf-ppa. -- 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/20140629/bc0e3f9c/attachment.html>
[Bug 80683] New: EDID valid check ignores errors in CEA blocks
https://bugs.freedesktop.org/show_bug.cgi?id=80683
Priority: medium
Bug ID: 80683
Assignee: dri-devel at lists.freedesktop.org
Summary: EDID valid check ignores errors in CEA blocks
Severity: normal
Classification: Unclassified
OS: All
Reporter: stefan.bruens at rwth-aachen.de
Hardware: Other
Status: NEW
Version: DRI CVS
Component: DRM/other
Product: DRI
in linux/drivers/gpu/drm/drm_edid.c:
bool drm_edid_block_valid(u8 *raw_edid, int block, bool print_bad_edid)
{
...
if (csum) {
if (print_bad_edid) {
DRM_ERROR("EDID checksum is invalid, remainder is
%d\n", csum);
}
/* allow CEA to slide through, switches mangle this */
if (raw_edid[0] != 0x02)
goto bad;
}
...
return true;
---
i.e. CEA blocks are always reported as valid.
This occurs frequently for me with a Radeon 7750 and a Dell U2713HM connected
via DisplayPort, the I2C-over-AUX seems to be buggy and swallows single bytes.
If I change the "return true;" to "return !csum;" bad transfers are retried.
--
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/20140629/51140951/attachment.html>
[Bug 80684] New: I2C-over-AUX drops single bytes
https://bugs.freedesktop.org/show_bug.cgi?id=80684 Priority: medium Bug ID: 80684 Assignee: dri-devel at lists.freedesktop.org Summary: I2C-over-AUX drops single bytes Severity: normal Classification: Unclassified OS: All Reporter: stefan.bruens at rwth-aachen.de Hardware: Other Status: NEW Version: DRI CVS Component: DRM/Radeon Product: DRI I get frequent errors for the EDID checksum, obviously single bytes are dropped from the EDID. Good EDID: Raw EDID: 02 03 1d f1 50 90 05 04 03 02 07 16 01 06 11 12 15 13 14 1f 20 23 09 7f 07 83 01 00 00 02 3a 80 18 71 38 2d 40 58 2c 25 00 55 50 21 00 00 1e 01 1d 80 18 71 1c 16 20 58 2c 25 00 55 50 21 00 00 <-- 9e 01 1d 00 72 51 d0 1e 20 6e 28 55 00 55 50 21 00 00 1e 8c 0a d0 8a 20 e0 2d 10 10 3e 96 00 55 50 21 00 00 18 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 5d Bad EDID example: Raw EDID: 02 03 1d f1 50 90 05 04 03 02 07 16 01 06 11 12 15 13 14 1f 20 23 09 7f 07 83 01 00 00 02 3a 80 18 71 38 2d 40 58 2c 25 00 55 50 21 00 00 1e 01 1d 80 18 1c 16 20 58 2c 25 00 55 50 21 00 00 9e <-- 0x71 is missing 01 1d 00 72 51 d0 1e 20 6e 28 55 00 55 50 21 00 00 1e 8c 0a d0 8a 20 e0 2d 10 10 3e 96 00 55 50 21 00 00 18 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 5d 00 The position of the dropped byte changes, sometimes the EDID is complete, sometimes several bytes are dropped. The bad EDIDs are *often* accompanied with [drm:radeon_process_aux_ch] dp_aux_ch flags not zero messages. Most probably the common i2c-over-aux code drops the byte, as it starts the transfer again in case of -EBUSY. If I change radeon_process_aux_ch to return -EIO in case of (ReplyStatus == 2), I no longer have any bad checksums. Hardware is Radeon 7750 + Dell U2713HM, connected via DP. Same monitor with Intel Haswell and different cable works without any errors. Kernel is 3.15.1, i.e. without the i2c bus mutex, dont know if this fixes the problems as well. -- 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/20140629/0beec6d3/attachment.html>
[Bug 80684] I2C-over-AUX drops single bytes
https://bugs.freedesktop.org/show_bug.cgi?id=80684 --- Comment #1 from Stefan Br?ns --- I have added the i2c bus mutex, this does *not* fix 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/20140629/111eed9f/attachment.html>
[PATCH 1/3] drm/radeon: stop poisoning the GART TLB
Am 27.06.2014 10:59, schrieb Michel D?nzer: > On 27.06.2014 17:26, Christian K?nig wrote: >> Am 27.06.2014 04:31, schrieb Michel D?nzer: >>> On 25.06.2014 12:59, Michel D?nzer wrote: >>>> With these patches, 3.15 just survived two piglit runs on my Bonaire, >>>> one with the GART poisoning fix and one without. It never survived a >>>> single run before. >>>> >>>> Acked-and-Tested-by: Michel D?nzer >>> So, are these patches going to 3.16 and 3.15? >> We could send them in for 3.15, > What's the alternative for 3.15? Well, figuring out what's the real reason behind those lockups would be a good start :) > Looks like e.g. https://bugs.freedesktop.org/show_bug.cgi?id=80141 is > confirmed to be this. > > >> but for 3.16 we have some new features that depend on the new code. >> >> We could backport them to the old code, but I really want to work on >> figuring out what's wrong with the new approach instead. >> >> Going to prepare a branch for you to test over the weekend, would be >> nice if you could give it a try on Monday and see if that fixes the >> issues as well. > Sure, will do. I've just pushed the branch testing-3.15 to git://people.freedesktop.org/~deathsimple/linux. It's based on 3.15.2 and contains the "stop poisoning the GART TLB" patch backported to 3.15 and a couple of things that I would like to try. I've disabled the redirection of page faults to the dummy page for now and so the system should lockup on the first page fault it encounters. Apart from that the page directory and page tables are now completely over allocated and over aligned. Setting the READABLE bit on invalid entries shouldn't have an effect other than making those entries non zero. So please try to lockup your bonaire with this branch and as soon as you encounter the first page fault take a look at VM_CONTEXT1_PROTECTION_FAULT_STATUS and figure out which VMID caused the lockup. Then use the attached script to make a dump from the complete page directory and page table of the VMID in question. E.g. "./dump_vm.sh 1" if the lockup was caused by VMID 1 etc... Make sure you've got a radeontool that supports CIK, otherwise it would only return zeros as page directory address. Since even the invalid page table entries should now have at least the READABLE bit set there shouldn't be anything zero in this dump and look out for anything else suspicious as well (0xdeadbeef etc...). Thanks for the help, Christian. -- next part -- A non-text attachment was scrubbed... Name: dump_vm.sh Type: application/x-shellscript Size: 562 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140629/45d28bc6/attachment-0001.bin>
[Bug 68571] GPU lockup on AMD Radeon HD6850 with DPM=1
https://bugzilla.kernel.org/show_bug.cgi?id=68571 --- Comment #48 from Mihai Coman --- Seems to be fixed on kernel 3.16rc2. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 80690] New: Suddenly X halts
https://bugs.freedesktop.org/show_bug.cgi?id=80690 Priority: medium Bug ID: 80690 Assignee: dri-devel at lists.freedesktop.org Summary: Suddenly X halts Severity: normal Classification: Unclassified OS: All Reporter: omegatype at gmail.com Hardware: Other Status: NEW Version: 10.2 Component: Drivers/Gallium/radeonsi Product: Mesa Created attachment 101986 --> https://bugs.freedesktop.org/attachment.cgi?id=101986&action=edit XOrg log Hello! After some time of work screen goes dark, than blinks and than hangs (picture stands still with no changes and no reaction on keyboard or mouse, numlock isn't working). # uname -a Linux 3.15.2-1-ARCH #1 SMP PREEMPT Fri Jun 27 07:41:19 CEST 2014 x86_64 GNU/Linux Mesa: 10.2.2-1 I have no specific options for radeon in /etc/X11/xorg.conf.d/*. XOrg.log end with messages like: (EE) [mi] EQ overflowing. Additional events will be discarded until existing events are processed. (EE) (EE) Backtrace: (EE) 0: /usr/bin/X (xorg_backtrace+0x48) [0x584b08] (EE) 1: /usr/bin/X (mieqEnqueue+0x22b) [0x566b7b] (EE) 2: /usr/bin/X (QueuePointerEvents+0x52) [0x44cc72] (EE) 3: /usr/lib/xorg/modules/input/evdev_drv.so (0x7fdd74bb3000+0x60ba) [0x7fdd74bb90ba] (EE) 4: /usr/lib/xorg/modules/input/evdev_drv.so (0x7fdd74bb3000+0x657d) [0x7fdd74bb957d] (EE) 5: /usr/bin/X (0x40+0x72f08) [0x472f08] (EE) 6: /usr/bin/X (0x40+0x9b4b0) [0x49b4b0] (EE) 7: /usr/lib/libpthread.so.0 (0x7fdd7ba3b000+0xf4b0) [0x7fdd7ba4a4b0] (EE) 8: /usr/lib/libc.so.6 (ioctl+0x7) [0x7fdd7a769e47] (EE) 9: /usr/lib/libdrm.so.2 (drmIoctl+0x28) [0x7fdd7b8329b8] (EE) 10: /usr/lib/libdrm.so.2 (drmCommandWrite+0x1b) [0x7fdd7b834c2b] (EE) 11: /usr/lib/libdrm_radeon.so.1 (0x7fdd74fc2000+0x2189) [0x7fdd74fc4189] (EE) 12: /usr/lib/xorg/modules/drivers/radeon_drv.so (0x7fdd751d+0x41b3a) [0x7fdd75211b3a] (EE) 13: /usr/lib/xorg/modules/drivers/radeon_drv.so (0x7fdd751d+0x42e00) [0x7fdd75212e00] (EE) 14: /usr/lib/libdrm.so.2 (drmHandleEvent+0x7e) [0x7fdd7b836e6e] (EE) 15: /usr/bin/X (WakeupHandler+0x6d) [0x43a59d] (EE) 16: /usr/bin/X (WaitForSomething+0x1bf) [0x5820bf] (EE) 17: /usr/bin/X (0x40+0x359e1) [0x4359e1] (EE) 18: /usr/bin/X (0x40+0x39aaa) [0x439aaa] (EE) 19: /usr/lib/libc.so.6 (__libc_start_main+0xf0) [0x7fdd7a6a8000] (EE) 20: /usr/bin/X (0x40+0x2507e) [0x42507e] -- 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/20140629/737d419d/attachment.html>
[Bug 80691] New: HDMI audio stops working when drm_kms_helper edid overwrite in place
https://bugs.freedesktop.org/show_bug.cgi?id=80691 Priority: medium Bug ID: 80691 Assignee: dri-devel at lists.freedesktop.org Summary: HDMI audio stops working when drm_kms_helper edid overwrite in place Severity: normal Classification: Unclassified OS: Linux (All) Reporter: warlock0 at hotmail.com Hardware: x86-64 (AMD64) Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI Created attachment 101987 --> https://bugs.freedesktop.org/attachment.cgi?id=101987&action=edit dmesg When powering on a PC with radeon gpu (E350 in this case), without an output device powered on (on the hdmi out), X won't start. Therefore using drm_kms_helper to overwrite the edid information and forcing the display to on is needed. In this combination the hdmi audio output is not working. It also is not working if the system is started with the overwrite in place and TV / AVR turned on. It seems as if the audio codec is not enabled when EDID is loaded with drm_kms_helper Expectation: Audio will continue to work when overwriting EDID with drm_kms_helper. -- 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/20140629/996ce8de/attachment.html>
[Bug 80691] HDMI audio stops working when drm_kms_helper edid overwrite in place
https://bugs.freedesktop.org/show_bug.cgi?id=80691 --- Comment #1 from warlock0 at hotmail.com --- Created attachment 101988 --> https://bugs.freedesktop.org/attachment.cgi?id=101988&action=edit edid parsed with edid-decode -- 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/20140629/7c1a9c7f/attachment.html>
[Bug 80691] HDMI audio stops working when drm_kms_helper edid overwrite in place
https://bugs.freedesktop.org/show_bug.cgi?id=80691 --- Comment #2 from warlock0 at hotmail.com --- Created attachment 101989 --> https://bugs.freedesktop.org/attachment.cgi?id=101989&action=edit extracted edid.bin -- 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/20140629/4213ac35/attachment.html>
[Bug 79011] GPU lockup, screen freeze with Radeon HD7770
https://bugzilla.kernel.org/show_bug.cgi?id=79011 --- Comment #10 from Fabian Pas --- Someone commented (and deleted it), that it might be possible fixed in kernel 3.16-rc3, but it's not. I compiled and ran the kernel, but the problem persists. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 79850] [awesomenauts][radeonsi] pageflip is clearly missing vblank with vsync on
https://bugs.freedesktop.org/show_bug.cgi?id=79850 --- Comment #19 from Sylvain BERTRAND --- news: I did dive reluctantly into rpm dev (with debug info). I got my self a xorg server compiled properly for debugging with gdb and its related debufinfo. Only dri2.c:934 make DRI2CanFlip return FALSE. I check my xorg server log and I got: [13.506] (**) RADEON(0): Option "BackingStore" "off" [13.506] (**) RADEON(0): Backing store disabled -- 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/20140629/5a1226d0/attachment-0001.html>
[Bug 80567] [portal2] broken
https://bugs.freedesktop.org/show_bug.cgi?id=80567 Sylvain BERTRAND changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTOURBUG --- Comment #1 from Sylvain BERTRAND --- after further investigation, it's a libstdc++ version mismatch. c++.. -- 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/20140629/123bd51c/attachment.html>
[PATCH] drm/radeon: use RADEON_MAX_CRTCS, RADEON_MAX_AFMT_BLOCKS
Signed-off-by: Stefan Br?ns
---
drivers/gpu/drm/radeon/radeon_mode.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_mode.h
b/drivers/gpu/drm/radeon/radeon_mode.h
index ad0e4b8..79b8c7e 100644
--- a/drivers/gpu/drm/radeon/radeon_mode.h
+++ b/drivers/gpu/drm/radeon/radeon_mode.h
@@ -233,8 +233,8 @@ struct radeon_mode_info {
struct card_info *atom_card_info;
enum radeon_connector_table connector_table;
bool mode_config_initialized;
- struct radeon_crtc *crtcs[6];
- struct radeon_afmt *afmt[7];
+ struct radeon_crtc *crtcs[RADEON_MAX_CRTCS];
+ struct radeon_afmt *afmt[RADEON_MAX_AFMT_BLOCKS];
/* DVI-I properties */
struct drm_property *coherent_mode_property;
/* DAC enable load detect */
--
1.8.4.5
--
Stefan Br?ns / Bergstra?e 21 / 52062 Aachen
phone: +49 241 53809034 mobile: +49 151 50412019
[PATCH] drm/radeon: Use only one line for whole DPCD debug output
Signed-off-by: Stefan Br?ns
---
drivers/gpu/drm/radeon/atombios_dp.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_dp.c
b/drivers/gpu/drm/radeon/atombios_dp.c
index c5b1f2d..35f4182 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -403,16 +403,18 @@ bool radeon_dp_getdpcd(struct radeon_connector
*radeon_connector)
{
struct radeon_connector_atom_dig *dig_connector =
radeon_connector->con_priv;
u8 msg[DP_DPCD_SIZE];
- int ret, i;
+ int ret;
+
+ char dpcd_hex_dump[DP_DPCD_SIZE * 3];
ret = drm_dp_dpcd_read(&radeon_connector->ddc_bus->aux, DP_DPCD_REV,
msg,
DP_DPCD_SIZE);
if (ret > 0) {
memcpy(dig_connector->dpcd, msg, DP_DPCD_SIZE);
- DRM_DEBUG_KMS("DPCD: ");
- for (i = 0; i < DP_DPCD_SIZE; i++)
- DRM_DEBUG_KMS("%02x ", msg[i]);
- DRM_DEBUG_KMS("\n");
+
+ hex_dump_to_buffer(dig_connector->dpcd,
sizeof(dig_connector->dpcd),
+ 32, 1, dpcd_hex_dump, sizeof(dpcd_hex_dump),
false);
+ DRM_DEBUG_KMS("DPCD: %s\n", dpcd_hex_dump);
radeon_dp_probe_oui(radeon_connector);
--
1.8.4.5
--
Stefan Br?ns / Bergstra?e 21 / 52062 Aachen
phone: +49 241 53809034 mobile: +49 151 50412019
