> /**
>+ * 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 (
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
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
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
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121023/25948dd4/attachment.html>
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
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 #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
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/
... 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
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
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,
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
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
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_
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
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 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
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>
e bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121023/d665bab1/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=49351
Alex Deucher changed:
What|Removed |Added
Attachment #84441|0 |1
is obsolete|
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: ---
> /**
>+ * 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 (
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121023/1c2768d1/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=46241
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
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
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
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
Hi Dave, hi Chris,
thanks for your answers.
On Di, 23 Okt 2012, Dave Airlie wrote:
> Does booting with i915.i915_enable_rc6=0 help?
No,booted with that, it happened again on a completely idle
system (well, I believe completely idle, I was doing the
dishes ;-)
[12437.995026] [drm:i915_hangcheck_
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>
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://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
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20121023/f235338c/attachment.html>
>
> (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.
--
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
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121023/64fc3f90/attachment.html>
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 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:
dri-devel/attachments/20121023/fb31b667/attachment-0001.html>
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(-
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 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
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 +---
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:
---
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
--- 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 #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 #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
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
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
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
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
> ---
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
https://bugs.freedesktop.org/show_bug.cgi?id=27708
--- Comment #17 from aceman ---
I haven't seen the message for a long time now.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
[email protected]
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
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
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
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
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
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
Alex Deucher changed:
What|Removed |Added
Attachment #84391|0 |1
is obsolete|
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
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 flexi
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
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/
... 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
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
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,
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
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
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_
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
https://bugs.freedesktop.org/show_bug.cgi?id=56329
--- Comment #6 from Orion Poplawski ---
I'm not sure nothing else is going on, but I started having the problem when I
switched to this graphics card. And unfortunately I don't seem to get any
messages to indicate where it might be failing.
--
https://bugs.freedesktop.org/show_bug.cgi?id=56329
--- Comment #5 from Alex Deucher ---
Suspend and hibernate are treated the same in the driver. Are you sure there
isn't something else happening with hibernate?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=49351
Alex Deucher changed:
What|Removed |Added
Attachment #84441|0 |1
is obsolete|
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: ---
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
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
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
https://bugs.freedesktop.org/show_bug.cgi?id=56329
--- Comment #4 from Orion Poplawski ---
NoAccel make no difference.
Suspend works fine.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@
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>
https://bugzilla.kernel.org/show_bug.cgi?id=46241
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
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
Sure.. seems this error is happening frequently to gather the debug info(will
send out as soon as it hits). As for the bisect it is doable when I get the
time. Just need a reliable recreation of the error so the bisect is correct.
Justin P. Mattock
- Reply message -
From: "Daniel Vetter
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 #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
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://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
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://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
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:
>
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
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://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
[email protected]
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
Priority: medium
Bug ID: 56329
Assignee: [email protected]
Summary: System does not hibernate ATI Technologies Inc RV370
secondary [Sapphire X550 Silent]
Severi
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://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 #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.
___
1 - 100 of 129 matches
Mail list logo
