Hi
On Mon, Sep 9, 2013 at 1:43 PM, Thierry Reding
wrote:
> On Mon, Sep 09, 2013 at 12:48:08PM +0200, David Herrmann wrote:
>> Hi
>>
>> On Mon, Sep 9, 2013 at 12:27 PM, Thierry Reding
>> wrote:
>> > The genshader and genunifont utilities are run during the build process
>> > to generate source
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130912/286ab64e/attachment-0001.html>
https://bugs.freedesktop.org/show_bug.cgi?id=43829
--- Comment #33 from Jose P. lbdkm...@sharklasers.com ---
Created attachment 85691
-- https://bugs.freedesktop.org/attachment.cgi?id=85691action=edit
dmesg+Xorg.0.log
Same bug here...
HP laptop (dv6-6174la), dual GPU:
00:01.0 VGA compatible
https://bugs.freedesktop.org/show_bug.cgi?id=69062
--- Comment #7 from LRN lrn1...@gmail.com ---
Upgraded kernel to b7a5ae97502e104371c7eb3b7b17ae959e50d6f5
No effect.
Tried to build and install older drm and mesa (git revs from ~Jan 2013, since i
remember that things worked back then).
On mer., 2013-09-11 at 08:45 +, Matthew Garrett wrote:
On Wed, 2013-09-11 at 11:45 +0300, Jani Nikula wrote:
Before plunging forward, have you observed any difference between the
boot modes? We have reports [1] that the backlight behaviour is
different with UEFI vs. UEFI+CSM or legacy
From: Randy Dunlap rdun...@infradead.org
Fix nouveau build error on x86, when ACPI is enabled but
VGA_SWITCHEROO is not enabled, by providing a stub function.
drivers/built-in.o: In function `nouveau_pmops_runtime_suspend':
nouveau_drm.c:(.text+0x3aac89): undefined reference to
On Wed, 2013-09-11 at 11:45 +0300, Jani Nikula wrote:
Before plunging forward, have you observed any difference between the
boot modes? We have reports [1] that the backlight behaviour is
different with UEFI vs. UEFI+CSM or legacy boot. So I'm wondering if the
acpi_gbl_osi_data =
On Wed, 2013-09-11 at 13:29 +0300, Jani Nikula wrote:
On Wed, 11 Sep 2013, Matthew Garrett matthew.garr...@nebula.com wrote:
On Wed, 2013-09-11 at 11:45 +0300, Jani Nikula wrote:
Before plunging forward, have you observed any difference between the
boot modes? We have reports [1] that the
From: Wei Yongjun yongjun_...@trendmicro.com.cn
Fix to return -ENOMEM in the refill memory alloc error handling
case instead of 0, as done elsewhere in this function.
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
---
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 1 +
1 file changed, 1
From: Wei Yongjun yongjun_...@trendmicro.com.cn
The dereference to 'pdata' should be moved below the NULL test.
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
---
drivers/gpu/drm/msm/msm_gpu.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
Hello,
I am writing to report two issues I'm having with a hybrid graphics laptop.
Namely, Sony Vaio SA3S9R with Intel HD3000 and Radeon HD6630M
First one looks like a regression introduced by the commit named
gpu/vga_switcheroo: add driver control power feature. (v3). After I echo
the OFF
On Wed, Sep 11, 2013 at 11:45:19AM +0300, Jani Nikula wrote:
On Wed, 11 Sep 2013, Aaron Lu aaron...@intel.com wrote:
It is possible the i915 driver decides not to register a backlight
interface for the graphics card for some reason(memory allocation failed
or it knows the native control
https://bugs.freedesktop.org/show_bug.cgi?id=68235
--- Comment #22 from Alex Deucher ag...@yahoo.com ---
(In reply to comment #20)
Ok, if I apply the whole suggested patch but the following, it hangs:
@@ -4152,14 +4152,14 @@ int ni_dpm_init(struct radeon_device *rdev)
}
https://bugs.freedesktop.org/show_bug.cgi?id=68235
--- Comment #23 from Alex Deucher ag...@yahoo.com ---
(In reply to comment #21)
Adding printk(KERN_DEBUG DEBUG: about to pass the following value of
module_index to radeon_atom_init_mc_reg_table(): %d, module_index); just
before calling
https://bugs.freedesktop.org/show_bug.cgi?id=68451
--- Comment #17 from Marko Srebre bgz.ma...@gmail.com ---
Hi,
I am also having this behavior in Dota2. Peter, are you sure
7948ed1250cae78ae1b22dbce4ab23aceacc6159 is the first non-working? Can you try
one earlier commit,
On Thu, Sep 12, 2013 at 05:36:43PM +0200, Daniel Vetter wrote:
The set_need_resched in i915_gem.c:i915_gem_fault can actually be
removed. It was there to give the error handler a chance to sneak in
and reset the hw/sw tracking when the gpu is dead. That hack goes back
to the days when the
On Thu, Sep 12, 2013 at 05:58:49PM +0200, Daniel Vetter wrote:
On Thu, Sep 12, 2013 at 5:43 PM, Peter Zijlstra pet...@infradead.org wrote:
The one in ttm is just bonghits to shut up lockdep: ttm can recurse
into it's own pagefault handler and then deadlock, the trylock just
keeps lockdep
On 09/12/2013 05:58 PM, Daniel Vetter wrote:
On Thu, Sep 12, 2013 at 5:43 PM, Peter Zijlstra pet...@infradead.org wrote:
The one in ttm is just bonghits to shut up lockdep: ttm can recurse
into it's own pagefault handler and then deadlock, the trylock just
keeps lockdep quiet.
Could you
On Thu, Sep 12, 2013 at 05:57:29PM +0200, Daniel Vetter wrote:
This very much looks like copypasta from drm/i915's fault handler.
It was used there to duct-tape over issues around gpu reset handling.
Since that can't ever happen for udl and there's seemingly no other
reason for this just
On Thu, Sep 12, 2013 at 05:35:43PM +0100, Chris Wilson wrote:
Not quite, as it would be possible for the evil userspace to trigger a
GPU hang that would cause the sane userspace to spin indefinitely
waiting for the error recovery to kick in.
So with FIFOn+1 preempting FIFOn its a live-lock
On Thu, Sep 12, 2013 at 05:57:28PM +0200, Daniel Vetter wrote:
This is just a remnant from the old days when our reset handling was
horribly racy, suffered from terribly locking issues and often happily
live-locked. Those days are now gone so we can drop the hacks and just
rip the
On Thu, Sep 12, 2013 at 05:59:51PM +0200, Peter Zijlstra wrote:
On Thu, Sep 12, 2013 at 05:57:28PM +0200, Daniel Vetter wrote:
This is just a remnant from the old days when our reset handling was
horribly racy, suffered from terribly locking issues and often happily
live-locked. Those days
On Thu, Sep 12, 2013 at 10:20 PM, Thomas Gleixner t...@linutronix.de wrote:
I think for ttm drivers it's just execbuf being exploitable. But on
drm/i915 we've
had the same issue with the pwrite/pread ioctls, so a simple
glBufferData(glMap) kind of recursion from gl clients blew the kernel
to
On Thu, Sep 12, 2013 at 9:58 PM, Thomas Gleixner t...@linutronix.de wrote:
On Thu, Sep 12, 2013 at 6:22 PM, Peter Zijlstra pet...@infradead.org wrote:
If 'sane' userspace is never supposed to do this, then only insane
userspace is going to hurt from this and that's a GOOD (tm) thing,
This very much looks like copypasta from drm/i915's fault handler.
It was used there to duct-tape over issues around gpu reset handling.
Since that can't ever happen for udl and there's seemingly no other
reason for this just drop it.
Reported-by: Peter Zijlstra pet...@infradead.org
Cc: Peter
https://bugs.freedesktop.org/show_bug.cgi?id=68451
--- Comment #18 from Peter Kraus peter.kr...@geeksonbikes.net ---
(In reply to comment #17)
Hi,
I am also having this behavior in Dota2. Peter, are you sure
7948ed1250cae78ae1b22dbce4ab23aceacc6159 is the first non-working? Can you
try one
On Thu, Sep 12, 2013 at 5:06 PM, Peter Zijlstra pet...@infradead.org wrote:
So I'm poking around the preemption code and stumbled upon:
drivers/gpu/drm/i915/i915_gem.c:set_need_resched();
drivers/gpu/drm/ttm/ttm_bo_vm.c:set_need_resched();
Op 12-09-13 18:44, Thomas Hellstrom schreef:
On 09/12/2013 05:45 PM, Maarten Lankhorst wrote:
Op 12-09-13 17:36, Daniel Vetter schreef:
On Thu, Sep 12, 2013 at 5:06 PM, Peter Zijlstra pet...@infradead.org
wrote:
So I'm poking around the preemption code and stumbled upon:
On 09/12/2013 10:39 PM, Thomas Gleixner wrote:
On Thu, 12 Sep 2013, Daniel Vetter wrote:
On Thu, Sep 12, 2013 at 10:20 PM, Thomas Gleixner t...@linutronix.de wrote:
I think for ttm drivers it's just execbuf being exploitable. But on
drm/i915 we've
had the same issue with the pwrite/pread
On 09/12/2013 05:45 PM, Maarten Lankhorst wrote:
Op 12-09-13 17:36, Daniel Vetter schreef:
On Thu, Sep 12, 2013 at 5:06 PM, Peter Zijlstra pet...@infradead.org wrote:
So I'm poking around the preemption code and stumbled upon:
drivers/gpu/drm/i915/i915_gem.c:
Op 12-09-13 17:36, Daniel Vetter schreef:
On Thu, Sep 12, 2013 at 5:06 PM, Peter Zijlstra pet...@infradead.org wrote:
So I'm poking around the preemption code and stumbled upon:
drivers/gpu/drm/i915/i915_gem.c:set_need_resched();
drivers/gpu/drm/ttm/ttm_bo_vm.c:
Hello,
I am writing to report two issues I'm having with a hybrid graphics laptop.
Namely, Sony Vaio SA3S9R with Intel HD3000 and Radeon HD6630M
First one looks like a regression introduced by the commit named
gpu/vga_switcheroo: add driver control power feature. (v3). After I echo
the OFF
https://bugs.freedesktop.org/show_bug.cgi?id=68235
--- Comment #24 from Alexandre Demers alexandre.f.dem...@gmail.com ---
(In reply to comment #22)
(In reply to comment #20)
Ok, if I apply the whole suggested patch but the following, it hangs:
@@ -4152,14 +4152,14 @@ int ni_dpm_init(struct
On Thu, Sep 12, 2013 at 6:22 PM, Peter Zijlstra pet...@infradead.org wrote:
If 'sane' userspace is never supposed to do this, then only insane
userspace is going to hurt from this and that's a GOOD (tm) thing,
right? ;-)
Afaik sane userspace doesn't hit the _deadlock_ (or lifelock if we
have
On Thu, Sep 12, 2013 at 6:44 PM, Thomas Hellstrom thellst...@vmware.com wrote:
I think a possible fix would be if fault() were allowed to return an error
and drop the mmap_sem() before returning.
Otherwise we need to track down all copy_to_user / copy_from_user which
happen with bo::reserve
Op 12-09-13 17:06, Peter Zijlstra schreef:
Hi Dave,
So I'm poking around the preemption code and stumbled upon:
drivers/gpu/drm/i915/i915_gem.c:set_need_resched();
drivers/gpu/drm/ttm/ttm_bo_vm.c:set_need_resched();
drivers/gpu/drm/ttm/ttm_bo_vm.c:
On Thu, Sep 12, 2013 at 05:11:25PM +0200, Maarten Lankhorst wrote:
Op 12-09-13 17:06, Peter Zijlstra schreef:
Hi Dave,
So I'm poking around the preemption code and stumbled upon:
drivers/gpu/drm/i915/i915_gem.c:set_need_resched();
drivers/gpu/drm/ttm/ttm_bo_vm.c:
On Thu, Sep 12, 2013 at 06:22:10PM +0200, Peter Zijlstra wrote:
On Thu, Sep 12, 2013 at 05:58:49PM +0200, Daniel Vetter wrote:
On Thu, Sep 12, 2013 at 5:43 PM, Peter Zijlstra pet...@infradead.org
wrote:
The one in ttm is just bonghits to shut up lockdep: ttm can recurse
into it's own
Hi Dave,
So I'm poking around the preemption code and stumbled upon:
drivers/gpu/drm/i915/i915_gem.c:set_need_resched();
drivers/gpu/drm/ttm/ttm_bo_vm.c:set_need_resched();
drivers/gpu/drm/ttm/ttm_bo_vm.c:set_need_resched();
This is just a remnant from the old days when our reset handling was
horribly racy, suffered from terribly locking issues and often happily
live-locked. Those days are now gone so we can drop the hacks and just
rip the reschedule-point out.
Reported-by: Peter Zijlstra pet...@infradead.org
Cc:
On Thu, Sep 12, 2013 at 5:43 PM, Peter Zijlstra pet...@infradead.org wrote:
The one in ttm is just bonghits to shut up lockdep: ttm can recurse
into it's own pagefault handler and then deadlock, the trylock just
keeps lockdep quiet. We've had that bug arise in drm/i915 due to some
fun
https://bugs.freedesktop.org/show_bug.cgi?id=69081
José Suárez j.suarez.agap...@gmail.com changed:
What|Removed |Added
Summary|Incorrect rendering of |[radeonsi]
hmm, looks like I cargo-cult'd the same into msm.
I guess in i915 (and ttm) case, the issue arises due to need for CPU
access to buffer via GTT? In which case I should be safe to drop the
set_need_resched() as well? (Since CPU always has direct access to the
pages.) Or am I missing something
43 matches
Mail list logo
