On Sun, Apr 17, 2011 at 06:49:20PM +0200, Marcin Slusarz wrote:
> On Sun, Apr 17, 2011 at 12:24:27PM -0400, Kyle Spaans wrote:
> > On Sun, Apr 17, 2011 at 05:45:57PM +0200, Marcin Slusarz wrote:
> > > On Sun, Apr 17, 2011 at 11:12:04AM -0400, Kyle Spaans wrote:
> > > &
On Mon, Apr 18, 2011 at 04:09:11PM -0700, Joe Perches wrote:
> On Mon, 2011-04-18 at 16:01 -0700, Ian Romanick wrote:
> > > @@ -214,9 +214,9 @@ parse_lfp_panel_data(struct drm_i915_private
> > > *dev_priv,
> > > i915_lvds_downclock) {
> > > dev_priv->lvds_downclock_avail = 1;
> > >
On Mon, Apr 18, 2011 at 01:27:10PM -0700, Linus Torvalds wrote:
> On Mon, Apr 18, 2011 at 1:02 PM, Marcin Slusarz
> wrote:
> >
> > It's some nasty corruption:
>
> Looks like something wrote 0x to free'd memory.
>
> Enabling DEBUG
fy was always 0, so it didn't
matter it was a value in bytes).
Reported-by: Dominik Brodowski
Reported-by: Nigel Cunningham
Signed-off-by: Marcin Slusarz
Cc: Ben Skeggs
Cc: Pekka Paalanen
Cc: sta...@kernel.org[2.6.38]
---
drivers/gpu/drm/nouveau/nouveau_fbcon.c |4 ++--
1 files c
Commit 73412c3854c877e5f37ad944ee8977addde4d35a ("drm/nouveau: allocate
kernel's notifier object at end of block") intended to align end of
notifier block to page boundary, but start of block was miscalculated
to be off by -16 bytes. Fix it.
Signed-off-by: Marcin Slusarz
On Fri, Apr 29, 2011 at 01:57:10PM +1000,
christopher.halse.rog...@canonical.com wrote:
> From: Christopher James Halse Rogers
>
> v2: Also pull out the drm_vblank_put call.
> Signed-off-by: Christopher James Halse Rogers
>
> ---
> drivers/gpu/drm/drm_irq.c | 44 ++--
Both drmIoctl and ioctl define second argument as unigned long, but
DRM_IOCTL do not.
Debugging/tracing tools (like strace or valgrind) on 64-bit machines see
different request value for ioctls with 32nd bit set, because casting
signed int to unsigned long extends 32nd bit to upper word, so 0x8000
On Sun, Jun 05, 2011 at 07:28:20PM +0200, Marcin Slusarz wrote:
> Both drmIoctl and ioctl define second argument as unigned long, but
> DRM_IOCTL do not.
>
> Debugging/tracing tools (like strace or valgrind) on 64-bit machines see
> different request value for ioctls with 32nd b
On Tue, Jun 21, 2011 at 08:48:55PM +0200, Francesco Allertsen wrote:
> On Tue, Jun 21, 2011 at 11:29:41AM -0700, Jesse Barnes wrote:
> > Use netconsole. Documentation/networking/netconsole.txt has all the
> > gory details.
>
> I have used netconsole, with that documentation, but it doesn't show m
tical.
There's no need to change these strings. Nouveau prints chipset id earlier.
For patch with only kfrees:
Reviewed-by: Marcin Slusarz
> Signed-off-by: Jesper Juhl
> ---
> drivers/gpu/drm/nouveau/nv20_graph.c |4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
ttm_tt_destroy kfrees passed object, so we need to nullify
a reference to it.
Signed-off-by: Marcin Slusarz
Cc: sta...@kernel.org
---
drivers/gpu/drm/ttm/ttm_bo.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm
gnal.
Signed-off-by: Marcin Slusarz
---
drivers/gpu/drm/nouveau/nouveau_channel.c |1 +
drivers/gpu/drm/nouveau/nouveau_drv.h |7 ++-
drivers/gpu/drm/nouveau/nouveau_fence.c | 34 -
drivers/gpu/drm/nouveau/nouveau_gem.c | 34 +---
drivers/gpu/drm
New ioctl is used internally by nouveau_bo_wait to properly handle
timeouts with signals.
---
include/drm/nouveau_drm.h | 33 ++
nouveau/nouveau_bo.c | 66 ++---
2 files changed, 77 insertions(+), 22 deletions(-)
diff --git a/in
On Sun, Sep 18, 2011 at 03:59:50PM +0200, Daniel Vetter wrote:
> On Sun, Sep 18, 2011 at 03:18:57PM +0200, Marcin Slusarz wrote:
> > Currently DRM_NOUVEAU_GEM_CPU_PREP ioctl is broken WRT handling of signals.
> >
> > nouveau_gem_ioctl_cpu_prep calls ttm_bo_wait whi
On Tue, Apr 13, 2010 at 09:50:04PM +0200, Marcin Slusarz wrote:
> On Mon, Apr 12, 2010 at 11:33:27PM +0200, Marcin Slusarz wrote:
> > > > > Have you got a pointer to a machine where it fails?
> > > >
> > > > No, it failed with an artifical test while
> nothing prevents it right now)
> > - vga16fb registration error path is iounmapping memory which was not
> > ioremapped.
> > I'm going to fix it soon.
>
> Nak. See comments below.
Thanks for a review.
> > ---
> > From: Marcin Slusarz
> > Subj
uveau
initialisation.
Fix it by kicking firmware driver(s) before we start touching the hardware.
Reported-by: Didier Spaier
Tested-by: Didier Spaier
Signed-off-by: Marcin Slusarz
Cc: Ben Skeggs
Cc: Dave Airlie
Cc: Peter Jones
Cc: Andrew Morton
---
no changes since last submission
---
driver
let vga16fb claim 0xA+0x1 region as its aperture;
drm drivers don't use it, so we have to detect it and kick
vga16fb manually - but only if drm is driving the primary card
Signed-off-by: Marcin Slusarz
Cc: James Simmons
Cc: Dave Airlie
Cc: Ben Skeggs
---
no changes since
nouveau_irq_handler tries to take
dev_priv->context_switch_lock (spins)
deadlock
Possible solutions:
- reverting "drm/nouveau: use drm_mm in preference to custom code doing the
same thing"
- disabling interrupts before calling drm_mm functions - unmaintainable and
still
deadlock
On Sun, Jul 11, 2010 at 11:02:12AM +1000, Ben Skeggs wrote:
> On Sun, 2010-07-11 at 01:24 +0200, Marcin Slusarz wrote:
> > Hi
> >
> > Patch "drm/nouveau: use drm_mm in preference to custom code doing the same
> > thing"
> > in nouveau tree introduced
On Mon, Jul 26, 2010 at 07:15:47PM +0200, Francisco Jerez wrote:
> Marcin Slusarz writes:
>
> > On Sun, Jul 11, 2010 at 11:02:12AM +1000, Ben Skeggs wrote:
> >> On Sun, 2010-07-11 at 01:24 +0200, Marcin Slusarz wrote:
> >> > Hi
> >> >
> >
On Wed, Jul 28, 2010 at 01:42:03AM -0400, valdis.kletni...@vt.edu wrote:
> On Tue, 27 Jul 2010 14:56:50 PDT, a...@linux-foundation.org said:
> > The mm-of-the-moment snapshot 2010-07-27-14-56 has been uploaded to
> >
> >http://userweb.kernel.org/~akpm/mmotm/
>
> Hit this while the X server wa
On Thu, Jul 29, 2010 at 08:02:31PM +0200, Dan Carpenter wrote:
> nouveau_load() just returned directly if there was an error instead of
> releasing resources.
>
> Signed-off-by: Dan Carpenter
Patch looks good, but could you base it on top of nouveau tree?
git://anongit.freedesktop.org/nouveau/
resources.
>
>
> Signed-off-by: Dan Carpenter
> ---
> V2: updated to the nouveau git tree.
Thanks.
Reviewed-by: Marcin Slusarz
> diff --git a/drivers/gpu/drm/nouveau/nouveau_state.c
> b/drivers/gpu/drm/nouveau/nouveau_state.c
> inde
Hi
Since upgrade from 2.6.35 to 2.6.36-rc3 (nouveau tree) I'm hitting this bug a
couple of times a day:
[ 2869.618504] [ cut here ]
[ 2869.618532] kernel BUG at drivers/gpu/drm/ttm/ttm_bo.c:153!
[ 2869.618560] invalid opcode: [#1] PREEMPT SMP
[ 2869.618600] last sysf
On Sat, Sep 18, 2010 at 09:39:21AM +1000, Ben Skeggs wrote:
> On Fri, 2010-09-17 at 19:43 +0200, Marcin Slusarz wrote:
> > Hi
> > Since upgrade from 2.6.35 to 2.6.36-rc3 (nouveau tree) I'm hitting this bug
> > a couple of times a day:
> >
> >
On Fri, Sep 17, 2010 at 06:53:26PM -0400, Andy Walls wrote:
> On my system, every 10 seconds drm_edid_block_valid() gets called 4
> times by radeon_dvi_detect(). This results in 4 instances of a
> multi-line hex dump of the same EDID (non-)data being logged every 10
> seconds.
>
> Silence the hex
> If we let the ghost object inherit cpu_writers from the original
> object, ttm_bo_release_list() will raise a kernel BUG when the ghost
> object is destroyed. This can be reproduced with the nouveau driver on
> nv5x.
>
> Reported-by: Marcin Slusarz
> Signed-off-by: Francisc
On Sat, Oct 02, 2010 at 09:58:56AM +0200, Jiri Slaby wrote:
> There are two messages in the ISR of nouvea which might be printed out
> hundred times in a second. Ratelimit them.
>
> Signed-off-by: Jiri Slaby
> Cc: Ben Skeggs
> ---
> drivers/gpu/drm/nouveau/nouveau_irq.c |9 ++---
> 1 fi
: Ben Skeggs
> Cc: Marcin Slusarz
FWIW
Reviewed-by: Marcin Slusarz
> ---
> drivers/gpu/drm/nouveau/nouveau_irq.c | 23 +--
> 1 files changed, 13 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_irq.c
> b/drivers/gpu/dr
On Wed, Oct 06, 2010 at 06:39:07PM +0200, Daniel Vetter wrote:
> From: Benjamin Herrenschmidt
>
> Without this, we attempt the handover too late, the firmware fb
> might be accessing the chip simultaneously to us re-initializing
> various parts of it, which might frighten babies or cause all sort
On Wed, Oct 06, 2010 at 08:54:12PM +0200, Daniel Vetter wrote:
> On Wed, Oct 06, 2010 at 08:20:15PM +0200, Marcin Slusarz wrote:
> > On Wed, Oct 06, 2010 at 06:39:07PM +0200, Daniel Vetter wrote:
> > > +static void radeon_kick_out_firmware_fb(struct drm_device *ddev)
>
On Sat, Oct 09, 2010 at 03:53:58PM +0200, Kai Ruhnau wrote:
> On 09/18/2010 01:18 PM, Marcin Slusarz wrote:
> > On Sat, Sep 18, 2010 at 09:39:21AM +1000, Ben Skeggs wrote:
> >> On Fri, 2010-09-17 at 19:43 +0200, Marcin Slusarz wrote:
> >>> Hi
> >>> Since
It printed garbage from stack:
[drm:drm_debugfs_create_files] *ERROR* Cannot create
/sys/kernel/debug/dri/!.wy/2
Reported-by: Daniel Yek
Signed-off-by: Marcin Slusarz
Cc: stable at kernel.org
---
drivers/gpu/drm/drm_debugfs.c |3 +--
drivers/gpu/drm/drm_proc.c|3 +--
2 files
It printed garbage.
Signed-off-by: Marcin Slusarz
---
drivers/gpu/drm/drm_proc.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_proc.c b/drivers/gpu/drm/drm_proc.c
index 9e5b07e..0f3c4e3 100644
--- a/drivers/gpu/drm/drm_proc.c
+++ b/drivers/gpu
There's no need to copy d_name.name.
Signed-off-by: Marcin Slusarz
---
drivers/gpu/drm/drm_debugfs.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index 9d2668a..b9dc262 100644
--- a/drivers/gp
le of xterms with
looped glxinfo.
Signed-off-by: Marcin Slusarz
---
drivers/gpu/drm/drm_debugfs.c |5 +
include/drm/drmP.h|1 +
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index 9d2668a..1144fbe 1
On Mon, Oct 31, 2011 at 09:06:57AM +0100, Daniel Vetter wrote:
> This is just ugly, you're adding a mutex to every drm_info_node, but only
> use the one embedded into the minor. On a quick grep we're only ever using
> the list in there, so I suggest to
> - replace minor->debugfs_node.list with mino
le of xterms with
looped glxinfo.
Signed-off-by: Marcin Slusarz
---
drivers/gpu/drm/drm_debugfs.c | 12 +---
drivers/gpu/drm/i915/i915_debugfs.c |5 -
include/drm/drmP.h |4 +++-
3 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/gp
gnal.
Signed-off-by: Marcin Slusarz
---
drivers/gpu/drm/nouveau/nouveau_channel.c |1 +
drivers/gpu/drm/nouveau/nouveau_drv.h |7 ++-
drivers/gpu/drm/nouveau/nouveau_fence.c | 34 -
drivers/gpu/drm/nouveau/nouveau_gem.c | 34 +---
drivers/gpu/drm
New ioctl is used internally by nouveau_bo_wait to properly handle
timeouts with signals.
---
include/drm/nouveau_drm.h | 33 ++
nouveau/nouveau_bo.c | 66 ++---
2 files changed, 77 insertions(+), 22 deletions(-)
diff --git a/in
On Sun, Sep 18, 2011 at 03:59:50PM +0200, Daniel Vetter wrote:
> On Sun, Sep 18, 2011 at 03:18:57PM +0200, Marcin Slusarz wrote:
> > Currently DRM_NOUVEAU_GEM_CPU_PREP ioctl is broken WRT handling of signals.
> >
> > nouveau_gem_ioctl_cpu_prep calls ttm_bo_wait whi
On Tue, Apr 10, 2012 at 10:52:06AM +0200, Jiri Slaby wrote:
> On 04/06/2012 11:31 PM, Jiri Slaby wrote:
> > On 03/30/2012 02:24 PM, Chris Wilson wrote:
> >> On Fri, 30 Mar 2012 14:11:47 +0200, Jiri Slaby wrote:
> >>> On 03/30/2012 12:45 PM, Chris Wilson wrote:
> On Fri, 30 Mar 2012 11:59:28 +
Nouveau, in normal circumstances, does not need device lock for every ioctl,
but incoming "gpu reset" code needs exclusive access to the device.
This commit adds drm_driver flag which turns on read lock ioctl encapsulation.
Signed-off-by: Marcin Slusarz
---
drivers/gpu/drm/drm_drv
Wait loop can be interrupted by signal, so if signals are raised
periodically (e.g. SIGALRM) this loop may never finish. Use
emission time as a base for fence timeout.
Signed-off-by: Marcin Slusarz
---
drivers/gpu/drm/nouveau/nouveau_fence.c |5 -
1 files changed, 4 insertions(+), 1
We need this for lockup recovery.
Signed-off-by: Marcin Slusarz
---
drivers/gpu/drm/nouveau/nouveau_bo.c |9 +++--
drivers/gpu/drm/nouveau/nouveau_drv.h |6 +++---
drivers/gpu/drm/nouveau/nouveau_vm.c | 20 ++--
drivers/gpu/drm/nouveau/nouveau_vm.h | 18
Signed-off-by: Marcin Slusarz
---
drivers/gpu/drm/nouveau/nv50_graph.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nv50_graph.c
b/drivers/gpu/drm/nouveau/nv50_graph.c
index 6899547..a61853f 100644
--- a/drivers/gpu/drm/nouveau
waits
Signed-off-by: Marcin Slusarz
---
Tested only on nv92.
---
drivers/gpu/drm/nouveau/Makefile |2 +-
drivers/gpu/drm/nouveau/nouveau_bo.c |2 +-
drivers/gpu/drm/nouveau/nouveau_channel.c |5 +-
drivers/gpu/drm/nouveau/nouveau_drv.c |3 +-
drivers/gpu/drm
On Mon, Apr 23, 2012 at 10:43:08AM +0200, Martin Peres wrote:
> Le 23/04/2012 00:18, Marcin Slusarz a ?crit :
> > Overall idea:
> > Detect lockups by watching for timeouts (vm flush / fence), return -EIOs,
> > handle them at ioctl level, reset the GPU and repeat last ioctl.
On Mon, Apr 23, 2012 at 09:51:48AM +0200, Daniel Vetter wrote:
> On Mon, Apr 23, 2012 at 12:18:28AM +0200, Marcin Slusarz wrote:
> > Nouveau, in normal circumstances, does not need device lock for every ioctl,
> > but incoming "gpu reset" code needs exclusive access to th
On Mon, Apr 23, 2012 at 07:09:57PM +0200, Martin Peres wrote:
> Le 23/04/2012 00:18, Marcin Slusarz a ?crit :
> > Signed-off-by: Marcin Slusarz
> > ---
> > drivers/gpu/drm/nouveau/nv50_graph.c |5 +
> > 1 files changed, 5 insertions(+), 0 deletions(-)
>
On Mon, Apr 23, 2012 at 06:46:41PM +0200, Martin Peres wrote:
> Hey,
>
> Just a minor mistake spotted while skimming through the patch.
>
> Le 23/04/2012 00:18, Marcin Slusarz a ?crit :
> > +static inline uint64_t nv_timeout(struct drm_device *dev)
> > +{
> >
On Tue, Apr 24, 2012 at 12:37:34PM +1000, Ben Skeggs wrote:
> On Mon, 2012-04-23 at 00:18 +0200, Marcin Slusarz wrote:
> > Wait loop can be interrupted by signal, so if signals are raised
> > periodically (e.g. SIGALRM) this loop may never finish. Use
> > emission time as a b
On Mon, Apr 23, 2012 at 09:51:48AM +0200, Daniel Vetter wrote:
> On Mon, Apr 23, 2012 at 12:18:28AM +0200, Marcin Slusarz wrote:
> > Nouveau, in normal circumstances, does not need device lock for every ioctl,
> > but incoming "gpu reset" code needs exclusive access to th
On Mon, Apr 23, 2012 at 06:56:44PM +0200, Martin Peres wrote:
> Le 23/04/2012 18:32, Marcin Slusarz a ?crit :
> >
> > Just run piglit. Even "quick" tests can cause ~5 lockups (it eventually
> > messes
> > up DDX channel, but this patchset can't fix thi
Wait loop can be interrupted by signal, so if signals are raised
periodically (e.g. SIGALRM) this loop may never finish. Use
emission time as a base for fence timeout.
Signed-off-by: Marcin Slusarz
---
drivers/gpu/drm/nouveau/nouveau_fence.c |5 -
1 files changed, 4 insertions(+), 1
We need this for lockup recovery.
Signed-off-by: Marcin Slusarz
---
drivers/gpu/drm/nouveau/nouveau_bo.c |9 +++--
drivers/gpu/drm/nouveau/nouveau_drv.h |6 +++---
drivers/gpu/drm/nouveau/nouveau_vm.c | 20 ++--
drivers/gpu/drm/nouveau/nouveau_vm.h | 18
Signed-off-by: Marcin Slusarz
---
drivers/gpu/drm/nouveau/nv50_graph.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nv50_graph.c
b/drivers/gpu/drm/nouveau/nv50_graph.c
index 6899547..a61853f 100644
--- a/drivers/gpu/drm/nouveau
waits
Signed-off-by: Marcin Slusarz
---
drivers/gpu/drm/nouveau/Makefile |2 +-
drivers/gpu/drm/nouveau/nouveau_bo.c |2 +-
drivers/gpu/drm/nouveau/nouveau_channel.c |5 +-
drivers/gpu/drm/nouveau/nouveau_drv.c | 56 ++-
drivers/gpu/drm/nouveau
On Wed, Apr 25, 2012 at 11:20:36PM +0200, Marcin Slusarz wrote:
> Overall idea:
> Detect lockups by watching for timeouts (vm flush / fence), return -EIOs,
> handle them at ioctl level, reset the GPU and repeat last ioctl.
>
> GPU reset is done by doing suspend / resume cycle
On Thu, Apr 26, 2012 at 05:32:29PM +1000, Ben Skeggs wrote:
> On Wed, 2012-04-25 at 23:20 +0200, Marcin Slusarz wrote:
> > Overall idea:
> > Detect lockups by watching for timeouts (vm flush / fence), return -EIOs,
> > handle them at ioctl level, reset the GPU and repeat las
On Thu, Aug 02, 2012 at 01:26:55PM +0200, Ortwin Gl?ck wrote:
> I have managed to turn the crash into a WARN_ON, by adding this to the
> begin of nouveau_software_vblank():
>
> if (!psw) {
> WARN_ON(1);
> return;
> }
Yes, I know about it, but t
On Mon, Dec 24, 2012 at 09:26:17PM +0100, balducci at units.it wrote:
> hello everybody,
>
> apologies if I am missing any blatant point; my knowledge about
> KMS/DRM etc. is very poor, so I am asking for help here (hoping to be
> at the right place)
>
> Starting with kernel-3.7 I am not able to
On Mon, Dec 31, 2012 at 03:34:59AM +0200, Aaro Koskinen wrote:
> Check that the AGP aperture can be mapped. This follows a similar change
> done for Radeon (commit 365048ff, drm/radeon: AGP memory is only I/O if
> the aperture can be mapped by the CPU.).
>
> The patch fixes the following error see
Hi
Since upgrade from 2.6.35 to 2.6.36-rc3 (nouveau tree) I'm hitting this bug a
couple of times a day:
[ 2869.618504] [ cut here ]
[ 2869.618532] kernel BUG at drivers/gpu/drm/ttm/ttm_bo.c:153!
[ 2869.618560] invalid opcode: [#1] PREEMPT SMP
[ 2869.618600] last sysf
On Sat, Sep 18, 2010 at 09:39:21AM +1000, Ben Skeggs wrote:
> On Fri, 2010-09-17 at 19:43 +0200, Marcin Slusarz wrote:
> > Hi
> > Since upgrade from 2.6.35 to 2.6.36-rc3 (nouveau tree) I'm hitting this bug
> > a couple of times a day:
> >
> >
On Fri, Sep 17, 2010 at 06:53:26PM -0400, Andy Walls wrote:
> On my system, every 10 seconds drm_edid_block_valid() gets called 4
> times by radeon_dvi_detect(). This results in 4 instances of a
> multi-line hex dump of the same EDID (non-)data being logged every 10
> seconds.
>
> Silence the hex
> If we let the ghost object inherit cpu_writers from the original
> object, ttm_bo_release_list() will raise a kernel BUG when the ghost
> object is destroyed. This can be reproduced with the nouveau driver on
> nv5x.
>
> Reported-by: Marcin Slusarz
> Signed-off-by: Francisc
On Thu, Apr 14, 2011 at 07:05:59PM +0200, Dominik Brodowski wrote:
> Thought about CCing Linus to show him that 2.6.39-rcX isn't as "calm"
> to everyone, but then chose to CC Maciej instead: Would you be so kind and
> add this to your regression list? Thanks!
>
> Since commit 38f1cff
>
> From
r 14, 2011 at 09:02:01PM +0200, Marcin Slusarz wrote:
> > > >> On Thu, Apr 14, 2011 at 07:05:59PM +0200, Dominik Brodowski wrote:
> > > >>> Thought about CCing Linus to show him that 2.6.39-rcX isn't as "calm"
> > > >>> to everyone, but
Dominik Brodowski wrote:
> > > > On Thu, Apr 14, 2011 at 09:02:01PM +0200, Marcin Slusarz wrote:
> > > >> On Thu, Apr 14, 2011 at 07:05:59PM +0200, Dominik Brodowski wrote:
> > > >>> Thought about CCing Linus to show him that 2.6.39-rcX isn't as "cal
On Sun, Apr 17, 2011 at 12:24:27PM -0400, Kyle Spaans wrote:
> On Sun, Apr 17, 2011 at 05:45:57PM +0200, Marcin Slusarz wrote:
> > On Sun, Apr 17, 2011 at 11:12:04AM -0400, Kyle Spaans wrote:
> > > On Sat, Apr 16, 2011 at 07:50:28PM -0400, Kyle Spaans wrote:
> > > >
On Sun, Apr 17, 2011 at 06:49:20PM +0200, Marcin Slusarz wrote:
> On Sun, Apr 17, 2011 at 12:24:27PM -0400, Kyle Spaans wrote:
> > On Sun, Apr 17, 2011 at 05:45:57PM +0200, Marcin Slusarz wrote:
> > > On Sun, Apr 17, 2011 at 11:12:04AM -0400, Kyle Spaans wrote:
> > > &
On Mon, Apr 18, 2011 at 04:09:11PM -0700, Joe Perches wrote:
> On Mon, 2011-04-18 at 16:01 -0700, Ian Romanick wrote:
> > > @@ -214,9 +214,9 @@ parse_lfp_panel_data(struct drm_i915_private
> > > *dev_priv,
> > > i915_lvds_downclock) {
> > > dev_priv->lvds_downclock_avail = 1;
> > >
On Mon, Apr 18, 2011 at 01:27:10PM -0700, Linus Torvalds wrote:
> On Mon, Apr 18, 2011 at 1:02 PM, Marcin Slusarz
> wrote:
> >
> > It's some nasty corruption:
>
> Looks like something wrote 0x to free'd memory.
>
> Enabling DEBUG
fy was always 0, so it didn't
matter it was a value in bytes).
Reported-by: Dominik Brodowski
Reported-by: Nigel Cunningham
Signed-off-by: Marcin Slusarz
Cc: Ben Skeggs
Cc: Pekka Paalanen
Cc: stable at kernel.org[2.6.38]
---
drivers/gpu/drm/nouveau/nouveau_fbcon.c |4 ++--
Commit 73412c3854c877e5f37ad944ee8977addde4d35a ("drm/nouveau: allocate
kernel's notifier object at end of block") intended to align end of
notifier block to page boundary, but start of block was miscalculated
to be off by -16 bytes. Fix it.
Signed-off-by: Marcin Slusarz
On Fri, Apr 29, 2011 at 01:57:10PM +1000, christopher.halse.rogers at
canonical.com wrote:
> From: Christopher James Halse Rogers canonical.com>
>
> v2: Also pull out the drm_vblank_put call.
> Signed-off-by: Christopher James Halse Rogers canonical.com>
> ---
> drivers/gpu/drm/drm_irq.c | 4
ttm_tt_destroy kfrees passed object, so we need to nullify
a reference to it.
Signed-off-by: Marcin Slusarz
Cc: stable at kernel.org
---
drivers/gpu/drm/ttm/ttm_bo.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm
le of xterms with
looped glxinfo.
Signed-off-by: Marcin Slusarz
Reviewed-by: Daniel Vetter
---
Updated changelog.
---
drivers/gpu/drm/drm_debugfs.c | 12 +---
drivers/gpu/drm/i915/i915_debugfs.c |5 -
include/drm/drmP.h |4 +++-
3 files changed, 16 inser
nouveau_irq_handler tries to take
dev_priv->context_switch_lock (spins)
deadlock
Possible solutions:
- reverting "drm/nouveau: use drm_mm in preference to custom code doing the
same thing"
- disabling interrupts before calling drm_mm functions - unmaintainable and
still
deadlock
On Sun, Jul 11, 2010 at 11:02:12AM +1000, Ben Skeggs wrote:
> On Sun, 2010-07-11 at 01:24 +0200, Marcin Slusarz wrote:
> > Hi
> >
> > Patch "drm/nouveau: use drm_mm in preference to custom code doing the same
> > thing"
> > in nouveau tree introduced
On Mon, Jul 26, 2010 at 07:15:47PM +0200, Francisco Jerez wrote:
> Marcin Slusarz writes:
>
> > On Sun, Jul 11, 2010 at 11:02:12AM +1000, Ben Skeggs wrote:
> >> On Sun, 2010-07-11 at 01:24 +0200, Marcin Slusarz wrote:
> >> > Hi
> >> >
> >
On Wed, Jul 28, 2010 at 01:42:03AM -0400, Valdis.Kletnieks at vt.edu wrote:
> On Tue, 27 Jul 2010 14:56:50 PDT, akpm at linux-foundation.org said:
> > The mm-of-the-moment snapshot 2010-07-27-14-56 has been uploaded to
> >
> >http://userweb.kernel.org/~akpm/mmotm/
>
> Hit this while the X ser
On Thu, Jul 29, 2010 at 08:02:31PM +0200, Dan Carpenter wrote:
> nouveau_load() just returned directly if there was an error instead of
> releasing resources.
>
> Signed-off-by: Dan Carpenter
Patch looks good, but could you base it on top of nouveau tree?
git://anongit.freedesktop.org/nouveau/
resources.
>
>
> Signed-off-by: Dan Carpenter
> ---
> V2: updated to the nouveau git tree.
Thanks.
Reviewed-by: Marcin Slusarz
> diff --git a/drivers/gpu/drm/nouveau/nouveau_state.c
> b/drivers/gpu/drm/nouveau/nouveau_state.c
> inde
uveau
initialisation.
Fix it by kicking firmware driver(s) before we start touching the hardware.
Reported-by: Didier Spaier
Tested-by: Didier Spaier
Signed-off-by: Marcin Slusarz
Cc: Ben Skeggs
Cc: Dave Airlie
Cc: Peter Jones
Cc: Andrew Morton
---
no changes since last submission
---
driver
let vga16fb claim 0xA+0x1 region as its aperture;
drm drivers don't use it, so we have to detect it and kick
vga16fb manually - but only if drm is driving the primary card
Signed-off-by: Marcin Slusarz
Cc: James Simmons
Cc: Dave Airlie
Cc: Ben Skeggs
---
no changes since
On Sat, Oct 02, 2010 at 09:58:56AM +0200, Jiri Slaby wrote:
> There are two messages in the ISR of nouvea which might be printed out
> hundred times in a second. Ratelimit them.
>
> Signed-off-by: Jiri Slaby
> Cc: Ben Skeggs
> ---
> drivers/gpu/drm/nouveau/nouveau_irq.c |9 ++---
> 1 fi
: Ben Skeggs
> Cc: Marcin Slusarz
FWIW
Reviewed-by: Marcin Slusarz
> ---
> drivers/gpu/drm/nouveau/nouveau_irq.c | 23 +--
> 1 files changed, 13 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_irq.c
> b/drivers/gpu/dr
On Wed, Oct 06, 2010 at 06:39:07PM +0200, Daniel Vetter wrote:
> From: Benjamin Herrenschmidt
>
> Without this, we attempt the handover too late, the firmware fb
> might be accessing the chip simultaneously to us re-initializing
> various parts of it, which might frighten babies or cause all sort
On Wed, Oct 06, 2010 at 08:54:12PM +0200, Daniel Vetter wrote:
> On Wed, Oct 06, 2010 at 08:20:15PM +0200, Marcin Slusarz wrote:
> > On Wed, Oct 06, 2010 at 06:39:07PM +0200, Daniel Vetter wrote:
> > > +static void radeon_kick_out_firmware_fb(struct drm_device *ddev)
>
On Sat, Oct 09, 2010 at 03:53:58PM +0200, Kai Ruhnau wrote:
> On 09/18/2010 01:18 PM, Marcin Slusarz wrote:
> > On Sat, Sep 18, 2010 at 09:39:21AM +1000, Ben Skeggs wrote:
> >> On Fri, 2010-09-17 at 19:43 +0200, Marcin Slusarz wrote:
> >>> Hi
> >>> Since
nd framebuffer registration when
> two drivers touch the hardware. Unfortunately sometimes it breaks nouveau
> initialisation.
>
> Fix it by kicking firmware driver(s) before we start touching the hardware.
>
> Reported-by: Didier Spaier
> Signed-off-by: Marcin Slusarz
> Cc: Ben
urrent code?
> Have you got a pointer to a machine where it fails?
No, it failed with an artifical test while I was working on vga16fb handoff
(unfinished).
> Dave.
>
>
> > Signed-off-by: Marcin Slusarz
> > Cc: Dave Airlie
> > Cc: Peter Jones
> > Cc: Andre
On Tue, Apr 13, 2010 at 06:28:21AM +1000, Dave Airlie wrote:
> On Mon, 2010-04-12 at 13:34 +0200, Marcin Slusarz wrote:
> > On Mon, Apr 12, 2010 at 09:54:28AM +1000, Dave Airlie wrote:
> > > On Sat, 2010-04-10 at 21:55 +0200, marcin.slusarz at gmail.com wrote:
> > > &
On Mon, Apr 12, 2010 at 11:33:27PM +0200, Marcin Slusarz wrote:
> > > > Have you got a pointer to a machine where it fails?
> > >
> > > No, it failed with an artifical test while I was working on vga16fb
> > > handoff
> > > (unfinished).
> >
On Tue, Apr 13, 2010 at 09:50:04PM +0200, Marcin Slusarz wrote:
> On Mon, Apr 12, 2010 at 11:33:27PM +0200, Marcin Slusarz wrote:
> > > > > Have you got a pointer to a machine where it fails?
> > > >
> > > > No, it failed with an artifical test while
> nothing prevents it right now)
> > - vga16fb registration error path is iounmapping memory which was not
> > ioremapped.
> > I'm going to fix it soon.
>
> Nak. See comments below.
Thanks for a review.
> > ---
> > From: Marcin Slusarz
> > Subj
tical.
There's no need to change these strings. Nouveau prints chipset id earlier.
For patch with only kfrees:
Reviewed-by: Marcin Slusarz
> Signed-off-by: Jesper Juhl
> ---
> drivers/gpu/drm/nouveau/nv20_graph.c |4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
101 - 200 of 239 matches
Mail list logo
