REGRESSION: dpms-on broken (drm_radeon,displayport) -- bisected
Hi Alex, Hi All, > Any chance you could bisect it? good news. It's a two-line patch. commit fb668c2fed628179c7aa409a0de39a2b96bed18c Author: Alex Deucher Date: Wed Mar 31 14:42:11 2010 -0400 drm/radeon/kms/evergreen: get DP working Need to enable the VID stream after link training Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Please note the lines from from the [kernel.log] in my original report: > : [drm:dp_link_train] ERROR clock recovery tried 5 times > : [drm:dp_link_train] ERROR clock recovery failed > : [drm:dp_link_train] ERROR channel eq failed: 5 tries > : [drm:dp_link_train] ERROR channel eq failed > >> i write to report a regression > >> The effect is, that after DPMS-OFF, the monitor cannot be reactivated > >> locally by a key press or remotely via `xset dpms force on?. > >> I can work around the issue switching the monitor off and on again. > >> I can provide more information on request and offer help testing patches. Kind regards Lars
[Bug 28294] [r300g] Unigine Sanctuary v2.2: black glitches
https://bugs.freedesktop.org/show_bug.cgi?id=28294 Tom Stellard changed: What|Removed |Added AssignedTo|tstellar at gmail.com |dri-devel at lists.freedesktop ||.org -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 25109] [r300] Wine - Civ4 Black Terrain after upgrading to mesa 7.6
https://bugs.freedesktop.org/show_bug.cgi?id=25109 Tom Stellard changed: What|Removed |Added AssignedTo|tstellar at gmail.com |dri-devel at lists.freedesktop ||.org -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[ANNOUNCE] libdrm 2.4.21
On Thursday 10 of June 2010, Eric Anholt wrote: Unresolved symbols found in: /usr/lib64/libkms.so.1.0.0 drmIoctl drmCommandWriteRead drmCommandWrite and the patch http://cvs.pld-linux.org/cgi-bin/cvsweb/packages/libdrm/libdrm- kms.patch?rev=1.1 -- Arkadiusz Mi?kiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/
REGRESSION: dpms-on broken (drm_radeon,displayport)
Hi Alex, Hi All, > >> i write to report a regression that happened after 2.6.34-rc3 and before > >> or including 2.6.34-rc4 and still persists on 2.6.35-rc2. > >> > >> The effect is, that after DPMS-OFF, the monitor cannot be reactivated > >> locally by a key press or remotely via `xset dpms force on?. > >> > >> I can work around the issue switching the monitor off and on again. > >> > >> For the technical details of the local environment see below. > >> I can provide more information on request and offer help testing patches. > Any chance you could bisect it? Absolutely, I'll try to localize it further. Soon and thanks for the quick reply. Lars
[PATCH] drm/radeon/kms: fix DP after DPMS cycle
The transmitter needs to be enabled before the link is trained.
Reported-By: Lars Doelle
Signed-off-by: Alex Deucher
Cc: stable
---
drivers/gpu/drm/radeon/radeon_encoders.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c
b/drivers/gpu/drm/radeon/radeon_encoders.c
index 1ebb100..e0b30b2 100644
--- a/drivers/gpu/drm/radeon/radeon_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_encoders.c
@@ -1072,6 +1072,8 @@ radeon_atom_encoder_dpms(struct drm_encoder *encoder, int
mode)
if (is_dig) {
switch (mode) {
case DRM_MODE_DPMS_ON:
+ if (!ASIC_IS_DCE4(rdev))
+ atombios_dig_transmitter_setup(encoder,
ATOM_TRANSMITTER_ACTION_ENABLE_OUTPUT, 0, 0);
if (atombios_get_encoder_mode(encoder) ==
ATOM_ENCODER_MODE_DP) {
struct drm_connector *connector =
radeon_get_connector_for_encoder(encoder);
@@ -1079,8 +1081,6 @@ radeon_atom_encoder_dpms(struct drm_encoder *encoder, int
mode)
if (ASIC_IS_DCE4(rdev))
atombios_dig_encoder_setup(encoder,
ATOM_ENCODER_CMD_DP_VIDEO_ON);
}
- if (!ASIC_IS_DCE4(rdev))
- atombios_dig_transmitter_setup(encoder,
ATOM_TRANSMITTER_ACTION_ENABLE_OUTPUT, 0, 0);
break;
case DRM_MODE_DPMS_STANDBY:
case DRM_MODE_DPMS_SUSPEND:
--
1.7.0.1
REGRESSION: dpms-on broken (drm_radeon,displayport) -- bisected
On Thu, Jun 10, 2010 at 4:50 PM, Lars Doelle wrote: > Hi Alex, > Hi All, > > >> Any chance you could bisect it? > > good news. It's a two-line patch. > Attached patch should fix it. Alex > > commit fb668c2fed628179c7aa409a0de39a2b96bed18c > Author: Alex Deucher > Date: ? Wed Mar 31 14:42:11 2010 -0400 > > ? ?drm/radeon/kms/evergreen: get DP working > > ? ?Need to enable the VID stream after link training > > ? ?Signed-off-by: Alex Deucher > ? ?Signed-off-by: Dave Airlie > > > Please note the lines from from the [kernel.log] in my original report: > >> : [drm:dp_link_train] ERROR clock recovery tried 5 times >> : [drm:dp_link_train] ERROR clock recovery failed >> : [drm:dp_link_train] ERROR channel eq failed: 5 tries >> : [drm:dp_link_train] ERROR channel eq failed > > >> >> i write to report a regression >> >> The effect is, that after DPMS-OFF, the monitor cannot be reactivated >> >> locally by a key press or remotely via `xset dpms force on?. >> >> I can work around the issue switching the monitor off and on again. > >> >> I can provide more information on request and offer help testing patches. > > > Kind regards > > ?Lars > > -- next part -- A non-text attachment was scrubbed... Name: 0001-drm-radeon-kms-fix-DP-after-DPMS-cycle.patch Type: text/x-patch Size: 1558 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20100610/1f6703e1/attachment.bin>
[Bug 28440] Linux kernel 2.6.34's KMS crashes and disables GPU acceleration with X1250.
https://bugs.freedesktop.org/show_bug.cgi?id=28440 coomasiehead at yahoo.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||NOTABUG --- Comment #10 from coomasiehead at yahoo.com 2010-06-10 16:58:21 PDT --- This is not a bug although the missing firmware is another bug. This bug is closed. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
REGRESSION: dpms-on broken (drm_radeon,displayport)
Moving to the dri-devel list as you're using KMS. On Don, 2010-06-10 at 16:01 +0200, Lars Doelle wrote: > Hi Benjamin, > Hi All, > > > i write to report a regression that happened after 2.6.34-rc3 and before > or including 2.6.34-rc4 and still persists on 2.6.35-rc2. > > The effect is, that after DPMS-OFF, the monitor cannot be reactivated > locally by a key press or remotely via `xset dpms force on?. > > I can work around the issue switching the monitor off and on again. > > For the technical details of the local environment see below. > I can provide more information on request and offer help testing patches. > > > > Kind regards > > Lars > > > > > > - config.gz attached, below some lines. > > CONFIG_X86_64=y > > CONFIG_DRM=y > CONFIG_DRM_KMS_HELPER=y > CONFIG_DRM_TTM=y > CONFIG_DRM_RADEON=y > CONFIG_DRM_RADEON_KMS=y > CONFIG_VIDEO_OUTPUT_CONTROL=y > > > - X11: find attached the Xorg.0.log for full information > > X.Org X Server 1.7.7 > Release Date: 2010-05-04 > [..] > (**) |-->Screen "Default Screen" (0) > (**) | |-->Monitor "DELL 2408WFP" > (**) | |-->Device "ATI FireMV 2260" > [..] > (II) RADEON(0): Output DisplayPort-0 using monitor section DELL 2408WFP > [..] > (**) RADEON(0): DPMS enabled > > > - Notes from the kernel.log > > following messages occur only >= 2.6.34-rc4. I think they are issued > when i `xset dpms force off? or dpms is used automatically. > > ... > > : [drm:dp_link_train] *ERROR* clock recovery tried 5 times > : [drm:dp_link_train] *ERROR* clock recovery failed > : [drm:dp_link_train] *ERROR* channel eq failed: 5 tries > : [drm:dp_link_train] *ERROR* channel eq failed > > ... > > The following messages might be unrelated to the problem and occur > on 2.6.34-rc3 too, when i switch the monitor off/on. > > : [drm:atom_dp_get_link_status] *ERROR* displayport link status failed > : [drm:atom_dp_get_link_status] *ERROR* displayport link status failed > : [drm:atom_dp_get_link_status] *ERROR* displayport link status failed > > Below stuff from the initiation ... > > ... > > : [drm] Initialized drm 1.1.0 20060810 > : [drm] radeon defaulting to kernel modesetting. > : [drm] radeon kernel modesetting enabled. > : radeon :01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 > : radeon :01:00.0: setting latency timer to 64 > : [drm] radeon: Initializing kernel modesetting. > : [drm] register mmio base: 0x9020 > : [drm] register mmio size: 65536 > : ATOM BIOS: 113 > : [drm] Clocks initialized ! > : [drm] Internal thermal controller with fan control > : [drm] 3 Power State(s) > : [drm] State 0 Default (default) > : [drm] 16 PCIE Lanes > : [drm] 3 Clock Mode(s) > : [drm] 0 engine/memory: 50/50 > : [drm] 1 engine/memory: 50/50 > : [drm] 2 engine/memory: 50/50 > : [drm] State 1 Performance > : [drm] 16 PCIE Lanes > : [drm] 3 Clock Mode(s) > : [drm] 0 engine/memory: 11/252000 > : [drm] 1 engine/memory: 30/396000 > : [drm] 2 engine/memory: 50/50 > : [drm] State 2 Performance > : [drm] 16 PCIE Lanes > : [drm] 3 Clock Mode(s) > : [drm] 0 engine/memory: 45/50 > : [drm] 1 engine/memory: 45/50 > : [drm] 2 engine/memory: 50/50 > : [drm] radeon: power management initialized > : radeon :01:00.0: VRAM: 256M 0x - 0x0FFF (256M used) > : radeon :01:00.0: GTT: 512M 0x1000 - 0x2FFF > : [drm] Detected VRAM RAM=256M, BAR=256M > : [drm] RAM width 64bits DDR > : Available graphics memory: 1017548 kiB. > : [drm] radeon: 256M of VRAM memory ready > : [drm] radeon: 512M of GTT memory ready. > : radeon :01:00.0: irq 30 for MSI/MSI-X > : [drm] radeon: using MSI. > : [drm] radeon: irq initialized. > : [drm] GART: num cpu pages 131072, num gpu pages 131072 > : [drm] Loading RV620 Microcode > : platform radeon_cp.0: firmware: using built-in firmware radeon/RV620_pfp.bin > : platform radeon_cp.0: firmware: using built-in firmware radeon/RV620_me.bin > : platform radeon_cp.0: firmware: using built-in firmware radeon/R600_rlc.bin > : [drm] ring test succeeded in 1 usecs > : [drm] radeon: ib pool ready. > : [drm] ib test succeeded in 0 usecs > : [drm] Enabling audio support > : [drm] Radeon Display Connectors > : [drm] Connector 0: > : [drm] DisplayPort > : [drm] HPD2 > : [drm] DDC: 0x7e60 0x7e60 0x7e64 0x7e64 0x7e68 0x7e68 0x7e6c 0x7e6c > : [drm] Encoders: > : [drm] DFP1: INTERNAL_UNIPHY > : [drm] Connector 1: > : [drm] DisplayPort > : [drm] HPD4 > : [drm] DDC: 0x7e20 0x7e20 0x7e24 0x7e24 0x7e28 0x7e28 0x7e2c 0x7e2c > : [drm] Encoders: > : [drm] DFP2: INTERNAL_UNIPHY > : [drm] fb mappable at 0x80141000 > : [drm] vram apper at 0x8000 > : [drm] size 9216000 > : [drm] fb depth is 24 > : [drm]pitch is 7680 > : Console: switching to colour frame buffer device 240x75
[Bug 28474] [gallium] lugaru/etc locks up laptop
https://bugs.freedesktop.org/show_bug.cgi?id=28474 --- Comment #3 from Marek Ol??k 2010-06-10 15:43:07 PDT --- libdrm shouldn't hardlock no matter what version you have. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 16148] New: page allocation failure. order:1, mode:0x50d0
(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Mon, 7 Jun 2010 17:32:04 GMT bugzilla-daemon at bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=16148 > >Summary: page allocation failure. order:1, mode:0x50d0 >Product: Memory Management >Version: 2.5 > Kernel Version: 2.6.35-rc1 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: Page Allocator > AssignedTo: akpm at linux-foundation.org > ReportedBy: devnull at plzk.org > Regression: No > > > Created an attachment (id=26687) > --> (https://bugzilla.kernel.org/attachment.cgi?id=26687) > dmesg > > Never seen this before. > > 2.6.35-rc1 #1 SMP Mon May 31 21:31:02 CEST 2010 x86_64 GNU/Linux > > [48126.787684] Xorg: page allocation failure. order:1, mode:0x50d0 > [48126.787691] Pid: 1895, comm: Xorg Tainted: GW 2.6.35-rc1 #1 > [48126.787694] Call Trace: > [48126.787709] [] __alloc_pages_nodemask+0x5f5/0x6f0 > [48126.787716] [] alloc_pages_current+0x95/0x100 > [48126.787720] [] new_slab+0x2ba/0x2c0 > [48126.787724] [] __slab_alloc+0x14b/0x4e0 > [48126.787730] [] ? > security_vm_enough_memory_kern+0x21/0x30 > [48126.787736] [] ? agp_alloc_page_array+0x5a/0x70 > [48126.787740] [] __kmalloc+0x11f/0x1c0 > [48126.787744] [] agp_alloc_page_array+0x5a/0x70 > [48126.787747] [] agp_generic_alloc_user+0x64/0x140 > [48126.787750] [] agp_allocate_memory+0x9a/0x140 > [48126.787755] [] drm_agp_allocate_memory+0x9/0x10 > [48126.787758] [] drm_agp_bind_pages+0x57/0x100 > [48126.787765] [] i915_gem_object_bind_to_gtt+0x144/0x340 > [48126.787768] [] i915_gem_object_pin+0xb5/0xd0 > [48126.787772] [] i915_gem_do_execbuffer+0x6cc/0x14f0 > [48126.78] [] ? __is_ram+0x0/0x10 > [48126.787783] [] ? lookup_memtype+0xce/0xe0 > [48126.787787] [] ? i915_gem_execbuffer+0x91/0x390 > [48126.787790] [] i915_gem_execbuffer+0x1d5/0x390 > [48126.787794] [] ? i915_gem_sw_finish_ioctl+0x90/0xc0 > [48126.787799] [] drm_ioctl+0x32a/0x4b0 > [48126.787802] [] ? i915_gem_execbuffer+0x0/0x390 > [48126.787807] [] vfs_ioctl+0x38/0xd0 > [48126.787810] [] do_vfs_ioctl+0x8a/0x580 > [48126.787814] [] sys_ioctl+0x81/0xa0 > [48126.787820] [] system_call_fastpath+0x16/0x1b > David, I have a vague feeling that we've been round this loop before.. Why does agp_alloc_page_array() use __GFP_NORETRY? It's pretty unusual and it's what caused this spew. There's nothing in the changelog and the only relevant commentary appears to be "This speeds things up and also saves memory for small AGP regions", which is inscrutable. Can you please add a usable comment there? Presumably this was added in response to some observed behaviour, but what was it?? If the __GFP_NORETRY is indeed useful and legitimate and given that we have a vmalloc fallback, I'd suggest that we add __GFP_NOWARN there as well to keep the bug reports away. btw, agp_memory.vmalloc_flag can be done away with - it's conventional to use is_vmalloc_addr() for this.
[Bug 28474] [gallium] lugaru/etc locks up laptop
https://bugs.freedesktop.org/show_bug.cgi?id=28474 Tormod Volden changed: What|Removed |Added Summary|lugaru/etc locks up laptop |[gallium] lugaru/etc locks ||up laptop --- Comment #2 from Tormod Volden 2010-06-10 15:38:57 PDT --- Thanks, I got almost the same list with "git log --format=oneline fa552261..f4bcd0ca -- src/gallium/drivers/r300" and started with the "monosecting". However it hung on the first commit. Now I reinstalled the same fa552261 packages and still got the hang. So back to square one. I will reinstall the same kernel as I had at the time. I am always using package management so I can find everything in dpkg.log. Just need a rainy weekend day I guess. BTW, should it be ok to use the stock libdrm from Lucid? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 26852] Build libkms against in-tree xf86drm.h
https://bugs.freedesktop.org/show_bug.cgi?id=26852 --- Comment #4 from Julien Cristau 2010-06-10 14:09:20 PDT --- the headers part was fixed in ae57dcf6e063860200b7949d5e2365e80ac4aea7, but libdrm is still missing from libkms_la_LIBADD. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] drm/fb: Fix video= mode computation
Reduced blanking is valid only when doing CVT modes. Also, generate GTF modes unless CVT was requested; CVT devices are required to support GTF, but the reverse is not true. Signed-off-by: Adam Jackson --- drivers/gpu/drm/drm_fb_helper.c | 19 +-- 1 files changed, 13 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index b3779d2..dc48806 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -146,7 +146,7 @@ static bool drm_fb_helper_connector_parse_command_line(struct drm_fb_helper_conn cvt = 1; break; case 'R': - if (!cvt) + if (cvt) rb = 1; break; case 'm': @@ -1024,11 +1024,18 @@ static struct drm_display_mode *drm_pick_cmdline_mode(struct drm_fb_helper_conne } create_mode: - mode = drm_cvt_mode(fb_helper_conn->connector->dev, cmdline_mode->xres, - cmdline_mode->yres, - cmdline_mode->refresh_specified ? cmdline_mode->refresh : 60, - cmdline_mode->rb, cmdline_mode->interlace, - cmdline_mode->margins); + if (cmdline_mode->cvt) + mode = drm_cvt_mode(fb_helper_conn->connector->dev, + cmdline_mode->xres, cmdline_mode->yres, + cmdline_mode->refresh_specified ? cmdline_mode->refresh : 60, + cmdline_mode->rb, cmdline_mode->interlace, + cmdline_mode->margins); + else + mode = drm_gtf_mode(fb_helper_conn->connector->dev, + cmdline_mode->xres, cmdline_mode->y_res, + cmdline_mode->refresh_specified ? cmdline_mode->refresh : 60, + cmdline_mode->interlace, + cmdline_mode->margins); drm_mode_set_crtcinfo(mode, CRTC_INTERLACE_HALVE_V); list_add(>head, _helper_conn->connector->modes); return mode; -- 1.7.0.1
[Bug 28440] Linux kernel 2.6.34's KMS crashes and disables GPU acceleration with X1250.
https://bugs.freedesktop.org/show_bug.cgi?id=28440 --- Comment #9 from Marcin Slusarz 2010-06-10 12:51:28 PDT --- So there was no bug - just a problem with missing firmware? If yes, please close the bug. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[ANNOUNCE] libdrm 2.4.21
Getting new intel API out the door. The two major changes: 1) media ring support on kernel 2.6.35 for doing media decode on G45+ 2) Reduced memory allocation for BO cached objects -- saves about 1/4 of the graphics memory on workloads I tested on Ironlake and 945GM. Alan Coopersmith (2): Make libkms build default OS-dependent Correct the Solaris definitions of atomic_add & atomic_dec Ben Skeggs (1): nouveau: stop shipping nouveau_class.h Chris Wilson (6): intel: Use the correct size when allocating reloc_target_info array intel: We don't need to take the bufmgr lock whilst mapping. intel: query whether a buffer is reusable. Revert "intel: We don't need to take the bufmgr lock whilst mapping." intel: Don't change tiling mode unless the kernel reports success. intel: Convert to untiled pitches if surface is too large for tiling. Daniel Stone (1): libkms: Fix include paths Eric Anholt (7): intel_bufmgr_fake: fix compile warning. Enable silent automake rules. Allow a buffer to point at itself and still get relocs. intel: Add more intermediate sizes of cache buckets between powers of 2. intel: Fix several other paths for buffers pointing at themselves. Fix radeon distcheck. Bump version to 2.4.21 for release. Jerome Glisse (1): drm/radeon: add new cs command stream dumping facilities Jesse Barnes (2): tests: add new vblank test add vbltest to .gitignore Jonathan Callen (1): Only build tests in make check Kristian H?gsberg (2): Revert "Fix pkgconfig includes for /usr/include/drm" Pull in new kernel headers Marek Ol??k (1): radeon: use the const qualifier in radeon_cs_write_table Michel D?nzer (1): vbltest: Doesn't need intel stuff. Zou Nan hai (1): intel: Add support for kernel multi-ringbuffer API. git tag: 2.4.21 http://dri.freedesktop.org/libdrm/libdrm-2.4.21.tar.bz2 MD5: 273ed9dad986e3a931649f3d8762ff74 libdrm-2.4.21.tar.bz2 SHA1: be7754008424a12e01ab0f0da3deb8de13ad2f0c libdrm-2.4.21.tar.bz2 http://dri.freedesktop.org/libdrm/libdrm-2.4.21.tar.gz MD5: 65a04d1a70b666971fb9e0fb64118a96 libdrm-2.4.21.tar.gz SHA1: 021c01d82e562ac658cc4b3ba5f599e6e52a2559 libdrm-2.4.21.tar.gz -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20100610/2ad17689/attachment.pgp>
REGRESSION: dpms-on broken (drm_radeon,displayport)
2010/6/10 Michel D?nzer : > > Moving to the dri-devel list as you're using KMS. > > On Don, 2010-06-10 at 16:01 +0200, Lars Doelle wrote: >> Hi Benjamin, >> Hi All, >> >> >> i write to report a regression that happened after 2.6.34-rc3 and before >> or including 2.6.34-rc4 and still persists on 2.6.35-rc2. >> >> The effect is, that after DPMS-OFF, the monitor cannot be reactivated >> locally by a key press or remotely via `xset dpms force on?. >> >> I can work around the issue switching the monitor off and on again. >> >> For the technical details of the local environment see below. >> I can provide more information on request and offer help testing patches. >> Any chance you could bisect it? Alex >> >> >> Kind regards >> >> ? Lars >> >> >> >> >> >> - config.gz attached, below some lines. >> >> CONFIG_X86_64=y >> >> CONFIG_DRM=y >> CONFIG_DRM_KMS_HELPER=y >> CONFIG_DRM_TTM=y >> CONFIG_DRM_RADEON=y >> CONFIG_DRM_RADEON_KMS=y >> CONFIG_VIDEO_OUTPUT_CONTROL=y >> >> >> - X11: find attached the Xorg.0.log for full information >> >> X.Org X Server 1.7.7 >> Release Date: 2010-05-04 >> [..] >> (**) |-->Screen "Default Screen" (0) >> (**) | ? |-->Monitor "DELL 2408WFP" >> (**) | ? |-->Device "ATI FireMV 2260" >> [..] >> (II) RADEON(0): Output DisplayPort-0 using monitor section DELL 2408WFP >> [..] >> (**) RADEON(0): DPMS enabled >> >> >> - Notes from the kernel.log >> >> following messages occur only >= 2.6.34-rc4. I think they are issued >> when i `xset dpms force off? or dpms is used automatically. >> >> ... >> >> : [drm:dp_link_train] *ERROR* clock recovery tried 5 times >> : [drm:dp_link_train] *ERROR* clock recovery failed >> : [drm:dp_link_train] *ERROR* channel eq failed: 5 tries >> : [drm:dp_link_train] *ERROR* channel eq failed >> >> ... >> >> The following messages might be unrelated to the problem and occur >> on 2.6.34-rc3 too, when i switch the monitor off/on. >> >> : [drm:atom_dp_get_link_status] *ERROR* displayport link status failed >> : [drm:atom_dp_get_link_status] *ERROR* displayport link status failed >> : [drm:atom_dp_get_link_status] *ERROR* displayport link status failed >> >> Below stuff from the initiation ... >> >> ... >> >> : [drm] Initialized drm 1.1.0 20060810 >> : [drm] radeon defaulting to kernel modesetting. >> : [drm] radeon kernel modesetting enabled. >> : radeon :01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 >> : radeon :01:00.0: setting latency timer to 64 >> : [drm] radeon: Initializing kernel modesetting. >> : [drm] register mmio base: 0x9020 >> : [drm] register mmio size: 65536 >> : ATOM BIOS: 113 >> : [drm] Clocks initialized ! >> : [drm] Internal thermal controller with fan control >> : [drm] 3 Power State(s) >> : [drm] State 0 Default (default) >> : [drm] ? ? ? 16 PCIE Lanes >> : [drm] ? ? ? 3 Clock Mode(s) >> : [drm] ? ? ? ? ? ? ? 0 engine/memory: 50/50 >> : [drm] ? ? ? ? ? ? ? 1 engine/memory: 50/50 >> : [drm] ? ? ? ? ? ? ? 2 engine/memory: 50/50 >> : [drm] State 1 Performance >> : [drm] ? ? ? 16 PCIE Lanes >> : [drm] ? ? ? 3 Clock Mode(s) >> : [drm] ? ? ? ? ? ? ? 0 engine/memory: 11/252000 >> : [drm] ? ? ? ? ? ? ? 1 engine/memory: 30/396000 >> : [drm] ? ? ? ? ? ? ? 2 engine/memory: 50/50 >> : [drm] State 2 Performance >> : [drm] ? ? ? 16 PCIE Lanes >> : [drm] ? ? ? 3 Clock Mode(s) >> : [drm] ? ? ? ? ? ? ? 0 engine/memory: 45/50 >> : [drm] ? ? ? ? ? ? ? 1 engine/memory: 45/50 >> : [drm] ? ? ? ? ? ? ? 2 engine/memory: 50/50 >> : [drm] radeon: power management initialized >> : radeon :01:00.0: VRAM: 256M 0x - 0x0FFF (256M used) >> : radeon :01:00.0: GTT: 512M 0x1000 - 0x2FFF >> : [drm] Detected VRAM RAM=256M, BAR=256M >> : [drm] RAM width 64bits DDR >> : Available graphics memory: 1017548 kiB. >> : [drm] radeon: 256M of VRAM memory ready >> : [drm] radeon: 512M of GTT memory ready. >> : radeon :01:00.0: irq 30 for MSI/MSI-X >> : [drm] radeon: using MSI. >> : [drm] radeon: irq initialized. >> : [drm] GART: num cpu pages 131072, num gpu pages 131072 >> : [drm] Loading RV620 Microcode >> : platform radeon_cp.0: firmware: using built-in firmware >> radeon/RV620_pfp.bin >> : platform radeon_cp.0: firmware: using built-in firmware radeon/RV620_me.bin >> : platform radeon_cp.0: firmware: using built-in firmware radeon/R600_rlc.bin >> : [drm] ring test succeeded in 1 usecs >> : [drm] radeon: ib pool ready. >> : [drm] ib test succeeded in 0 usecs >> : [drm] Enabling audio support >> : [drm] Radeon Display Connectors >> : [drm] Connector 0: >> : [drm] ? DisplayPort >> : [drm] ? HPD2 >> : [drm] ? DDC: 0x7e60 0x7e60 0x7e64 0x7e64 0x7e68 0x7e68 0x7e6c 0x7e6c >> : [drm] ? Encoders: >> : [drm] ? ? DFP1: INTERNAL_UNIPHY >> : [drm] Connector 1: >> : [drm] ? DisplayPort >> : [drm] ? HPD4 >> : [drm] ? DDC: 0x7e20 0x7e20 0x7e24 0x7e24 0x7e28 0x7e28 0x7e2c 0x7e2c >> : [drm] ? Encoders: >> : [drm] ? ? DFP2: INTERNAL_UNIPHY >> : [drm] fb mappable
[Bug 28490] page allocation failure with 2.6.35-rc2
https://bugs.freedesktop.org/show_bug.cgi?id=28490 Julien Cristau changed: What|Removed |Added Product|xorg|DRI Component|Driver/Radeon |DRM/Radeon AssignedTo|xorg-driver-ati at lists.x.org |dri-devel at lists.freedesktop ||.org QAContact|xorg-team at lists.x.org | -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 26428] [KMS] doom3-demo aborts early on rv280
https://bugs.freedesktop.org/show_bug.cgi?id=26428 --- Comment #11 from Roland Scheidegger 2010-06-10 06:44:05 PDT --- (In reply to comment #10) > using mesa debug build and RADEON_DEBUG=tex i have some additional info > > - > radeon_validate_texture_miptree: Using miptree 0x114bff08 > Checking image level 0, face 0, mt 0x114bff08 ... OK > Checking image level 1, face 0, mt 0x114bff08 ... OK > Checking image level 2, face 0, mt 0x114bff08 ... OK > Checking image level 3, face 0, mt 0x114bff08 ... OK > Checking image level 4, face 0, mt 0x114bff08 ... OK > Checking image level 5, face 0, mt 0x114bff08 ... OK > Checking image level 6, face 0, mt 0x114bff08 ... OK > Checking image level 7, face 0, mt 0x114bff08 ... OK I don't think this corresponds to the texture which is rejected. > [drm:r100_cs_track_cube] *ERROR* Cube texture offset greater than object size > 22080 20480 > [drm:r100_cs_track_texture_print] *ERROR* width 128 > [drm:r100_cs_track_texture_print] *ERROR* height 128 > [drm:r100_cs_track_texture_print] *ERROR* bpp4 > [drm:r100_cs_track_texture_print] *ERROR* coordinate type2 > [drm:r100_cs_track_texture_print] *ERROR* compress format1 Just like bug #28459 this also has the seemingly impossible bpp == 4 and compress != 0 case (bug #1). But I doubt it's the problem, as the cube texture tracking code can't cope with compressed textures anyway (bug #2) - its size calculation should be similar to what's done for non-cube compressed textures. I've also got my serious doubts about the size calculation with cube mipmaps, that offset stuff looks seriously wrong to me but I didn't look closer (that would be bug #3). Since I think there's something else entirely going on (more bugs), since if you actually look at the numbers 128*128*4 (which is what the cube texture tracking code seemingly would calculate as it ignores compress bits) would be already 64k. That can only mean the cube faces (the sizes aren't printed) were smaller than the corresponding texture faces, which, while the hardware allows this, should never happen. There also appears to be a bug (let's call it bug #4) with the command checker on the R200_PP_TXFORMAT_X packets since it ignores the TEX_COORD_TYPES 3 and 4 - I don't think the driver would ever use 4 but 3 is projected 2d and certainly used. Hence I think something similar to bug #1 could be going on when actually 2d proj is active but due to a former packet tex_coord_type is still set to cubic (this would explain the different sized cube faces). I think there are more bugs in the verifier, for one it doesn't really seem to handle ATI_fragment_shader very well (PP_CNTL_X and PP_TXMULTI_CTL regs mostly). These allow for instance enabled texture units with sampling disabled which the verifier might refuse if it doesn't like the bound texture (I'm not entirely sure though this can actually be a problem or is disallowed by the API). Also it would completely miss to check for bogus textures in the first phase, if sampling is only done there and not in the second phase, but at least this shouldn't cause any unwarranted rejection :-). Unfortunately checking correctly both phases seems quite complicated. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28459] [r300g] Heroes of Newerth slow and corrupted with libtxc_dxtn.so
https://bugs.freedesktop.org/show_bug.cgi?id=28459 --- Comment #7 from Roland Scheidegger 2010-06-10 05:17:58 PDT --- I think an explanation could be that there are two packets for the same texture unit in the command stream - if the first one is compressed, it would set cpp to 1 and set the compress bits, but if the second one is uncompressed it would set cpp according to format but the compress bits would stay as it's only written if the format is compressed. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28459] [r300g] Heroes of Newerth slow and corrupted with libtxc_dxtn.so
https://bugs.freedesktop.org/show_bug.cgi?id=28459 --- Comment #6 from Pavel Ondra?ka 2010-06-10 04:01:41 PDT --- Sadly, this bug is present also with kernel 2.6.35-rc2. Do you need any more info or logs? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28459] [r300g] Heroes of Newerth slow and corrupted with libtxc_dxtn.so
https://bugs.freedesktop.org/show_bug.cgi?id=28459 --- Comment #6 from Pavel Ondračka dra...@centrum.cz 2010-06-10 04:01:41 PDT --- Sadly, this bug is present also with kernel 2.6.35-rc2. Do you need any more info or logs? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28459] [r300g] Heroes of Newerth slow and corrupted with libtxc_dxtn.so
https://bugs.freedesktop.org/show_bug.cgi?id=28459 --- Comment #7 from Roland Scheidegger srol...@vmware.com 2010-06-10 05:17:58 PDT --- I think an explanation could be that there are two packets for the same texture unit in the command stream - if the first one is compressed, it would set cpp to 1 and set the compress bits, but if the second one is uncompressed it would set cpp according to format but the compress bits would stay as it's only written if the format is compressed. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 26428] [KMS] doom3-demo aborts early on rv280
https://bugs.freedesktop.org/show_bug.cgi?id=26428 --- Comment #11 from Roland Scheidegger srol...@vmware.com 2010-06-10 06:44:05 PDT --- (In reply to comment #10) using mesa debug build and RADEON_DEBUG=tex i have some additional info - radeon_validate_texture_miptree: Using miptree 0x114bff08 Checking image level 0, face 0, mt 0x114bff08 ... OK Checking image level 1, face 0, mt 0x114bff08 ... OK Checking image level 2, face 0, mt 0x114bff08 ... OK Checking image level 3, face 0, mt 0x114bff08 ... OK Checking image level 4, face 0, mt 0x114bff08 ... OK Checking image level 5, face 0, mt 0x114bff08 ... OK Checking image level 6, face 0, mt 0x114bff08 ... OK Checking image level 7, face 0, mt 0x114bff08 ... OK I don't think this corresponds to the texture which is rejected. [drm:r100_cs_track_cube] *ERROR* Cube texture offset greater than object size 22080 20480 [drm:r100_cs_track_texture_print] *ERROR* width 128 [drm:r100_cs_track_texture_print] *ERROR* height 128 [drm:r100_cs_track_texture_print] *ERROR* bpp4 [drm:r100_cs_track_texture_print] *ERROR* coordinate type2 [drm:r100_cs_track_texture_print] *ERROR* compress format1 Just like bug #28459 this also has the seemingly impossible bpp == 4 and compress != 0 case (bug #1). But I doubt it's the problem, as the cube texture tracking code can't cope with compressed textures anyway (bug #2) - its size calculation should be similar to what's done for non-cube compressed textures. I've also got my serious doubts about the size calculation with cube mipmaps, that offset stuff looks seriously wrong to me but I didn't look closer (that would be bug #3). Since I think there's something else entirely going on (more bugs), since if you actually look at the numbers 128*128*4 (which is what the cube texture tracking code seemingly would calculate as it ignores compress bits) would be already 64k. That can only mean the cube faces (the sizes aren't printed) were smaller than the corresponding texture faces, which, while the hardware allows this, should never happen. There also appears to be a bug (let's call it bug #4) with the command checker on the R200_PP_TXFORMAT_X packets since it ignores the TEX_COORD_TYPES 3 and 4 - I don't think the driver would ever use 4 but 3 is projected 2d and certainly used. Hence I think something similar to bug #1 could be going on when actually 2d proj is active but due to a former packet tex_coord_type is still set to cubic (this would explain the different sized cube faces). I think there are more bugs in the verifier, for one it doesn't really seem to handle ATI_fragment_shader very well (PP_CNTL_X and PP_TXMULTI_CTL regs mostly). These allow for instance enabled texture units with sampling disabled which the verifier might refuse if it doesn't like the bound texture (I'm not entirely sure though this can actually be a problem or is disallowed by the API). Also it would completely miss to check for bogus textures in the first phase, if sampling is only done there and not in the second phase, but at least this shouldn't cause any unwarranted rejection :-). Unfortunately checking correctly both phases seems quite complicated. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: REGRESSION: dpms-on broken (drm_radeon,displayport)
Moving to the dri-devel list as you're using KMS. On Don, 2010-06-10 at 16:01 +0200, Lars Doelle wrote: Hi Benjamin, Hi All, i write to report a regression that happened after 2.6.34-rc3 and before or including 2.6.34-rc4 and still persists on 2.6.35-rc2. The effect is, that after DPMS-OFF, the monitor cannot be reactivated locally by a key press or remotely via `xset dpms force on´. I can work around the issue switching the monitor off and on again. For the technical details of the local environment see below. I can provide more information on request and offer help testing patches. Kind regards Lars - config.gz attached, below some lines. CONFIG_X86_64=y CONFIG_DRM=y CONFIG_DRM_KMS_HELPER=y CONFIG_DRM_TTM=y CONFIG_DRM_RADEON=y CONFIG_DRM_RADEON_KMS=y CONFIG_VIDEO_OUTPUT_CONTROL=y - X11: find attached the Xorg.0.log for full information X.Org X Server 1.7.7 Release Date: 2010-05-04 [..] (**) |--Screen Default Screen (0) (**) | |--Monitor DELL 2408WFP (**) | |--Device ATI FireMV 2260 [..] (II) RADEON(0): Output DisplayPort-0 using monitor section DELL 2408WFP [..] (**) RADEON(0): DPMS enabled - Notes from the kernel.log following messages occur only = 2.6.34-rc4. I think they are issued when i `xset dpms force off´ or dpms is used automatically. ... : [drm:dp_link_train] *ERROR* clock recovery tried 5 times : [drm:dp_link_train] *ERROR* clock recovery failed : [drm:dp_link_train] *ERROR* channel eq failed: 5 tries : [drm:dp_link_train] *ERROR* channel eq failed ... The following messages might be unrelated to the problem and occur on 2.6.34-rc3 too, when i switch the monitor off/on. : [drm:atom_dp_get_link_status] *ERROR* displayport link status failed : [drm:atom_dp_get_link_status] *ERROR* displayport link status failed : [drm:atom_dp_get_link_status] *ERROR* displayport link status failed Below stuff from the initiation ... ... : [drm] Initialized drm 1.1.0 20060810 : [drm] radeon defaulting to kernel modesetting. : [drm] radeon kernel modesetting enabled. : radeon :01:00.0: PCI INT A - GSI 16 (level, low) - IRQ 16 : radeon :01:00.0: setting latency timer to 64 : [drm] radeon: Initializing kernel modesetting. : [drm] register mmio base: 0x9020 : [drm] register mmio size: 65536 : ATOM BIOS: 113 : [drm] Clocks initialized ! : [drm] Internal thermal controller with fan control : [drm] 3 Power State(s) : [drm] State 0 Default (default) : [drm] 16 PCIE Lanes : [drm] 3 Clock Mode(s) : [drm] 0 engine/memory: 50/50 : [drm] 1 engine/memory: 50/50 : [drm] 2 engine/memory: 50/50 : [drm] State 1 Performance : [drm] 16 PCIE Lanes : [drm] 3 Clock Mode(s) : [drm] 0 engine/memory: 11/252000 : [drm] 1 engine/memory: 30/396000 : [drm] 2 engine/memory: 50/50 : [drm] State 2 Performance : [drm] 16 PCIE Lanes : [drm] 3 Clock Mode(s) : [drm] 0 engine/memory: 45/50 : [drm] 1 engine/memory: 45/50 : [drm] 2 engine/memory: 50/50 : [drm] radeon: power management initialized : radeon :01:00.0: VRAM: 256M 0x - 0x0FFF (256M used) : radeon :01:00.0: GTT: 512M 0x1000 - 0x2FFF : [drm] Detected VRAM RAM=256M, BAR=256M : [drm] RAM width 64bits DDR : Available graphics memory: 1017548 kiB. : [drm] radeon: 256M of VRAM memory ready : [drm] radeon: 512M of GTT memory ready. : radeon :01:00.0: irq 30 for MSI/MSI-X : [drm] radeon: using MSI. : [drm] radeon: irq initialized. : [drm] GART: num cpu pages 131072, num gpu pages 131072 : [drm] Loading RV620 Microcode : platform radeon_cp.0: firmware: using built-in firmware radeon/RV620_pfp.bin : platform radeon_cp.0: firmware: using built-in firmware radeon/RV620_me.bin : platform radeon_cp.0: firmware: using built-in firmware radeon/R600_rlc.bin : [drm] ring test succeeded in 1 usecs : [drm] radeon: ib pool ready. : [drm] ib test succeeded in 0 usecs : [drm] Enabling audio support : [drm] Radeon Display Connectors : [drm] Connector 0: : [drm] DisplayPort : [drm] HPD2 : [drm] DDC: 0x7e60 0x7e60 0x7e64 0x7e64 0x7e68 0x7e68 0x7e6c 0x7e6c : [drm] Encoders: : [drm] DFP1: INTERNAL_UNIPHY : [drm] Connector 1: : [drm] DisplayPort : [drm] HPD4 : [drm] DDC: 0x7e20 0x7e20 0x7e24 0x7e24 0x7e28 0x7e28 0x7e2c 0x7e2c : [drm] Encoders: : [drm] DFP2: INTERNAL_UNIPHY : [drm] fb mappable at 0x80141000 : [drm] vram apper at 0x8000 : [drm] size 9216000 : [drm] fb depth is 24 : [drm]pitch is 7680 : Console: switching to colour frame buffer device 240x75 : fb0: radeondrmfb frame buffer device : registered panic notifier : [drm] Initialized radeon 2.2.0 20080528 for :01:00.0 on minor 0 -- Earthling
Re: REGRESSION: dpms-on broken (drm_radeon,displayport)
2010/6/10 Michel Dänzer mic...@daenzer.net: Moving to the dri-devel list as you're using KMS. On Don, 2010-06-10 at 16:01 +0200, Lars Doelle wrote: Hi Benjamin, Hi All, i write to report a regression that happened after 2.6.34-rc3 and before or including 2.6.34-rc4 and still persists on 2.6.35-rc2. The effect is, that after DPMS-OFF, the monitor cannot be reactivated locally by a key press or remotely via `xset dpms force on´. I can work around the issue switching the monitor off and on again. For the technical details of the local environment see below. I can provide more information on request and offer help testing patches. Any chance you could bisect it? Alex Kind regards Lars - config.gz attached, below some lines. CONFIG_X86_64=y CONFIG_DRM=y CONFIG_DRM_KMS_HELPER=y CONFIG_DRM_TTM=y CONFIG_DRM_RADEON=y CONFIG_DRM_RADEON_KMS=y CONFIG_VIDEO_OUTPUT_CONTROL=y - X11: find attached the Xorg.0.log for full information X.Org X Server 1.7.7 Release Date: 2010-05-04 [..] (**) |--Screen Default Screen (0) (**) | |--Monitor DELL 2408WFP (**) | |--Device ATI FireMV 2260 [..] (II) RADEON(0): Output DisplayPort-0 using monitor section DELL 2408WFP [..] (**) RADEON(0): DPMS enabled - Notes from the kernel.log following messages occur only = 2.6.34-rc4. I think they are issued when i `xset dpms force off´ or dpms is used automatically. ... : [drm:dp_link_train] *ERROR* clock recovery tried 5 times : [drm:dp_link_train] *ERROR* clock recovery failed : [drm:dp_link_train] *ERROR* channel eq failed: 5 tries : [drm:dp_link_train] *ERROR* channel eq failed ... The following messages might be unrelated to the problem and occur on 2.6.34-rc3 too, when i switch the monitor off/on. : [drm:atom_dp_get_link_status] *ERROR* displayport link status failed : [drm:atom_dp_get_link_status] *ERROR* displayport link status failed : [drm:atom_dp_get_link_status] *ERROR* displayport link status failed Below stuff from the initiation ... ... : [drm] Initialized drm 1.1.0 20060810 : [drm] radeon defaulting to kernel modesetting. : [drm] radeon kernel modesetting enabled. : radeon :01:00.0: PCI INT A - GSI 16 (level, low) - IRQ 16 : radeon :01:00.0: setting latency timer to 64 : [drm] radeon: Initializing kernel modesetting. : [drm] register mmio base: 0x9020 : [drm] register mmio size: 65536 : ATOM BIOS: 113 : [drm] Clocks initialized ! : [drm] Internal thermal controller with fan control : [drm] 3 Power State(s) : [drm] State 0 Default (default) : [drm] 16 PCIE Lanes : [drm] 3 Clock Mode(s) : [drm] 0 engine/memory: 50/50 : [drm] 1 engine/memory: 50/50 : [drm] 2 engine/memory: 50/50 : [drm] State 1 Performance : [drm] 16 PCIE Lanes : [drm] 3 Clock Mode(s) : [drm] 0 engine/memory: 11/252000 : [drm] 1 engine/memory: 30/396000 : [drm] 2 engine/memory: 50/50 : [drm] State 2 Performance : [drm] 16 PCIE Lanes : [drm] 3 Clock Mode(s) : [drm] 0 engine/memory: 45/50 : [drm] 1 engine/memory: 45/50 : [drm] 2 engine/memory: 50/50 : [drm] radeon: power management initialized : radeon :01:00.0: VRAM: 256M 0x - 0x0FFF (256M used) : radeon :01:00.0: GTT: 512M 0x1000 - 0x2FFF : [drm] Detected VRAM RAM=256M, BAR=256M : [drm] RAM width 64bits DDR : Available graphics memory: 1017548 kiB. : [drm] radeon: 256M of VRAM memory ready : [drm] radeon: 512M of GTT memory ready. : radeon :01:00.0: irq 30 for MSI/MSI-X : [drm] radeon: using MSI. : [drm] radeon: irq initialized. : [drm] GART: num cpu pages 131072, num gpu pages 131072 : [drm] Loading RV620 Microcode : platform radeon_cp.0: firmware: using built-in firmware radeon/RV620_pfp.bin : platform radeon_cp.0: firmware: using built-in firmware radeon/RV620_me.bin : platform radeon_cp.0: firmware: using built-in firmware radeon/R600_rlc.bin : [drm] ring test succeeded in 1 usecs : [drm] radeon: ib pool ready. : [drm] ib test succeeded in 0 usecs : [drm] Enabling audio support : [drm] Radeon Display Connectors : [drm] Connector 0: : [drm] DisplayPort : [drm] HPD2 : [drm] DDC: 0x7e60 0x7e60 0x7e64 0x7e64 0x7e68 0x7e68 0x7e6c 0x7e6c : [drm] Encoders: : [drm] DFP1: INTERNAL_UNIPHY : [drm] Connector 1: : [drm] DisplayPort : [drm] HPD4 : [drm] DDC: 0x7e20 0x7e20 0x7e24 0x7e24 0x7e28 0x7e28 0x7e2c 0x7e2c : [drm] Encoders: : [drm] DFP2: INTERNAL_UNIPHY : [drm] fb mappable at 0x80141000 : [drm] vram apper at 0x8000 : [drm] size 9216000 : [drm] fb depth is 24 : [drm] pitch is 7680 : Console: switching to colour frame buffer device 240x75 : fb0: radeondrmfb frame buffer device : registered panic notifier : [drm] Initialized radeon
[Bug 28490] page allocation failure with 2.6.35-rc2
https://bugs.freedesktop.org/show_bug.cgi?id=28490 Julien Cristau jcris...@debian.org changed: What|Removed |Added Product|xorg|DRI Component|Driver/Radeon |DRM/Radeon AssignedTo|xorg-driver-...@lists.x.org |dri-de...@lists.freedesktop ||.org QAContact|xorg-t...@lists.x.org | -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] libkms: don't export internal functions
---
libkms/internal.h |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/libkms/internal.h b/libkms/internal.h
index 63122d1..efb781a 100644
--- a/libkms/internal.h
+++ b/libkms/internal.h
@@ -30,6 +30,7 @@
#define INTERNAL_H_
#include libkms.h
+#include xf86drm-internals.h
struct kms_driver
{
@@ -62,12 +63,12 @@ struct kms_bo
unsigned handle;
};
-int linux_create(int fd, struct kms_driver **out);
+_DRM_HIDDEN int linux_create(int fd, struct kms_driver **out);
-int vmwgfx_create(int fd, struct kms_driver **out);
+_DRM_HIDDEN int vmwgfx_create(int fd, struct kms_driver **out);
-int intel_create(int fd, struct kms_driver **out);
+_DRM_HIDDEN int intel_create(int fd, struct kms_driver **out);
-int nouveau_create(int fd, struct kms_driver **out);
+_DRM_HIDDEN int nouveau_create(int fd, struct kms_driver **out);
#endif
--
1.7.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [ANNOUNCE] libdrm 2.4.21
On Thursday 10 of June 2010, Eric Anholt wrote: Unresolved symbols found in: /usr/lib64/libkms.so.1.0.0 drmIoctl drmCommandWriteRead drmCommandWrite and the patch http://cvs.pld-linux.org/cgi-bin/cvsweb/packages/libdrm/libdrm- kms.patch?rev=1.1 -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28440] Linux kernel 2.6.34's KMS crashes and disables GPU acceleration with X1250.
https://bugs.freedesktop.org/show_bug.cgi?id=28440 --- Comment #9 from Marcin Slusarz marcin.slus...@gmail.com 2010-06-10 12:51:28 PDT --- So there was no bug - just a problem with missing firmware? If yes, please close the bug. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon/kms: fix DP after DPMS cycle
The transmitter needs to be enabled before the link is trained.
Reported-By: Lars Doelle lars.doe...@on-line.de
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
Cc: stable sta...@kernel.org
---
drivers/gpu/drm/radeon/radeon_encoders.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c
b/drivers/gpu/drm/radeon/radeon_encoders.c
index 1ebb100..e0b30b2 100644
--- a/drivers/gpu/drm/radeon/radeon_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_encoders.c
@@ -1072,6 +1072,8 @@ radeon_atom_encoder_dpms(struct drm_encoder *encoder, int
mode)
if (is_dig) {
switch (mode) {
case DRM_MODE_DPMS_ON:
+ if (!ASIC_IS_DCE4(rdev))
+ atombios_dig_transmitter_setup(encoder,
ATOM_TRANSMITTER_ACTION_ENABLE_OUTPUT, 0, 0);
if (atombios_get_encoder_mode(encoder) ==
ATOM_ENCODER_MODE_DP) {
struct drm_connector *connector =
radeon_get_connector_for_encoder(encoder);
@@ -1079,8 +1081,6 @@ radeon_atom_encoder_dpms(struct drm_encoder *encoder, int
mode)
if (ASIC_IS_DCE4(rdev))
atombios_dig_encoder_setup(encoder,
ATOM_ENCODER_CMD_DP_VIDEO_ON);
}
- if (!ASIC_IS_DCE4(rdev))
- atombios_dig_transmitter_setup(encoder,
ATOM_TRANSMITTER_ACTION_ENABLE_OUTPUT, 0, 0);
break;
case DRM_MODE_DPMS_STANDBY:
case DRM_MODE_DPMS_SUSPEND:
--
1.7.0.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] Add _DRM_HIDDEN macro
On Thu, Jun 10, 2010 at 23:50:09 +0200, Julien Cristau wrote: Introduce a new internal header since that doesn't seem to exist yet. Or maybe I should rename xf86atomic.h instead. --- xf86drm-internals.h | 12 1 files changed, 12 insertions(+), 0 deletions(-) create mode 100644 xf86drm-internals.h Sorry, forgot to include it in Makefile.am. If the rest of the series is acked I can resend with the fix. Cheers, Julien ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28474] [gallium] lugaru/etc locks up laptop
https://bugs.freedesktop.org/show_bug.cgi?id=28474 Tormod Volden bugzi09.fdo.tor...@xoxy.net changed: What|Removed |Added Summary|lugaru/etc locks up laptop |[gallium] lugaru/etc locks ||up laptop --- Comment #2 from Tormod Volden bugzi09.fdo.tor...@xoxy.net 2010-06-10 15:38:57 PDT --- Thanks, I got almost the same list with git log --format=oneline fa552261..f4bcd0ca -- src/gallium/drivers/r300 and started with the monosecting. However it hung on the first commit. Now I reinstalled the same fa552261 packages and still got the hang. So back to square one. I will reinstall the same kernel as I had at the time. I am always using package management so I can find everything in dpkg.log. Just need a rainy weekend day I guess. BTW, should it be ok to use the stock libdrm from Lucid? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: REGRESSION: dpms-on broken (drm_radeon,displayport) -- bisected
On Thu, Jun 10, 2010 at 4:50 PM, Lars Doelle lars.doe...@on-line.de wrote:
Hi Alex,
Hi All,
Any chance you could bisect it?
good news. It's a two-line patch.
Attached patch should fix it.
Alex
commit fb668c2fed628179c7aa409a0de39a2b96bed18c
Author: Alex Deucher alexdeuc...@gmail.com
Date: Wed Mar 31 14:42:11 2010 -0400
drm/radeon/kms/evergreen: get DP working
Need to enable the VID stream after link training
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
Signed-off-by: Dave Airlie airl...@redhat.com
Please note the lines from from the [kernel.log] in my original report:
: [drm:dp_link_train] ERROR clock recovery tried 5 times
: [drm:dp_link_train] ERROR clock recovery failed
: [drm:dp_link_train] ERROR channel eq failed: 5 tries
: [drm:dp_link_train] ERROR channel eq failed
i write to report a regression
The effect is, that after DPMS-OFF, the monitor cannot be reactivated
locally by a key press or remotely via `xset dpms force on´.
I can work around the issue switching the monitor off and on again.
I can provide more information on request and offer help testing patches.
Kind regards
Lars
From 29714c1738f5956dab0ccee85473b928d5be30bd Mon Sep 17 00:00:00 2001
From: Alex Deucher alexdeuc...@gmail.com
Date: Thu, 10 Jun 2010 17:01:19 -0400
Subject: [PATCH] drm/radeon/kms: fix DP after DPMS cycle
The transmitter needs to be enabled before the link is trained.
Reported-By: Lars Doelle lars.doe...@on-line.de
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
Cc: stable sta...@kernel.org
---
drivers/gpu/drm/radeon/radeon_encoders.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c b/drivers/gpu/drm/radeon/radeon_encoders.c
index 1ebb100..e0b30b2 100644
--- a/drivers/gpu/drm/radeon/radeon_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_encoders.c
@@ -1072,6 +1072,8 @@ radeon_atom_encoder_dpms(struct drm_encoder *encoder, int mode)
if (is_dig) {
switch (mode) {
case DRM_MODE_DPMS_ON:
+ if (!ASIC_IS_DCE4(rdev))
+atombios_dig_transmitter_setup(encoder, ATOM_TRANSMITTER_ACTION_ENABLE_OUTPUT, 0, 0);
if (atombios_get_encoder_mode(encoder) == ATOM_ENCODER_MODE_DP) {
struct drm_connector *connector = radeon_get_connector_for_encoder(encoder);
@@ -1079,8 +1081,6 @@ radeon_atom_encoder_dpms(struct drm_encoder *encoder, int mode)
if (ASIC_IS_DCE4(rdev))
atombios_dig_encoder_setup(encoder, ATOM_ENCODER_CMD_DP_VIDEO_ON);
}
- if (!ASIC_IS_DCE4(rdev))
-atombios_dig_transmitter_setup(encoder, ATOM_TRANSMITTER_ACTION_ENABLE_OUTPUT, 0, 0);
break;
case DRM_MODE_DPMS_STANDBY:
case DRM_MODE_DPMS_SUSPEND:
--
1.7.0.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] Add _DRM_HIDDEN macro
Introduce a new internal header since that doesn't seem to exist yet. Or maybe I should rename xf86atomic.h instead. --- xf86drm-internals.h | 12 1 files changed, 12 insertions(+), 0 deletions(-) create mode 100644 xf86drm-internals.h diff --git a/xf86drm-internals.h b/xf86drm-internals.h new file mode 100644 index 000..bf5ff51 --- /dev/null +++ b/xf86drm-internals.h @@ -0,0 +1,12 @@ +#ifndef XF86DRM_INTERNALS_H +#define XF86DRM_INTERNALS_H + +#if defined(__GNUC__) (__GNUC__ = 4) +# define _DRM_HIDDEN __attribute__((visibility(hidden))) +#elif defined(__SUNPRO_C) (__SUNPRO_C = 0x550) +# define _DRM_HIDDEN __hidden +#else /* not gcc = 4 and not Sun Studio = 8 */ +# define _X_HIDDEN +#endif /* GNUC = 4 */ + +#endif -- 1.7.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: REGRESSION: dpms-on broken (drm_radeon,displayport) -- bisected
Hi Alex, Hi All, Attached patch should fix it. Yes, it does. Alex, All, great job! Thanks and kind regards Lars ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28474] [gallium] lugaru/etc locks up laptop
https://bugs.freedesktop.org/show_bug.cgi?id=28474 --- Comment #3 from Marek Olšák mar...@gmail.com 2010-06-10 15:43:07 PDT --- libdrm shouldn't hardlock no matter what version you have. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28440] Linux kernel 2.6.34's KMS crashes and disables GPU acceleration with X1250.
https://bugs.freedesktop.org/show_bug.cgi?id=28440 coomasieh...@yahoo.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||NOTABUG --- Comment #10 from coomasieh...@yahoo.com 2010-06-10 16:58:21 PDT --- This is not a bug although the missing firmware is another bug. This bug is closed. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
