[PATCH 0/9] drm/radeon/kms: update pm code
2010/5/10 Andy Furniss : >> The module parameter is obsolete. you can enable it dynamically via >> sysfs (power_method). ?The default pm method is profile. > > OK, I know dynpm was removed - but this is dynclks are the two the same? dynclks is for disabling clocking unused blocks. It means you don't provide clock signal to blocks and save some power. It was the case in older hardware, newer don't use that command anymore. I believe newer hardware handles that automatically. -- Rafa?
[PATCH 0/9] drm/radeon/kms: update pm code
Alex Deucher wrote: > Send me a copy of your vbios, I may need to adjust the profile table > for rv670. As root: > cd /sys/bus/pci/devices/ > echo 1> rom > cat rom> /tmp/vbios.rom > echo 0> rom Sent >> One separate question - do I need to use the module param dynclks=1 or is it >> the default? >> > > The module parameter is obsolete. you can enable it dynamically via > sysfs (power_method). The default pm method is profile. OK, I know dynpm was removed - but this is dynclks are the two the same?
[PATCH 0/9] drm/radeon/kms: update pm code
Alex Deucher wrote: > The "profile" method exposes 4 profiles that can be selected from: > 1. "default" > 2. "auto" > 3. "low" > 4. "high" > Select the profile by echoing the selected profile to > /sys/class/drm/card-0/device/power_profile. Testing on a rv670 desktop it seems that low does not force the card to low clock. Before these patches went in I could force low by echo 2.0 > /sys/class/drm/card0/device/power_state for 2 screens or echo 1.0 > /sys/class/drm/card0/device/power_state for one screen. Though dmesg didn't always report setting it did work (using bench mark to verify) - I could also get dmesg to confirm by echo 2.0 echo 2.2 then echo 2.0. Running current drt with the info -> debug patch reverted I can't get echo low > /sys/class/drm/card0/device/power_profile to lower the clock whatever I try - one screen, two screens forcing high then low etc. (nothing in dmesg and benchmark gives full clock results) dynpm works as before and I do get low clock in dpms with profile. One separate question - do I need to use the module param dynclks=1 or is it the default?
[PATCH] radeon: Fix 3 regressions (was: glxgears crashes radeon driver)
Yes, it's me again ;)
On Sun, 9 May 2010 22:58:30 +0200, Jean Delvare wrote:
> Bisection says that the faulty commit is:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=b4fe945405e477cded91772b4fec854705443dd5
>
> It doesn't revert cleanly from 2.6.34-rc6+, I'll try a manual revert
> tomorrow. My device is a Radeon 9200, so r200, if it helps.
I can confirm that manually reverting the patch above helps somewhat.
The crash is gone. Now I get an essentially black image in glxgears,
which may be a different bug.
(gdb) file drivers/gpu/drm/radeon/radeon.o
Reading symbols from
/home/khali/src/linux-2.6.34-rc6/drivers/gpu/drm/radeon/radeon.o...done.
(gdb) list *(radeon_cp_cmdbuf+0x15e)
0xa58e is in radeon_cp_cmdbuf (drivers/gpu/drm/radeon/radeon_state.c:2921).
2916
2917drm_radeon_cmd_header_t *header;
2918header = drm_buffer_read_object(cmdbuf->buffer,
2919sizeof(stack_header), _header);
2920
2921switch (header->header.cmd_type) {
2922case RADEON_CMD_PACKET:
2923DRM_DEBUG("RADEON_CMD_PACKET\n");
2924if (radeon_emit_packets
2925(dev_priv, file_priv, *header, cmdbuf)) {
(gdb)
I took a look at the above commit and found 3 bugs in it, one of which
is directly responsible for my crash. Candidate patch below.
Note 1: Why one would call radeon_cp_cmdbuf() with an empty buffer is
beyond me, but hey, what do I know about graphics drivers.
Note 2: Even with this patch, glxgears is all black unless I move the
window around, so there's one more bug to track. I guess I'm up for one
more bisection afternoon.
* * * * *
From: Jean Delvare
Subject: radeon: Fix 3 regressions
Commit b4fe945405e477cded91772b4fec854705443dd5 introduced 3 bugs,
fix them:
* Use the right command dword for second packet offset in
RADEON_CNTL_PAINT/BITBLT_MULTI.
* Don't leak memory if drm_buffer_copy_from_user() fails.
* Don't call drm_buffer_unprocessed() unless drm_buffer_alloc() and
drm_buffer_copy_from_user() have been called successfully first.
Signed-off-by: Jean Delvare
Cc: Pauli Nieminen
Cc: Dave Airlie
---
I can certainly provide 3 separate patches for clarity if you prefer.
drivers/gpu/drm/radeon/radeon_state.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
--- linux-2.6.34-rc6.orig/drivers/gpu/drm/radeon/radeon_state.c 2010-05-10
09:20:07.0 +0200
+++ linux-2.6.34-rc6/drivers/gpu/drm/radeon/radeon_state.c 2010-05-10
15:19:19.0 +0200
@@ -424,7 +424,7 @@ static __inline__ int radeon_check_and_f
if ((*cmd & RADEON_GMC_SRC_PITCH_OFFSET_CNTL) &&
(*cmd & RADEON_GMC_DST_PITCH_OFFSET_CNTL)) {
u32 *cmd3 = drm_buffer_pointer_to_dword(cmdbuf->buffer,
3);
- offset = *cmd << 10;
+ offset = *cmd3 << 10;
if (radeon_check_and_fixup_offset
(dev_priv, file_priv, )) {
DRM_ERROR("Invalid second packet offset\n");
@@ -2895,9 +2895,12 @@ static int radeon_cp_cmdbuf(struct drm_d
return rv;
rv = drm_buffer_copy_from_user(cmdbuf->buffer, buffer,
cmdbuf->bufsz);
- if (rv)
+ if (rv) {
+ drm_buffer_free(cmdbuf->buffer);
return rv;
- }
+ }
+ } else
+ goto done;
orig_nbox = cmdbuf->nbox;
@@ -2905,8 +2908,7 @@ static int radeon_cp_cmdbuf(struct drm_d
int temp;
temp = r300_do_cp_cmdbuf(dev, file_priv, cmdbuf);
- if (cmdbuf->bufsz != 0)
- drm_buffer_free(cmdbuf->buffer);
+ drm_buffer_free(cmdbuf->buffer);
return temp;
}
@@ -3012,16 +3014,15 @@ static int radeon_cp_cmdbuf(struct drm_d
}
}
- if (cmdbuf->bufsz != 0)
- drm_buffer_free(cmdbuf->buffer);
+ drm_buffer_free(cmdbuf->buffer);
+ done:
DRM_DEBUG("DONE\n");
COMMIT_RING();
return 0;
err:
- if (cmdbuf->bufsz != 0)
- drm_buffer_free(cmdbuf->buffer);
+ drm_buffer_free(cmdbuf->buffer);
return -EINVAL;
}
--
Jean Delvare
[Bug 28030] HDMI audio does not work with HD4200 IGP but does work with radeonhd
https://bugs.freedesktop.org/show_bug.cgi?id=28030 --- Comment #5 from sean finney 2010-05-10 13:26:13 PDT --- okay, this is really interesting... when the system starts up after booting/rebooting, the audio does not work. attempting to play to the alsa audio device will result in various errors having to do with sysctl requests *but*, if i restart the graphical user session (i.e. /etc/init.d/gdm restart), the audio works! it only seems to be in 2-channel stereo though, but i'm not sure if that's just me needing to find the right modprobe option foo to snd-hda-intel. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH 0/9] drm/radeon/kms: update pm code
On Mon, May 10, 2010 at 12:04 PM, Andy Furniss wrote: > Alex Deucher wrote: > >> The "profile" method exposes 4 profiles that can be selected from: >> 1. "default" >> 2. "auto" >> 3. "low" >> 4. "high" >> Select the profile by echoing the selected profile to >> /sys/class/drm/card-0/device/power_profile. > > Testing on a rv670 desktop it seems that low does not force the card to low > clock. > > Before these patches went in I could force low by > > echo 2.0 > /sys/class/drm/card0/device/power_state for 2 screens or > echo 1.0 > /sys/class/drm/card0/device/power_state for one screen. > > Though dmesg didn't always report setting it did work (using bench mark to > verify) - I could also get dmesg to confirm by echo 2.0 echo 2.2 then echo > 2.0. > > Running current drt with the info -> debug patch reverted I can't get > > echo low > ?/sys/class/drm/card0/device/power_profile > > to lower the clock whatever I try - one screen, two screens forcing high > then low etc. (nothing in dmesg and benchmark gives full clock results) > Send me a copy of your vbios, I may need to adjust the profile table for rv670. As root: cd /sys/bus/pci/devices/ echo 1 > rom cat rom > /tmp/vbios.rom echo 0 > rom > dynpm works as before and I do get low clock in dpms with profile. > > One separate question - do I need to use the module param dynclks=1 or is it > the default? > The module parameter is obsolete. you can enable it dynamically via sysfs (power_method). The default pm method is profile. Alex
[Bug 28016] KMS:RV635:HD3650 GPU lockup
https://bugs.freedesktop.org/show_bug.cgi?id=28016 --- Comment #11 from Grzegorz Kowal 2010-05-10 12:30:42 PDT --- Created an attachment (id=35553) --> (https://bugs.freedesktop.org/attachment.cgi?id=35553) Full dmesg with the revert. I have not noticed that my dmesg was not full (kernel log size was too small). I am submitting two full dmesg outputs for the recent drm-radeon-testing branch: one without any modifications (bad) and the second with the reverted commit 6b8b1786 (good). Jerome, let me know if you need anything else in order to diagnose this problem. Thanks! -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28016] KMS:RV635:HD3650 GPU lockup
https://bugs.freedesktop.org/show_bug.cgi?id=28016 --- Comment #10 from Grzegorz Kowal 2010-05-10 12:22:58 PDT --- Created an attachment (id=35552) --> (https://bugs.freedesktop.org/attachment.cgi?id=35552) Full dmesg without the revert. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28054] Every application accessing GL segfaults
https://bugs.freedesktop.org/show_bug.cgi?id=28054 Gregor Galwas changed: What|Removed |Added Status|NEW |RESOLVED Resolution||NOTABUG --- Comment #4 from Gregor Galwas 2010-05-10 12:12:29 PDT --- Alright, I did that. It's fine again. Sorry for bothering you... -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28054] Every application accessing GL segfaults
https://bugs.freedesktop.org/show_bug.cgi?id=28054 --- Comment #3 from Rafa? Mi?ecki 2010-05-10 12:00:47 PDT --- Just some guess... but could you enter your mesa directory and perform: make distclean make realclean and then recompile & reinstall mesa? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28054] Every application accessing GL segfaults
https://bugs.freedesktop.org/show_bug.cgi?id=28054 --- Comment #2 from Gregor Galwas 2010-05-10 11:55:56 PDT --- I just tested it, it happens with and without KMS. Using kernel 2.6.34-rc5 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28054] Every application accessing GL segfaults
https://bugs.freedesktop.org/show_bug.cgi?id=28054 --- Comment #1 from Gregor Galwas 2010-05-10 11:37:44 PDT --- Please let me know if you need more information. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28054] New: Every application accessing GL segfaults
https://bugs.freedesktop.org/show_bug.cgi?id=28054 Summary: Every application accessing GL segfaults Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component: Drivers/DRI/R600 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: g.galwas at highantdev.de Created an attachment (id=35549) --> (https://bugs.freedesktop.org/attachment.cgi?id=35549) output of gdb without debug symbols with backtrace (bt command) I updated libdrm+ddx+mesa today. Every application I tried: wine, glxgears, glxinfo, alien-arena segfaults: Example: mcgreg at pegasos:~$ glxinfo name of display: :0.0 Segmentation fault dmesg: glxinfo[6061]: segfault at 11 ip 7fbf254efd44 sp 7fffa24c06f0 error 4 in libpthread-2.10.2.so[7fbf254e7000+16000] -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
R600g ported to mesa git
On Mon, May 10, 2010 at 05:30:59AM +0200, Marek Ol??k wrote:
> Hi Jerome,
>
> I've ported your R600 Gallium3D driver to current mesa git. The list of
> changes:
>
> - Wrapped the buffer and texture create/destroy/transfer/... functions using
> u_resource, which is then used to implement the resource functions.
> - Implemented texture transfers. I left the buffer and texture transfers
> separate because one day we'll need a special codepath for textures.
> - Added index_bias to the draw_*elements functions.
> - Removed nonexistent *REP and *FOR instructions.
> - Some pipe formats have changed channel ordering, so I've removed/fixed
> nonexistent ones.
> - Added stubs for create/set/destroy sampler views.
> - Added a naive implementation of vertex elements state (new CSO).
> - Reworked {texture,buffer}_{from,to}_handle.
> - Reorganized winsys files, removed dri,egl,python directories (other hw
> drivers don't have them too).
> - Added a new build target dri-r600.
>
> The winsys code is untouched besides r600_drm.c, which had to be ported too.
> The scons build is not wired up yet. Other than that, it's compile- and
> link-tested.
>
> It's all here:
> http://cgit.freedesktop.org/~mareko/mesa/log/?h=r600g
> Sorry for making just one commit (it wouldn't compile in between). Given the
> list of changes here, it shouldn't be hard to follow it.
>
> -Marek
I will look at it tonight, thx for doing that.
Cheers,
Jerome
[Bug 28016] KMS:RV635:HD3650 GPU lockup
https://bugs.freedesktop.org/show_bug.cgi?id=28016 --- Comment #9 from Jerome Glisse 2010-05-10 06:51:51 PDT --- Full dmesg without the revert. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28016] KMS:RV635:HD3650 GPU lockup
https://bugs.freedesktop.org/show_bug.cgi?id=28016 --- Comment #8 from Jerome Glisse 2010-05-10 06:51:33 PDT --- Please attach full dmesg -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28016] KMS:RV635:HD3650 GPU lockup
https://bugs.freedesktop.org/show_bug.cgi?id=28016 --- Comment #7 from Grzegorz Kowal 2010-05-10 06:29:42 PDT --- Basically, I am just booting the kernel. The screen is corrupted since the initialization of the KMS (bounch of white dots on black background, it looks like each line is shifted horizontally). When I log in using ssh, however, everything seems to work fine. Once I start the X server I am getting the soft lockup. The screen flickers a few times, the server seems to restart ending with the distorted image of kdm background. I can post the images if necessary. After reverting 6b8b1786a8c29ce6e32298b93ac8d4a18a2b11c4 everything works fine. There is no screen corruption after the KMS initialization and the X server works fine. Obviously, the amount of accessible VRAM is reduced from 1024MB to 256MB then. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
R600g ported to mesa git
Hi Jerome,
I've ported your R600 Gallium3D driver to current mesa git. The list of
changes:
- Wrapped the buffer and texture create/destroy/transfer/... functions using
u_resource, which is then used to implement the resource functions.
- Implemented texture transfers. I left the buffer and texture transfers
separate because one day we'll need a special codepath for textures.
- Added index_bias to the draw_*elements functions.
- Removed nonexistent *REP and *FOR instructions.
- Some pipe formats have changed channel ordering, so I've removed/fixed
nonexistent ones.
- Added stubs for create/set/destroy sampler views.
- Added a naive implementation of vertex elements state (new CSO).
- Reworked {texture,buffer}_{from,to}_handle.
- Reorganized winsys files, removed dri,egl,python directories (other hw
drivers don't have them too).
- Added a new build target dri-r600.
The winsys code is untouched besides r600_drm.c, which had to be ported too.
The scons build is not wired up yet. Other than that, it's compile- and
link-tested.
It's all here:
http://cgit.freedesktop.org/~mareko/mesa/log/?h=r600g<http://cgit.freedesktop.org/%7Emareko/mesa/log/?h=r600g>
Sorry for making just one commit (it wouldn't compile in between). Given the
list of changes here, it shouldn't be hard to follow it.
-Marek
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20100510/1875d8b3/attachment.html>
[Bug 28049] Failure observed while running the Glean test
https://bugs.freedesktop.org/show_bug.cgi?id=28049 --- Comment #2 from samit vats 2010-05-10 05:21:01 PDT --- Created an attachment (id=35544) --> (https://bugs.freedesktop.org/attachment.cgi?id=35544) glxinfo -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28049] Failure observed while running the Glean test
https://bugs.freedesktop.org/show_bug.cgi?id=28049 --- Comment #1 from samit vats 2010-05-10 05:20:37 PDT --- Created an attachment (id=35543) --> (https://bugs.freedesktop.org/attachment.cgi?id=35543) Xorg.log -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28049] New: Failure observed while running the Glean test
https://bugs.freedesktop.org/show_bug.cgi?id=28049 Summary: Failure observed while running the Glean test Product: Mesa Version: git Platform: x86 (IA32) OS/Version: other Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/R600 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: hysvats at gmail.com Created an attachment (id=35542) --> (https://bugs.freedesktop.org/attachment.cgi?id=35542) glean-logs KMS Driver Stack details : = 1)Kernel-2.6.33 2)Libdrm-2.4.19 3)Mesa-7.8-rc2 4)Xorg-server-1.7.4 5)ddx: xf86-video-ati-6.13.0 System Environment : === O.S. - Ubuntu-9.10(32bit) Asic - M97 CPU - Intel(R) Pentium(R)@ 3.60 GHz Steps to Reproduce: === glean -r result -t pbo Observation : = 8 tests passed, 2 tests failed (logs attached) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 25394] [Display port] : Massive corruption observed on changing the resolution on Display port
https://bugs.freedesktop.org/show_bug.cgi?id=25394 samit vats changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from samit vats 2010-05-10 04:11:46 PDT --- (In reply to comment #5) > Is this still an issue with xf86-video-ati from git master? Also, if you are > using a kms drm, you need to make sure your xf86-video-ati was built with kms > support, otherwise, you'll need to disable kms (boot with radeon.modeset=0). Fixed with xf86-video-ati 6.13.0 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28016] KMS:RV635:HD3650 GPU lockup
https://bugs.freedesktop.org/show_bug.cgi?id=28016 Jerome Glisse changed: What|Removed |Added Summary|[REGR] RV635 GPU lockup |KMS:RV635:HD3650 GPU lockup |after enabling unmappable | |VRAM V2 (KMS, Radeon) | --- Comment #6 from Jerome Glisse 2010-05-10 03:14:46 PDT --- Can you describe what you are doing when it lockup (where you using firefox on heavy website with lot of picture ? ...) Also please try with reverting : 6b8b1786a8c29ce6e32298b93ac8d4a18a2b11c4 and report if it helps -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 27858] [r300g] wine game crashes
https://bugs.freedesktop.org/show_bug.cgi?id=27858 Fabio Pedretti changed: What|Removed |Added Attachment #35307|0 |1 is obsolete|| --- Comment #2 from Fabio Pedretti 2010-05-10 00:48:59 PDT --- Created an attachment (id=35537) --> (https://bugs.freedesktop.org/attachment.cgi?id=35537) updated r300g backtrace with ST_DEBUG=mesa,tgsi with mesa 7c5e2672 (In reply to comment #1) > Could you please try the game again with current git? It's still crashing with a similar backtrace (attached). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 27729] [r300g, mesa] gallium compressed texture problems
https://bugs.freedesktop.org/show_bug.cgi?id=27729 --- Comment #19 from Fabio Pedretti 2010-05-10 00:44:24 PDT --- Created an attachment (id=35536) --> (https://bugs.freedesktop.org/attachment.cgi?id=35536) updated swrastg backtrace with ST_DEBUG=mesa,tgsi with mesa 7c5e2672 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 27729] [r300g, mesa] gallium compressed texture problems
https://bugs.freedesktop.org/show_bug.cgi?id=27729 --- Comment #18 from Fabio Pedretti 2010-05-10 00:43:49 PDT --- Created an attachment (id=35535) --> (https://bugs.freedesktop.org/attachment.cgi?id=35535) updated r300g backtrace with ST_DEBUG=mesa,tgsi with mesa 7c5e2672 (In reply to comment #17) > Is this still an issue with current Mesa git? With mesa up to 7c5e2672f050644bcab6902b11d0ff4036603bb3 both r300g and swrast are still crashing, but now in a different way. Game log + backtrace are attached. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 27858] [r300g] wine game crashes
https://bugs.freedesktop.org/show_bug.cgi?id=27858 Fabio Pedretti fabio@libero.it changed: What|Removed |Added Attachment #35307|0 |1 is obsolete|| --- Comment #2 from Fabio Pedretti fabio@libero.it 2010-05-10 00:48:59 PDT --- Created an attachment (id=35537) -- (https://bugs.freedesktop.org/attachment.cgi?id=35537) updated r300g backtrace with ST_DEBUG=mesa,tgsi with mesa 7c5e2672 (In reply to comment #1) Could you please try the game again with current git? It's still crashing with a similar backtrace (attached). -- 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 28049] New: Failure observed while running the Glean test
https://bugs.freedesktop.org/show_bug.cgi?id=28049 Summary: Failure observed while running the Glean test Product: Mesa Version: git Platform: x86 (IA32) OS/Version: other Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/R600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: hysv...@gmail.com Created an attachment (id=35542) -- (https://bugs.freedesktop.org/attachment.cgi?id=35542) glean-logs KMS Driver Stack details : = 1)Kernel-2.6.33 2)Libdrm-2.4.19 3)Mesa-7.8-rc2 4)Xorg-server-1.7.4 5)ddx: xf86-video-ati-6.13.0 System Environment : === O.S. - Ubuntu-9.10(32bit) Asic - M97 CPU - Intel(R) Pentium(R)@ 3.60 GHz Steps to Reproduce: === glean -r result -t pbo Observation : = 8 tests passed, 2 tests failed (logs attached) -- 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 28049] Failure observed while running the Glean test
https://bugs.freedesktop.org/show_bug.cgi?id=28049 --- Comment #2 from samit vats hysv...@gmail.com 2010-05-10 05:21:01 PDT --- Created an attachment (id=35544) -- (https://bugs.freedesktop.org/attachment.cgi?id=35544) glxinfo -- 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 28016] KMS:RV635:HD3650 GPU lockup
https://bugs.freedesktop.org/show_bug.cgi?id=28016 --- Comment #7 from Grzegorz Kowal astron...@op.pl 2010-05-10 06:29:42 PDT --- Basically, I am just booting the kernel. The screen is corrupted since the initialization of the KMS (bounch of white dots on black background, it looks like each line is shifted horizontally). When I log in using ssh, however, everything seems to work fine. Once I start the X server I am getting the soft lockup. The screen flickers a few times, the server seems to restart ending with the distorted image of kdm background. I can post the images if necessary. After reverting 6b8b1786a8c29ce6e32298b93ac8d4a18a2b11c4 everything works fine. There is no screen corruption after the KMS initialization and the X server works fine. Obviously, the amount of accessible VRAM is reduced from 1024MB to 256MB then. -- 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: [PATCH 0/9] drm/radeon/kms: update pm code
Alex Deucher wrote: The profile method exposes 4 profiles that can be selected from: 1. default 2. auto 3. low 4. high Select the profile by echoing the selected profile to /sys/class/drm/card-0/device/power_profile. Testing on a rv670 desktop it seems that low does not force the card to low clock. Before these patches went in I could force low by echo 2.0 /sys/class/drm/card0/device/power_state for 2 screens or echo 1.0 /sys/class/drm/card0/device/power_state for one screen. Though dmesg didn't always report setting it did work (using bench mark to verify) - I could also get dmesg to confirm by echo 2.0 echo 2.2 then echo 2.0. Running current drt with the info - debug patch reverted I can't get echo low /sys/class/drm/card0/device/power_profile to lower the clock whatever I try - one screen, two screens forcing high then low etc. (nothing in dmesg and benchmark gives full clock results) dynpm works as before and I do get low clock in dpms with profile. One separate question - do I need to use the module param dynclks=1 or is it the default? ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/9] drm/radeon/kms: update pm code
On Mon, May 10, 2010 at 12:04 PM, Andy Furniss andy...@ukfsn.org wrote: Alex Deucher wrote: The profile method exposes 4 profiles that can be selected from: 1. default 2. auto 3. low 4. high Select the profile by echoing the selected profile to /sys/class/drm/card-0/device/power_profile. Testing on a rv670 desktop it seems that low does not force the card to low clock. Before these patches went in I could force low by echo 2.0 /sys/class/drm/card0/device/power_state for 2 screens or echo 1.0 /sys/class/drm/card0/device/power_state for one screen. Though dmesg didn't always report setting it did work (using bench mark to verify) - I could also get dmesg to confirm by echo 2.0 echo 2.2 then echo 2.0. Running current drt with the info - debug patch reverted I can't get echo low /sys/class/drm/card0/device/power_profile to lower the clock whatever I try - one screen, two screens forcing high then low etc. (nothing in dmesg and benchmark gives full clock results) Send me a copy of your vbios, I may need to adjust the profile table for rv670. As root: cd /sys/bus/pci/devices/pci bus id echo 1 rom cat rom /tmp/vbios.rom echo 0 rom dynpm works as before and I do get low clock in dpms with profile. One separate question - do I need to use the module param dynclks=1 or is it the default? The module parameter is obsolete. you can enable it dynamically via sysfs (power_method). The default pm method is profile. Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/9] drm/radeon/kms: update pm code
Alex Deucher wrote: Send me a copy of your vbios, I may need to adjust the profile table for rv670. As root: cd /sys/bus/pci/devices/pci bus id echo 1 rom cat rom /tmp/vbios.rom echo 0 rom Sent One separate question - do I need to use the module param dynclks=1 or is it the default? The module parameter is obsolete. you can enable it dynamically via sysfs (power_method). The default pm method is profile. OK, I know dynpm was removed - but this is dynclks are the two the same? ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/9] drm/radeon/kms: update pm code
2010/5/10 Andy Furniss andy...@ukfsn.org: The module parameter is obsolete. you can enable it dynamically via sysfs (power_method). The default pm method is profile. OK, I know dynpm was removed - but this is dynclks are the two the same? dynclks is for disabling clocking unused blocks. It means you don't provide clock signal to blocks and save some power. It was the case in older hardware, newer don't use that command anymore. I believe newer hardware handles that automatically. -- Rafał ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] radeon: Fix 3 regressions (was: glxgears crashes radeon driver)
Yes, it's me again ;)
On Sun, 9 May 2010 22:58:30 +0200, Jean Delvare wrote:
Bisection says that the faulty commit is:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=b4fe945405e477cded91772b4fec854705443dd5
It doesn't revert cleanly from 2.6.34-rc6+, I'll try a manual revert
tomorrow. My device is a Radeon 9200, so r200, if it helps.
I can confirm that manually reverting the patch above helps somewhat.
The crash is gone. Now I get an essentially black image in glxgears,
which may be a different bug.
(gdb) file drivers/gpu/drm/radeon/radeon.o
Reading symbols from
/home/khali/src/linux-2.6.34-rc6/drivers/gpu/drm/radeon/radeon.o...done.
(gdb) list *(radeon_cp_cmdbuf+0x15e)
0xa58e is in radeon_cp_cmdbuf (drivers/gpu/drm/radeon/radeon_state.c:2921).
2916
2917drm_radeon_cmd_header_t *header;
2918header = drm_buffer_read_object(cmdbuf-buffer,
2919sizeof(stack_header), stack_header);
2920
2921switch (header-header.cmd_type) {
2922case RADEON_CMD_PACKET:
2923DRM_DEBUG(RADEON_CMD_PACKET\n);
2924if (radeon_emit_packets
2925(dev_priv, file_priv, *header, cmdbuf)) {
(gdb)
I took a look at the above commit and found 3 bugs in it, one of which
is directly responsible for my crash. Candidate patch below.
Note 1: Why one would call radeon_cp_cmdbuf() with an empty buffer is
beyond me, but hey, what do I know about graphics drivers.
Note 2: Even with this patch, glxgears is all black unless I move the
window around, so there's one more bug to track. I guess I'm up for one
more bisection afternoon.
* * * * *
From: Jean Delvare kh...@linux-fr.org
Subject: radeon: Fix 3 regressions
Commit b4fe945405e477cded91772b4fec854705443dd5 introduced 3 bugs,
fix them:
* Use the right command dword for second packet offset in
RADEON_CNTL_PAINT/BITBLT_MULTI.
* Don't leak memory if drm_buffer_copy_from_user() fails.
* Don't call drm_buffer_unprocessed() unless drm_buffer_alloc() and
drm_buffer_copy_from_user() have been called successfully first.
Signed-off-by: Jean Delvare kh...@linux-fr.org
Cc: Pauli Nieminen suok...@gmail.com
Cc: Dave Airlie airl...@redhat.com
---
I can certainly provide 3 separate patches for clarity if you prefer.
drivers/gpu/drm/radeon/radeon_state.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
--- linux-2.6.34-rc6.orig/drivers/gpu/drm/radeon/radeon_state.c 2010-05-10
09:20:07.0 +0200
+++ linux-2.6.34-rc6/drivers/gpu/drm/radeon/radeon_state.c 2010-05-10
15:19:19.0 +0200
@@ -424,7 +424,7 @@ static __inline__ int radeon_check_and_f
if ((*cmd RADEON_GMC_SRC_PITCH_OFFSET_CNTL)
(*cmd RADEON_GMC_DST_PITCH_OFFSET_CNTL)) {
u32 *cmd3 = drm_buffer_pointer_to_dword(cmdbuf-buffer,
3);
- offset = *cmd 10;
+ offset = *cmd3 10;
if (radeon_check_and_fixup_offset
(dev_priv, file_priv, offset)) {
DRM_ERROR(Invalid second packet offset\n);
@@ -2895,9 +2895,12 @@ static int radeon_cp_cmdbuf(struct drm_d
return rv;
rv = drm_buffer_copy_from_user(cmdbuf-buffer, buffer,
cmdbuf-bufsz);
- if (rv)
+ if (rv) {
+ drm_buffer_free(cmdbuf-buffer);
return rv;
- }
+ }
+ } else
+ goto done;
orig_nbox = cmdbuf-nbox;
@@ -2905,8 +2908,7 @@ static int radeon_cp_cmdbuf(struct drm_d
int temp;
temp = r300_do_cp_cmdbuf(dev, file_priv, cmdbuf);
- if (cmdbuf-bufsz != 0)
- drm_buffer_free(cmdbuf-buffer);
+ drm_buffer_free(cmdbuf-buffer);
return temp;
}
@@ -3012,16 +3014,15 @@ static int radeon_cp_cmdbuf(struct drm_d
}
}
- if (cmdbuf-bufsz != 0)
- drm_buffer_free(cmdbuf-buffer);
+ drm_buffer_free(cmdbuf-buffer);
+ done:
DRM_DEBUG(DONE\n);
COMMIT_RING();
return 0;
err:
- if (cmdbuf-bufsz != 0)
- drm_buffer_free(cmdbuf-buffer);
+ drm_buffer_free(cmdbuf-buffer);
return -EINVAL;
}
--
Jean Delvare
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28054] New: Every application accessing GL segfaults
https://bugs.freedesktop.org/show_bug.cgi?id=28054 Summary: Every application accessing GL segfaults Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component: Drivers/DRI/R600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: g.gal...@highantdev.de Created an attachment (id=35549) -- (https://bugs.freedesktop.org/attachment.cgi?id=35549) output of gdb without debug symbols with backtrace (bt command) I updated libdrm+ddx+mesa today. Every application I tried: wine, glxgears, glxinfo, alien-arena segfaults: Example: mcg...@pegasos:~$ glxinfo name of display: :0.0 Segmentation fault dmesg: glxinfo[6061]: segfault at 11 ip 7fbf254efd44 sp 7fffa24c06f0 error 4 in libpthread-2.10.2.so[7fbf254e7000+16000] -- 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 28054] Every application accessing GL segfaults
https://bugs.freedesktop.org/show_bug.cgi?id=28054 --- Comment #1 from Gregor Galwas g.gal...@highantdev.de 2010-05-10 11:37:44 PDT --- Please let me know if you need more information. -- 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 28054] Every application accessing GL segfaults
https://bugs.freedesktop.org/show_bug.cgi?id=28054 --- Comment #2 from Gregor Galwas g.gal...@highantdev.de 2010-05-10 11:55:56 PDT --- I just tested it, it happens with and without KMS. Using kernel 2.6.34-rc5 -- 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
