Hi Linus,
fixes for intel and nouveau mainly.
intel: disable HSW by default, sdvo fixes, link train regression fix
nouveau: acpi rom loading regression fix, with a few other fixes from the
rework
core: just other minor fixes and race fixes for ttm.
Dave.
The following changes since commit 6f0
https://bugzilla.kernel.org/show_bug.cgi?id=49351
--- Comment #2 from Igor Murzov 2012-10-23 01:26:13 ---
Created an attachment (id=84401)
--> (https://bugzilla.kernel.org/attachment.cgi?id=84401)
dmesg output for v3.7.0-rc2+ with the patch applied
I'm sure that i did everything right, but
RL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121023/88f86b94/attachment.html>
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121023/5c8052d2/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121023/08744168/attachment.html>
This patch adds iommu support for g2d driver. For this, it
adds subdrv_probe/remove callback to enable or disable
g2d iommu. And with this patch, in case of using g2d iommu,
we can get or put device address to a gem handle from user
through exynos_drm_gem_get/put_dma_addr(). Actually, these
functio
Hi everyone,
(please Cc)
I am running 3.7-rc2 and got recently hit a few times (under rc1, too)
by hanging drm i915 while doing large io operations.
The efect in the dmesg:
[13193.297751] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU
hung
[13193.297758] [drm] capturing error
>
> (please Cc)
>
> I am running 3.7-rc2 and got recently hit a few times (under rc1, too)
> by hanging drm i915 while doing large io operations.
Does booting with i915.i915_enable_rc6=0 help?
(Daniel, looks like an ironlake).
Dave.
--
Hi Dave,
(switched to freedesktop for dri-dvel)
> Does booting with i915.i915_enable_rc6=0 help?
Will try immediately.
> (Daniel, looks like an ironlake).
Sorry, I forgot that one ... how stupid>
>From XOrg.0.log:
...
[ 13535.841] (II) intel(0): Integrated Graphics Chipset: Intel(R) Arrandale
On Tue, 23 Oct 2012 14:38:30 +0900, Norbert Preining
wrote:
> Hi everyone,
>
> (please Cc)
>
> I am running 3.7-rc2 and got recently hit a few times (under rc1, too)
> by hanging drm i915 while doing large io operations.
[snip]
>
> I captured the i915_error_state and uploaded it here:
>
higher so I don't
know if it will ever get to 100 and start lagging.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121023/fed7aac1/attachment.html>
On Tue, 2012-10-09 at 01:00 +0200, Mario Kleiner wrote:
> On 08.10.12 13:35, Imre Deak wrote:
> > On Sat, 2012-10-06 at 03:41 +0200, Mario Kleiner wrote:
> >> [...]
> >>
> >> But then Psychtoolbox checks each timestamp it gets from somewhere
> >> "outside" (OML_sync_control / INTEL_swap_events / AL
GART and VRAM size limits need to be a power of two.
Fix values greater than 1GB and simplify those checks a bit.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_device.c | 55
1 file changed, 21 insertions(+), 34 deletions(-)
diff --git a/dri
When allocating more than 2GB of GART the array of pages
gets to big for kzalloc, use vzmalloc instead.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_gart.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
When internal users want VRAM we shouldn't return GART memory instead.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_gem.c|8 +++-
drivers/gpu/drm/radeon/radeon_object.c | 10 --
2 files changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/
Driver internal users shouldn't be limited in their allocation size.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_gem.c| 10 ++
drivers/gpu/drm/radeon/radeon_object.c |9 -
2 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/d
On Die, 2012-10-23 at 14:23 +0200, Christian K?nig wrote:
> GART and VRAM size limits need to be a power of two.
> Fix values greater than 1GB and simplify those checks a bit.
>
> Signed-off-by: Christian K?nig
> ---
> drivers/gpu/drm/radeon/radeon_device.c | 55
> ---
On 23.10.2012 14:44, Michel D?nzer wrote:
> On Die, 2012-10-23 at 14:23 +0200, Christian K?nig wrote:
>> GART and VRAM size limits need to be a power of two.
>> Fix values greater than 1GB and simplify those checks a bit.
>>
>> Signed-off-by: Christian K?nig
>> ---
>> drivers/gpu/drm/radeon/rade
https://bugzilla.kernel.org/show_bug.cgi?id=49351
Alex Deucher changed:
What|Removed |Added
Attachment #84391|0 |1
is obsolete|
GART and VRAM size limits need to be a power of two.
Fix values greater than 1GB and simplify those checks a bit.
v2: also fix radeon_vram_limit usage, and simplify test even more.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_device.c | 60 +---
When allocating more than 2GB of GART the array of pages
gets to big for kzalloc, use vzalloc instead.
Signed-off-by: Christian K?nig
Reviewed-by: Michel D?nzer
---
drivers/gpu/drm/radeon/radeon_gart.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu
Driver internal users shouldn't be limited in their allocation size.
Signed-off-by: Christian K?nig
Reviewed-by: Michel D?nzer
---
drivers/gpu/drm/radeon/radeon_gem.c| 10 ++
drivers/gpu/drm/radeon/radeon_object.c |9 -
2 files changed, 10 insertions(+), 9 deletions(-)
When internal users want VRAM we shouldn't return GART memory instead.
Signed-off-by: Christian K?nig
Reviewed-by: Michel D?nzer
---
drivers/gpu/drm/radeon/radeon_gem.c|8 +++-
drivers/gpu/drm/radeon/radeon_object.c | 10 --
2 files changed, 7 insertions(+), 11 deletions(-
On Die, 2012-10-23 at 15:53 +0200, Christian K?nig wrote:
> GART and VRAM size limits need to be a power of two.
> Fix values greater than 1GB and simplify those checks a bit.
>
> v2: also fix radeon_vram_limit usage, and simplify test even more.
>
> Signed-off-by: Christian K?nig
Reviewed-by:
https://bugzilla.kernel.org/show_bug.cgi?id=49351
--- Comment #4 from Igor Murzov 2012-10-23 15:00:02 ---
Still no "ATPX function mask" in the log.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watchin
https://bugzilla.kernel.org/show_bug.cgi?id=49351
--- Comment #5 from Alex Deucher 2012-10-23
15:03:11 ---
Does it show up if you try switching?
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching
https://bugzilla.kernel.org/show_bug.cgi?id=49351
--- Comment #6 from Igor Murzov 2012-10-23 15:15:40 ---
No.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=49351
--- Comment #7 from Alex Deucher 2012-10-23
15:19:20 ---
It should be printing. Make sure you've booted the right kernel and are using
the right module. If you are using an initrd, make sure it's up to date. Make
sure you aren't redirecti
https://bugzilla.kernel.org/show_bug.cgi?id=49351
--- Comment #8 from Igor Murzov 2012-10-23 15:44:39 ---
Created an attachment (id=84451)
--> (https://bugzilla.kernel.org/attachment.cgi?id=84451)
dmesg output for v3.7.0-rc2+
This dmesg output was produced with following changes:
---
dri-devel/attachments/20121023/fb31b667/attachment-0001.html>
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121023/64fc3f90/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20121023/f235338c/attachment.html>
This is happening both with MAINLINE and NEXT.
basically system is running fine, then under load system becomes really
sluggish and unresponsive. I was able to get dmesg of the error..:
[ 7745.007008] ath9k :05:00.0 wlan0: disabling VHT as WMM/QoS is not
supported by the AP
[ 7745.007736] w
https://bugzilla.kernel.org/show_bug.cgi?id=49351
--- Comment #9 from Alex Deucher 2012-10-23
17:17:15 ---
Created an attachment (id=84461)
--> (https://bugzilla.kernel.org/attachment.cgi?id=84461)
possible fix 1
Try this patch and see if it helps.
--
Configure bugmail: https://bugzilla
https://bugzilla.kernel.org/show_bug.cgi?id=49351
--- Comment #10 from Alex Deucher 2012-10-23
17:22:14 ---
Created an attachment (id=84471)
--> (https://bugzilla.kernel.org/attachment.cgi?id=84471)
possible fix 2
If the previous patch doesn't help, try this one.
--
Configure bugmail: h
u are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121023/024118fb/attachment.html>
On Tue, Oct 23, 2012 at 10:06:52AM -0700, Justin P. Mattock wrote:
> This is happening both with MAINLINE and NEXT.
>
> basically system is running fine, then under load system becomes
> really sluggish and unresponsive. I was able to get dmesg of the
> error..:
>
> [ 7745.007008] ath9k :05:0
https://bugzilla.kernel.org/show_bug.cgi?id=49351
--- Comment #11 from Igor Murzov 2012-10-23 17:57:53 ---
The first patch doesn't help.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assig
error_state
from debugfs? That contains the gpu hang dump we need to diagnose things.
And the bisect would obviously be awesome.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
-- next part --
An HTML attachment
https://bugzilla.kernel.org/show_bug.cgi?id=49351
--- Comment #12 from Igor Murzov 2012-10-23 18:25:48 ---
Created an attachment (id=84481)
--> (https://bugzilla.kernel.org/attachment.cgi?id=84481)
dmesg output for v3.7.0-rc2+ with kbug49351-2.diff applied
The second patch doens't help ei
https://bugzilla.kernel.org/show_bug.cgi?id=46241
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121023/1c2768d1/attachment.html>
This is needed to make applications using wait-for-vblank/page-flip
timestamps independent of time ajdustments other than adjustments for
HW clock jitter.
I've tested these with an updated intel-gpu-test/flip_test and will send
the update for that once there's no objection about this patchset.
Th
For measuring duration we want to avoid that our start/end timestamps
jump, so use monotonic instead of real time for that.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/drm_irq.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b
Jumps in the vblank and page flip event timestamps cause trouble for
clients, so we should avoid them. The timestamp we get currently with
gettimeofday can jump, so use instead monotonic timestamps.
For backward compatibility use a module flag to revert back to using
gettimeofday timestamps. Add a
https://bugzilla.kernel.org/show_bug.cgi?id=49351
--- Comment #13 from Alex Deucher 2012-10-23
19:09:28 ---
Please attach the dmesg output from a working kernel.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
https://bugzilla.kernel.org/show_bug.cgi?id=49351
Alex Deucher changed:
What|Removed |Added
Attachment #84441|0 |1
is obsolete|
e bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121023/d665bab1/attachment.html>
be failing.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121023/62c047a1/attachment.html>
Hi all,
I've always been a bit unhappy with the overall approach of my old hpd patches,
I think they've tried to move too much clever logic into the helper code. Now we
can still make the helper code a bit more smarter and flexible, but I think the
really clever hpd handling code should be in the
Useful if drivers want to be slightly more clever about hotplug
handling.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc_helper.c | 17 +++--
include/drm/drm_crtc_helper.h | 1 +
2 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_
Instead of reusing the polling code for hpd handling, split them up.
This has a few consequences:
- Don't touch HPD capable connectors in the poll loop.
- Only touch HPD capable connectors in drm_helper_hpd_irq_event.
- We could run the HPD handling directly (because all callers already
use their
All drivers already have a work item to run the hpd code, so we don't
need to launch a new one in the helper code. Dave Airlie mentioned
that the cancel+re-queue might paper over DP related hpd ping-pongs,
hence why this is split out.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc_hel
This can help drivers to make somewhat intelligent decisions in their
->detect callback: If the connector is hpd capable and in the unknown
state, the driver needs to force a full detect cycle. Otherwise it
could just (if it chooses so) to update the connector state from it's
hpd handler directly,
Actually there's a reason this stuff is there, and it's called
commit e58f637bb96d5a0ae0919b9998b891d1ba7e47c9
Author: Chris Wilson
Date: Fri Aug 20 09:13:36 2010 +0100
drm/kms: Add a module parameter to disable polling
The idea has been that users can enable/disable polling at runtime. S
... by properly checking connector->polled. This doesn't matter too
much because the polling work itself gets this slightly more right and
doesn't set repoll if there's nothing to do. But we can do better.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc_helper.c | 6 ++
1 file chan
Otherwise if the detect callback reports a different state than what
the user forced (rather likely), we continously annoy userspace about
a hotplug uevent.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc_helper.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/
https://bugzilla.kernel.org/show_bug.cgi?id=49351
--- Comment #15 from Igor Murzov 2012-10-23 20:02:35 ---
Created an attachment (id=84511)
--> (https://bugzilla.kernel.org/attachment.cgi?id=84511)
dmesg output for v3.5.2
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab
On Tue, Oct 23, 2012 at 2:23 PM, Daniel Vetter
wrote:
> Hi all,
>
> I've always been a bit unhappy with the overall approach of my old hpd
> patches,
> I think they've tried to move too much clever logic into the helper code. Now
> we
> can still make the helper code a bit more smarter and flex
https://bugzilla.kernel.org/show_bug.cgi?id=49351
--- Comment #16 from Igor Murzov 2012-10-23 20:42:41 ---
Created an attachment (id=84531)
--> (https://bugzilla.kernel.org/attachment.cgi?id=84531)
dmesg output for v3.7.0-rc2+ with kbug49351.diff applied
[ 11.833549] vga_switcheroo: enab
https://bugzilla.kernel.org/show_bug.cgi?id=49351
Alex Deucher changed:
What|Removed |Added
Attachment #84491|0 |1
is obsolete|
https://bugzilla.kernel.org/show_bug.cgi?id=49351
--- Comment #18 from Igor Murzov 2012-10-23 21:27:47 ---
Created an attachment (id=84561)
--> (https://bugzilla.kernel.org/attachment.cgi?id=84561)
dmesg output for v3.7.0-rc2+ with the patch from comment #17
vga_switcheroo seems to work fi
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121023/25948dd4/attachment.html>
From: Alex Deucher
Copy and paste typo in the apci rework.
Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=49351
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_atpx_handler.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/rad
> /**
>+ * radeon_check_pot_argument - check that argument is a power of two
>+ *
>+ * @arg: value to check
>+ *
>+ * Validates that a certain argument is a power of two (all asics).
>+ * Returns true if argument is valid.
>+ */
>+static bool radeon_ckeck_pot_argument(int arg)
>+{
>+ return (
This patch adds iommu support for g2d driver. For this, it
adds subdrv_probe/remove callback to enable or disable
g2d iommu. And with this patch, in case of using g2d iommu,
we can get or put device address to a gem handle from user
through exynos_drm_gem_get/put_dma_addr(). Actually, these
functio
On Mon, Oct 22, 2012 at 9:44 AM, Alan Cox wrote:
>> That (walking all parent nodes) is probably the safest thing to do. I'm
>> not sure whether it's optimal. It would likely depend on whether you
>> can meaningfully have a bridge that's faster on the downstream side than
>> on the upstream.
>
>
On Mon, Oct 08, 2012 at 02:50:38PM -0500, Rob Clark wrote:
> From: Rob Clark
>
> Add a helper fxn to send vblank event after pageflip, plus a handful
> of fixes for other issues that I noticed in the process.
>
> Other than OMAP, the changes are just compile tested, so would be
> good to get a q
On 10/22/2012 05:39 PM, Greg KH wrote:
On Mon, Oct 08, 2012 at 02:50:38PM -0500, Rob Clark wrote:
From: Rob Clark
Add a helper fxn to send vblank event after pageflip, plus a handful
of fixes for other issues that I noticed in the process.
Other than OMAP, the changes are just compile tested,
Hi everyone,
(please Cc)
I am running 3.7-rc2 and got recently hit a few times (under rc1, too)
by hanging drm i915 while doing large io operations.
The efect in the dmesg:
[13193.297751] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU
hung
[13193.297758] [drm] capturing error
>
> (please Cc)
>
> I am running 3.7-rc2 and got recently hit a few times (under rc1, too)
> by hanging drm i915 while doing large io operations.
Does booting with i915.i915_enable_rc6=0 help?
(Daniel, looks like an ironlake).
Dave.
--
Hi Dave,
(switched to freedesktop for dri-dvel)
> Does booting with i915.i915_enable_rc6=0 help?
Will try immediately.
> (Daniel, looks like an ironlake).
Sorry, I forgot that one ... how stupid>
>From XOrg.0.log:
...
[ 13535.841] (II) intel(0): Integrated Graphics Chipset: Intel(R) Arrandale
On Tue, 23 Oct 2012 14:38:30 +0900, Norbert Preining wrote:
> Hi everyone,
>
> (please Cc)
>
> I am running 3.7-rc2 and got recently hit a few times (under rc1, too)
> by hanging drm i915 while doing large io operations.
[snip]
>
> I captured the i915_error_state and uploaded it here:
> h
https://bugs.freedesktop.org/show_bug.cgi?id=55913
--- Comment #5 from Andy Furniss ---
(In reply to comment #4)
> mplayer2 uses advanced VDPAU functionality that mplayer does not use - the
> presentation queue. This works fine with Nvidia's implementation. Likely the
> bug is in Mesa's implement
On Tue, 2012-10-09 at 01:00 +0200, Mario Kleiner wrote:
> On 08.10.12 13:35, Imre Deak wrote:
> > On Sat, 2012-10-06 at 03:41 +0200, Mario Kleiner wrote:
> >> [...]
> >>
> >> But then Psychtoolbox checks each timestamp it gets from somewhere
> >> "outside" (OML_sync_control / INTEL_swap_events / AL
GART and VRAM size limits need to be a power of two.
Fix values greater than 1GB and simplify those checks a bit.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_device.c | 55
1 file changed, 21 insertions(+), 34 deletions(-)
diff --git a/dri
When allocating more than 2GB of GART the array of pages
gets to big for kzalloc, use vzmalloc instead.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_gart.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
When internal users want VRAM we shouldn't return GART memory instead.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_gem.c|8 +++-
drivers/gpu/drm/radeon/radeon_object.c | 10 --
2 files changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/
Driver internal users shouldn't be limited in their allocation size.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_gem.c| 10 ++
drivers/gpu/drm/radeon/radeon_object.c |9 -
2 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/d
On Die, 2012-10-23 at 14:23 +0200, Christian König wrote:
> GART and VRAM size limits need to be a power of two.
> Fix values greater than 1GB and simplify those checks a bit.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/radeon/radeon_device.c | 55
> ---
On 23.10.2012 14:44, Michel Dänzer wrote:
On Die, 2012-10-23 at 14:23 +0200, Christian König wrote:
GART and VRAM size limits need to be a power of two.
Fix values greater than 1GB and simplify those checks a bit.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_device.c |
https://bugzilla.kernel.org/show_bug.cgi?id=49351
Alex Deucher changed:
What|Removed |Added
Attachment #84391|0 |1
is obsolete|
GART and VRAM size limits need to be a power of two.
Fix values greater than 1GB and simplify those checks a bit.
v2: also fix radeon_vram_limit usage, and simplify test even more.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_device.c | 60 +---
When allocating more than 2GB of GART the array of pages
gets to big for kzalloc, use vzalloc instead.
Signed-off-by: Christian König
Reviewed-by: Michel Dänzer
---
drivers/gpu/drm/radeon/radeon_gart.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu
Driver internal users shouldn't be limited in their allocation size.
Signed-off-by: Christian König
Reviewed-by: Michel Dänzer
---
drivers/gpu/drm/radeon/radeon_gem.c| 10 ++
drivers/gpu/drm/radeon/radeon_object.c |9 -
2 files changed, 10 insertions(+), 9 deletions(-)
When internal users want VRAM we shouldn't return GART memory instead.
Signed-off-by: Christian König
Reviewed-by: Michel Dänzer
---
drivers/gpu/drm/radeon/radeon_gem.c|8 +++-
drivers/gpu/drm/radeon/radeon_object.c | 10 --
2 files changed, 7 insertions(+), 11 deletions(-
On Die, 2012-10-23 at 15:53 +0200, Christian König wrote:
> GART and VRAM size limits need to be a power of two.
> Fix values greater than 1GB and simplify those checks a bit.
>
> v2: also fix radeon_vram_limit usage, and simplify test even more.
>
> Signed-off-by: Christian König
Reviewed-by:
https://bugzilla.kernel.org/show_bug.cgi?id=49351
--- Comment #4 from Igor Murzov 2012-10-23 15:00:02 ---
Still no "ATPX function mask" in the log.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watchin
https://bugzilla.kernel.org/show_bug.cgi?id=49351
--- Comment #5 from Alex Deucher 2012-10-23 15:03:11
---
Does it show up if you try switching?
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching
https://bugzilla.kernel.org/show_bug.cgi?id=49351
--- Comment #6 from Igor Murzov 2012-10-23 15:15:40 ---
No.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
https://bugzilla.kernel.org/show_bug.cgi?id=49351
--- Comment #7 from Alex Deucher 2012-10-23 15:19:20
---
It should be printing. Make sure you've booted the right kernel and are using
the right module. If you are using an initrd, make sure it's up to date. Make
sure you aren't redirecti
https://bugzilla.kernel.org/show_bug.cgi?id=49351
--- Comment #8 from Igor Murzov 2012-10-23 15:44:39 ---
Created an attachment (id=84451)
--> (https://bugzilla.kernel.org/attachment.cgi?id=84451)
dmesg output for v3.7.0-rc2+
This dmesg output was produced with following changes:
---
https://bugs.freedesktop.org/show_bug.cgi?id=56329
Priority: medium
Bug ID: 56329
Assignee: dri-devel@lists.freedesktop.org
Summary: System does not hibernate ATI Technologies Inc RV370
secondary [Sapphire X550 Silent]
Severi
https://bugs.freedesktop.org/show_bug.cgi?id=56329
--- Comment #1 from Alex Deucher ---
Does the system hibernate ok if you blacklist the radeon module and use vesa?
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-dev
https://bugs.freedesktop.org/show_bug.cgi?id=56329
--- Comment #2 from Orion Poplawski ---
Yes, it hibernates fine with vesa.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesk
This is happening both with MAINLINE and NEXT.
basically system is running fine, then under load system becomes really
sluggish and unresponsive. I was able to get dmesg of the error..:
[ 7745.007008] ath9k :05:00.0 wlan0: disabling VHT as WMM/QoS is not
supported by the AP
[ 7745.007736
https://bugzilla.kernel.org/show_bug.cgi?id=49351
--- Comment #9 from Alex Deucher 2012-10-23 17:17:15
---
Created an attachment (id=84461)
--> (https://bugzilla.kernel.org/attachment.cgi?id=84461)
possible fix 1
Try this patch and see if it helps.
--
Configure bugmail: https://bugzilla
https://bugzilla.kernel.org/show_bug.cgi?id=49351
--- Comment #10 from Alex Deucher 2012-10-23 17:22:14
---
Created an attachment (id=84471)
--> (https://bugzilla.kernel.org/attachment.cgi?id=84471)
possible fix 2
If the previous patch doesn't help, try this one.
--
Configure bugmail: h
https://bugs.freedesktop.org/show_bug.cgi?id=56329
--- Comment #3 from Alex Deucher ---
Does it hibernate if you disable acceleration?
Option "NoAccel" "True"
in the device section of your xorg.conf?
Also, does suspend work or does it behave the same as hibernate?
--
You are receiving this m
On Tue, Oct 23, 2012 at 10:06:52AM -0700, Justin P. Mattock wrote:
> This is happening both with MAINLINE and NEXT.
>
> basically system is running fine, then under load system becomes
> really sluggish and unresponsive. I was able to get dmesg of the
> error..:
>
> [ 7745.007008] ath9k :05:0
1 - 100 of 129 matches
Mail list logo
