On Tue, Sep 22, 2015 at 09:15:58AM -0700, Matt Roper wrote:
> On Tue, Sep 22, 2015 at 05:13:55PM +0200, Daniel Vetter wrote:
> > On Tue, Sep 22, 2015 at 08:00:17AM -0700, Jesse Barnes wrote:
> > > Cc'ing Maarten and Matt; I'm guessing this may be related to one of
> > > their recent patches.
>
On Mon, Sep 07, 2015 at 02:45:59PM -0400, Dave Jones wrote:
> On Fri, Sep 04, 2015 at 11:40:53PM +0100, Dave Airlie wrote:
> >
> > Hi Linus,
> >
> > This is the main pull request for the drm for 4.3. Nouveau is probably
> the biggest
> > amount
On Fri, Sep 04, 2015 at 11:40:53PM +0100, Dave Airlie wrote:
>
> Hi Linus,
>
> This is the main pull request for the drm for 4.3. Nouveau is probably the
> biggest
> amount of changes in here, since it missed 4.2. Highlights below, along with
> the usual
> bunch of fixes. There are a fe
I finally got around to playing with kasan. It didn't end well.
I added some debugging to validate_cmds_sorted to print out the table
sizes right before the stack traces.
Dave
validate_cmds_sorted: table:a1fb4220 cmd_table_count:3
validate_cmds_sorted: table:a1fb4220 tabl
On Mon, Jul 06, 2015 at 04:56:19PM -0400, Alex Deucher wrote:
> On Mon, Jul 6, 2015 at 3:19 PM, Dave Jones
> wrote:
> > I wanted to switch my LCD to a different machine momentarily.
> > When I plugged the cable back in, this was on the screen..
>
> Is this readil
I wanted to switch my LCD to a different machine momentarily.
When I plugged the cable back in, this was on the screen..
WARNING: CPU: 1 PID: 209 at kernel/locking/mutex.c:526
__mutex_lock_slowpath+0x322/0x340()
DEBUG_LOCKS_WARN_ON(l->magic != l)
CPU: 1 PID: 209 Comm: kworker/1:3 Not tainted 4.2.
I was just browsing with chrome, and X locked up.
When I flipped to tty1, I saw a flood of these message..
kernel: [ 6800.937575] radeon :01:00.0: bo 88080859ec00 don't has a
mapping in vm 8808085c6600
kernel: [ 6800.948242] radeon :01:00.0: bo 88080859ec00 don't has a
mappin
On Fri, May 15, 2015 at 06:16:59PM +0900, Michel Dänzer wrote:
> On 15.05.2015 12:52, Dave Jones wrote:
> >
> > The only remaining problem is there are some visible glitches, mostly
> > noticable
> > while scrolling a terminal.
>
> What kind of glitch
On Thu, May 14, 2015 at 09:49:52AM -0400, Alex Deucher wrote:
> On Tue, May 12, 2015 at 8:04 PM, Dave Jones
> wrote:
> > On Mon, May 11, 2015 at 03:59:55PM -0400, Alex Deucher wrote:
> >
> > > > I tried tweaking the delays in
> > drm_dp_link_tra
On Thu, May 14, 2015 at 09:49:52AM -0400, Alex Deucher wrote:
> On Tue, May 12, 2015 at 8:04 PM, Dave Jones
> wrote:
> > On Mon, May 11, 2015 at 03:59:55PM -0400, Alex Deucher wrote:
> >
> > > > I tried tweaking the delays in
> > drm_dp_link_tra
On Mon, May 11, 2015 at 03:59:55PM -0400, Alex Deucher wrote:
> > I tried tweaking the delays in drm_dp_link_train_clock_recovery_delay,
> > without any noticable
> > difference. Is there something else I can try to make it try harder
> > before giving up?
> >
>
> Can you attach your bo
On Mon, May 11, 2015 at 03:59:55PM -0400, Alex Deucher wrote:
> Can you attach your boot dmesg output with drm.debug=0xf set?
Strange, haven't seen this happen before.
[8.437431] [drm:drm_calc_vbltimestamp_from_scanoutpos] crtc 5: Noop due to
uninitialized mode.
[8.437433] [drm:drm_upd
On Mon, May 11, 2015 at 03:59:55PM -0400, Alex Deucher wrote:
> > > > The link training with the monitor seems to fail periodically. You
> > may have to play with the timing in the link training sequence. It looks
> > like you also have some power management related issues. Does booting
On Fri, May 08, 2015 at 11:40:55AM -0400, Dave Jones wrote:
> On Fri, May 08, 2015 at 01:23:59PM +, Deucher, Alexander wrote:
> > > I just bought a new radeon (1002:682c), to pair with my shiny new
> displayport
> > > monitor.
> > > It shows a dis
On Fri, May 08, 2015 at 01:23:59PM +, Deucher, Alexander wrote:
> > -Original Message-
> > From: Dave Jones [mailto:davej at codemonkey.org.uk]
> > Sent: Thursday, May 07, 2015 7:48 PM
> > To: dri-devel at lists.freedesktop.org
> > Cc: Deucher
I just bought a new radeon (1002:682c), to pair with my shiny new displayport
monitor.
It shows a display during through the BIOS POST, and grub, but when the kernel
starts up, it's a coin toss whether or not I get anything.
Sometimes it just goes straight into power saving.
When I do get somethi
On Wed, Mar 25, 2015 at 09:56:28AM +0100, Daniel Vetter wrote:
> > I've started seeing this one too as of rc5.
> > Along with..
>
> Yeah we're freeing memory too early with these bugs. To get up to the
> current debug state can you please cherry-pick
>
> commit f55548b5af87ebfc586ca757489
On Mon, Mar 23, 2015 at 11:33:42AM -0400, Josh Boyer wrote:
> I have a machine that no longer boots in a headless manner with -rc5.
> It's an Celeron based NUC device. I blacklisted the i915 driver and
> it boots fine, then I ran insmod manually and got the backtrace below.
> This machine onl
The irony here of the hung task detector triggering a locking disaster.
The laptop hung completely after spewing this partial trace.
[11881.16] ==
[11881.16] [ INFO: possible circular locking dependency detected ]
[11881.16] 3.19.0-rc
This is set and compared to -1 in the code, which evaluates to always false.
If we want to treat it as a signed var, we should declare it as one.
Signed-off-by: Dave Jones
diff --git a/drivers/gpu/drm/nouveau/core/subdev/devinit/nv04.h
b/drivers/gpu/drm/nouveau/core/subdev/devinit/nv04.h
index
On Thu, Jan 30, 2014 at 05:58:38PM +0100, Daniel Vetter wrote:
> This regression has been introduced in
>
> commit b3f2333de8e81b089262b26d52272911523e605f
> Author: Daniel Vetter
> Date: Wed Dec 11 11:34:31 2013 +0100
>
> drm: restrict the device list for shadow attached drivers
>
This code appears to be calling psb_gtt_free_range twice with the same args.
(The second call didn't appear in the diff output, it's right after the
mutex_unlock)
Spotted with Coverity, not tested due to lack of hardware.
Signed-off-by: Dave Jones
diff --git a/drivers/gpu/
On Thu, Aug 29, 2013 at 06:35:22AM +1000, Dave Airlie wrote:
> On Thu, Aug 29, 2013 at 6:30 AM, Dave Jones wrote:
> > On Mon, Aug 05, 2013 at 09:40:33AM +0200, Daniel Vetter wrote:
> > > On Mon, Jul 29, 2013 at 08:53:35PM -0400, Dave Jones wrote:
> > > > On M
On Mon, Aug 05, 2013 at 09:40:33AM +0200, Daniel Vetter wrote:
> On Mon, Jul 29, 2013 at 08:53:35PM -0400, Dave Jones wrote:
> > On Mon, Jun 17, 2013 at 09:49:27PM -0400, David Airlie wrote:
> > >
> > > > Reading /proc/dri/0/vma causes bad things to happ
On Thu, Aug 29, 2013 at 06:35:22AM +1000, Dave Airlie wrote:
> On Thu, Aug 29, 2013 at 6:30 AM, Dave Jones wrote:
> > On Mon, Aug 05, 2013 at 09:40:33AM +0200, Daniel Vetter wrote:
> > > On Mon, Jul 29, 2013 at 08:53:35PM -0400, Dave Jones wrote:
> > > > On M
On Mon, Aug 05, 2013 at 09:40:33AM +0200, Daniel Vetter wrote:
> On Mon, Jul 29, 2013 at 08:53:35PM -0400, Dave Jones wrote:
> > On Mon, Jun 17, 2013 at 09:49:27PM -0400, David Airlie wrote:
> > >
> > > > Reading /proc/dri/0/vma causes bad things to happ
On Mon, Jun 17, 2013 at 09:49:27PM -0400, David Airlie wrote:
>
> > Reading /proc/dri/0/vma causes bad things to happen on a box with nouveau
> > loaded.
> > (Note, no X running on that box)
> >
> > Trace below shows trinity, but I can reproduce it with just cat
> > /proc/dri/0/vma
>
>
On Mon, Jun 17, 2013 at 09:49:27PM -0400, David Airlie wrote:
>
> > Reading /proc/dri/0/vma causes bad things to happen on a box with nouveau
> > loaded.
> > (Note, no X running on that box)
> >
> > Trace below shows trinity, but I can reproduce it with just cat
> > /proc/dri/0/vma
>
>
On Mon, Jun 17, 2013 at 09:49:27PM -0400, David Airlie wrote:
>
> > Reading /proc/dri/0/vma causes bad things to happen on a box with nouveau
> > loaded.
> > (Note, no X running on that box)
> >
> > Trace below shows trinity, but I can reproduce it with just cat
> > /proc/dri/0/vma
>
>
On Mon, Jun 17, 2013 at 09:49:27PM -0400, David Airlie wrote:
>
> > Reading /proc/dri/0/vma causes bad things to happen on a box with nouveau
> > loaded.
> > (Note, no X running on that box)
> >
> > Trace below shows trinity, but I can reproduce it with just cat
> > /proc/dri/0/vma
>
>
On Sun, Mar 17, 2013 at 08:50:03PM +0100, Daniel Vetter wrote:
> Doesn't that mean that we need these checks everywhere? Or at least a
> fixup in drm core proper?
>
> And I think we need to add trinity to our test setup eventually ;-)
Note that trinity's ioctl fuzzing is still very new (adde
On Sun, Mar 17, 2013 at 08:50:03PM +0100, Daniel Vetter wrote:
> Doesn't that mean that we need these checks everywhere? Or at least a
> fixup in drm core proper?
>
> And I think we need to add trinity to our test setup eventually ;-)
Note that trinity's ioctl fuzzing is still very new (adde
On Wed, May 30, 2012 at 05:58:48PM -0400, Dave Jones wrote:
> On Wed, May 30, 2012 at 11:51:54PM +0200, Daniel Vetter wrote:
> > On Wed, May 30, 2012 at 11:31 PM, Dave Jones wrote:
> > > On this hardware:
> > >
> > > 00:02.0 VGA compatible con
On Wed, May 30, 2012 at 11:51:54PM +0200, Daniel Vetter wrote:
> On Wed, May 30, 2012 at 11:31 PM, Dave Jones wrote:
> > On this hardware:
> >
> > 00:02.0 VGA compatible controller: Intel Corporation 82945G/GZ Integrated
> > Graphics Controller (rev 02)
> >
On this hardware:
00:02.0 VGA compatible controller: Intel Corporation 82945G/GZ Integrated
Graphics Controller (rev 02)
I get this every boot with Linus current tree (up to
af56e0aa35f3ae2a4c1a6d1000702df1dd78cb76)
[8.046291] udevadm used greatest stack depth: 4952 bytes left
[8.15320
On Wed, May 30, 2012 at 05:58:48PM -0400, Dave Jones wrote:
> On Wed, May 30, 2012 at 11:51:54PM +0200, Daniel Vetter wrote:
> > On Wed, May 30, 2012 at 11:31 PM, Dave Jones wrote:
> > > On this hardware:
> > >
> > > 00:02.0 VGA compatible con
On Wed, May 30, 2012 at 11:51:54PM +0200, Daniel Vetter wrote:
> On Wed, May 30, 2012 at 11:31 PM, Dave Jones wrote:
> > On this hardware:
> >
> > 00:02.0 VGA compatible controller: Intel Corporation 82945G/GZ Integrated
> > Graphics Controller (rev 02)
> >
On this hardware:
00:02.0 VGA compatible controller: Intel Corporation 82945G/GZ Integrated
Graphics Controller (rev 02)
I get this every boot with Linus current tree (up to
af56e0aa35f3ae2a4c1a6d1000702df1dd78cb76)
[8.046291] udevadm used greatest stack depth: 4952 bytes left
[8.15320
On Tue, Mar 27, 2012 at 10:20:21AM +0200, Michel Dänzer wrote:
> On Die, 2012-03-27 at 17:21 +1100, Benjamin Herrenschmidt wrote:
> > On Mon, 2012-03-26 at 17:32 -0400, Dave Jones wrote:
> > > Seeing this in Linus' tree as of v3.3-6972-ge22057c
> &g
On Tue, Mar 27, 2012 at 10:20:21AM +0200, Michel D?nzer wrote:
> On Die, 2012-03-27 at 17:21 +1100, Benjamin Herrenschmidt wrote:
> > On Mon, 2012-03-26 at 17:32 -0400, Dave Jones wrote:
> > > Seeing this in Linus' tree as of v3.3-6972-ge22057c
> &g
On Sun, Aug 28, 2011 at 08:22:05PM +0200, Rafael J. Wysocki wrote:
> Bug-Entry: http://bugzilla.kernel.org/show_bug.cgi?id=41742
> Subject : duplicate filename for intel_backlight with the i915
> driver
> Submitter: François Valenduc
> Date : 2011-08-25 18:51
On Sun, Aug 28, 2011 at 08:22:05PM +0200, Rafael J. Wysocki wrote:
> Bug-Entry: http://bugzilla.kernel.org/show_bug.cgi?id=41742
> Subject : duplicate filename for intel_backlight with the i915
> driver
> Submitter: Fran?ois Valenduc
> Date : 2011-08-25 18:51 (
42 matches
Mail list logo
