On 09/12/2013 11:50 PM, Maarten Lankhorst wrote:
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 wrote:
So I'm poking around the preemption code and stumble
https://bugs.freedesktop.org/show_bug.cgi?id=57919
--- Comment #21 from Thilo Cestonaro ---
Latest Saucy. Still no luck :(
Kernel: 3.11.0-7-generic
Greetings Thilo
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-deve
https://bugs.freedesktop.org/show_bug.cgi?id=68235
--- Comment #25 from Alexandre Demers ---
(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 radeon_device *rdev)
> >
On 09/12/2013 11:50 PM, Maarten Lankhorst wrote:
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 wrote:
So I'm poking around the preemption code and stumble
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 abo
https://bugs.freedesktop.org/show_bug.cgi?id=69081
José Suárez changed:
What|Removed |Added
Summary|Incorrect rendering of |[radeonsi] Incorrect
|te
On Thu, Sep 12, 2013 at 5:43 PM, Peter Zijlstra 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 userspace did and now
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
Cc: Peter Zijlstra
Cc: Linu
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
> > wrote:
> > >> The one in ttm is just bonghits to shut up lockdep: ttm can recurse
> > >> into it's own pagefault
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
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();
drivers/
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
On Thu, Sep 12, 2013 at 6:44 PM, Thomas Hellstrom 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 held.
For maxim
On Thu, Sep 12, 2013 at 6:22 PM, Peter Zijlstra 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 the set_need_resche
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" com
https://bugs.freedesktop.org/show_bug.cgi?id=68235
--- Comment #24 from Alexandre Demers ---
(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 radeon_device *rdev)
> >
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 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
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 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
glB
Op 12-09-13 17:36, Daniel Vetter schreef:
> On Thu, Sep 12, 2013 at 5:06 PM, Peter Zijlstra 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
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
>>> wrote:
So I'm poking around the preemption code and stumbled upon:
drivers/gpu/drm/i9
On Thu, Sep 12, 2013 at 5:06 PM, Peter Zijlstra 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();
> drivers/gpu/drm/ttm/ttm_bo_
https://bugs.freedesktop.org/show_bug.cgi?id=68451
--- Comment #18 from Peter Kraus ---
(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 earlier commit, 1b40398d024
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
Cc: Peter Zijlstra
Cc: Linux Ker
On Thu, Sep 12, 2013 at 9:58 PM, Thomas Gleixner wrote:
>
>> On Thu, Sep 12, 2013 at 6:22 PM, Peter Zijlstra 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 user
On Thu, Sep 12, 2013 at 10:20 PM, Thomas Gleixner 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 pieces ..
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
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 reschedul
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 f
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: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 09/12/2013 05:58 PM, Daniel Vetter wrote:
On Thu, Sep 12, 2013 at 5:43 PM, Peter Zijlstra 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 describe how it could recu
On Thu, Sep 12, 2013 at 05:58:49PM +0200, Daniel Vetter wrote:
> On Thu, Sep 12, 2013 at 5:43 PM, Peter Zijlstra 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
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 l
https://bugs.freedesktop.org/show_bug.cgi?id=68451
--- Comment #17 from Marko Srebre ---
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, 1b40398d024d2ac5c8e8b78d0f4941e2a007de2c, an
https://bugs.freedesktop.org/show_bug.cgi?id=68235
--- Comment #23 from Alex Deucher ---
(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 radeon_atom_init_
https://bugs.freedesktop.org/show_bug.cgi?id=68235
--- Comment #22 from Alex Deucher ---
(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)
> }
> ni_pi->mclk_rtt_mode_t
On Wed, Sep 11, 2013 at 11:45:19AM +0300, Jani Nikula wrote:
> On Wed, 11 Sep 2013, Aaron Lu 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 does not work o
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" com
From: Wei Yongjun
The dereference to 'pdata' should be moved below the NULL test.
Signed-off-by: Wei Yongjun
---
drivers/gpu/drm/msm/msm_gpu.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index e1e1ec9..6b50
From: Wei Yongjun
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
---
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_
On Wed, 2013-09-11 at 13:29 +0300, Jani Nikula wrote:
> On Wed, 11 Sep 2013, 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 behav
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 >= ACPI_OSI
From: Randy Dunlap
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
`nouveau_switcheroo_optimus_dsm'
Sign
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
https://bugs.freedesktop.org/show_bug.cgi?id=69062
--- Comment #7 from LRN ---
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).
Installed drm - no effect.
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130912/286ab64e/attachment-0001.html>
46 matches
Mail list logo
