I was going to leave these for stable, but really they should go in now.
The unmappable VRAM fixes a problem on evergreen cards in 2.6.36, we end
up giving out memory past what the CPU can see and we get SIGBUS in
userspace, this is because we don't have support for GPU to move memory
around o
vailable
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20101012/18453915/attachment.bin>
https://bugs.freedesktop.org/show_bug.cgi?id=28456
--- Comment #9 from J. Kanowitz 2010-10-12 16:33:20 PDT ---
Just noticed this when doing some work on two "identical" Compaq SR1611NX
desktops. The 4-pipe log has quite a bit of noise at the end from uptime.
Both run Ubuntu 9.10 with its kernel
https://bugs.freedesktop.org/show_bug.cgi?id=28456
--- Comment #9 from J. Kanowitz 2010-10-12 16:33:20 PDT
---
Just noticed this when doing some work on two "identical" Compaq SR1611NX
desktops. The 4-pipe log has quite a bit of noise at the end from uptime.
Both run Ubuntu 9.10 with its kerne
https://bugs.freedesktop.org/show_bug.cgi?id=28456
--- Comment #8 from J. Kanowitz 2010-10-12 16:12:59 PDT ---
Created an attachment (id=39402)
--> (https://bugs.freedesktop.org/attachment.cgi?id=39402)
4 quad pipes, radeon "module version = 6.12.99" / Ubuntu 9.10 i386
--
Configure bugmail: ht
https://bugs.freedesktop.org/show_bug.cgi?id=28456
--- Comment #8 from J. Kanowitz 2010-10-12 16:12:59 PDT
---
Created an attachment (id=39402)
--> (https://bugs.freedesktop.org/attachment.cgi?id=39402)
4 quad pipes, radeon "module version = 6.12.99" / Ubuntu 9.10 i386
--
Configure bugmail: h
https://bugs.freedesktop.org/show_bug.cgi?id=28456
--- Comment #7 from J. Kanowitz 2010-10-12 16:11:31 PDT ---
Created an attachment (id=39401)
--> (https://bugs.freedesktop.org/attachment.cgi?id=39401)
1 quad pipe, radeon "module version = 6.12.99" / Ubuntu 9.10 i386
--
Configure bugmail: htt
https://bugs.freedesktop.org/show_bug.cgi?id=28456
--- Comment #7 from J. Kanowitz 2010-10-12 16:11:31 PDT
---
Created an attachment (id=39401)
--> (https://bugs.freedesktop.org/attachment.cgi?id=39401)
1 quad pipe, radeon "module version = 6.12.99" / Ubuntu 9.10 i386
--
Configure bugmail: ht
https://bugs.freedesktop.org/show_bug.cgi?id=30313
--- Comment #27 from Tomasz Czapiewski 2010-10-12 16:00:40 PDT
---
(In reply to comment #26)
> Thomasz,
>
> your issue seems to be similar to bug 28800. I guess Nexuiz uses some
> auxiliary
> textures to compute lighting.
My problem has been
https://bugs.freedesktop.org/show_bug.cgi?id=30313
--- Comment #27 from Tomasz Czapiewski 2010-10-12 16:00:40
PDT ---
(In reply to comment #26)
> Thomasz,
>
> your issue seems to be similar to bug 28800. I guess Nexuiz uses some
> auxiliary
> textures to compute lighting.
My problem has been
https://bugs.freedesktop.org/show_bug.cgi?id=29244
--- Comment #6 from Marek Olšák 2010-10-12 15:56:48 PDT ---
I guess you guys are all running Mesa master. Could you please test the 7.9
branch as well?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are r
https://bugs.freedesktop.org/show_bug.cgi?id=29244
--- Comment #6 from Marek Ol??k 2010-10-12 15:56:48 PDT
---
I guess you guys are all running Mesa master. Could you please test the 7.9
branch as well?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are
https://bugs.freedesktop.org/show_bug.cgi?id=30385
Tomasz Czapiewski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=30385
Tomasz Czapiewski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=29026
--- Comment #10 from Daniel 2010-10-12 15:45:01 PDT
---
(In reply to comment #9)
> If s/r used to work, when did it last work, and can you bisect what commit
> broke it?
Sorry for the late reply. I cannot find the commit which broke it, however
https://bugs.freedesktop.org/show_bug.cgi?id=29026
--- Comment #10 from Daniel 2010-10-12 15:45:01
PDT ---
(In reply to comment #9)
> If s/r used to work, when did it last work, and can you bisect what commit
> broke it?
Sorry for the late reply. I cannot find the commit which broke it, however
https://bugs.freedesktop.org/show_bug.cgi?id=30406
Martin Stolpe changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=30406
Martin Stolpe changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
I was going to leave these for stable, but really they should go in now.
The unmappable VRAM fixes a problem on evergreen cards in 2.6.36, we end
up giving out memory past what the CPU can see and we get SIGBUS in
userspace, this is because we don't have support for GPU to move memory
around o
From: Chris Ball
Francisco Jerez advises that pre-nv20 cards would hang if we entered
kdb with accel on and IRQs disabled, so we now disable accel before
entering kdb and re-enable it on the way back out.
Reported-by: Francisco Jerez
Signed-off-by: Chris Ball
Signed-off-by: Jason Wessel
---
When changing VTs non-atomically the kernel works in conjunction with
the Xserver in user space and receives the LUT information from the
Xserver via a system call. When changing modes atomically for kdb,
this information must be saved and restored without disturbing user
space as if nothing ever
Some devices such as the pre nv02 chips have enter and exit
constraints where hardware compression must be turned off and
re-enabled on resuming normal operations.
This patch extends the mode_set_base_atomic() call to pass an argument
to indicate if this is an entry or an exit from an atomic kerne
From: Chris Ball
Tested on nv50 and nv04 HW.
Signed-off-by: Chris Ball
Signed-off-by: Jason Wessel
CC: Jesse Barnes
CC: David Airlie
CC: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/nouveau/nouveau_fbcon.c |6
drivers/gpu/drm/nouveau/nv04_crtc.c | 45 +++
From: Chris Ball
Signed-off-by: Chris Ball
Signed-off-by: Jason Wessel
CC: Jesse Barnes
CC: David Airlie
CC: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/radeon/atombios_crtc.c | 117 +++
drivers/gpu/drm/radeon/radeon_fb.c |2 +
drivers/gp
What is new in patch set v3
* Patch 3 - Per comment from Jesse Barnes change enter arg for
mode_set_base_atomic() to be an enum
* Patch 4 - Fixed a defect in the LUT save/restore where it should
have used ctrc->gamma_size instead of the local size variable
* Patch 5 - Context changes
From: Jerome Glisse
We should not allocate any object into unmappable vram if we
have no means to access them which on all GPU means having the
CP running and on newer GPU having the blit utility working.
This patch limit the vram allocation to visible vram until
we have acceleration up and runn
2.6.35 and 2.6.36 do not contain blit support for evergreen
asics so if they use unmappable vram, you can end up with an
unreachable buffer address. This should not be applied to drm-next
as that tree already contains evergreen blit support. This should
only be applied to the 2.6.35 and 2.6.36 st
Hello,
currently r600g ignores relative constant addressing when splitting constant
accesses into multiple instructions which is fixed by the attached patch.
I noticed it when messing with vp-tris arl.txt of
git://anongit.freedesktop.org/mesa/demos (I modified "arr[addr.x-2]" into
"arr[addr.x]"
https://bugs.freedesktop.org/show_bug.cgi?id=29244
Sven Arvidsson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=29244
Sven Arvidsson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
From: Chris Ball
Francisco Jerez advises that pre-nv20 cards would hang if we entered
kdb with accel on and IRQs disabled, so we now disable accel before
entering kdb and re-enable it on the way back out.
Reported-by: Francisco Jerez
Signed-off-by: Chris Ball
Signed-off-by: Jason Wessel
---
From: Chris Ball
Tested on nv50 and nv04 HW.
Signed-off-by: Chris Ball
Signed-off-by: Jason Wessel
CC: Jesse Barnes
CC: David Airlie
CC: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/nouveau/nouveau_fbcon.c |6
drivers/gpu/drm/nouveau/nv04_crtc.c | 45 ++
From: Chris Ball
Signed-off-by: Chris Ball
Signed-off-by: Jason Wessel
CC: Jesse Barnes
CC: David Airlie
CC: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/radeon/atombios_crtc.c | 117 +++
drivers/gpu/drm/radeon/radeon_fb.c |2 +
drivers/gpu/d
What is new in patch set v3
* Patch 3 - Per comment from Jesse Barnes change enter arg for
mode_set_base_atomic() to be an enum
* Patch 4 - Fixed a defect in the LUT save/restore where it should
have used ctrc->gamma_size instead of the local size variable
* Patch 5 - Context changes
Some devices such as the pre nv02 chips have enter and exit
constraints where hardware compression must be turned off and
re-enabled on resuming normal operations.
This patch extends the mode_set_base_atomic() call to pass an argument
to indicate if this is an entry or an exit from an atomic kerne
When changing VTs non-atomically the kernel works in conjunction with
the Xserver in user space and receives the LUT information from the
Xserver via a system call. When changing modes atomically for kdb,
this information must be saved and restored without disturbing user
space as if nothing ever
On 10/12/2010 10:38 AM, Jesse Barnes wrote:
> On Tue, 12 Oct 2010 07:49:59 -0500
> Jason Wessel wrote:
>
>
>> Some devices such as the pre nv02 chips have enter and exit
>> constraints where hardware compression must be turned off and
>> re-enabled on resuming normal operations.
>>
>> This patc
From: Jerome Glisse
We should not allocate any object into unmappable vram if we
have no means to access them which on all GPU means having the
CP running and on newer GPU having the blit utility working.
This patch limit the vram allocation to visible vram until
we have acceleration up and runn
2.6.35 and 2.6.36 do not contain blit support for evergreen
asics so if they use unmappable vram, you can end up with an
unreachable buffer address. This should not be applied to drm-next
as that tree already contains evergreen blit support. This should
only be applied to the 2.6.35 and 2.6.36 st
https://bugs.freedesktop.org/show_bug.cgi?id=30188
--- Comment #26 from Alex Deucher 2010-10-12 09:19:50 PDT ---
Created an attachment (id=39385)
View: https://bugs.freedesktop.org/attachment.cgi?id=39385
Review: https://bugs.freedesktop.org/review?bug=30188&attachment=39385
fix for 2.6.35 and
https://bugs.freedesktop.org/show_bug.cgi?id=30188
--- Comment #26 from Alex Deucher 2010-10-12 09:19:50 PDT
---
Created an attachment (id=39385)
View: https://bugs.freedesktop.org/attachment.cgi?id=39385
Review: https://bugs.freedesktop.org/review?bug=30188&attachment=39385
fix for 2.6.35 an
On 10/12/2010 10:38 AM, Jesse Barnes wrote:
> On Tue, 12 Oct 2010 07:49:59 -0500
> Jason Wessel wrote:
>
>
>> Some devices such as the pre nv02 chips have enter and exit
>> constraints where hardware compression must be turned off and
>> re-enabled on resuming normal operations.
>>
>> This patc
From: Chris Ball
Francisco Jerez advises that pre-nv20 cards would hang if we entered
kdb with accel on and IRQs disabled, so we now disable accel before
entering kdb and re-enable it on the way back out.
Reported-by: Francisco Jerez
Signed-off-by: Chris Ball
Signed-off-by: Jason Wessel
---
From: Chris Ball
Signed-off-by: Chris Ball
Signed-off-by: Jason Wessel
CC: Jesse Barnes
CC: David Airlie
CC: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/radeon/atombios_crtc.c | 117 +++
drivers/gpu/drm/radeon/radeon_fb.c |2 +
drivers/gpu/d
From: Chris Ball
Tested on nv50 and nv04 HW.
Signed-off-by: Chris Ball
Signed-off-by: Jason Wessel
CC: Jesse Barnes
CC: David Airlie
CC: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/nouveau/nouveau_fbcon.c |6
drivers/gpu/drm/nouveau/nv04_crtc.c | 45 ++
When changing VTs non-atomically the kernel works in conjunction with
the Xserver in user space and receives the LUT information from the
Xserver via a system call. When changing modes atomically for kdb,
this information must be saved and restored without disturbing user
space as if nothing ever
What is new in patch set v2
* patch 4 which was previously radeon specific was replaced with a
generic patch to save and restore the LUT data for all drivers
* minor white space cleanup vs checkpatch.pl in patches
---
The goal of this patch set is to add atomic kernel mode setting hooks
Some devices such as the pre nv02 chips have enter and exit
constraints where hardware compression must be turned off and
re-enabled on resuming normal operations.
This patch extends the mode_set_base_atomic() call to pass an argument
to indicate if this is an entry or an exit from an atomic kerne
On Tue, 12 Oct 2010 10:46:52 -0500
Jason Wessel wrote:
> On 10/12/2010 10:38 AM, Jesse Barnes wrote:
> > On Tue, 12 Oct 2010 07:49:59 -0500
> > Jason Wessel wrote:
> >
> >
> >> Some devices such as the pre nv02 chips have enter and exit
> >> constraints where hardware compression must be turn
On Tue, 12 Oct 2010 10:46:52 -0500
Jason Wessel wrote:
> On 10/12/2010 10:38 AM, Jesse Barnes wrote:
> > On Tue, 12 Oct 2010 07:49:59 -0500
> > Jason Wessel wrote:
> >
> >
> >> Some devices such as the pre nv02 chips have enter and exit
> >> constraints where hardware compression must be turn
On Tue, 12 Oct 2010 07:49:59 -0500
Jason Wessel wrote:
> Some devices such as the pre nv02 chips have enter and exit
> constraints where hardware compression must be turned off and
> re-enabled on resuming normal operations.
>
> This patch extends the mode_set_base_atomic() call to pass an argum
On Tue, 12 Oct 2010 07:49:59 -0500
Jason Wessel wrote:
> Some devices such as the pre nv02 chips have enter and exit
> constraints where hardware compression must be turned off and
> re-enabled on resuming normal operations.
>
> This patch extends the mode_set_base_atomic() call to pass an argum
From: Chris Ball
Francisco Jerez advises that pre-nv20 cards would hang if we entered
kdb with accel on and IRQs disabled, so we now disable accel before
entering kdb and re-enable it on the way back out.
Reported-by: Francisco Jerez
Signed-off-by: Chris Ball
Signed-off-by: Jason Wessel
---
When changing VTs non-atomically the kernel works in conjunction with
the Xserver in user space and receives the LUT information from the
Xserver via a system call. When changing modes atomically for kdb,
this information must be saved and restored without disturbing user
space as if nothing ever
Some devices such as the pre nv02 chips have enter and exit
constraints where hardware compression must be turned off and
re-enabled on resuming normal operations.
This patch extends the mode_set_base_atomic() call to pass an argument
to indicate if this is an entry or an exit from an atomic kerne
From: Chris Ball
Tested on nv50 and nv04 HW.
Signed-off-by: Chris Ball
Signed-off-by: Jason Wessel
CC: Jesse Barnes
CC: David Airlie
CC: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/nouveau/nouveau_fbcon.c |6
drivers/gpu/drm/nouveau/nv04_crtc.c | 45 +++
From: Chris Ball
Signed-off-by: Chris Ball
Signed-off-by: Jason Wessel
CC: Jesse Barnes
CC: David Airlie
CC: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/radeon/atombios_crtc.c | 117 +++
drivers/gpu/drm/radeon/radeon_fb.c |2 +
drivers/gp
What is new in patch set v2
* patch 4 which was previously radeon specific was replaced with a
generic patch to save and restore the LUT data for all drivers
* minor white space cleanup vs checkpatch.pl in patches
---
The goal of this patch set is to add atomic kernel mode setting hooks
https://bugs.freedesktop.org/show_bug.cgi?id=30771
--- Comment #2 from Kevin DeKorte 2010-10-12 05:54:04 PDT
---
confirmed fixed... thanks airlied
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assigne
https://bugs.freedesktop.org/show_bug.cgi?id=30771
--- Comment #2 from Kevin DeKorte 2010-10-12 05:54:04
PDT ---
confirmed fixed... thanks airlied
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assigne
https://bugs.freedesktop.org/show_bug.cgi?id=30329
--- Comment #9 from Michele Corazza 2010-10-12 05:50:16
PDT ---
Created an attachment (id=39381)
--> (https://bugs.freedesktop.org/attachment.cgi?id=39381)
dmesg | grep drm on mobility hd 4570
--
Configure bugmail: https://bugs.freedesktop.or
https://bugs.freedesktop.org/show_bug.cgi?id=30329
--- Comment #9 from Michele Corazza 2010-10-12 05:50:16
PDT ---
Created an attachment (id=39381)
--> (https://bugs.freedesktop.org/attachment.cgi?id=39381)
dmesg | grep drm on mobility hd 4570
--
Configure bugmail: https://bugs.freedesktop.or
https://bugs.freedesktop.org/show_bug.cgi?id=30329
--- Comment #8 from Michele Corazza 2010-10-12 05:49:12
PDT ---
Created an attachment (id=39380)
--> (https://bugs.freedesktop.org/attachment.cgi?id=39380)
Xorg.0.log on mobility radeon hd 4570
--
Configure bugmail: https://bugs.freedesktop.o
https://bugs.freedesktop.org/show_bug.cgi?id=30329
--- Comment #8 from Michele Corazza 2010-10-12 05:49:12
PDT ---
Created an attachment (id=39380)
--> (https://bugs.freedesktop.org/attachment.cgi?id=39380)
Xorg.0.log on mobility radeon hd 4570
--
Configure bugmail: https://bugs.freedesktop.o
https://bugs.freedesktop.org/show_bug.cgi?id=30329
--- Comment #7 from Michele Corazza 2010-10-12 05:47:26
PDT ---
I can confirm general slowness with ati mobility 4570 and open driver (using
xorg-edgers ubuntu ppa and latest 2.6.36 kernel from mainline). I read about
problems using blur and lan
https://bugs.freedesktop.org/show_bug.cgi?id=30329
--- Comment #7 from Michele Corazza 2010-10-12 05:47:26
PDT ---
I can confirm general slowness with ati mobility 4570 and open driver (using
xorg-edgers ubuntu ppa and latest 2.6.36 kernel from mainline). I read about
problems using blur and lan
https://bugs.freedesktop.org/show_bug.cgi?id=28402
--- Comment #78 from Da Fox 2010-10-12 05:17:12 PDT
---
(In reply to comment #77)
> I also set radeon.agpmode=4 on the kernel commandline in grub.conf. I don't
> know what the default is, I could test it if it's important. But agpmode=4 has
> wo
https://bugs.freedesktop.org/show_bug.cgi?id=28402
--- Comment #78 from Da Fox 2010-10-12 05:17:12
PDT ---
(In reply to comment #77)
> I also set radeon.agpmode=4 on the kernel commandline in grub.conf. I don't
> know what the default is, I could test it if it's important. But agpmode=4 has
> wo
Le 11/10/2010 18:29, Randy Dunlap a ?crit :
> When CONFIG_HWMON is not enabled:
>
> drivers/built-in.o: In function `nouveau_pm_fini':
> (.text+0x1c680f): undefined reference to `hwmon_device_unregister'
> drivers/built-in.o: In function `nouveau_hwmon_init':
> nouveau_pm.c:(.text+0x1c6f93): unde
---
drivers/gpu/drm/nouveau/nouveau_pm.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_pm.c
b/drivers/gpu/drm/nouveau/nouveau_pm.c
index 1c99c55..74a7d3a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_pm.c
+++ b/drivers/gpu/drm/nou
https://bugs.freedesktop.org/show_bug.cgi?id=30616
--- Comment #1 from Andy Furniss 2010-10-12
03:14:10 PDT ---
(In reply to comment #0)
> I get quite severe 1/2 second glitches running the mesa demo tunnel
Still getting this, just wanted to add that it seems to be related to demos
that start
https://bugs.freedesktop.org/show_bug.cgi?id=30616
--- Comment #1 from Andy Furniss 2010-10-12
03:14:10 PDT ---
(In reply to comment #0)
> I get quite severe 1/2 second glitches running the mesa demo tunnel
Still getting this, just wanted to add that it seems to be related to demos
that start
https://bugs.freedesktop.org/show_bug.cgi?id=29244
--- Comment #4 from Fabio Pedretti 2010-10-12 02:55:22
PDT ---
This issue is fixed for me in current master.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You ar
https://bugs.freedesktop.org/show_bug.cgi?id=29244
--- Comment #4 from Fabio Pedretti 2010-10-12 02:55:22
PDT ---
This issue is fixed for me in current master.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You ar
https://bugs.freedesktop.org/show_bug.cgi?id=22576
--- Comment #14 from Fabio Pedretti 2010-10-12 01:20:45
PDT ---
This could be fixed in mesa master and 7.9 branch:
http://lists.freedesktop.org/archives/mesa-dev/2010-October/003492.html
--
Configure bugmail: https://bugs.freedesktop.org/userp
https://bugs.freedesktop.org/show_bug.cgi?id=29367
--- Comment #6 from Fabio Pedretti 2010-10-12 01:20:33
PDT ---
This could be fixed in mesa master and 7.9 branch:
http://lists.freedesktop.org/archives/mesa-dev/2010-October/003492.html
--
Configure bugmail: https://bugs.freedesktop.org/userpr
https://bugs.freedesktop.org/show_bug.cgi?id=22576
--- Comment #14 from Fabio Pedretti 2010-10-12
01:20:45 PDT ---
This could be fixed in mesa master and 7.9 branch:
http://lists.freedesktop.org/archives/mesa-dev/2010-October/003492.html
--
Configure bugmail: https://bugs.freedesktop.org/userp
https://bugs.freedesktop.org/show_bug.cgi?id=29367
--- Comment #6 from Fabio Pedretti 2010-10-12 01:20:33
PDT ---
This could be fixed in mesa master and 7.9 branch:
http://lists.freedesktop.org/archives/mesa-dev/2010-October/003492.html
--
Configure bugmail: https://bugs.freedesktop.org/userpr
https://bugs.freedesktop.org/show_bug.cgi?id=30761
--- Comment #8 from Tom Stellard 2010-10-12 00:15:04 PDT
---
(In reply to comment #7)
>
> How should I check for fp similarities? Just run diff? I don't really know how
> to read that output, I was hoping someone here did. Without noopt, I usua
https://bugs.freedesktop.org/show_bug.cgi?id=30761
--- Comment #8 from Tom Stellard 2010-10-12 00:15:04
PDT ---
(In reply to comment #7)
>
> How should I check for fp similarities? Just run diff? I don't really know how
> to read that output, I was hoping someone here did. Without noopt, I usua
80 matches
Mail list logo
