https://bugs.freedesktop.org/show_bug.cgi?id=28600
Summary: The LXterminal Window TitleBar does not show up when
KMS is enabled
Product: DRI
Version: XOrg CVS
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
Severity: minor
Priority: medium
Component: DRM/Radeon
AssignedTo: dri-devel(a)lists.freedesktop.org
ReportedBy: jjorge(a)free.fr
On a R100 Mobility GPU, Mandriva 2010.1 , I can try Radeon Modesetting. All
works, except the title bar of LXterminal that appears transparent. I still can
move the windo clicking on it.
Then WM used is OpenBox.
ATI Technologies Inc Radeon Mobility M6 LY
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=28426
Summary: hardware cursor corruption with radeon+kms
Product: DRI
Version: unspecified
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: DRM/Radeon
AssignedTo: dri-devel(a)lists.freedesktop.org
ReportedBy: maillist(a)pnpitalia.it
please see also bug #19215, may be related
After some days the xorg server is up and running the cursor get corrupted.
This is a kde4 desktop on a dual 1920x1080 screen powered by an ATI Radeon HD
4670.
The bug happens often, having played a game like Aquaria (in windowed mode)
help a lot, but it does not guarantees an immediate trigger.
This time xorg was up and running for about four days (not totally sure),
yesterday I've played with the already mentioned Aquaria.
please feel free to request further information
since I don't know where to start I've tried to be broad on covering the system
information, here is what the attached zip file contain:
- "cursor-gimp.jpeg"
cursor as it should be (after a reboot)
- "VGA-0-cursor-broken.jpeg"
cursor as it's shown in the left monitor VGA-0
- "DVI-0-cursor-broken.jpeg"
cursor as it's shown in the right monitor DVI-0
- "Xorg.0.log"
log for the server on vt7 whit kde running
- "Xorg.1.log"
tentative to start another X server on vt8, it also had a broken cursor
- "xorg.conf"
"SWcursor" is commented out
- "radeontool--debug-regs.log"
`radeontool debug regs` output
- "installed-software.log"
radeon and x11 related software installed on this pc
- "modinfo-radeon.log"
`modinfo radeon` output
- "lsmod.log"
`lsmod` output
- "xrandr--verbose.log"
`xrandr -q --verbose` output
- "lspci-vvv.log"
`lspci -vvv` output
- "lshw.log"
`lshw` output, it's an hardware lister
- "dmesg.log"
`dmesg` output
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=28373
Summary: DRM lockup on X startup
Product: DRI
Version: DRI CVS
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: DRM/Radeon
AssignedTo: dri-devel(a)lists.freedesktop.org
ReportedBy: mattias.nissler(a)gmx.de
I've tried to get the DRM/KMS stuff going on my Ati X800 Pro R423 PCIE. Here
are theversions I've tried with:
drm-2.6.git at 9e67e5b Merge tag 'v2.6.34' into drm-radeon-testing
libdrm git at 607e228 Enable silent automake rules.
xf86-video-ati git at 428125c r3xx-r5xx: enable color tiling by default on KMS
mesa git at b202c78 r300: fix blits for textures of width/height greater than
2048 on r5xx
The kernel boots up just fine and the text console switches to the drm
framebuffer device as expected. When starting the X server, the VT switch
occurs, but the display just freezes (presumably at modesetting time). The
kernel doesn't crash, but graphics become unusable (no VT switching,
modesetting whatsoever possible from the command line). In my kernel logs, I
see the following:
Jun 3 17:51:06 kea kernel: INFO: task X:3245 blocked for more than 120
seconds.
Jun 3 17:51:06 kea kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
Jun 3 17:51:06 kea kernel: X D ffffffff8175c820 0 3245 3243
0x00400004
Jun 3 17:51:06 kea kernel: ffff88007c515788 0000000000000046 0000000000000000
ffffffff00000000
Jun 3 17:51:06 kea kernel: ffff88007c515fd8 ffff88007c515fd8 ffff88007a961040
0000000000014000
Jun 3 17:51:06 kea kernel: ffff88007c515fd8 0000000000014000 ffffffff81a67020
ffff88007a961040
Jun 3 17:51:06 kea kernel: Call Trace:
Jun 3 17:51:06 kea kernel: [<ffffffff81743bc3>] mutex_lock_nested+0x183/0x370
Jun 3 17:51:06 kea kernel: [<ffffffff813bfb5b>] ? radeon_ring_lock+0x2b/0x60
Jun 3 17:51:06 kea kernel: [<ffffffff813bfb5b>] radeon_ring_lock+0x2b/0x60
Jun 3 17:51:06 kea kernel: [<ffffffff8174519b>] ?
_raw_write_unlock_irqrestore+0x3b/0x60
Jun 3 17:51:06 kea kernel: [<ffffffff813d36a1>] r300_gpu_is_lockup+0x71/0x190
Jun 3 17:51:06 kea kernel: [<ffffffff813a8aee>] radeon_fence_wait+0x32e/0x3c0
Jun 3 17:51:06 kea kernel: [<ffffffff810926b0>] ?
autoremove_wake_function+0x0/0x40
Jun 3 17:51:06 kea kernel: [<ffffffff813a82a5>] ? radeon_fence_emit+0xe5/0x130
Jun 3 17:51:06 kea kernel: [<ffffffff814074c8>]
radeon_pm_set_clocks+0x428/0x670
Jun 3 17:51:06 kea kernel: [<ffffffff81407742>] ?
radeon_pm_compute_clocks+0x32/0x280
Jun 3 17:51:06 kea kernel: [<ffffffff814077f0>]
radeon_pm_compute_clocks+0xe0/0x280
Jun 3 17:51:06 kea kernel: [<ffffffff813ac42c>]
radeon_crtc_mode_fixup+0x2c/0x50
Jun 3 17:51:06 kea kernel: [<ffffffff81358958>]
drm_crtc_helper_set_mode+0x138/0x3c0
Jun 3 17:51:06 kea kernel: [<ffffffff81359657>]
drm_crtc_helper_set_config+0x837/0x8e0
Jun 3 17:51:06 kea kernel: [<ffffffff8136be00>] drm_mode_setcrtc+0x170/0x3c0
Jun 3 17:51:06 kea kernel: [<ffffffff8135e79a>] drm_ioctl+0x33a/0x4c0
Jun 3 17:51:06 kea kernel: [<ffffffff8136bc90>] ? drm_mode_setcrtc+0x0/0x3c0
Jun 3 17:51:06 kea kernel: [<ffffffff810973de>] ? up_read+0x1e/0x40
Jun 3 17:51:06 kea kernel: [<ffffffff81114a98>] vfs_ioctl+0x38/0xd0
Jun 3 17:51:06 kea kernel: [<ffffffff81114c7a>] do_vfs_ioctl+0x8a/0x640
Jun 3 17:51:06 kea kernel: [<ffffffff8111527a>] sys_ioctl+0x4a/0x80
Jun 3 17:51:06 kea kernel: [<ffffffff81032f42>] system_call_fastpath+0x16/0x1b
Jun 3 17:51:06 kea kernel: 6 locks held by X/3245:
Jun 3 17:51:06 kea kernel: #0: (&dev->mode_config.mutex){......}, at:
[<ffffffff8136bcca>] drm_mode_setcrtc+0x3a/0x3c0
Jun 3 17:51:06 kea kernel: #1: (&rdev->pm.mutex){......}, at:
[<ffffffff81407742>] radeon_pm_compute_clocks+0x32/0x280
Jun 3 17:51:06 kea kernel: #2: (&dev->struct_mutex){......}, at:
[<ffffffff814070d1>] radeon_pm_set_clocks+0x31/0x670
Jun 3 17:51:06 kea kernel: #3: (&rdev->vram_mutex){......}, at:
[<ffffffff814070db>] radeon_pm_set_clocks+0x3b/0x670
Jun 3 17:51:06 kea kernel: #4: (&rdev->cp.mutex){......}, at:
[<ffffffff814070e5>] radeon_pm_set_clocks+0x45/0x670
Jun 3 17:51:06 kea kernel: #5: (&rdev->cp.mutex){......}, at:
[<ffffffff813bfb5b>] radeon_ring_lock+0x2b/0x60
I've had a quick look at the code, seems radeon_ring_lock cannot acquire the
lock, since it's already taken by radeon_pm_set_clocks? But maybe the
300_gpu_is_lockup call indicates there's a bigger problem occurring before? You
see, I don't know the code ;)
If you want me to try patches, different versions etc. I'm happy to help. Keep
up the good work!
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=28217
Summary: Black screen and crash on r600 with radeon module not
loaded
Product: DRI
Version: XOrg CVS
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: DRM/Radeon
AssignedTo: dri-devel(a)lists.freedesktop.org
ReportedBy: kilobug(a)freesurf.fr
If the radeon kernel module isn't loaded, starting Xorg gives me a black screen
and I need to do a hard reboot (reset).
I've a HD4650 radeon, so it's r600 driver. This didn't happen with my old
Radeon 9250, but I did upgrade X and kernel at the same time (to have r600
support), so not sure if it's related to hardware or to more recent X.
I'm using Debian GNU/Linux with 64-bits kernel and 32-bits userland and :
- xserver-xorg-video-radeon version 1:6.13.0-2
- xserver-xorg version 1:7.5+6
- libgl1-mesa-dri version 7.8.1-1
- kernel 2.6.33-2-amd64
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=28069
Summary: maniadrive - smooth play with
LIBGL_ALWAYS_INDIRECT=true, (almost) unplayable
otherwise
Product: DRI
Version: XOrg CVS
Platform: Other
OS/Version: All
Status: NEW
Severity: enhancement
Priority: medium
Component: DRM/Radeon
AssignedTo: dri-devel(a)lists.freedesktop.org
ReportedBy: pcpa(a)mandriva.com.br
The problem described in https://bugs.freedesktop.org/show_bug.cgi?id=28002
actually also happens with the ati driver.
Just that with the ati driver, it is less visible (the car position jumps
less), but with LIBGL_ALWAYS_INDIRECT it also becomes a lot more smooth.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=27609
Summary: Regression: r600 CS checker rejects narrow FBO
renderbuffers.
Product: DRI
Version: unspecified
Platform: Other
OS/Version: All
Status: NEW
Severity: major
Priority: medium
Component: DRM/Radeon
AssignedTo: dri-devel(a)lists.freedesktop.org
ReportedBy: nbowler(a)draconx.ca
Created an attachment (id=34944)
--> (https://bugs.freedesktop.org/attachment.cgi?id=34944)
Full kernel log including failure message.
The R600 CS checker recently merged into the mainline kernel breaks rendering
to FBOs with renderbuffers of width <= 48. The height does not matter.
Attempting to run such a program terminates with
drmRadeonCmdBuffer: -22. Kernel failed to parse or rejected command stream.
See dmesg for more info.
and in dmesg:
radeon 0000:03:00.0: r600_cs_track_validate_cb:198 cb pitch (32 x 4 = 128)
invalid
radeon 0000:03:00.0: r600_packet3_check:1109 invalid cmd stream 514
[drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
Please see the test case attached to bug 27590 for a program which triggers
this issue. The program works on Linux 2.6.33 and with the software
rasterizer. The problem is reproducible with both mesa 7.8.1 and git master,
against latest Linus git kernel.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=51042
Bug #: 51042
Summary: Turning off connector polling in drm_kms_helper
inhibits HDMI hot plug
Classification: Unclassified
Product: DRI
Version: XOrg CVS
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: DRM/Radeon
AssignedTo: dri-devel(a)lists.freedesktop.org
ReportedBy: dargllun(a)gmail.com
When turning off connector polling in drm_kms_helper using the poll=N module
parameter HDMI hot plugging does not work anymore. Quoting Alex Deucher:
See this discussion for details and some logs:
http://comments.gmane.org/gmane.comp.freedesktop.xorg.drivers.ati/22107
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=53544
Bug #: 53544
Summary: Incorrect modeline due to incorrect EDID block for LG
SL80 TV
Classification: Unclassified
Product: DRI
Version: DRI CVS
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: medium
Component: General
AssignedTo: dri-devel(a)lists.freedesktop.org
ReportedBy: paulepanter(a)users.sourceforge.net
The LG SL80 TV exhibits the same garbled screen as reported in #26294 [1] when
connecting an ASUS Eee PC 701 4G over VGA.
This is just a separate report for this particular TV and a patch is going to
be send to the list. Log files are included in comment 26294#c20 and comment
26294#c21 of the referenced report.
[1] https://bugs.freedesktop.org/show_bug.cgi?id=26294
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.