http://bugzilla.kernel.org/show_bug.cgi?id=15078
--- Comment #1 from Tomáš Trnka 2010-02-01 08:57:26 ---
Actually, there's a bug in my bugreport :-) There should be r100_hdp_reset()
instead of r100_rb2d_reset() (i.e. inserting a printk between those two doesn't
make the bug disappear).
--
http://bugs.freedesktop.org/show_bug.cgi?id=23993
--- Comment #29 from Pauli 2010-02-01 02:22:34 PST ---
Thanks for testing.
Can you reproduce the bug? If yes then booting with drm.debug=1 kernel
parameter and providing dmesg log showing what is going wrong in command
stream parsing would h
http://bugs.freedesktop.org/show_bug.cgi?id=26358
Summary: new_pll algo gives flickering LVDS on rv620 (HD 3470
mobility) laptop
Product: DRI
Version: unspecified
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Sta
http://bugs.freedesktop.org/show_bug.cgi?id=26358
--- Comment #1 from Stefano Carignano 2010-02-01
02:28:11 PST ---
Created an attachment (id=32961)
--> (http://bugs.freedesktop.org/attachment.cgi?id=32961)
dmesg with new_pll=0
--
Configure bugmail: http://bugs.freedesktop.org/userprefs
http://bugs.freedesktop.org/show_bug.cgi?id=26358
--- Comment #2 from Stefano Carignano 2010-02-01
02:29:03 PST ---
Created an attachment (id=32962)
--> (http://bugs.freedesktop.org/attachment.cgi?id=32962)
xrandr --verbose output. It's the same for new_pll=0 and =1
--
Configure bugmail
http://bugs.freedesktop.org/show_bug.cgi?id=23993
--- Comment #30 from Thomas Schwarzgruber 2010-02-01
03:39:10 PST ---
Im sorry, your patch also doesn't work for me -- i see the same error as Rafał
now.
I hadn't checked before if the correct kernel module was loaded.
So now I have rebuilt
http://bugs.freedesktop.org/show_bug.cgi?id=23993
--- Comment #31 from Thomas Schwarzgruber 2010-02-01
03:42:32 PST ---
Created an attachment (id=32963)
--> (http://bugs.freedesktop.org/attachment.cgi?id=32963)
Log produced by drm.debug=1
This log shows the messages produced by the patche
http://bugzilla.kernel.org/show_bug.cgi?id=15186
--- Comment #4 from Jérôme Glisse 2010-02-01 11:50:18
---
Created an attachment (id=24851)
--> (http://bugzilla.kernel.org/attachment.cgi?id=24851)
Flush HDP before IB
Please try if this patch fix the issue (don't revert the other HDP commi
http://bugs.freedesktop.org/show_bug.cgi?id=23993
Pauli changed:
What|Removed |Added
Attachment #32899|0 |1
is obsolete|
http://bugs.freedesktop.org/show_bug.cgi?id=26061
Fabio Pedretti changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Mon, Feb 01, 2010 at 11:35:21AM +1000, Dave Airlie wrote:
> On Thu, Jan 28, 2010 at 7:26 PM, Luca Barbieri wrote:
> > Currently TTM tries to preserve the previous caching even for moves
> > between unrelated memory spaces.
> >
> > This results for instance in moves from VRAM to PCIE GART changi
http://bugs.freedesktop.org/show_bug.cgi?id=24159
Fabio Pedretti changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://bugs.freedesktop.org/show_bug.cgi?id=26358
Alex Deucher changed:
What|Removed |Added
Attachment #32960|text/x-log |text/plain
mime type|
http://bugs.freedesktop.org/show_bug.cgi?id=26358
Alex Deucher changed:
What|Removed |Added
Attachment #32961|text/x-log |text/plain
mime type|
http://bugs.freedesktop.org/show_bug.cgi?id=26358
Alex Deucher changed:
What|Removed |Added
Attachment #32962|text/x-log |text/plain
mime type|
http://bugs.freedesktop.org/show_bug.cgi?id=26358
--- Comment #3 from Alex Deucher 2010-02-01 06:41:31 PST ---
(In reply to comment #0)
> Created an attachment (id=32960)
--> (http://bugs.freedesktop.org/attachment.cgi?id=32960) [details]
> dmesg with new_pll=1
>
> Latest drm-radeon-testin
Jerome Glisse wrote:
> On Mon, Feb 01, 2010 at 11:35:21AM +1000, Dave Airlie wrote:
>
>> On Thu, Jan 28, 2010 at 7:26 PM, Luca Barbieri
>> wrote:
>>
>>> Currently TTM tries to preserve the previous caching even for moves
>>> between unrelated memory spaces.
>>>
>>> This results for instan
> If you set to uncached | cached, VRAM->SYSTEM will still be broken
> because it will choose uncached.
Assuming VRAM is uncached and not WC of course.
The reasoning still holds if you replace all instances of "uncached" with WC.
---
I see a problem with this.
If you have uncached TT (e.g. AGP) you want to get uncached for
TT->SYSTEM, but you want cached for VRAM->SYSTEM.
If you set SYSTEM to uncached, then VRAM->SYSTEM will broken, and if
you set SYSTEM to cached, TT->SYSTEM will be broken.
If you set to uncached | cached, VR
Fixing kernel memory allocation bugs in radeon command stream parser requires
splitting the buffer to multiple independ pages.
To make splitting one large array to multiple pages first patch adds drm_buffer
structure and functions to reference data in the buffer.
Second patch converts existing
Allocating multiple pages of memory for data that is coming
from user space may fail. To fix memory allocation failures
the buffer object should be split to multiple independ pages.
drm buffer provides generic interface to copy and process
large data arrays from user space.
Interface includes all
Allocation of single large block of memory may fail under memory
presure. drm_buffer object can hold one large block of data in
multiple independ pages which preents alloation failures.
This patch converts all access to command stream to use drm_buffer
interface. All direct access to array has to
> Idea is to mask all move which involve TT (AGP) with the agp_caching_mask,
> it's easy to do in radeon ttm layer code and i believe it's easy to do
> in nouveau
> too. On non AGP you set agp_caching_mask to UC|WC|CACHED.
Sure, but isn't that uglier and much more ad-hoc that the patch I proposed?
> Your patch remove the consistency of caching attribute and make move btw
> non fixed area different than others move, while driver can already achieve
> so.
It is already different, because TTM does it by changing the page
attributes, as opposed to copying data.
Thus, it is useful to preserve th
If there is section size mismatch reusing the section object
makes section start fail.
Reseting the object before doing error checking prevents the
possible flood of errors.
Signed-off-by: Pauli Nieminen
---
radeon/radeon_cs_gem.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff
http://bugzilla.kernel.org/show_bug.cgi?id=15186
--- Comment #5 from r.sche...@yahoo.de 2010-02-01 18:49:32 ---
Applied patch on top of vanilla 2.6.33-rc6:
Unfortunately not fixed, no visible impact.
"x11perf -create" still triggered white window frames. Also changing focus
between X11 windo
On Sat, 30 Jan 2010, Kevin Winchester wrote:
>
> Thank you - the patch from FUJITA Tomonori corrected the issue.
>
> I also tried out the additional patches from John Kacur. They did not
> break anything that I could see, and the logic behind them seems
> reasonable to me. They weren't necess
http://bugzilla.kernel.org/show_bug.cgi?id=15166
Alexey Diomin changed:
What|Removed |Added
CC||diomi...@gmail.com
--- Comment #7 from
On Tue, Feb 2, 2010 at 4:24 AM, Pauli Nieminen wrote:
> If there is section size mismatch reusing the section object
> makes section start fail.
> Reseting the object before doing error checking prevents the
> possible flood of errors.
>
That can't be right. did you read what your patch does?
of
Yes. That was bad mistake.
Better solution is to do the resetting of the section also in the error
path.
Attached the fixed patch.
diff --git a/radeon/radeon_cs_gem.c b/radeon/radeon_cs_gem.c
index c2301ad..45a219c 100644
--- a/radeon/radeon_cs_gem.c
+++ b/radeon/radeon_cs_gem.c
@@ -260,7 +260,1
http://bugzilla.kernel.org/show_bug.cgi?id=15186
Rafael J. Wysocki changed:
What|Removed |Added
CC||r...@sisk.pl
Blocks|
2010/1/31 Jerome Glisse :
>>
>> Eventually, strace log is flooded with
>> ioctl(4, 0xc0106451, 0x6fd530f8) = 0
>> roughly at the time the CPU charge increases. This is consistent with
>> what is recorded in syslog:
>> Jan 29 21:16:03 longspeak kernel: [ 318.611783] [drm:drm_ioctl],
>> pid
>From b3f9e7f481506058174154d5c6fa8e1cd0c56918 Mon Sep 17 00:00:00 2001
From: Alex Deucher
Date: Mon, 1 Feb 2010 16:02:25 -0500
Subject: [PATCH] drm/radeon/kms: consolidate crtc count in rdev
Set the number of crtcs in rdev at crtc init and use it
whenever we need the crtc count rather than recal
http://bugzilla.kernel.org/show_bug.cgi?id=15166
--- Comment #8 from Alexey Diomin 2010-02-01 21:20:21 ---
2.6.33-rc6 also with bug
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of
http://bugzilla.kernel.org/show_bug.cgi?id=15198
Rafael J. Wysocki changed:
What|Removed |Added
Status|RESOLVED|CLOSED
Resolution|PATCH_ALREA
>From 834b08c0b247470a49da6c5d5bbe85469dcc268a Mon Sep 17 00:00:00 2001
From: Alex Deucher
Date: Mon, 1 Feb 2010 16:39:11 -0500
Subject: [PATCH] drm/radeon/kms/atom: clean up spread spectrum code
use a union for the atom args.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/atombios_crt
>From eb604bd475ad7c9c66cf13658714c574d96d18b7 Mon Sep 17 00:00:00 2001
From: Alex Deucher
Date: Mon, 1 Feb 2010 19:06:06 -0500
Subject: [PATCH] drm/radeon/kms/atom: add a helper function to get the
radeon connector priv
This is used in a lot of places in the atom encoder code.
While here fix th
On Mon, Feb 1, 2010 at 1:22 AM, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.32. Please verify if it still should be listed and let me know
On Mon, Feb 1, 2010 at 5:26 PM, Luca Barbieri wrote:
> I see a problem with this.
>
> If you have uncached TT (e.g. AGP) you want to get uncached for
> TT->SYSTEM, but you want cached for VRAM->SYSTEM.
> If you set SYSTEM to uncached, then VRAM->SYSTEM will broken, and if
> you set SYSTEM to cache
On Mon, Feb 1, 2010 at 6:46 PM, Luca Barbieri wrote:
>> Idea is to mask all move which involve TT (AGP) with the agp_caching_mask,
>> it's easy to do in radeon ttm layer code and i believe it's easy to do
>> in nouveau
>> too. On non AGP you set agp_caching_mask to UC|WC|CACHED.
>
> Sure, but isn'
On Mon, Feb 1, 2010 at 13:17, Émeric Maschino wrote:
> 2010/1/31 Jerome Glisse :
>>>
>>> Eventually, strace log is flooded with
>>> ioctl(4, 0xc0106451, 0x6fd530f8) = 0
>>> roughly at the time the CPU charge increases. This is consistent with
>>> what is recorded in syslog:
>>> Jan 29 21:
String constants that are continued on subsequent lines with \
are not good.
Signed-off-by: Joe Perches
---
drivers/gpu/drm/i915/intel_bios.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 15
Some more fixes to formats with continuation lines
Joe Perches (10):
arch/ia64: Fix continuation line formats
drivers/ata: Fix continuation line formats
drivers/gpu/drm/i915/intel_bios.c: Fix continuation line formats
drivers/hwmon/vt8231.c: Fix continuation line formats
drivers/net/davi
43 matches
Mail list logo
