[regression] [git pull] drm for 4.3

[Dave Jones]

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.
 > 
 > Sounds like this showed up before my recent work, but I think I might
 > have seen similar problems while working on atomic watermarks; the
 > issues I was seeing were because the initial hardware readout could
 > leave primary->visible set to true even when the CRTC was off.  My
 > series (which is still under development) contains this patch to fix
 > that:
 > 
 > http://patchwork.freedesktop.org/patch/59564/
 > 
 > Does applying that help with the problems reported here?

No difference at all for me.

Dave

[git pull] drm for 4.3

[Dave Jones]

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 of changes in here, since it missed 4.2. Highlights below, along 
 > with the usual
 >  > bunch of fixes. There are a few minor conflicts with your tree but 
 > nothing 
 >  > you can't handle. All stuff outside drm should have applicable acks.
 >  > 
 >  > Highlights:
 >  > 
 >  > ...
 >  > i915:
 >  >   Skylake support enabled by default
 >  >   legacy modesetting using atomic infrastructure
 >  >   Skylake fixes
 >  >   GEN9 workarounds
 > 
 > Since this merge, I'm seeing this twice during boot..

And still there in -rc2.  Several other people reported this too,
and they also got no reponse.

I'll start bisecting when I get home tonight. It shouldn't be too hard,
as 4.2 was fine.

Dave

 > [ cut here ]
 > WARNING: CPU: 0 PID: 6 at drivers/gpu/drm/i915/intel_display.c:1377 
 > assert_planes_disabled+0xdf/0x140()
 > plane A assertion failure, should be disabled but not
 > CPU: 0 PID: 6 Comm: kworker/u8:0 Not tainted 4.2.0-think+ #9
 > Workqueue: events_unbound async_run_entry_fn
 >  0561 88050392b6f8 8d7dccce 88050392b740
 >  88050392b730 8d079ee2 880500a6 
 >    8805008e99c8 88050392b790
 > Call Trace:
 >  [] dump_stack+0x4e/0x79
 >  [] warn_slowpath_common+0x82/0xc0
 >  [] warn_slowpath_fmt+0x4c/0x50
 >  [] assert_planes_disabled+0xdf/0x140
 >  [] intel_disable_pipe+0x4b/0x2c0
 >  [] haswell_crtc_disable+0x8a/0x2e0
 >  [] intel_atomic_commit+0xff/0x1320
 >  [] ? drm_atomic_check_only+0x21e/0x550
 >  [] drm_atomic_commit+0x37/0x60
 >  [] drm_atomic_helper_set_config+0x1c5/0x430
 >  [] drm_mode_set_config_internal+0x65/0x110
 >  [] restore_fbdev_mode+0xbe/0xe0
 >  [] drm_fb_helper_restore_fbdev_mode_unlocked+0x25/0x70
 >  [] drm_fb_helper_set_par+0x2d/0x50
 >  [] intel_fbdev_set_par+0x1a/0x60
 >  [] fbcon_init+0x545/0x5d0
 >  [] visual_init+0xca/0x130
 >  [] do_bind_con_driver+0x1c5/0x3b0
 >  [] do_take_over_console+0x149/0x1a0
 >  [] do_fbcon_takeover+0x57/0xb0
 >  [] fbcon_event_notify+0x66c/0x760
 >  [] notifier_call_chain+0x3e/0xb0
 >  [] __blocking_notifier_call_chain+0x4d/0x70
 >  [] blocking_notifier_call_chain+0x16/0x20
 >  [] fb_notifier_call_chain+0x1b/0x20
 >  [] register_framebuffer+0x1e7/0x300
 >  [] drm_fb_helper_initial_config+0x252/0x3e0
 >  [] intel_fbdev_initial_config+0x1b/0x20
 >  [] async_run_entry_fn+0x4a/0x140
 >  [] process_one_work+0x1fd/0x670
 >  [] ? process_one_work+0x16c/0x670
 >  [] worker_thread+0x4e/0x450
 >  [] ? process_one_work+0x670/0x670
 >  [] kthread+0x101/0x120
 >  [] ? kthread_create_on_node+0x250/0x250
 >  [] ret_from_fork+0x3f/0x70
 >  [] ? kthread_create_on_node+0x250/0x250
 > ---[ end trace 54cab2e0c772d5d9 ]---
 > 
 > 
 > 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3 
 > Processor Integrated Graphics Controller (rev 06)

[git pull] drm for 4.3

[Dave Jones]

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 few minor conflicts with your tree but nothing 
 > you can't handle. All stuff outside drm should have applicable acks.
 > 
 > Highlights:
 > 
 > ...
 > i915:
 >  Skylake support enabled by default
 >  legacy modesetting using atomic infrastructure
 >  Skylake fixes
 >  GEN9 workarounds

Since this merge, I'm seeing this twice during boot..


[ cut here ]
WARNING: CPU: 0 PID: 6 at drivers/gpu/drm/i915/intel_display.c:1377 
assert_planes_disabled+0xdf/0x140()
plane A assertion failure, should be disabled but not
CPU: 0 PID: 6 Comm: kworker/u8:0 Not tainted 4.2.0-think+ #9
Workqueue: events_unbound async_run_entry_fn
 0561 88050392b6f8 8d7dccce 88050392b740
 88050392b730 8d079ee2 880500a6 
   8805008e99c8 88050392b790
Call Trace:
 [] dump_stack+0x4e/0x79
 [] warn_slowpath_common+0x82/0xc0
 [] warn_slowpath_fmt+0x4c/0x50
 [] assert_planes_disabled+0xdf/0x140
 [] intel_disable_pipe+0x4b/0x2c0
 [] haswell_crtc_disable+0x8a/0x2e0
 [] intel_atomic_commit+0xff/0x1320
 [] ? drm_atomic_check_only+0x21e/0x550
 [] drm_atomic_commit+0x37/0x60
 [] drm_atomic_helper_set_config+0x1c5/0x430
 [] drm_mode_set_config_internal+0x65/0x110
 [] restore_fbdev_mode+0xbe/0xe0
 [] drm_fb_helper_restore_fbdev_mode_unlocked+0x25/0x70
 [] drm_fb_helper_set_par+0x2d/0x50
 [] intel_fbdev_set_par+0x1a/0x60
 [] fbcon_init+0x545/0x5d0
 [] visual_init+0xca/0x130
 [] do_bind_con_driver+0x1c5/0x3b0
 [] do_take_over_console+0x149/0x1a0
 [] do_fbcon_takeover+0x57/0xb0
 [] fbcon_event_notify+0x66c/0x760
 [] notifier_call_chain+0x3e/0xb0
 [] __blocking_notifier_call_chain+0x4d/0x70
 [] blocking_notifier_call_chain+0x16/0x20
 [] fb_notifier_call_chain+0x1b/0x20
 [] register_framebuffer+0x1e7/0x300
 [] drm_fb_helper_initial_config+0x252/0x3e0
 [] intel_fbdev_initial_config+0x1b/0x20
 [] async_run_entry_fn+0x4a/0x140
 [] process_one_work+0x1fd/0x670
 [] ? process_one_work+0x16c/0x670
 [] worker_thread+0x4e/0x450
 [] ? process_one_work+0x670/0x670
 [] kthread+0x101/0x120
 [] ? kthread_create_on_node+0x250/0x250
 [] ret_from_fork+0x3f/0x70
 [] ? kthread_create_on_node+0x250/0x250
---[ end trace 54cab2e0c772d5d9 ]---


00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3 Processor 
Integrated Graphics Controller (rev 06)

i915/kasan: out of bounds access in i915_cmd_parser_init_ring

[Dave Jones]

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 table->count:12
validate_cmds_sorted: table:a1fb4230 table->count:20
validate_cmds_sorted: table:a1fb4230 table->count:20
validate_cmds_sorted: table:a1fb4240 table->count:18
validate_cmds_sorted: table:a1fb41e0 cmd_table_count:2
validate_cmds_sorted: table:a1fb41e0 table->count:12
validate_cmds_sorted: table:a1fb41f0 table->count:7
validate_cmds_sorted: table:a1fb4100 cmd_table_count:3
validate_cmds_sorted: table:a1fb4100 table->count:12
validate_cmds_sorted: table:a1fb4110 table->count:6
==
BUG: KASan: out of bounds access in i915_cmd_parser_init_ring+0x66b/0x760 at 
addr a1fb4374
Read of size 4 by task swapper/0/1
Address belongs to variable hsw_blt_cmds+0xb4/0xe0
CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.2.0-rc6-firewall+ #4
 0002 8801d6baf478 a1c0b4fb 0032
 8801d6baf510 8801d6baf4f8 a123198f 8801d6baf5a8
 ed003ad75e9b 0246 a1fb4110 1000
Call Trace:
 [] dump_stack+0x4f/0x7b
 [] kasan_report_error+0x3bf/0x3f0
 [] kasan_report+0x3b/0x40
 [] ? i915_cmd_parser_init_ring+0x66b/0x760
 [] __asan_load4+0x66/0xa0
 [] i915_cmd_parser_init_ring+0x66b/0x760
 [] intel_init_ring_buffer+0x449/0x680
 [] intel_init_blt_ring_buffer+0x38e/0x520
 [] i915_gem_init_rings+0x74/0x220
 [] i915_gem_init+0x1e2/0x320
 [] i915_driver_load+0x1571/0x2310
 [] ? debug_lockdep_rcu_enabled+0x4e/0x70
 [] ? __lock_acquire+0x97e/0x2710
 [] ? debug_smp_processor_id+0x17/0x20
 [] ? debug_show_all_locks+0x280/0x280
 [] ? __mutex_unlock_slowpath+0x11b/0x1e0
 [] ? trace_hardirqs_on_caller+0x192/0x2a0
 [] ? i915_getparam+0x390/0x390
 [] ? mark_held_locks+0xa4/0xd0
 [] ? _raw_spin_unlock_irqrestore+0x58/0x70
 [] ? trace_hardirqs_on_caller+0x192/0x2a0
 [] ? preempt_count_sub+0xc1/0x130
 [] ? _raw_spin_unlock_irqrestore+0x43/0x70
 [] drm_dev_register+0xd1/0x170
 [] drm_get_pci_dev+0xf1/0x350
 [] ? trace_hardirqs_on_caller+0x192/0x2a0
 [] i915_pci_probe+0x83/0xb0
 [] pci_device_probe+0xcf/0x130
 [] driver_probe_device+0x1e1/0x410
 [] ? driver_probe_device+0x410/0x410
 [] ? driver_probe_device+0x410/0x410
 [] __driver_attach+0xd6/0xe0
 [] bus_for_each_dev+0xf5/0x160
 [] ? bus_remove_file+0xa0/0xa0
 [] ? do_raw_spin_unlock+0xa4/0x140
 [] ? preempt_count_sub+0xc1/0x130
 [] driver_attach+0x30/0x40
 [] bus_add_driver+0x2b1/0x330
 [] driver_register+0xde/0x1b0
 [] __pci_register_driver+0xbc/0xd0
 [] drm_pci_init+0x1e7/0x210
 [] ? do_one_initcall+0x108/0x242
 [] ? do_one_initcall+0x108/0x242
 [] i915_init+0xdb/0xe3
 [] ? mipi_dsi_bus_init+0x12/0x12
 [] do_one_initcall+0x227/0x242
 [] ? start_kernel+0x4ed/0x4ed
 [] ? parse_args+0x5b/0x4f0
 [] kernel_init_freeable+0x290/0x321
 [] ? rest_init+0x150/0x150
 [] kernel_init+0x14/0x100
 [] ? rest_init+0x150/0x150
 [] ret_from_fork+0x3f/0x70
 [] ? rest_init+0x150/0x150
Memory state around the buggy address:
 a1fb4200: fa fa fa fa 00 00 00 00 00 00 fa fa fa fa fa fa
 a1fb4280: 00 00 00 00 fa fa fa fa 00 00 00 00 00 00 00 00
>a1fb4300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fa fa
 ^
 a1fb4380: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 00 00
 a1fb4400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==
==
BUG: KASan: out of bounds access in i915_cmd_parser_init_ring+0x67e/0x760 at 
addr a1fb4378
Read of size 4 by task swapper/0/1
Address belongs to variable hsw_blt_cmds+0xb8/0xe0
CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.2.0-rc6-firewall+ #4
 0002 8801d6baf478 a1c0b4fb 0032
 8801d6baf510 8801d6baf4f8 a123198f 0010
 ed00 0246 fbfff43f686e 66201000
Call Trace:
 [] dump_stack+0x4f/0x7b
 [] kasan_report_error+0x3bf/0x3f0
 [] kasan_report+0x3b/0x40
 [] ? i915_cmd_parser_init_ring+0x67e/0x760
 [] __asan_load4+0x66/0xa0
 [] i915_cmd_parser_init_ring+0x67e/0x760
 [] intel_init_ring_buffer+0x449/0x680
 [] intel_init_blt_ring_buffer+0x38e/0x520
 [] i915_gem_init_rings+0x74/0x220
 [] i915_gem_init+0x1e2/0x320
 [] i915_driver_load+0x1571/0x2310
 [] ? debug_lockdep_rcu_enabled+0x4e/0x70
 [] ? __lock_acquire+0x97e/0x2710
 [] ? debug_smp_processor_id+0x17/0x20
 [] ? debug_show_all_locks+0x280/0x280
 [] ? __mutex_unlock_slowpath+0x11b/0x1e0
 [] ? trace_hardirqs_on_caller+0x192/0x2a0
 [] ? i915_getparam+0x390/0x390
 [] ? mark_held_locks+0xa4/0xd0
 [] ? 

radeon: 4.2-rc1 warning when unplugging DVI

[Dave Jones]

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 readily reproducible? 

I just did a half-dozen unplug/replugs without triggering it, so unfortunatly 
not..

Dave 

radeon: 4.2-rc1 warning when unplugging DVI

[Dave Jones]

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.0-rc1-gelk-debug+ #1
Workqueue: events radeon_hotplug_work_func [radeon]
 0009 8800b160bc78 9969fad4 8001
 8800b160bcc8 8800b160bcb8 9907689a 86be
 8800a24182b8 8800a24182c0 8800b086adc0 8800a24182b8
Call Trace:
 [] dump_stack+0x4f/0x7b
 [] warn_slowpath_common+0x8a/0xc0
 [] warn_slowpath_fmt+0x46/0x50
 [] __mutex_lock_slowpath+0x322/0x340
 [] mutex_lock+0x2c/0x40
 [] radeon_hotplug_work_func+0x26/0x80 [radeon]
 [] process_one_work+0x147/0x420
 [] worker_thread+0x69/0x470
 [] ? preempt_count_sub+0xa3/0xf0
 [] ? rescuer_thread+0x320/0x320
 [] kthread+0x107/0x120
 [] ? kthread_create_on_node+0x1b0/0x1b0
 [] ret_from_fork+0x3f/0x70
 [] ? kthread_create_on_node+0x1b0/0x1b0
---[ end trace 859b3faf9cb20dd3 ]---
Oops:  [#1] PREEMPT SMP DEBUG_PAGEALLOC 
CPU: 1 PID: 209 Comm: kworker/1:3 Tainted: GW   
4.2.0-rc1-gelk-debug+ #1
Workqueue: events radeon_hotplug_work_func [radeon]
task: 8800b086adc0 ti: 8800b1608000 task.ti: 8800b1608000
RIP: 0010:[]  [] __list_add+0x1f/0xc0
RSP: 0018:8800b160bcf8  EFLAGS: 00010046
RAX: 8800a24182d8 RBX: 8800b160bd38 RCX: 
RDX: 8800a24182d8 RSI:  RDI: 8800b160bd38
RBP: 8800b160bd18 R08:  R09: 0fcb
R10: 0353 R11:  R12: 8800a24182d8
R13:  R14:  R15: 0246
FS:  () GS:8800bf70() knlGS:
CS:  0010 DS:  ES:  CR0: 8005003b
CR2:  CR3: a25d3000 CR4: 07e0
Stack:
 8800b160bd18 8800a24182b8 8800a24182c0 8800b086adc0
 8800b160bd88 996a5291 8800b160bd58 8800a24182d8
 8800b160bd38 8800b160bd38  8800b160bd38
Call Trace:
 [] __mutex_lock_slowpath+0xc1/0x340
 [] mutex_lock+0x2c/0x40
 [] radeon_hotplug_work_func+0x26/0x80 [radeon]
 [] process_one_work+0x147/0x420
 [] worker_thread+0x69/0x470
 [] ? preempt_count_sub+0xa3/0xf0
 [] ? rescuer_thread+0x320/0x320
 [] kthread+0x107/0x120
 [] ? kthread_create_on_node+0x1b0/0x1b0
 [] ret_from_fork+0x3f/0x70
 [] ? kthread_create_on_node+0x1b0/0x1b0
Code: c3 66 2e 0f 1f 84 00 00 00 00 00 90 55 48 89 e5 41 55 49 89 f5 41 54 49 
89 d4 53 48 89 fb 48 83 ec 08 4c 8b 42 08 49 39 f0 75 2e <4d> 8b 45 00 4d 39 c4 
75 4e 4c 39 e3 74 6b 4c 39 eb 74 66 49 89 


radeon is an RV370.

Dave

4.2rc0 "bo don't have a message" flood.

[Dave Jones]

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 
mapping in vm 8808085c6600
kernel: [ 6800.948393] radeon :01:00.0: bo 88080859ec00 don't has a 
mapping in vm 8808085c6600

over nad over..

This is with Linus' kernel tree from sometime yesterday.

01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] 
Device 682c

Dave

Radeon Verde displayport failure.

[Dave Jones]

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 glitches? If it's tearing, with current xf86-video-ati Git
 > you can try Option "TearFree".

Hard to describe, just sort of.. bursts of coloured sparkle noise in
random positions.
They don't remain part of the image permanently, and only appear for a
split second. They are pretty constant when scrolling though.

I'll see if I can get video of it when I'm in front of it again on Monday.

One other bug I noticed: Once it goes into DPMS, I can't wake it up again
and need to reboot. Likewise if I power off the monitor and back on,
it goes into power saving again.

Dave

Radeon Verde displayport failure.

[Dave Jones]

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_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 boot dmesg output with drm.debug=0xf set?
 > >  >
 > >  > You might also check the dpcd values in the driver during boot up and
 > >  > link training.  There appears to be an issue where that data gets
 > >  > corrupted in some cases:
 > >  > https://bugs.freedesktop.org/show_bug.cgi?id=73530
 > >
 > > I tried both the 'disable spread spectrum' and 'grab dpcd info from vbios 
 > > for eDP'
 > > patches from that bug. Again, no obvious difference.
 > >
 > > Log from kernel with both applied attached.
 > >
 > > Also a log file from after I woke up the LCD when it was in sleep mode.
 > >
 > > Something else curious is how it only discovers a maximum mode from the LCD
 > > of 1024x768.
 > 
 > I looks like the monitor is not responding.  I'm not entirely sure
 > what's going on.  I posted a new debugging patch on the bug report
 > that will dump the dpcd at various times to see if and when it's
 > getting corrupt.  Fixing that should at least get the monitor to come
 > up reliably (assuming you are experiencing the same issue).

Thanks to some back-and-forth on irc, airlied got this mostly working.
The working combo seems to be..

- Switch monitor to DP 1.2
- boot with radeon.mst=1
- apply the patch below

With all that, it boots up, and X starts up in 2560x1440 like it should.

The only remaining problem is there are some visible glitches, mostly noticable
while scrolling a terminal.

Happy to continue applying further debug patches if you have any more ideas.

thanks,
Dave


diff --git a/drivers/gpu/drm/radeon/radeon_dp_auxch.c 
b/drivers/gpu/drm/radeon/radeon_dp_auxch.c
index bf1fecc6cceb..3b401cc8d209 100644
--- a/drivers/gpu/drm/radeon/radeon_dp_auxch.c
+++ b/drivers/gpu/drm/radeon/radeon_dp_auxch.c
@@ -30,7 +30,6 @@
AUX_SW_RX_HPD_DISCON |   \
AUX_SW_RX_PARTIAL_BYTE | \
AUX_SW_NON_AUX_MODE |\
-   AUX_SW_RX_MIN_COUNT_VIOL |   \
AUX_SW_RX_INVALID_STOP | \
AUX_SW_RX_SYNC_INVALID_L |   \
AUX_SW_RX_SYNC_INVALID_H |   \

Radeon Verde displayport failure.

[Dave Jones]

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_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 boot dmesg output with drm.debug=0xf set?
 > >  >
 > >  > You might also check the dpcd values in the driver during boot up and
 > >  > link training.  There appears to be an issue where that data gets
 > >  > corrupted in some cases:
 > >  > https://bugs.freedesktop.org/show_bug.cgi?id=73530
 > >
 > > I tried both the 'disable spread spectrum' and 'grab dpcd info from vbios 
 > > for eDP'
 > > patches from that bug. Again, no obvious difference.
 > >
 > > Log from kernel with both applied attached.
 > >
 > > Also a log file from after I woke up the LCD when it was in sleep mode.
 > >
 > > Something else curious is how it only discovers a maximum mode from the LCD
 > > of 1024x768.
 > 
 > I looks like the monitor is not responding.  I'm not entirely sure
 > what's going on.  I posted a new debugging patch on the bug report
 > that will dump the dpcd at various times to see if and when it's
 > getting corrupt.  Fixing that should at least get the monitor to come
 > up reliably (assuming you are experiencing the same issue).

attached.

Dave

-- next part --
[7.071367] [drm] Initialized drm 1.1.0 20060810
[7.096163] [drm] radeon kernel modesetting enabled.
[7.096206] [drm:drm_pci_init] 
[7.096301] [drm:drm_get_pci_dev] 
[7.096385] [drm:drm_minor_register] 
[7.098055] [drm:drm_minor_register] new minor registered 64
[7.098065] [drm:drm_minor_register] 
[7.098158] [drm:drm_minor_register] new minor registered 128
[7.098163] [drm:drm_minor_register] 
[7.098225] [drm:drm_minor_register] new minor registered 0
[7.098237] [drm] initializing kernel modesetting (VERDE 0x1002:0x682C 
0x1002:0x2B1E).
[7.098251] [drm] register mmio base: 0xFBE0
[7.098254] [drm] register mmio size: 262144
[7.098315] [drm:radeon_get_bios] ATOMBIOS detected
[7.098325] [drm:atom_allocate_fb_scratch] atom firmware requested 001fffe0 
32kb
[7.098470] [drm] Detected VRAM RAM=2048M, BAR=256M
[7.098473] [drm] RAM width 128bits DDR
[7.098602] [drm] radeon: 2048M of VRAM memory ready
[7.098607] [drm] radeon: 1024M of GTT memory ready.
[7.098621] [drm:si_init_microcode] 
[7.098625] [drm] Loading verde Microcode
[7.103464] [drm] Internal thermal controller with fan control
[7.103596] [drm] probing gen 2 caps for device 8086:2f08 = 77a3903/e
[7.103631] [drm:radeon_ucode_print_mc_hdr] MC
[7.103635] [drm:radeon_ucode_print_common_hdr] size_bytes: 32044
[7.103638] [drm:radeon_ucode_print_common_hdr] header_size_bytes: 40
[7.103641] [drm:radeon_ucode_print_common_hdr] header_version_major: 1
[7.103645] [drm:radeon_ucode_print_common_hdr] header_version_minor: 0
[7.103648] [drm:radeon_ucode_print_common_hdr] ip_version_major: 6
[7.103651] [drm:radeon_ucode_print_common_hdr] ip_version_minor: 0
[7.103655] [drm:radeon_ucode_print_common_hdr] ucode_version: 0x00a37610
[7.103658] [drm:radeon_ucode_print_common_hdr] ucode_size_bytes: 31500
[7.103661] [drm:radeon_ucode_print_common_hdr] ucode_array_offset_bytes: 544
[7.103665] [drm:radeon_ucode_print_common_hdr] crc32: 0x442d834d
[7.103678] [drm:radeon_ucode_print_mc_hdr] io_debug_size_bytes: 288
[7.103681] [drm:radeon_ucode_print_mc_hdr] io_debug_array_offset_bytes: 256
[7.104415] [drm:radeon_ucode_print_smc_hdr] SMC
[7.104419] [drm:radeon_ucode_print_common_hdr] size_bytes: 61800
[7.104422] [drm:radeon_ucode_print_common_hdr] header_size_bytes: 36
[7.104426] [drm:radeon_ucode_print_common_hdr] header_version_major: 1
[7.104429] [drm:radeon_ucode_print_common_hdr] header_version_minor: 0
[7.104432] [drm:radeon_ucode_print_common_hdr] ip_version_major: 6
[7.104435] [drm:radeon_ucode_print_common_hdr] ip_version_minor: 0
[7.104439] [drm:radeon_ucode_print_common_hdr] ucode_version: 0x0133524b
[7.104442] [drm:radeon_ucode_print_common_hdr] ucode_size_bytes: 61544
[7.104445] [drm:radeon_ucode_print_common_hdr] ucode_array_offset_bytes: 256
[7.104449] [drm:radeon_ucode_print_common_hdr] crc32: 0xfcbfb6b3
[7.104452] [drm:radeon_ucode_print_smc_hdr] ucode_start_addr: 65536
[7.111599] [drm] radeon: dpm initialized
[7.135847] [drm] GART: num cpu pages 262144, num gpu pages 262144
[7.136428] [drm] probing gen 2 caps for device 80

Radeon Verde displayport failure.

[Dave Jones]

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 boot dmesg output with drm.debug=0xf set?
 > 
 > You might also check the dpcd values in the driver during boot up and
 > link training.  There appears to be an issue where that data gets
 > corrupted in some cases:
 > https://bugs.freedesktop.org/show_bug.cgi?id=73530

I tried both the 'disable spread spectrum' and 'grab dpcd info from vbios for 
eDP'
patches from that bug. Again, no obvious difference.

Log from kernel with both applied attached.

Also a log file from after I woke up the LCD when it was in sleep mode.

Something else curious is how it only discovers a maximum mode from the LCD
of 1024x768.

Dave

-- next part --
[7.082329] [drm:drm_get_pci_dev] 
[7.082418] [drm:drm_minor_register] 
[7.082492] [drm:drm_minor_register] new minor registered 64
[7.082497] [drm:drm_minor_register] 
[7.082544] [drm:drm_minor_register] new minor registered 128
[7.082547] [drm:drm_minor_register] 
[7.082631] [drm:drm_minor_register] new minor registered 0
[7.082643] [drm] initializing kernel modesetting (VERDE 0x1002:0x682C 
0x1002:0x2B1E).
[7.082661] [drm] register mmio base: 0xFBE0
[7.082664] [drm] register mmio size: 262144
[7.082699] radeon :01:00.0: Invalid ROM contents
[7.082749] [drm:radeon_get_bios] ATOMBIOS detected
[7.082761] [drm:atom_allocate_fb_scratch] atom firmware requested 001fffe0 
32kb
[7.082909] radeon :01:00.0: VRAM: 2048M 0x - 
0x7FFF (2048M used)
[7.082917] radeon :01:00.0: GTT: 1024M 0x8000 - 
0xBFFF
[7.082923] [drm] Detected VRAM RAM=2048M, BAR=256M
[7.082927] [drm] RAM width 128bits DDR
[7.083017] [drm] radeon: 2048M of VRAM memory ready
[7.083020] [drm] radeon: 1024M of GTT memory ready.
[7.083037] [drm:si_init_microcode] 
[7.083040] [drm] Loading verde Microcode
[7.087660] [drm] Internal thermal controller with fan control
[7.087745] [drm] probing gen 2 caps for device 8086:2f08 = 77a3903/e
[7.087797] [drm:radeon_ucode_print_mc_hdr] MC
[7.087801] [drm:radeon_ucode_print_common_hdr] size_bytes: 32044
[7.087804] [drm:radeon_ucode_print_common_hdr] header_size_bytes: 40
[7.087807] [drm:radeon_ucode_print_common_hdr] header_version_major: 1
[7.087809] [drm:radeon_ucode_print_common_hdr] header_version_minor: 0
[7.087831] [drm:radeon_ucode_print_common_hdr] ip_version_major: 6
[7.087834] [drm:radeon_ucode_print_common_hdr] ip_version_minor: 0
[7.087837] [drm:radeon_ucode_print_common_hdr] ucode_version: 0x00a37610
[7.087839] [drm:radeon_ucode_print_common_hdr] ucode_size_bytes: 31500
[7.087842] [drm:radeon_ucode_print_common_hdr] ucode_array_offset_bytes: 544
[7.087845] [drm:radeon_ucode_print_common_hdr] crc32: 0x442d834d
[7.087847] [drm:radeon_ucode_print_mc_hdr] io_debug_size_bytes: 288
[7.087850] [drm:radeon_ucode_print_mc_hdr] io_debug_array_offset_bytes: 256
[7.088947] [drm:radeon_ucode_print_smc_hdr] SMC
[7.088951] [drm:radeon_ucode_print_common_hdr] size_bytes: 61800
[7.088953] [drm:radeon_ucode_print_common_hdr] header_size_bytes: 36
[7.088957] [drm:radeon_ucode_print_common_hdr] header_version_major: 1
[7.088960] [drm:radeon_ucode_print_common_hdr] header_version_minor: 0
[7.088964] [drm:radeon_ucode_print_common_hdr] ip_version_major: 6
[7.088968] [d[7.097176] [drm] radeon: dpm initialized
[7.110401] [drm] GART: num cpu pages 262144, num gpu pages 262144
[7.111088] [drm] probing gen 2 caps for device 8086:2f08 = 77a3903/e
[7.111096] [drm] PCIE gen 3 link speeds already enabled
[7.116299] [drm] PCIE GART of 1024M enabled (table at 0x00277000).
[7.116423] radeon :01:00.0: WB enabled
[7.116430] radeon :01:00.0: fence driver on ring 0 use gpu addr 
0x8c00 and cpu addr 0x880805abdc00
[7.116438] radeon :01:00.0: fence driver on ring 1 use gpu addr 
0x8c04 and cpu addr 0x880805abdc04
[7.116445] radeon :01:00.0: fence driver on ring 2 use gpu addr 
0x8c08 and cpu addr 0x880805abdc08
[7.116451] radeon :01:00.0: fence driver on ring 3 use gpu addr 
0x8c0c and cpu addr 0x880805abdc0c
[7.116458] radeon :01:00.0: fence driver on ring 4 use gpu addr 
0x8c10 and cpu addr 0x880805abdc10
[7.116774] radeon :01:00.0: fence driver on ring 5 use gpu addr 
0x00075a18 and cpu addr 0xc9835a18
[7.116783] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[7.116786] [drm] Driver supports precise vblank timestamp query.
[7.116791] radeon 

Radeon Verde displayport failure.

[Dave Jones]

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_update_vblank_count] updating vblank count on crtc 5, 
missed 0
[8.437444] [drm:drm_helper_probe_single_connector_modes_merge_bits] 
[CONNECTOR:40:DP-1]
[8.437506] [drm:si_irq_process] si_irq_process start: rptr 208, wptr 224
[8.437523] [drm:si_irq_process] si_irq_process start: rptr 224, wptr 224
[8.440711] [drm:radeon_dp_getdpcd] DPCD: 12 14 c4 01 01 01 01 81 02 00 06 
00 00 00 00
[8.441242] [drm:radeon_dp_aux_transfer_native] dp_aux_ch flags not zero: 
04001001
[8.441758] [drm:radeon_dp_probe_oui] Branch OUI: 00e04c
[8.442204] [drm:radeon_dp_mst_probe] Sink is MST capable
[8.742140] Oops:  [#1] PREEMPT SMP 
[8.742150] CPU: 3 PID: 418 Comm: systemd-udevd Not tainted 4.1.0-rc3-wopr+ 
#3
[8.742156] task: 88080a09f290 ti: 880808224000 task.ti: 
880808224000
[8.742160] RIP: 0010:[]  [] 
__list_add+0x50/0xe0
[8.742167] RSP: 0018:8808082276b8  EFLAGS: 00010246
[8.742170] RAX:  RBX:  RCX: 
[8.742173] RDX: 880805871720 RSI:  RDI: 8808082276f8
[8.742175] RBP: 8808082276e8 R08: 880808224000 R09: 
[8.742178] R10: 003d R11: 053e R12: 880805871720
[8.742181] R13: 88080a09f290 R14:  R15: 880805871720
[8.742184] FS:  7f16f77bd880() GS:88080f2c() 
knlGS:
[8.742188] CS:  0010 DS:  ES:  CR0: 80050033
[8.742190] CR2:  CR3: 00080820b000 CR4: 001407e0
[8.742193] Stack:
[8.742195]  0001 880805871718 0001 
880805871718
[8.742200]  88080587171c 88080a09f290 880808227748 
866ec970
[8.742205]  880808227758 866e5488 0018 
bea51cc4
[8.742210] Call Trace:
[8.742216]  [] __mutex_lock_slowpath+0x80/0x150
[8.742220]  [] ? printk+0x55/0x6b
[8.742223]  [] mutex_lock+0x1b/0x30
[8.742230]  [] drm_dp_mst_topology_mgr_set_mst+0x3a/0x3e0 
[drm_kms_helper]
[8.742251]  [] radeon_dp_mst_probe+0xaa/0x100 [radeon]
[8.742268]  [] radeon_dp_detect+0x26d/0x2f0 [radeon]
[8.742273]  [] 
drm_helper_probe_single_connector_modes_merge_bits+0x2c8/0x510 [drm_kms_helper]
[8.742278]  [] 
drm_helper_probe_single_connector_modes+0x13/0x20 [drm_kms_helper]
[8.742285]  [] 
drm_fb_helper_probe_connector_modes.isra.3+0x50/0x70 [drm_kms_helper]
[8.742291]  [] drm_fb_helper_initial_config+0x5a/0x410 
[drm_kms_helper]
[8.742304]  [] ? drm_modeset_unlock_all+0x42/0x70 [drm]
[8.742321]  [] radeon_fbdev_init+0xf4/0x120 [radeon]
[8.742335]  [] radeon_modeset_init+0x484/0xa60 [radeon]
[8.742354]  [] ? radeon_ib_ring_tests+0x5a/0xc0 [radeon]
[8.742368]  [] radeon_driver_load_kms+0x140/0x250 [radeon]
[8.742375]  [] drm_dev_register+0xb5/0x110 [drm]
[8.742382]  [] drm_get_pci_dev+0x8d/0x200 [drm]
[8.742394]  [] radeon_pci_probe+0xa3/0xd0 [radeon]
[8.742398]  [] pci_device_probe+0x8c/0xf0
[8.742402]  [] driver_probe_device+0x159/0x4c0
[8.742405]  [] __driver_attach+0x9b/0xa0
[8.742408]  [] ? __device_attach+0x40/0x40
[8.742412]  [] bus_for_each_dev+0x73/0xc0
[8.742415]  [] driver_attach+0x1e/0x20
[8.742418]  [] bus_add_driver+0x180/0x250
[8.742421]  [] driver_register+0x64/0xf0
[8.742425]  [] __pci_register_driver+0x4b/0x50
[8.742432]  [] drm_pci_init+0xfa/0x130 [drm]
[8.742436]  [] ? 0xc082d000
[8.742448]  [] radeon_init+0xdd/0xdf [radeon]
[8.742454]  [] do_one_initcall+0xd8/0x200
[8.742458]  [] ? __vunmap+0xa2/0x100
[8.742462]  [] ? kfree+0x173/0x180
[8.742465]  [] do_init_module+0x61/0x1cc
[8.742469]  [] load_module+0x1f90/0x23b0
[8.742472]  [] ? store_uevent+0x70/0x70
[8.742476]  [] ? copy_module_from_fd.isra.48+0xe5/0x1a0
[8.742479]  [] ? copy_module_from_fd.isra.48+0x132/0x1a0
[8.742483]  [] ? __acct_update_integrals+0x8b/0x120
[8.742486]  [] SyS_finit_module+0xa6/0xe0
[8.742490]  [] system_call_fastpath+0x12/0x6a
[8.742493] Code: c1 30 cc 84 86 31 c0 48 c7 c2 38 83 a3 86 be 1a 00 00 00 
48 c7 c7 b8 7d a3 86 e8 cc d8 cb ff 48 83 c4 18 5b 41 5c 41 5d 5d c3 90 <4c> 8b 
0e 4c 39 ca 74 38 48 89 34 24 49 89 d0 48 c7 c1 30 cc 84 

Radeon Verde displayport failure.

[Dave Jones]

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 
 > > with radeon.dpm=0 on the kernel command line in grub help?  Also does the 
 > > monitor support audio?  You might also try radeon.audio=0.
 > >  >
 > >  > Pretty much the same story with those options..
 > >  >
 > >  > [8.162285] [drm:si_dpm_set_power_state [radeon]] *ERROR* 
 > > si_enable_smc_cac failed
 > >  > [8.170753] [drm:radeon_dp_link_train [radeon]] *ERROR* displayport 
 > > link status failed
 > >  > [8.170778] [drm:radeon_dp_link_train [radeon]] *ERROR* clock 
 > > recovery failed
 > >  >
 > >  > I did manage to get it to display something for a while. By disabling 
 > > DP1.2 with the
 > >  > LCDs OSD, but then it would only do a maximum of 1024x768. And after a 
 > > reboot,
 > >  > I saw the same messages above, and straight to power saving.
 > >
 > > 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 boot dmesg output with drm.debug=0xf set?

Sure. Attached.  I noticed some of the printks are garbled.
Hopefully the important parts lie elsewhere.

 > You might also check the dpcd values in the driver during boot up and
 > link training.  There appears to be an issue where that data gets
 > corrupted in some cases:
 > https://bugs.freedesktop.org/show_bug.cgi?id=73530

Hm, I'll try out some of the patches in that report later (Assuming they aren't
already in the 4.1rc kernel)

thanks for the pointers.

Dave
-- next part --
[7.182169] [drm] Initialized drm 1.1.0 20060810
[7.209807] [drm] radeon kernel modesetting enabled.
[7.209837] [drm:drm_pci_init] 
[7.209943] [drm:drm_get_pci_dev] 
[7.210022] [drm:drm_minor_register] 
[7.210093] [drm:drm_minor_register] new minor registered 64
[7.210101] [drm:drm_minor_register] 
[7.210145] [drm:drm_minor_register] new minor registered 128
[7.210150] [drm:drm_minor_register] 
[7.210185] [drm:drm_minor_register] new minor registered 0
[7.210195] [drm] initializing kernel modesetting (VERDE 0x1002:0x682C 
0x1002:0x2B1E).
[7.210209] [drm] register mmio base: 0xFBE0
[7.210211] [drm] register mmio size: 262144
[7.210274] [drm:radeon_get_bios] ATOMBIOS detected
[7.210281] [drm:atom_allocate_fb_scratch] atom firmware requested 001fffe0 
32kb
[7.210434] [drm] Detected VRAM RAM=2048M, BAR=256M
[7.210438] [drm] RAM width 128bits DDR
[7.210507] [drm] radeon: 2048M of VRAM memory ready
[7.210510] [drm] radeon: 1024M of GTT memory ready.
[7.210520] [drm:si_init_microcode] 
[7.210522] [drm] Loading verde Microcode
[7.215344] [drm] Internal thermal controller with fan control
[7.215420] [drm] probing gen 2 caps for device 8086:2f08 = 77a3903/e
[7.215454] [drm:radeon_ucode_print_mc_hdr] MC
[7.215458] [drm:radeon_ucode_print_common_hdr] size_bytes: 32044
[7.215461] [drm:radeon_ucode_print_common_hdr] header_size_bytes: 40
[7.215466] [drm:radeon_ucode_print_common_hdr] header_version_major: 1
[7.215472] [drm:radeon_ucode_print_common_hdr] header_version_minor: 0
[7.215477] [drm:radeon_ucode_print_common_hdr] ip_version_major: 6
[7.215481] [drm:radeon_ucode_print_common_hdr] ip_version_minor: 0
[7.215484] [drm:radeon_ucode_print_common_hdr] ucode_version: 0x00a37610
[7.215487] [drm:radeon_ucode_print_common_hdr] ucode_size_bytes: 31500
[7.215490] [drm:radeon_ucode_print_common_hdr] ucode_array_offset_bytes: 544
[7.215494] [drm:radeon_ucode_print_common_hdr] crc32: 0x442d834d
[7.215497] [drm:radeon_ucode_print_mc_hdr] io_debug_size_bytes: 288
[7.215500] [drm:radeon_ucode_print_mc_hdr] io_debug_array_offset_bytes: 256
[7.216170] [drm:radeon_ucode_print_smc_hdr] SMC
[7.216175] [drm:radeon_ucode_print_common_hdr] size_bytes: 61800
[7.216178] [drm:radeon_ucode_print_common_hdr] header_size_bytes: 36
[7.216181] [drm:radeon_ucode_print_common_hdr] header_version_major: 1
[7.216184] [drm:radeon_ucode_print_common_hdr] header_version_minor: 0
[7.216187] [drm:radeon_ucode_print_common_hdr] ip_version_major: 6
[7.216190] [drm:radeon_ucode_print_common_hdr] ip_version_minor: 0
[7.216193] [drm:radeon_ucode_print_common_hdr] ucode_version: 0x0133524b
[7.216196] [drm:radeon_ucode_print_common_hdr] ucode_size_bytes: 61544
[7.216199] [drm:radeon_ucode_print_common_hdr] ucode_array_offset_bytes: 256
[7.216202] [drm:radeon_ucode_print_common_hdr] crc32: 0xfcbfb6b3
[7.216205] [drm:radeon_ucode_print_smc_hdr] ucode_start_addr: 65536
[7.222971] [drm] radeon: dpm initialized
[

Radeon Verde displayport failure.

[Dave Jones]

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 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 something on the console, it continues to boot and then X
 >  > > starts up and
 >  > > puts it into power saving too. Trying to flip back to tty1 doesn't 
 > light up the
 >  > > display again.
 >  > > 
 >  > > I'm running On debian stable, with copied-by-hand verde_* firmware files
 >  > > from the linux-firmware git tree.
 >  > > Here's a log from the 4.0-rc2 kernel.
 >  > > 
 >  > > Any other info I can provide ?
 >  > 
 >  > 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 with 
 > radeon.dpm=0 on the kernel command line in grub help?  Also does the monitor 
 > support audio?  You might also try radeon.audio=0.
 > 
 > Pretty much the same story with those options..
 > 
 > [8.162285] [drm:si_dpm_set_power_state [radeon]] *ERROR* 
 > si_enable_smc_cac failed
 > [8.170753] [drm:radeon_dp_link_train [radeon]] *ERROR* displayport link 
 > status failed
 > [8.170778] [drm:radeon_dp_link_train [radeon]] *ERROR* clock recovery 
 > failed
 > 
 > I did manage to get it to display something for a while. By disabling DP1.2 
 > with the
 > LCDs OSD, but then it would only do a maximum of 1024x768. And after a 
 > reboot,
 > I saw the same messages above, and straight to power saving.

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?

Dave

Radeon Verde displayport failure.

[Dave Jones]

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, Alexander; Koenig, Christian
 > > Subject: Radeon Verde displayport failure.
 > > 
 > > 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 something on the console, it continues to boot and then X
 > > starts up and
 > > puts it into power saving too. Trying to flip back to tty1 doesn't light 
 > > up the
 > > display again.
 > > 
 > > I'm running On debian stable, with copied-by-hand verde_* firmware files
 > > from the linux-firmware git tree.
 > > Here's a log from the 4.0-rc2 kernel.
 > > 
 > > Any other info I can provide ?
 > > 
 > 
 > 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 with 
 > radeon.dpm=0 on the kernel command line in grub help?  Also does the monitor 
 > support audio?  You might also try radeon.audio=0.

Pretty much the same story with those options..

[8.162285] [drm:si_dpm_set_power_state [radeon]] *ERROR* si_enable_smc_cac 
failed
[8.170753] [drm:radeon_dp_link_train [radeon]] *ERROR* displayport link 
status failed
[8.170778] [drm:radeon_dp_link_train [radeon]] *ERROR* clock recovery failed

I did manage to get it to display something for a while. By disabling DP1.2 
with the
LCDs OSD, but then it would only do a maximum of 1024x768. And after a reboot,
I saw the same messages above, and straight to power saving.

Dave

Radeon Verde displayport failure.

[Dave Jones]

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 something on the console, it continues to boot and then X starts 
up and
puts it into power saving too. Trying to flip back to tty1 doesn't light up the 
display again.

I'm running On debian stable, with copied-by-hand verde_* firmware files from 
the linux-firmware git tree.
Here's a log from the 4.0-rc2 kernel.

Any other info I can provide ?

Dave



[drm] register mmio base: 0xFBE0
[drm] register mmio size: 262144
radeon :01:00.0: Invalid ROM contents
ATOM BIOS: C755
radeon :01:00.0: VRAM: 2048M 0x - 0x7FFF (2048M 
used)
radeon :01:00.0: GTT: 1024M 0x8000 - 0xBFFF
[drm] Detected VRAM RAM=2048M, BAR=256M
[drm] RAM width 128bits DDR
[TTM] Zone  kernel: Available graphics memory: 16400232 kiB
[TTM] Zone   dma32: Available graphics memory: 2097152 kiB
[TTM] Initializing pool allocator
[TTM] Initializing DMA pool allocator
[drm] radeon: 2048M of VRAM memory ready
[drm] radeon: 1024M of GTT memory ready.
[drm] Loading verde Microcode
[drm] Internal thermal controller with fan control
[drm] probing gen 2 caps for device 8086:2f08 = 77a3103/e
input: HDA ATI HDMI HDMI as 
/devices/pci:00/:00:03.0/:01:00.1/sound/card0/input4
input: HDA ATI HDMI HDMI as 
/devices/pci:00/:00:03.0/:01:00.1/sound/card0/input5
[drm] radeon: dpm initialized
[drm] GART: num cpu pages 262144, num gpu pages 262144
[drm] probing gen 2 caps for device 8086:2f08 = 77a3103/e
[drm] PCIE gen 3 link speeds already enabled
[drm] PCIE GART of 1024M enabled (table at 0x00277000).
radeon :01:00.0: WB enabled
radeon :01:00.0: fence driver on ring 0 use gpu addr 0x8c00 and 
cpu addr 0x880807d0ac00
radeon :01:00.0: fence driver on ring 1 use gpu addr 0x8c04 and 
cpu addr 0x880807d0ac04
radeon :01:00.0: fence driver on ring 2 use gpu addr 0x8c08 and 
cpu addr 0x880807d0ac08
radeon :01:00.0: fence driver on ring 3 use gpu addr 0x8c0c and 
cpu addr 0x880807d0ac0c
radeon :01:00.0: fence driver on ring 4 use gpu addr 0x8c10 and 
cpu addr 0x880807d0ac10
radeon :01:00.0: fence driver on ring 5 use gpu addr 0x00075a18 and 
cpu addr 0xc90001035a18
[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] Driver supports precise vblank timestamp query.
radeon :01:00.0: radeon: MSI limited to 32-bit
radeon :01:00.0: radeon: using MSI.
[drm] radeon: irq initialized.
[drm] ring test on 0 succeeded in 1 usecs
[drm] ring test on 1 succeeded in 1 usecs
[drm] ring test on 2 succeeded in 1 usecs
[drm] ring test on 3 succeeded in 9 usecs
[drm] ring test on 4 succeeded in 3 usecs
[drm] ring test on 5 succeeded in 2 usecs
[drm] UVD initialized successfully.
[drm] ib test on ring 0 succeeded in 0 usecs
[drm] ib test on ring 1 succeeded in 0 usecs
[drm] ib test on ring 2 succeeded in 0 usecs
[drm] ib test on ring 3 succeeded in 0 usecs
[drm] ib test on ring 4 succeeded in 0 usecs
[drm] ib test on ring 5 succeeded
[drm] Radeon Display Connectors
[drm] Connector 0:
[drm]   DP-1
[drm]   HPD4
[drm]   DDC: 0x6540 0x6540 0x6544 0x6544 0x6548 0x6548 0x654c 0x654c
[drm]   Encoders:
[drm] DFP1: INTERNAL_UNIPHY2
[drm] Connector 1:
[drm]   DP-2
[drm]   HPD5
[drm]   DDC: 0x6530 0x6530 0x6534 0x6534 0x6538 0x6538 0x653c 0x653c
[drm]   Encoders:
[drm] DFP2: INTERNAL_UNIPHY1
[drm] Connector 2:
[drm]   DP-3
[drm]   HPD1
[drm]   DDC: 0x6560 0x6560 0x6564 0x6564 0x6568 0x6568 0x656c 0x656c
[drm]   Encoders:
[drm] DFP3: INTERNAL_UNIPHY1
[drm] Connector 3:
[drm]   DP-4
[drm]   HPD2
[drm]   DDC: 0x6580 0x6580 0x6584 0x6584 0x6588 0x6588 0x658c 0x658c
[drm]   Encoders:
[drm] DFP4: INTERNAL_UNIPHY
[drm:si_dpm_set_power_state [radeon]] *ERROR* si_enable_smc_cac failed
[drm] fb mappable at 0xD047A000
[drm] vram apper at 0xD000
[drm] size 3145728
[drm] fb depth is 24
[drm]pitch is 4096
fbcon: radeondrmfb (fb0) is primary device
[drm:si_dpm_set_power_state [radeon]] *ERROR* si_enable_smc_cac failed
[drm:radeon_dp_link_train [radeon]] *ERROR* displayport link status failed
[drm:radeon_dp_link_train [radeon]] *ERROR* clock recovery failed
Console: switching to colour frame buffer device 128x48
radeon :01:00.0: fb0: radeondrmfb frame buffer device
radeon :01:00.0: registered panic notifier
[drm] Initialized radeon 2.42.0 20080528 for :01:00.0 on minor 0
[drm:radeon_dp_link_train [radeon]] *ERROR* displayport link status failed
[drm:radeon_dp_link_train [radeon]] *ERROR* clock recovery failed

[git pull] drm fixes

[Dave Jones]

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 f55548b5af87ebfc586ca75748947f1c1b1a4a52
 > Author: Damien Lespiau 
 > Date:   Thu Feb 5 18:30:20 2015 +
 > 
 > drm/i915: Don't try to reference the fb in get_initial_plane_config()
 > 
 > and
 > 
 > commit fb9981aa675eb7b398849915364916fd98833cfa
 > Author: Damien Lespiau 
 > Date:   Thu Feb 5 19:24:25 2015 +
 > 
 > drm/i915: Fix atomic state when reusing the firmware fb
 > 
 > from linux-next and then check what's left?

I'm probably not going to get time to look at this again until the
weekend.  If things are still awry in rc6, I'll holler.

Dave

[git pull] drm fixes

[Dave Jones]

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 only has HDMI output on it.  If I have it connected (even
 > if the monitor is set to display some other input) it will boot fine,
 > but the backtrace is still present.  I'm going to guess the machine
 > "hangs" in headless because X causes some further issues in the
 > headless case.
 > 
 > Linux v4.0-rc4-199-gb314acaccd7e gets this splat in the headless state:
 > 
 > [  +0.39] WARNING: CPU: 0 PID: 63 at
 > drivers/gpu/drm/i915/i915_gem.c:4525 i915_gem_free_object+0x2e5/0x320
 > [i915]()
 > [  +0.02] WARN_ON(obj->frontbuffer_bits)
 > 
 > which is what I thought one of these commits was supposed to fix.  I
 > don't see that in -rc5, but then we have these other issues.


 > [  +0.37] WARNING: CPU: 1 PID: 1486 at include/linux/kref.h:47
 > drm_framebuffer_reference+0x7a/0x90 [drm]()
 ..
 > [  +0.37] WARNING: CPU: 0 PID: 563 at
 > drivers/gpu/drm/drm_atomic.c:482 drm_atomic_check_only+0x33d/0x500
 > [drm]()

I've started seeing this one too as of rc5.
Along with..


=
BUG kmalloc-192 (Tainted: GW  ): Poison overwritten
-
Disabling lock debugging due to kernel taint
INFO: 0x8804277e5c78-0x8804277e5c78. First byte 0x6a instead of 0x6b
INFO: Allocated in ironlake_get_initial_plane_config+0x86/0x390 [i915] age=175 
cpu=5 pid=313
__slab_alloc.constprop.79+0x5a9/0x670
kmem_cache_alloc_trace+0x21f/0x300
ironlake_get_initial_plane_config+0x86/0x390 [i915]
intel_modeset_init+0x9d9/0x1a50 [i915]
i915_driver_load+0xebf/0x1150 [i915]
drm_dev_register+0xb5/0x110 [drm]
drm_get_pci_dev+0x8d/0x200 [drm]
i915_pci_probe+0x3b/0x60 [i915]
pci_device_probe+0x8c/0xf0
driver_probe_device+0x90/0x3e0
__driver_attach+0xa3/0xb0
bus_for_each_dev+0x73/0xc0
driver_attach+0x1e/0x20
bus_add_driver+0x188/0x260
driver_register+0x64/0xf0
__pci_register_driver+0x64/0x70
INFO: Freed in intel_user_framebuffer_destroy+0x65/0xa0 [i915] age=40 cpu=0 
pid=128
__slab_free+0x19e/0x2c0
kfree+0x2c1/0x310
intel_user_framebuffer_destroy+0x65/0xa0 [i915]
drm_framebuffer_free+0x50/0x60 [drm]
drm_framebuffer_unreference+0x35/0x70 [drm]
drm_atomic_helper_plane_destroy_state+0x1f/0x30 [drm_kms_helper]
intel_plane_destroy_state+0xe/0x10 [i915]
drm_plane_helper_commit+0xb2/0x2e0 [drm_kms_helper]
drm_plane_helper_update+0x9a/0xf0 [drm_kms_helper]
__intel_set_mode+0x8b5/0xb70 [i915]
intel_crtc_set_config+0xc4b/0x1030 [i915]
drm_mode_set_config_internal+0x69/0x120 [drm]
restore_fbdev_mode+0xc8/0xf0 [drm_kms_helper]
drm_fb_helper_restore_fbdev_mode_unlocked+0x29/0x80 [drm_kms_helper]
drm_fb_helper_set_par+0x22/0x50 [drm_kms_helper]
intel_fbdev_set_par+0x1a/0x60 [i915]
INFO: Slab 0xea00109df900 objects=31 used=31 fp=0x  (null) 
flags=0x80004080
INFO: Object 0x8804277e5c70 @offset=7280 fp=0x8804277e6288
Bytes b4 8804277e5c60: 54 7a fb ff 00 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a  
Tz..
Object 8804277e5c70: 6b 6b 6b 6b 6b 6b 6b 6b 6a 6b 6b 6b 6b 6b 6b 6b  
jkkk
Object 8804277e5c80: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  

Object 8804277e5c90: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  

Object 8804277e5ca0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  

Object 8804277e5cb0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  

Object 8804277e5cc0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  

Object 8804277e5cd0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  

Object 8804277e5ce0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  

Object 8804277e5cf0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  

Object 8804277e5d00: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  

Object 8804277e5d10: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  

Object 8804277e5d20: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5  
kkk.
Redzone 8804277e5d30: bb bb bb bb bb bb bb bb  

Padding 8804277e5e70: 5a 5a 5a 5a 5a 5a 5a 5a  

CPU: 4 PID: 128 Comm: kworker/u16:4 Tainted: GB   W   
4.0.0-rc5-backupdebug+ #1
Workqueue: events_unbound async_run_entry_fn
 8804277e5c70 2ebc2945 

3.19rc6 lockdep warning from drm_fb

[Dave Jones]

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-rc6+ #2 Not tainted
[11881.16] ---
[11881.16] khungtaskd/20 is trying to acquire lock:
[11881.16]  ((fb_notifier_list).rwsem){.+.+.+}, at: [] 
__blocking_notifier_call_chain+0x39/0x70
[11881.16] 
[11881.16] but task is already holding lock:
[11881.16]  (crtc_ww_class_mutex){+.+.+.}, at: [] 
drm_modeset_lock+0x98/0x110
[11881.16] 
[11881.16] which lock already depends on the new lock.
[11881.16] 
[11881.16] 
[11881.16] the existing dependency chain (in reverse order) is:
[11881.16] 
-> #2 (crtc_ww_class_mutex){+.+.+.}:
[11881.16][] lock_acquire+0xc0/0x270
[11881.16][] mutex_lock_nested+0x78/0x3d0
[11881.16][] drm_modeset_lock+0xb7/0x110
[11881.16][] drm_mode_getconnector+0x19a/0x4b0
[11881.16][] drm_ioctl+0x1df/0x690
[11881.16][] radeon_drm_ioctl+0x4c/0x80
[11881.16][] do_vfs_ioctl+0x308/0x560
[11881.16][] SyS_ioctl+0x81/0xa0
[11881.16][] system_call_fastpath+0x12/0x17
[11881.16] 
-> #1 (>mode_config.mutex){+.+.+.}:
[11881.16][] lock_acquire+0xc0/0x270
[11881.16][] mutex_lock_nested+0x78/0x3d0
[11881.16][] __drm_modeset_lock_all+0x90/0x120
[11881.16][] drm_modeset_lock_all+0x10/0x40
[11881.16][] 
drm_fb_helper_restore_fbdev_mode_unlocked+0x21/0x80
[11881.16][] drm_fb_helper_set_par+0x22/0x50
[11881.16][] radeon_fb_helper_set_par+0x1a/0x80
[11881.16][] fbcon_init+0x588/0x610
[11881.16][] visual_init+0xbc/0x120
[11881.16][] do_bind_con_driver+0x17e/0x3b0
[11881.16][] do_take_over_console+0xb4/0x1e0
[11881.16][] do_fbcon_takeover+0x63/0xd0
[11881.16][] fbcon_event_notify+0x6dd/0x7e0
[11881.16][] notifier_call_chain+0x62/0x100
[11881.16][] 
__blocking_notifier_call_chain+0x51/0x70
[11881.16][] 
blocking_notifier_call_chain+0x16/0x20

nouveau: treat nv04_devinit_priv.owner as signed.

[Dave Jones]

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 23470a57510c..9d54c106dddf 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/devinit/nv04.h
+++ b/drivers/gpu/drm/nouveau/core/subdev/devinit/nv04.h
@@ -5,7 +5,7 @@

 struct nv04_devinit_priv {
struct nouveau_devinit base;
-   u8 owner;
+   s8 owner;
 };

 int  nv04_devinit_ctor(struct nouveau_object *, struct nouveau_object *,

[PATCH] drm: Fix use-after-free in the shadow-attache exit code

[Dave Jones]

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
 > 

btw, I noticed this because it got flagged in the nightly coverity runs.
Of the 18 new issues added yesterday 14 were from drivers/gpu/

If drm developers want to sign up at http://scan.coverity.com
to help out looking over those (and the backlog: stats below)
I can get those accounts approved quickly.

I've been going through trying to clear out as much of the 'noise'
as possible, but it's a huge job.  There's a bunch of cases where
the checker can't figure out if it's a real bug or not because
it doesn't know things like "the hardware will only ever return
these values", but the majority look like actual coding flaws.

Dave

Currently outstanding issues:

Radeon: 64 
Nouveau: 36
i915: 32
misc drm: 24
gma500: 11
qxl: 7

gma500: remove double free in psbfb_create

[Dave Jones]

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 da...@fedoraproject.org

diff --git a/drivers/gpu/drm/gma500/framebuffer.c 
b/drivers/gpu/drm/gma500/framebuffer.c
index 01dd7d2..d35ffc4 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -479,9 +479,7 @@ static int psbfb_create(struct psb_fbdev *fbdev,
mutex_unlock(dev-struct_mutex);
return 0;
 out_unref:
-   if (backing-stolen)
-   psb_gtt_free_range(dev, backing);
-   else
+   if (!backing-stolen)
drm_gem_object_unreference(backing-gem);
 out_err1:
mutex_unlock(dev-struct_mutex);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[3.10rc6] /proc/dri/0/vma broken on nouveau.

[Dave Jones]

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 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
 > >  > >  >
 > >  > >  > How about this, lets just rip it all out.
 > >  > >
 > >  > > No-one objected, and this is still around in 3.11-rc3 in the same
 > >  > > easily oopsable state.. I vote we kill it with fire.
 > >  >
 > >  > Can we make it burn brighter while at it?
 > >  >
 > >  > 
 > > http://cgit.freedesktop.org/~danvet/drm/commit/?h=for-dvdhrm=151591c2828e18fde1eb8447874704f3422168b0
 > >
 > > This went kinda quiet, what's the plan here ?
 > 
 > We nuked it from orbit in drm-next.

Awesome. Looks like that missed a Cc: -stable tag btw.

Dave

[3.10rc6] /proc/dri/0/vma broken on nouveau.

[Dave Jones]

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 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
 > >  > 
 > >  > How about this, lets just rip it all out.
 > > 
 > > No-one objected, and this is still around in 3.11-rc3 in the same
 > > easily oopsable state.. I vote we kill it with fire.
 > 
 > Can we make it burn brighter while at it?
 > 
 > http://cgit.freedesktop.org/~danvet/drm/commit/?h=for-dvdhrm=151591c2828e18fde1eb8447874704f3422168b0

This went kinda quiet, what's the plan here ?

Dave

Re: [3.10rc6] /proc/dri/0/vma broken on nouveau.

[Dave Jones]

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 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
 
 How about this, lets just rip it all out.
   
   No-one objected, and this is still around in 3.11-rc3 in the same
   easily oopsable state.. I vote we kill it with fire.
  
  Can we make it burn brighter while at it?
  
  http://cgit.freedesktop.org/~danvet/drm/commit/?h=for-dvdhrmid=151591c2828e18fde1eb8447874704f3422168b0

This went kinda quiet, what's the plan here ?

Dave

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [3.10rc6] /proc/dri/0/vma broken on nouveau.

[Dave Jones]

On Thu, Aug 29, 2013 at 06:35:22AM +1000, Dave Airlie wrote:
  On Thu, Aug 29, 2013 at 6:30 AM, Dave Jones da...@redhat.com 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 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
   
How about this, lets just rip it all out.
 
  No-one objected, and this is still around in 3.11-rc3 in the same
  easily oopsable state.. I vote we kill it with fire.

 Can we make it burn brighter while at it?

 
   http://cgit.freedesktop.org/~danvet/drm/commit/?h=for-dvdhrmid=151591c2828e18fde1eb8447874704f3422168b0
  
   This went kinda quiet, what's the plan here ?
  
  We nuked it from orbit in drm-next.

Awesome. Looks like that missed a Cc: -stable tag btw.

Dave

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[3.10rc6] /proc/dri/0/vma broken on nouveau.

[Dave Jones]

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
 > 
 > How about this, lets just rip it all out.

No-one objected, and this is still around in 3.11-rc3 in the same
easily oopsable state.. I vote we kill it with fire.

Dave

Re: [3.10rc6] /proc/dri/0/vma broken on nouveau.

[Dave Jones]

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
  
  How about this, lets just rip it all out.

No-one objected, and this is still around in 3.11-rc3 in the same
easily oopsable state.. I vote we kill it with fire.

Dave
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[3.10rc6] /proc/dri/0/vma broken on nouveau.

[Dave Jones]

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
 > 
 > How about this, lets just rip it all out.

That's one way to deal with it :)
If no programs use it, then yeah, sure, why not.

Dave

Re: [3.10rc6] /proc/dri/0/vma broken on nouveau.

[Dave Jones]

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
  
  How about this, lets just rip it all out.

That's one way to deal with it :)
If no programs use it, then yeah, sure, why not.

Dave
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Intel-gfx] [PATCH] drm/i915: Sanity check incoming ioctl data for a NULL pointer

[Dave Jones]

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 (added in just
the last few weeks), and for drm isn't very advanced at all yet.
I was pretty surprised when Tommi's changes started turning up bugs
so quickly, but I guess a lot of the ioctl paths have just never been
audited for these kinds of bugs.

As you can see at 
https://github.com/kernelslacker/trinity/blob/master/ioctls/drm.c
It's literally just enumerating the known ioctl's, and using the 
generic fuzzing routines (so it just guesses what the argument is,
and hence passes crap like NULL, or a page of garbage).

Eventually I'd like to have routines for each of the individual ioctl
cases to pass something that looks slightly more realistic to what
it's expecting to see.
(Compare to say, the SCSI SG_IO routines here:
 https://github.com/kernelslacker/trinity/blob/master/ioctls/scsi.c
 [still kinda dumb, but gives an idea of the direction])

Lots of work ahead.

Dave

Re: [Intel-gfx] [PATCH] drm/i915: Sanity check incoming ioctl data for a NULL pointer

[Dave Jones]

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 (added in just
the last few weeks), and for drm isn't very advanced at all yet.
I was pretty surprised when Tommi's changes started turning up bugs
so quickly, but I guess a lot of the ioctl paths have just never been
audited for these kinds of bugs.

As you can see at 
https://github.com/kernelslacker/trinity/blob/master/ioctls/drm.c
It's literally just enumerating the known ioctl's, and using the 
generic fuzzing routines (so it just guesses what the argument is,
and hence passes crap like NULL, or a page of garbage).

Eventually I'd like to have routines for each of the individual ioctl
cases to pass something that looks slightly more realistic to what
it's expecting to see.
(Compare to say, the SCSI SG_IO routines here:
 https://github.com/kernelslacker/trinity/blob/master/ioctls/scsi.c
 [still kinda dumb, but gives an idea of the direction])

Lots of work ahead.

Dave

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Lots of i915/drm spew on 3.4

[Dave Jones]

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 controller: Intel Corporation 82945G/GZ 
 > Integrated Graphics Controller (rev 02)
 >  > >
 >  > > I get this every boot with Linus current tree (up to 
 > af56e0aa35f3ae2a4c1a6d1000702df1dd78cb76)
 >  > 
 >  > Just a quick question, is this a regression? 
 > 
 > seems so, I don't see it on 3.3
 > 
 >  > If so, can you please
 >  > attach the output of xrandr --verbose from a noisy and a quite kernel
 >  > (otherwise just please attach it from this noisy kernel).
 > 
 > this machine runs headless, so has no X installed right now, I'll get it in 
 > a while.

Attached.

Dave 
-- next part --
A non-text attachment was scrubbed...
Name: xrandr-3.3
Type: application/x-troff-man
Size: 7704 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120530/3a1fc4a2/attachment-0002.man>
-- next part --
A non-text attachment was scrubbed...
Name: xrandr-3.4
Type: application/x-troff-man
Size: 21691 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120530/3a1fc4a2/attachment-0003.man>

Lots of i915/drm spew on 3.4

[Dave Jones]

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)
 > >
 > > I get this every boot with Linus current tree (up to 
 > > af56e0aa35f3ae2a4c1a6d1000702df1dd78cb76)
 > 
 > Just a quick question, is this a regression? 

seems so, I don't see it on 3.3

 > If so, can you please
 > attach the output of xrandr --verbose from a noisy and a quite kernel
 > (otherwise just please attach it from this noisy kernel).

this machine runs headless, so has no X installed right now, I'll get it in a 
while.

Dave

Lots of i915/drm spew on 3.4

[Dave Jones]

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.153209] [drm] Initialized drm 1.1.0 20060810
[8.491107] i915 :00:02.0: setting latency timer to 64
[8.495118] console_init used greatest stack depth: 4784 bytes left
[8.751664] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[8.751756] [drm] Driver supports precise vblank timestamp query.
[8.754836] vgaarb: device changed decodes: 
PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[8.992409] [ cut here ]
[8.992519] WARNING: at drivers/gpu/drm/drm_crtc.c:2886 
drm_object_attach_property+0x4d/0x50 [drm]()
[8.992634] Hardware name: 
[8.992702] Failed to attach object property (type: 0xc0c0c0c0). Please 
increase DRM_OBJECT_MAX_PROPERTY by 1 for each time you see this message on the 
same object type.
[8.992877] Modules linked in: i915(+) video i2c_algo_bit drm_kms_helper drm 
i2c_core
[8.992989] Pid: 126, comm: udevd Not tainted 3.4.0+ #3
[8.993711] Call Trace:
[8.993790]  [] warn_slowpath_common+0x7f/0xc0
[8.993872]  [] warn_slowpath_fmt+0x46/0x50
[8.993971]  [] drm_object_attach_property+0x4d/0x50 [drm]
[8.994113]  [] drm_connector_attach_property+0x15/0x20 
[drm]
[8.994270]  [] 
intel_sdvo_create_enhance_property+0xde4/0xe20 [i915]
[8.994404]  [] ? drm_property_add_enum+0xca/0x140 [drm]
[8.994524]  [] intel_sdvo_tv_init+0x1b6/0x1e0 [i915]
[8.994643]  [] intel_sdvo_init+0x4fd/0x7c0 [i915]
[8.994759]  [] intel_modeset_init+0xdcb/0xea0 [i915]
[8.994868]  [] i915_driver_load+0xa2e/0xb50 [i915]
[8.994965]  [] ? drm_get_minor+0x261/0x300 [drm]
[8.995105]  [] drm_get_pci_dev+0x186/0x2d0 [drm]
[8.995189]  [] ? trace_hardirqs_on+0xd/0x10
[8.995302]  [] i915_pci_probe+0x16/0x20 [i915]
[8.995385]  [] local_pci_probe+0x5c/0xd0
[8.995464]  [] pci_device_probe+0x111/0x120
[8.995547]  [] driver_probe_device+0x92/0x390
[8.995628]  [] __driver_attach+0xab/0xb0
[8.995708]  [] ? driver_probe_device+0x390/0x390
[8.995788]  [] bus_for_each_dev+0x55/0x90
[8.995867]  [] ? 0xa00f1fff
[8.995945]  [] driver_attach+0x1e/0x20
[8.996068]  [] bus_add_driver+0x1b8/0x2b0
[8.996151]  [] ? 0xa00f1fff
[8.996230]  [] driver_register+0x77/0x150
[8.996309]  [] ? 0xa00f1fff
[8.996388]  [] __pci_register_driver+0x6f/0xf0
[8.996468]  [] ? 0xa00f1fff
[8.996561]  [] drm_pci_init+0x11a/0x130 [drm]
[8.996642]  [] ? 0xa00f1fff
[8.996751]  [] i915_init+0x8b/0x8d [i915]
[8.996833]  [] do_one_initcall+0x12a/0x180
[8.996915]  [] sys_init_module+0x1116/0x2210
[8.996996]  [] ? ddebug_proc_open+0xd0/0xd0
[8.997119]  [] ? lock_release_holdtime.part.26+0xf/0x180
[8.997208]  [] system_call_fastpath+0x16/0x1b
[8.997284] ---[ end trace 533bf7565e4f928e ]---
[9.002178] [ cut here ]
[9.002272] WARNING: at drivers/gpu/drm/drm_crtc.c:2886 
drm_object_attach_property+0x4d/0x50 [drm]()
[9.002385] Hardware name: 
[9.002453] Failed to attach object property (type: 0xc0c0c0c0). Please 
increase DRM_OBJECT_MAX_PROPERTY by 1 for each time you see this message on the 
same object type.
[9.002626] Modules linked in: i915(+) video i2c_algo_bit drm_kms_helper drm 
i2c_core
[9.002738] Pid: 126, comm: udevd Tainted: GW3.4.0+ #3
[9.002811] Call Trace:
[9.002885]  [] warn_slowpath_common+0x7f/0xc0
[9.002965]  [] warn_slowpath_fmt+0x46/0x50
[9.003105]  [] drm_object_attach_property+0x4d/0x50 [drm]
[9.003205]  [] drm_connector_attach_property+0x15/0x20 
[drm]
[9.003358]  [] 
intel_sdvo_create_enhance_property+0x1fe/0xe20 [i915]
[9.003491]  [] ? drm_property_add_enum+0xca/0x140 [drm]
[9.003611]  [] intel_sdvo_tv_init+0x1b6/0x1e0 [i915]
[9.003729]  [] intel_sdvo_init+0x4fd/0x7c0 [i915]
[9.003845]  [] intel_modeset_init+0xdcb/0xea0 [i915]
[9.003953]  [] i915_driver_load+0xa2e/0xb50 [i915]
[9.004094]  [] ? drm_get_minor+0x261/0x300 [drm]
[9.004194]  [] drm_get_pci_dev+0x186/0x2d0 [drm]
[9.004275]  [] ? trace_hardirqs_on+0xd/0x10
[9.004388]  [] i915_pci_probe+0x16/0x20 [i915]
[9.004469]  [] local_pci_probe+0x5c/0xd0
[9.004549]  [] pci_device_probe+0x111/0x120
[9.004630]  [] driver_probe_device+0x92/0x390
[9.004711]  [] __driver_attach+0xab/0xb0
[9.004790]  [] ? driver_probe_device+0x390/0x390
[9.004870]  [] bus_for_each_dev+0x55/0x90
[9.004949]  [] ? 0xa00f1fff
[9.005068]  [] driver_attach+0x1e/0x20
[9.005148]  [] bus_add_driver+0x1b8/0x2b0
[9.005227]  [] ? 0xa00f1fff
[9.005307]  [] driver_register+0x77/0x150
[9.005387]  

Lots of i915/drm spew on 3.4

[Dave Jones]

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.153209] [drm] Initialized drm 1.1.0 20060810
[8.491107] i915 :00:02.0: setting latency timer to 64
[8.495118] console_init used greatest stack depth: 4784 bytes left
[8.751664] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[8.751756] [drm] Driver supports precise vblank timestamp query.
[8.754836] vgaarb: device changed decodes: 
PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[8.992409] [ cut here ]
[8.992519] WARNING: at drivers/gpu/drm/drm_crtc.c:2886 
drm_object_attach_property+0x4d/0x50 [drm]()
[8.992634] Hardware name: 
[8.992702] Failed to attach object property (type: 0xc0c0c0c0). Please 
increase DRM_OBJECT_MAX_PROPERTY by 1 for each time you see this message on the 
same object type.
[8.992877] Modules linked in: i915(+) video i2c_algo_bit drm_kms_helper drm 
i2c_core
[8.992989] Pid: 126, comm: udevd Not tainted 3.4.0+ #3
[8.993711] Call Trace:
[8.993790]  [8106084f] warn_slowpath_common+0x7f/0xc0
[8.993872]  [81060946] warn_slowpath_fmt+0x46/0x50
[8.993971]  [a00221dd] drm_object_attach_property+0x4d/0x50 [drm]
[8.994113]  [a00221f5] drm_connector_attach_property+0x15/0x20 
[drm]
[8.994270]  [a00a8f34] 
intel_sdvo_create_enhance_property+0xde4/0xe20 [i915]
[8.994404]  [a002329a] ? drm_property_add_enum+0xca/0x140 [drm]
[8.994524]  [a00a9e96] intel_sdvo_tv_init+0x1b6/0x1e0 [i915]
[8.994643]  [a00aa78d] intel_sdvo_init+0x4fd/0x7c0 [i915]
[8.994759]  [a009d9fb] intel_modeset_init+0xdcb/0xea0 [i915]
[8.994868]  [a007528e] i915_driver_load+0xa2e/0xb50 [i915]
[8.994965]  [a001c111] ? drm_get_minor+0x261/0x300 [drm]
[8.995105]  [a001e8b6] drm_get_pci_dev+0x186/0x2d0 [drm]
[8.995189]  [810cdfad] ? trace_hardirqs_on+0xd/0x10
[8.995302]  [a00bede2] i915_pci_probe+0x16/0x20 [i915]
[8.995385]  [8135288c] local_pci_probe+0x5c/0xd0
[8.995464]  [81352a11] pci_device_probe+0x111/0x120
[8.995547]  [8141a582] driver_probe_device+0x92/0x390
[8.995628]  [8141a92b] __driver_attach+0xab/0xb0
[8.995708]  [8141a880] ? driver_probe_device+0x390/0x390
[8.995788]  [81418515] bus_for_each_dev+0x55/0x90
[8.995867]  [a00f2000] ? 0xa00f1fff
[8.995945]  [81419e0e] driver_attach+0x1e/0x20
[8.996068]  [81419b18] bus_add_driver+0x1b8/0x2b0
[8.996151]  [a00f2000] ? 0xa00f1fff
[8.996230]  [8141b027] driver_register+0x77/0x150
[8.996309]  [a00f2000] ? 0xa00f1fff
[8.996388]  [8135160f] __pci_register_driver+0x6f/0xf0
[8.996468]  [a00f2000] ? 0xa00f1fff
[8.996561]  [a001eb1a] drm_pci_init+0x11a/0x130 [drm]
[8.996642]  [a00f2000] ? 0xa00f1fff
[8.996751]  [a00f208b] i915_init+0x8b/0x8d [i915]
[8.996833]  [8100212a] do_one_initcall+0x12a/0x180
[8.996915]  [810dbb26] sys_init_module+0x1116/0x2210
[8.996996]  [81345380] ? ddebug_proc_open+0xd0/0xd0
[8.997119]  [810c84cf] ? lock_release_holdtime.part.26+0xf/0x180
[8.997208]  [8169c729] system_call_fastpath+0x16/0x1b
[8.997284] ---[ end trace 533bf7565e4f928e ]---
[9.002178] [ cut here ]
[9.002272] WARNING: at drivers/gpu/drm/drm_crtc.c:2886 
drm_object_attach_property+0x4d/0x50 [drm]()
[9.002385] Hardware name: 
[9.002453] Failed to attach object property (type: 0xc0c0c0c0). Please 
increase DRM_OBJECT_MAX_PROPERTY by 1 for each time you see this message on the 
same object type.
[9.002626] Modules linked in: i915(+) video i2c_algo_bit drm_kms_helper drm 
i2c_core
[9.002738] Pid: 126, comm: udevd Tainted: GW3.4.0+ #3
[9.002811] Call Trace:
[9.002885]  [8106084f] warn_slowpath_common+0x7f/0xc0
[9.002965]  [81060946] warn_slowpath_fmt+0x46/0x50
[9.003105]  [a00221dd] drm_object_attach_property+0x4d/0x50 [drm]
[9.003205]  [a00221f5] drm_connector_attach_property+0x15/0x20 
[drm]
[9.003358]  [a00a834e] 
intel_sdvo_create_enhance_property+0x1fe/0xe20 [i915]
[9.003491]  [a002329a] ? drm_property_add_enum+0xca/0x140 [drm]
[9.003611]  [a00a9e96] intel_sdvo_tv_init+0x1b6/0x1e0 [i915]
[9.003729]  [a00aa78d] intel_sdvo_init+0x4fd/0x7c0 [i915]
[9.003845]  [a009d9fb] intel_modeset_init+0xdcb/0xea0 [i915]
[9.003953]  [a007528e] 

Re: Lots of i915/drm spew on 3.4

[Dave Jones]

On Wed, May 30, 2012 at 11:51:54PM +0200, Daniel Vetter wrote:
  On Wed, May 30, 2012 at 11:31 PM, Dave Jones da...@redhat.com wrote:
   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)
  
  Just a quick question, is this a regression? 

seems so, I don't see it on 3.3

  If so, can you please
  attach the output of xrandr --verbose from a noisy and a quite kernel
  (otherwise just please attach it from this noisy kernel).

this machine runs headless, so has no X installed right now, I'll get it in a 
while.

Dave

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Lots of i915/drm spew on 3.4

[Dave Jones]

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 da...@redhat.com wrote:
 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)

Just a quick question, is this a regression? 
  
  seems so, I don't see it on 3.3
  
If so, can you please
attach the output of xrandr --verbose from a noisy and a quite kernel
(otherwise just please attach it from this noisy kernel).
  
  this machine runs headless, so has no X installed right now, I'll get it in 
  a while.

Attached.

Dave 


xrandr-3.3
Description: Unix manual page


xrandr-3.4
Description: Unix manual page
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: WARNING: at drivers/gpu/drm/radeon/radeon_object.c:236

[Dave Jones]

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
   
   Same WARN_ON hit here on a G5 with rv350
  
  Thanks for the report, guys. Does the patch below help?
  
  
  diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
  b/drivers/gpu/drm/radeon/radeon_object.c
  index f441d58..ad9d450 100644
  --- a/drivers/gpu/drm/radeon/radeon_object.c
  +++ b/drivers/gpu/drm/radeon/radeon_object.c
  @@ -233,7 +233,17 @@ int radeon_bo_pin_restricted(struct radeon_bo *bo, u32 
  domain, u64 max_offset,
   bo-pin_count++;
   if (gpu_addr)
   *gpu_addr = radeon_bo_gpu_offset(bo);
  -WARN_ON_ONCE(max_offset != 0);
  +
  +if (max_offset != 0) {
  +u64 domain_start;
  +
  +if (domain == RADEON_GEM_DOMAIN_VRAM)
  +domain_start = bo-rdev-mc.vram_start;
  +else
  +domain_start = bo-rdev-mc.gtt_start;
  +WARN_ON_ONCE((*gpu_addr - domain_start)  max_offset);
  +}
  +
   return 0;

Stops the warning, and there are no additional side-effects,
so looks all good here.

Tested-by: Dave Jones da...@redhat.com

thanks,

Dave

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: at drivers/gpu/drm/radeon/radeon_object.c:236

[Dave Jones]

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
 > > 
 > > Same WARN_ON hit here on a G5 with rv350
 > 
 > Thanks for the report, guys. Does the patch below help?
 > 
 > 
 > diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
 > b/drivers/gpu/drm/radeon/radeon_object.c
 > index f441d58..ad9d450 100644
 > --- a/drivers/gpu/drm/radeon/radeon_object.c
 > +++ b/drivers/gpu/drm/radeon/radeon_object.c
 > @@ -233,7 +233,17 @@ int radeon_bo_pin_restricted(struct radeon_bo *bo, u32 
 > domain, u64 max_offset,
 >  bo->pin_count++;
 >  if (gpu_addr)
 >  *gpu_addr = radeon_bo_gpu_offset(bo);
 > -WARN_ON_ONCE(max_offset != 0);
 > +
 > +if (max_offset != 0) {
 > +u64 domain_start;
 > +
 > +if (domain == RADEON_GEM_DOMAIN_VRAM)
 > +domain_start = bo->rdev->mc.vram_start;
 > +else
 > +domain_start = bo->rdev->mc.gtt_start;
 > +WARN_ON_ONCE((*gpu_addr - domain_start) > max_offset);
 > +}
 > +
 >      return 0;

Stops the warning, and there are no additional side-effects,
so looks all good here.

Tested-by: Dave Jones 

thanks,

Dave

3.1-rc3-git6: Reported regressions from 3.0

[Dave Jones]

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 (4 days old)
 > First-Bad-Commit: 
 > http://git.kernel.org/linus/aaa6fd2a004147bf32fce05720938236de3361d9

this should be fixed by b727d20269e8ef1de002bfea8099f5e9db9e9f23

Dave

Re: 3.1-rc3-git6: Reported regressions from 3.0

[Dave Jones]

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 francois.valen...@tvcablenet.be
  Date : 2011-08-25 18:51 (4 days old)
  First-Bad-Commit: 
  http://git.kernel.org/linus/aaa6fd2a004147bf32fce05720938236de3361d9
 
this should be fixed by b727d20269e8ef1de002bfea8099f5e9db9e9f23
 
Dave

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel