* [git pull] drm fixes
@ 2015-03-20 21:49 ` Dave Airlie
0 siblings, 0 replies; 71+ messages in thread
From: Dave Airlie @ 2015-03-20 21:49 UTC (permalink / raw)
To: torvalds; +Cc: DRI mailing list, linux-kernel
Hi Linus,
a bunch of fixes across drivers,
radeon: disable two ended allocation for now, it breaks some stuff
amdkfd: misc fixes
nouveau: fix irq loop problem, add basic support for GM206 (new hw)
i915: fix some WARNs people were seeing
exynos: fix some iommu interactions causing boot failures
In other news I've some problem with my git tree and git request-pull
[airlied@dreadlord-bne-redhat-com linux]$ git request-pull linus/master origin
warn: No match for commit 8265d4486d5c2448a1c645fdc20d4e62873d9c3d found at origin
warn: Are you sure you pushed 'HEAD' there?
is happening when I just had my branch on drm-fixes, I've made it master
to generate this pull request so the branch name isn't missing, this
might be due to my attempt to remove my own master branch, using
git symbolic-ref HEAD refs/heads/drm-next, so I'll have to regen it next
week I suppose.
Dave.
The following changes since commit 06e5801b8cb3fc057d88cb4dc03c0b64b2744cda:
Linux 4.0-rc4 (2015-03-15 17:38:20 -0700)
are available in the git repository at:
git://people.freedesktop.org/~airlied/linux
for you to fetch changes up to 8265d4486d5c2448a1c645fdc20d4e62873d9c3d:
Merge tag 'drm-intel-fixes-2015-03-19' of git://anongit.freedesktop.org/drm-intel into drm-fixes (2015-03-20 17:32:21 +1000)
----------------------------------------------------------------
Alex Deucher (1):
drm/radeon: drop ttm two ended allocation
Andrzej Hajda (1):
drm/exynos: remove unused files
Ben Goz (3):
drm/amdkfd: destroy mqd when destroying kernel queue
drm/amdkfd: Fix SDMA queue init. in non-HWS mode
drm/radeon: Changing number of compute pipe lines
Ben Skeggs (3):
drm/nouveau/fifo/nv04: remove the loop from the interrupt handler
drm/nouveau/gr/gf100: fix some accidental or'ing of buffer addresses
drm/nouveau/device: post write to NV_PMC_BOOT_1 when flipping endian switch
Charles Keepax (1):
drm/exynos: Check for NULL dereference of crtc
Damien Lespiau (1):
drm/i915: Make sure the primary plane is enabled before reading out the fb state
Dan Carpenter (1):
drm/exynos: IS_ERR() vs NULL bug
Dave Airlie (5):
Merge branch 'linux-4.0' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes
Merge branch 'exynos-drm-fixes' of git://git.kernel.org/.../daeinki/drm-exynos into drm-fixes
Merge branch 'drm-fixes-4.0' of git://people.freedesktop.org/~agd5f/linux into drm-fixes
Merge tag 'drm-amdkfd-fixes-2015-03-19' of git://people.freedesktop.org/~gabbayo/linux into drm-fixes
Merge tag 'drm-intel-fixes-2015-03-19' of git://anongit.freedesktop.org/drm-intel into drm-fixes
Hyungwon Hwang (1):
drm/exynos: fix the initialization order in FIMD
Inki Dae (1):
drm/exynos: fix typo config name correctly.
Stefan Huehner (2):
drm/nouveau/device/gm100: Basic GM206 bring up (as copy of GM204)
drm/nouveau/bios: fix i2c table parsing for dcb 4.1
Xi Ruoyao (1):
drm/i915: Ensure plane->state->fb stays in sync with plane->fb
.../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 10 +-
drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c | 22 +-
drivers/gpu/drm/exynos/Kconfig | 2 +-
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 4 +-
drivers/gpu/drm/exynos/exynos_drm_connector.c | 245 ---------------------
drivers/gpu/drm/exynos/exynos_drm_connector.h | 20 --
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 29 +--
drivers/gpu/drm/exynos/exynos_drm_plane.c | 2 +-
drivers/gpu/drm/i915/intel_display.c | 32 ++-
drivers/gpu/drm/nouveau/nvkm/engine/device/base.c | 6 +-
drivers/gpu/drm/nouveau/nvkm/engine/device/gm100.c | 43 ++++
drivers/gpu/drm/nouveau/nvkm/engine/fifo/nv04.c | 85 +++----
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf100.c | 4 +-
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk104.c | 4 +-
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c | 4 +-
drivers/gpu/drm/nouveau/nvkm/subdev/bios/i2c.c | 6 +-
drivers/gpu/drm/radeon/radeon_kfd.c | 2 +-
drivers/gpu/drm/radeon/radeon_object.c | 11 -
18 files changed, 159 insertions(+), 372 deletions(-)
delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_connector.c
delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_connector.h
^ permalink raw reply [flat|nested] 71+ messages in thread
* [git pull] drm fixes
@ 2015-03-20 21:49 ` Dave Airlie
0 siblings, 0 replies; 71+ messages in thread
From: Dave Airlie @ 2015-03-20 21:49 UTC (permalink / raw)
To: torvalds; +Cc: linux-kernel, DRI mailing list
Hi Linus,
a bunch of fixes across drivers,
radeon: disable two ended allocation for now, it breaks some stuff
amdkfd: misc fixes
nouveau: fix irq loop problem, add basic support for GM206 (new hw)
i915: fix some WARNs people were seeing
exynos: fix some iommu interactions causing boot failures
In other news I've some problem with my git tree and git request-pull
[airlied@dreadlord-bne-redhat-com linux]$ git request-pull linus/master origin
warn: No match for commit 8265d4486d5c2448a1c645fdc20d4e62873d9c3d found at origin
warn: Are you sure you pushed 'HEAD' there?
is happening when I just had my branch on drm-fixes, I've made it master
to generate this pull request so the branch name isn't missing, this
might be due to my attempt to remove my own master branch, using
git symbolic-ref HEAD refs/heads/drm-next, so I'll have to regen it next
week I suppose.
Dave.
The following changes since commit 06e5801b8cb3fc057d88cb4dc03c0b64b2744cda:
Linux 4.0-rc4 (2015-03-15 17:38:20 -0700)
are available in the git repository at:
git://people.freedesktop.org/~airlied/linux
for you to fetch changes up to 8265d4486d5c2448a1c645fdc20d4e62873d9c3d:
Merge tag 'drm-intel-fixes-2015-03-19' of git://anongit.freedesktop.org/drm-intel into drm-fixes (2015-03-20 17:32:21 +1000)
----------------------------------------------------------------
Alex Deucher (1):
drm/radeon: drop ttm two ended allocation
Andrzej Hajda (1):
drm/exynos: remove unused files
Ben Goz (3):
drm/amdkfd: destroy mqd when destroying kernel queue
drm/amdkfd: Fix SDMA queue init. in non-HWS mode
drm/radeon: Changing number of compute pipe lines
Ben Skeggs (3):
drm/nouveau/fifo/nv04: remove the loop from the interrupt handler
drm/nouveau/gr/gf100: fix some accidental or'ing of buffer addresses
drm/nouveau/device: post write to NV_PMC_BOOT_1 when flipping endian switch
Charles Keepax (1):
drm/exynos: Check for NULL dereference of crtc
Damien Lespiau (1):
drm/i915: Make sure the primary plane is enabled before reading out the fb state
Dan Carpenter (1):
drm/exynos: IS_ERR() vs NULL bug
Dave Airlie (5):
Merge branch 'linux-4.0' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes
Merge branch 'exynos-drm-fixes' of git://git.kernel.org/.../daeinki/drm-exynos into drm-fixes
Merge branch 'drm-fixes-4.0' of git://people.freedesktop.org/~agd5f/linux into drm-fixes
Merge tag 'drm-amdkfd-fixes-2015-03-19' of git://people.freedesktop.org/~gabbayo/linux into drm-fixes
Merge tag 'drm-intel-fixes-2015-03-19' of git://anongit.freedesktop.org/drm-intel into drm-fixes
Hyungwon Hwang (1):
drm/exynos: fix the initialization order in FIMD
Inki Dae (1):
drm/exynos: fix typo config name correctly.
Stefan Huehner (2):
drm/nouveau/device/gm100: Basic GM206 bring up (as copy of GM204)
drm/nouveau/bios: fix i2c table parsing for dcb 4.1
Xi Ruoyao (1):
drm/i915: Ensure plane->state->fb stays in sync with plane->fb
.../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 10 +-
drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c | 22 +-
drivers/gpu/drm/exynos/Kconfig | 2 +-
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 4 +-
drivers/gpu/drm/exynos/exynos_drm_connector.c | 245 ---------------------
drivers/gpu/drm/exynos/exynos_drm_connector.h | 20 --
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 29 +--
drivers/gpu/drm/exynos/exynos_drm_plane.c | 2 +-
drivers/gpu/drm/i915/intel_display.c | 32 ++-
drivers/gpu/drm/nouveau/nvkm/engine/device/base.c | 6 +-
drivers/gpu/drm/nouveau/nvkm/engine/device/gm100.c | 43 ++++
drivers/gpu/drm/nouveau/nvkm/engine/fifo/nv04.c | 85 +++----
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf100.c | 4 +-
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk104.c | 4 +-
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c | 4 +-
drivers/gpu/drm/nouveau/nvkm/subdev/bios/i2c.c | 6 +-
drivers/gpu/drm/radeon/radeon_kfd.c | 2 +-
drivers/gpu/drm/radeon/radeon_object.c | 11 -
18 files changed, 159 insertions(+), 372 deletions(-)
delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_connector.c
delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_connector.h
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [git pull] drm fixes
2015-03-20 21:49 ` Dave Airlie
(?)
@ 2015-03-21 17:50 ` Linus Torvalds
-1 siblings, 0 replies; 71+ messages in thread
From: Linus Torvalds @ 2015-03-21 17:50 UTC (permalink / raw)
To: Dave Airlie; +Cc: DRI mailing list, Linux Kernel Mailing List
On Fri, Mar 20, 2015 at 2:49 PM, Dave Airlie <airlied@linux.ie> wrote:
>
> In other news I've some problem with my git tree and git request-pull
> [airlied@dreadlord-bne-redhat-com linux]$ git request-pull linus/master origin
>
> warn: No match for commit 8265d4486d5c2448a1c645fdc20d4e62873d9c3d found at origin
> warn: Are you sure you pushed 'HEAD' there?
This generally happens if you don't have the same symbolic names
(branch or tag) locally and remotely.
If your local branch name is "linus/master", and your remote one is
just "master", then do what you would do for a "git push": tell git
with the 'local':'remote' syntax _both_ branch names. So something
like
git request-pull linus/master:master origin
should have made request-pull understand to look for the commit at
'master' on the remote side.
That said, when you have a multi-branch setup like you do, I actually
would prefer that you *not* send me "master", but instead send me the
branch (among many) that is clearly for me. So I'd prefer "for-linus"
or similar, simply because it's clearly and explicitly directed at me
and not just some default branch.
Of course, even better would be if you used signed tags.
Linus
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [git pull] drm fixes
2015-03-20 21:49 ` Dave Airlie
@ 2015-03-23 15:33 ` Josh Boyer
-1 siblings, 0 replies; 71+ messages in thread
From: Josh Boyer @ 2015-03-23 15:33 UTC (permalink / raw)
To: Dave Airlie, Damien Lespiau, Xi Ruoyao
Cc: Linus Torvalds, DRI mailing list, Linux-Kernel@Vger. Kernel. Org,
Intel Graphics Development
On Fri, Mar 20, 2015 at 5:49 PM, Dave Airlie <airlied@linux.ie> wrote:
>
> Hi Linus,
>
> a bunch of fixes across drivers,
> radeon: disable two ended allocation for now, it breaks some stuff
> amdkfd: misc fixes
> nouveau: fix irq loop problem, add basic support for GM206 (new hw)
> i915: fix some WARNs people were seeing
> exynos: fix some iommu interactions causing boot failures
>
> In other news I've some problem with my git tree and git request-pull
> [airlied@dreadlord-bne-redhat-com linux]$ git request-pull linus/master origin
> warn: No match for commit 8265d4486d5c2448a1c645fdc20d4e62873d9c3d found at origin
> warn: Are you sure you pushed 'HEAD' there?
>
> is happening when I just had my branch on drm-fixes, I've made it master
> to generate this pull request so the branch name isn't missing, this
> might be due to my attempt to remove my own master branch, using
> git symbolic-ref HEAD refs/heads/drm-next, so I'll have to regen it next
> week I suppose.
<snip>
>
> Damien Lespiau (1):
> drm/i915: Make sure the primary plane is enabled before reading out the fb state
> Xi Ruoyao (1):
> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
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.000039] WARNING: CPU: 0 PID: 63 at
drivers/gpu/drm/i915/i915_gem.c:4525 i915_gem_free_object+0x2e5/0x320
[i915]()
[ +0.000002] 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.
josh
Backtrace via 'insmod i915.ko.xz' in headless state with 4.0-rc5:
[ +0.063764] vgaarb: device changed decodes:
PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[ +0.007099] ------------[ cut here ]------------
[ +0.000037] WARNING: CPU: 1 PID: 1486 at include/linux/kref.h:47
drm_framebuffer_reference+0x7a/0x90 [drm]()
[ +0.000003] Modules linked in: i915(+) ip6t_rpfilter ip6t_REJECT
nf_reject_ipv6 xt_conntrack bnep iTCO_wdt iTCO_vendor_support
ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables
ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6
ip6table_mangle ip6table_security ip6table_raw ip6table_filter
ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4
nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw arc4
iwlmvm mac80211 intel_rapl coretemp kvm_intel kvm iwlwifi btusb
bluetooth i2c_algo_bit cfg80211 drm_kms_helper crct10dif_pclmul
snd_hda_codec_hdmi crc32_pclmul crc32c_intel ghash_clmulni_intel
snd_hda_codec_realtek vfat snd_hda_codec_generic snd_intel_sst_acpi
fat serio_raw snd_intel_sst_core snd_hda_intel i2c_i801 drm
snd_soc_sst_mfld_platform snd_hda_controller
[ +0.000046] r8169 lpc_ich snd_soc_rt5640 snd_hda_codec mfd_core
snd_soc_rl6231 mii mei_txe ir_lirc_codec ir_xmp_decoder
ir_mce_kbd_decoder lirc_dev snd_soc_core ir_sharp_decoder shpchp
ir_sanyo_decoder ir_sony_decoder ir_jvc_decoder mei ir_rc6_decoder
ir_rc5_decoder ir_nec_decoder snd_compress snd_pcm_dmaengine snd_hwdep
snd_seq snd_seq_device iosf_mbi rc_rc6_mce snd_pcm ite_cir snd_timer
rc_core dw_dmac snd dw_dmac_core regmap_i2c i2c_hid
i2c_designware_platform soundcore rfkill_gpio i2c_designware_core
rfkill snd_soc_sst_acpi nfsd auth_rpcgss nfs_acl lockd grace sunrpc
sdhci_acpi video sdhci mmc_core
[ +0.000051] CPU: 1 PID: 1486 Comm: insmod Not tainted
4.0.0-0.rc5.git0.1.fc23.x86_64 #1
[ +0.000004] Hardware name:
\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff
\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff/DN2820FYK,
BIOS FYBYT10H.86A.0034.2014.0513.1413 05/13/2014
[ +0.000003] 0000000000000000 00000000ee312e2f ffff8800b7e03688
ffffffff8177ac09
[ +0.000004] 0000000000000000 0000000000000000 ffff8800b7e036c8
ffffffff8109c78a
[ +0.000004] ffff8800b7e036b8 ffff880234b46d80 ffff880228ef4f00
ffff88021a540000
[ +0.000005] Call Trace:
[ +0.000009] [<ffffffff8177ac09>] dump_stack+0x45/0x57
[ +0.000006] [<ffffffff8109c78a>] warn_slowpath_common+0x8a/0xc0
[ +0.000004] [<ffffffff8109c8ba>] warn_slowpath_null+0x1a/0x20
[ +0.000016] [<ffffffffa032022a>] drm_framebuffer_reference+0x7a/0x90 [drm]
[ +0.000018] [<ffffffffa03326fd>] drm_atomic_set_fb_for_plane+0x2d/0x90 [drm]
[ +0.000043] [<ffffffffa08418c5>]
i9xx_get_initial_plane_config+0x295/0x3e0 [i915]
[ +0.000006] [<ffffffff810c9207>] ? wake_up_process+0x27/0x50
[ +0.000031] [<ffffffffa0852721>] intel_modeset_init+0x9f1/0x1a40 [i915]
[ +0.000027] [<ffffffffa081bf5b>] ?
valleyview_irq_postinstall+0x3b/0x50 [i915]
[ +0.000034] [<ffffffffa08873ef>] i915_driver_load+0xe5f/0x10f0 [i915]
[ +0.000006] [<ffffffff816964ab>] ? netlink_broadcast_filtered+0x12b/0x380
[ +0.000005] [<ffffffff8139b730>] ? kobj_ns_drop+0x50/0x50
[ +0.000004] [<ffffffff8139bae8>] ? kobject_uevent_env+0x178/0x540
[ +0.000006] [<ffffffff814d98d9>] ? devtmpfs_create_node+0x109/0x140
[ +0.000004] [<ffffffff814cde27>] ? get_device+0x17/0x30
[ +0.000005] [<ffffffff814d3ce5>] ? klist_class_dev_get+0x15/0x20
[ +0.000005] [<ffffffff81770a22>] ? klist_add_tail+0x32/0x40
[ +0.000004] [<ffffffff814cf85f>] ? device_add+0x19f/0x6a0
[ +0.000018] [<ffffffffa031a825>] drm_dev_register+0xb5/0x110 [drm]
[ +0.000013] [<ffffffffa031d9bd>] drm_get_pci_dev+0x8d/0x200 [drm]
[ +0.000022] [<ffffffffa07de22b>] i915_pci_probe+0x3b/0x60 [i915]
[ +0.000006] [<ffffffff813e4485>] local_pci_probe+0x45/0xa0
[ +0.000005] [<ffffffff81299a72>] ? sysfs_do_create_link_sd.isra.2+0x72/0xc0
[ +0.000005] [<ffffffff813e57e9>] pci_device_probe+0xf9/0x150
[ +0.000004] [<ffffffff814d2d83>] driver_probe_device+0xa3/0x400
[ +0.000004] [<ffffffff814d31bb>] __driver_attach+0x9b/0xa0
[ +0.000005] [<ffffffff814d3120>] ? __device_attach+0x40/0x40
[ +0.000004] [<ffffffff814d0a43>] bus_for_each_dev+0x73/0xc0
[ +0.000004] [<ffffffff814d27ee>] driver_attach+0x1e/0x20
[ +0.000004] [<ffffffff814d23a0>] bus_add_driver+0x180/0x250
[ +0.000004] [<ffffffff814d39b4>] driver_register+0x64/0xf0
[ +0.000005] [<ffffffff813e3d0c>] __pci_register_driver+0x4c/0x50
[ +0.000013] [<ffffffffa031dc2a>] drm_pci_init+0xfa/0x130 [drm]
[ +0.000010] [<ffffffffa08e7000>] ? 0xffffffffa08e7000
[ +0.000022] [<ffffffffa08e70a0>] i915_init+0xa0/0xa8 [i915]
[ +0.000006] [<ffffffff81002148>] do_one_initcall+0xd8/0x210
[ +0.000005] [<ffffffff811ded12>] ? __vunmap+0xa2/0x100
[ +0.000005] [<ffffffff811fc599>] ? kmem_cache_alloc_trace+0x1a9/0x230
[ +0.000005] [<ffffffff81779e0d>] ? do_init_module+0x28/0x1cc
[ +0.000004] [<ffffffff81779e46>] do_init_module+0x61/0x1cc
[ +0.000005] [<ffffffff81120c4b>] load_module+0x20ab/0x2520
[ +0.000004] [<ffffffff8111c550>] ? store_uevent+0x70/0x70
[ +0.000004] [<ffffffff811dd9ec>] ? vmap_page_range_noflush+0x22c/0x350
[ +0.000005] [<ffffffff8112118d>] SyS_init_module+0xcd/0x120
[ +0.000006] [<ffffffff81781349>] system_call_fastpath+0x12/0x17
[ +0.000004] ---[ end trace ff7adae285a9d5a5 ]---
[ +0.026613] i915 0000:00:02.0: No connectors reported connected with modes
[ +0.000012] [drm] Cannot find any crtc or sizes - going 1024x768
[ +0.002192] fbcon: inteldrmfb (fb0) is primary device
[ +0.000122] Console: switching to colour frame buffer device 128x48
[ +0.000014] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
[ +0.000003] i915 0000:00:02.0: registered panic notifier
[ +0.003554] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no)
[ +0.002204] input: Video Bus as
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input13
[ +0.001292] [drm] Initialized i915 1.6.0 20150130 for 0000:00:02.0 on minor 0
[ +0.000873] ------------[ cut here ]------------
[ +0.000037] WARNING: CPU: 0 PID: 563 at
drivers/gpu/drm/drm_atomic.c:482 drm_atomic_check_only+0x33d/0x500
[drm]()
[ +0.000003] Modules linked in: i915(+) ip6t_rpfilter ip6t_REJECT
nf_reject_ipv6 xt_conntrack bnep iTCO_wdt iTCO_vendor_support
ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables
ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6
ip6table_mangle ip6table_security ip6table_raw ip6table_filter
ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4
nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw arc4
iwlmvm mac80211 intel_rapl coretemp kvm_intel kvm iwlwifi btusb
bluetooth i2c_algo_bit cfg80211 drm_kms_helper crct10dif_pclmul
snd_hda_codec_hdmi crc32_pclmul crc32c_intel ghash_clmulni_intel
snd_hda_codec_realtek vfat snd_hda_codec_generic snd_intel_sst_acpi
fat serio_raw snd_intel_sst_core snd_hda_intel i2c_i801 drm
snd_soc_sst_mfld_platform snd_hda_controller
[ +0.000046] r8169 lpc_ich snd_soc_rt5640 snd_hda_codec mfd_core
snd_soc_rl6231 mii mei_txe ir_lirc_codec ir_xmp_decoder
ir_mce_kbd_decoder lirc_dev snd_soc_core ir_sharp_decoder shpchp
ir_sanyo_decoder ir_sony_decoder ir_jvc_decoder mei ir_rc6_decoder
ir_rc5_decoder ir_nec_decoder snd_compress snd_pcm_dmaengine snd_hwdep
snd_seq snd_seq_device iosf_mbi rc_rc6_mce snd_pcm ite_cir snd_timer
rc_core dw_dmac snd dw_dmac_core regmap_i2c i2c_hid
i2c_designware_platform soundcore rfkill_gpio i2c_designware_core
rfkill snd_soc_sst_acpi nfsd auth_rpcgss nfs_acl lockd grace sunrpc
sdhci_acpi video sdhci mmc_core
[ +0.000050] CPU: 0 PID: 563 Comm: Xorg Tainted: G W
4.0.0-0.rc5.git0.1.fc23.x86_64 #1
[ +0.000003] Hardware name:
\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff
\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff/DN2820FYK,
BIOS FYBYT10H.86A.0034.2014.0513.1413 05/13/2014
[ +0.000003] 0000000000000000 000000001fbdeb23 ffff88022358bc28
ffffffff8177ac09
[ +0.000005] 0000000000000000 0000000000000000 ffff88022358bc68
ffffffff8109c78a
[ +0.000004] ffff88021a79fb00 0000000000000040 ffff8802344da000
ffff88021a4482a0
[ +0.000004] Call Trace:
[ +0.000010] [<ffffffff8177ac09>] dump_stack+0x45/0x57
[ +0.000006] [<ffffffff8109c78a>] warn_slowpath_common+0x8a/0xc0
[ +0.000004] [<ffffffff8109c8ba>] warn_slowpath_null+0x1a/0x20
[ +0.000017] [<ffffffffa033213d>] drm_atomic_check_only+0x33d/0x500 [drm]
[ +0.000006] [<ffffffff811bc0a6>] ? kmemdup+0x36/0x50
[ +0.000016] [<ffffffffa0332317>] drm_atomic_commit+0x17/0x60 [drm]
[ +0.000011] [<ffffffffa03f571d>]
drm_atomic_helper_plane_set_property+0x8d/0xd0 [drm_kms_helper]
[ +0.000014] [<ffffffffa03208ad>] drm_mode_plane_set_obj_prop+0x2d/0x90 [drm]
[ +0.000009] [<ffffffffa03f750b>] restore_fbdev_mode+0x6b/0xf0
[drm_kms_helper]
[ +0.000009] [<ffffffffa03f95c9>]
drm_fb_helper_restore_fbdev_mode_unlocked+0x29/0x80 [drm_kms_helper]
[ +0.000041] [<ffffffffa0860b3e>] intel_fbdev_restore_mode+0x1e/0x50 [i915]
[ +0.000034] [<ffffffffa088795e>] i915_driver_lastclose+0xe/0x20 [i915]
[ +0.000036] [<ffffffffa0314d3e>] drm_lastclose+0x2e/0x150 [drm]
[ +0.000012] [<ffffffffa0315128>] drm_release+0x2c8/0x4b0 [drm]
[ +0.000006] [<ffffffff8121c66f>] __fput+0xdf/0x1f0
[ +0.000005] [<ffffffff8121c7ce>] ____fput+0xe/0x10
[ +0.000004] [<ffffffff810b9727>] task_work_run+0xb7/0xf0
[ +0.000006] [<ffffffff81014cdd>] do_notify_resume+0x8d/0xa0
[ +0.000005] [<ffffffff817815a3>] int_signal+0x12/0x17
[ +0.000003] ---[ end trace ff7adae285a9d5a6 ]---
[ +0.097956] ------------[ cut here ]------------
[ +0.000036] WARNING: CPU: 0 PID: 563 at
drivers/gpu/drm/i915/i915_gem.c:4525 i915_gem_free_object+0x2e5/0x320
[i915]()
[ +0.000003] WARN_ON(obj->frontbuffer_bits)
[ +0.000002] Modules linked in:
[ +0.000002] i915 ip6t_rpfilter ip6t_REJECT nf_reject_ipv6
xt_conntrack bnep iTCO_wdt iTCO_vendor_support ebtable_nat
ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat
nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle
ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat
nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack
iptable_mangle iptable_security iptable_raw arc4 iwlmvm mac80211
intel_rapl coretemp kvm_intel kvm iwlwifi btusb bluetooth i2c_algo_bit
cfg80211 drm_kms_helper crct10dif_pclmul snd_hda_codec_hdmi
crc32_pclmul crc32c_intel ghash_clmulni_intel snd_hda_codec_realtek
vfat snd_hda_codec_generic snd_intel_sst_acpi fat serio_raw
snd_intel_sst_core snd_hda_intel i2c_i801 drm
snd_soc_sst_mfld_platform snd_hda_controller r8169 lpc_ich
[ +0.000057] snd_soc_rt5640 snd_hda_codec mfd_core snd_soc_rl6231
mii mei_txe ir_lirc_codec ir_xmp_decoder ir_mce_kbd_decoder lirc_dev
snd_soc_core ir_sharp_decoder shpchp ir_sanyo_decoder ir_sony_decoder
ir_jvc_decoder mei ir_rc6_decoder ir_rc5_decoder ir_nec_decoder
snd_compress snd_pcm_dmaengine snd_hwdep snd_seq snd_seq_device
iosf_mbi rc_rc6_mce snd_pcm ite_cir snd_timer rc_core dw_dmac snd
dw_dmac_core regmap_i2c i2c_hid i2c_designware_platform soundcore
rfkill_gpio i2c_designware_core rfkill snd_soc_sst_acpi nfsd
auth_rpcgss nfs_acl lockd grace sunrpc sdhci_acpi video sdhci mmc_core
[ +0.000048] CPU: 0 PID: 563 Comm: Xorg Tainted: G W
4.0.0-0.rc5.git0.1.fc23.x86_64 #1
[ +0.000003] Hardware name:
\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff
\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff/DN2820FYK,
BIOS FYBYT10H.86A.0034.2014.0513.1413 05/13/2014
[ +0.000003] 0000000000000000 000000001fbdeb23 ffff88022358bbc8
ffffffff8177ac09
[ +0.000004] 0000000000000000 ffff88022358bc20 ffff88022358bc08
ffffffff8109c78a
[ +0.000004] ffff880228d95570 ffff8800ac0fc040 ffff8800ac0fc000
ffff8800ac0fc0c0
[ +0.000005] Call Trace:
[ +0.000009] [<ffffffff8177ac09>] dump_stack+0x45/0x57
[ +0.000006] [<ffffffff8109c78a>] warn_slowpath_common+0x8a/0xc0
[ +0.000004] [<ffffffff8109c815>] warn_slowpath_fmt+0x55/0x70
[ +0.000020] [<ffffffffa080ac6d>] ? i915_vma_unbind+0x24d/0x260 [i915]
[ +0.000018] [<ffffffffa080c4f5>] i915_gem_free_object+0x2e5/0x320 [i915]
[ +0.000006] [<ffffffff813b6451>] ? list_del+0x11/0x40
[ +0.000020] [<ffffffffa0315417>] drm_gem_object_free+0x27/0x40 [drm]
[ +0.000023] [<ffffffffa0840645>]
intel_user_framebuffer_destroy+0x75/0xa0 [i915]
[ +0.000015] [<ffffffffa0320a0e>] drm_framebuffer_free+0x4e/0x60 [drm]
[ +0.000014] [<ffffffffa0322095>] drm_framebuffer_unreference+0x35/0x70 [drm]
[ +0.000014] [<ffffffffa032219a>]
drm_mode_set_config_internal+0xca/0x100 [drm]
[ +0.000010] [<ffffffffa03f7568>] restore_fbdev_mode+0xc8/0xf0
[drm_kms_helper]
[ +0.000010] [<ffffffffa03f95c9>]
drm_fb_helper_restore_fbdev_mode_unlocked+0x29/0x80 [drm_kms_helper]
[ +0.000022] [<ffffffffa0860b3e>] intel_fbdev_restore_mode+0x1e/0x50 [i915]
[ +0.000025] [<ffffffffa088795e>] i915_driver_lastclose+0xe/0x20 [i915]
[ +0.000012] [<ffffffffa0314d3e>] drm_lastclose+0x2e/0x150 [drm]
[ +0.000011] [<ffffffffa0315128>] drm_release+0x2c8/0x4b0 [drm]
[ +0.000006] [<ffffffff8121c66f>] __fput+0xdf/0x1f0
[ +0.000004] [<ffffffff8121c7ce>] ____fput+0xe/0x10
[ +0.000005] [<ffffffff810b9727>] task_work_run+0xb7/0xf0
[ +0.000006] [<ffffffff81014cdd>] do_notify_resume+0x8d/0xa0
[ +0.000005] [<ffffffff817815a3>] int_signal+0x12/0x17
[ +0.000002] ---[ end trace ff7adae285a9d5a7 ]---
[ +0.191566] ------------[ cut here ]------------
[ +0.000041] WARNING: CPU: 1 PID: 563 at
drivers/gpu/drm/drm_atomic.c:482 drm_atomic_check_only+0x33d/0x500
[drm]()
[ +0.000003] Modules linked in: i915 ip6t_rpfilter ip6t_REJECT
nf_reject_ipv6 xt_conntrack bnep iTCO_wdt iTCO_vendor_support
ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables
ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6
ip6table_mangle ip6table_security ip6table_raw ip6table_filter
ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4
nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw arc4
iwlmvm mac80211 intel_rapl coretemp kvm_intel kvm iwlwifi btusb
bluetooth i2c_algo_bit cfg80211 drm_kms_helper crct10dif_pclmul
snd_hda_codec_hdmi crc32_pclmul crc32c_intel ghash_clmulni_intel
snd_hda_codec_realtek vfat snd_hda_codec_generic snd_intel_sst_acpi
fat serio_raw snd_intel_sst_core snd_hda_intel i2c_i801 drm
snd_soc_sst_mfld_platform snd_hda_controller
[ +0.000046] r8169 lpc_ich snd_soc_rt5640 snd_hda_codec mfd_core
snd_soc_rl6231 mii mei_txe ir_lirc_codec ir_xmp_decoder
ir_mce_kbd_decoder lirc_dev snd_soc_core ir_sharp_decoder shpchp
ir_sanyo_decoder ir_sony_decoder ir_jvc_decoder mei ir_rc6_decoder
ir_rc5_decoder ir_nec_decoder snd_compress snd_pcm_dmaengine snd_hwdep
snd_seq snd_seq_device iosf_mbi rc_rc6_mce snd_pcm ite_cir snd_timer
rc_core dw_dmac snd dw_dmac_core regmap_i2c i2c_hid
i2c_designware_platform soundcore rfkill_gpio i2c_designware_core
rfkill snd_soc_sst_acpi nfsd auth_rpcgss nfs_acl lockd grace sunrpc
sdhci_acpi video sdhci mmc_core
[ +0.000051] CPU: 1 PID: 563 Comm: Xorg Tainted: G W
4.0.0-0.rc5.git0.1.fc23.x86_64 #1
[ +0.000002] Hardware name:
\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff
\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff/DN2820FYK,
BIOS FYBYT10H.86A.0034.2014.0513.1413 05/13/2014
[ +0.000003] 0000000000000000 000000001fbdeb23 ffff88022358bbb8
ffffffff8177ac09
[ +0.000005] 0000000000000000 0000000000000000 ffff88022358bbf8
ffffffff8109c78a
[ +0.000004] ffff8800b7e13740 0000000000000040 ffff880228e6c480
ffff88021e70ec60
[ +0.000004] Call Trace:
[ +0.000010] [<ffffffff8177ac09>] dump_stack+0x45/0x57
[ +0.000006] [<ffffffff8109c78a>] warn_slowpath_common+0x8a/0xc0
[ +0.000004] [<ffffffff8109c8ba>] warn_slowpath_null+0x1a/0x20
[ +0.000016] [<ffffffffa033213d>] drm_atomic_check_only+0x33d/0x500 [drm]
[ +0.000006] [<ffffffff811bc0a6>] ? kmemdup+0x36/0x50
[ +0.000016] [<ffffffffa0332317>] drm_atomic_commit+0x17/0x60 [drm]
[ +0.000011] [<ffffffffa03f571d>]
drm_atomic_helper_plane_set_property+0x8d/0xd0 [drm_kms_helper]
[ +0.000014] [<ffffffffa03208ad>] drm_mode_plane_set_obj_prop+0x2d/0x90 [drm]
[ +0.000009] [<ffffffffa03f750b>] restore_fbdev_mode+0x6b/0xf0
[drm_kms_helper]
[ +0.000009] [<ffffffffa03f95c9>]
drm_fb_helper_restore_fbdev_mode_unlocked+0x29/0x80 [drm_kms_helper]
[ +0.000009] [<ffffffffa03f9642>] drm_fb_helper_set_par+0x22/0x50
[drm_kms_helper]
[ +0.000008] [<ffffffffa03f954f>]
drm_fb_helper_hotplug_event+0x8f/0xe0 [drm_kms_helper]
[ +0.000009] [<ffffffffa03f95ec>]
drm_fb_helper_restore_fbdev_mode_unlocked+0x4c/0x80 [drm_kms_helper]
[ +0.000030] [<ffffffffa0860b3e>] intel_fbdev_restore_mode+0x1e/0x50 [i915]
[ +0.000026] [<ffffffffa088795e>] i915_driver_lastclose+0xe/0x20 [i915]
[ +0.000012] [<ffffffffa0314d3e>] drm_lastclose+0x2e/0x150 [drm]
[ +0.000012] [<ffffffffa0315128>] drm_release+0x2c8/0x4b0 [drm]
[ +0.000005] [<ffffffff8121c66f>] __fput+0xdf/0x1f0
[ +0.000005] [<ffffffff8121c7ce>] ____fput+0xe/0x10
[ +0.000004] [<ffffffff810b9727>] task_work_run+0xb7/0xf0
[ +0.000006] [<ffffffff81014cdd>] do_notify_resume+0x8d/0xa0
[ +0.000005] [<ffffffff817815a3>] int_signal+0x12/0x17
[ +0.000003] ---[ end trace ff7adae285a9d5a8 ]---
[ +0.000015] general protection fault: 0000 [#1] SMP
[ +0.000054] Modules linked in: i915 ip6t_rpfilter ip6t_REJECT
nf_reject_ipv6 xt_conntrack bnep iTCO_wdt iTCO_vendor_support
ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables
ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6
ip6table_mangle ip6table_security ip6table_raw ip6table_filter
ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4
nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw arc4
iwlmvm mac80211 intel_rapl coretemp kvm_intel kvm iwlwifi btusb
bluetooth i2c_algo_bit cfg80211 drm_kms_helper crct10dif_pclmul
snd_hda_codec_hdmi crc32_pclmul crc32c_intel ghash_clmulni_intel
snd_hda_codec_realtek vfat snd_hda_codec_generic snd_intel_sst_acpi
fat serio_raw snd_intel_sst_core snd_hda_intel i2c_i801 drm
snd_soc_sst_mfld_platform snd_hda_controller
[ +0.000702] r8169 lpc_ich snd_soc_rt5640 snd_hda_codec mfd_core
snd_soc_rl6231 mii mei_txe ir_lirc_codec ir_xmp_decoder
ir_mce_kbd_decoder lirc_dev snd_soc_core ir_sharp_decoder shpchp
ir_sanyo_decoder ir_sony_decoder ir_jvc_decoder mei ir_rc6_decoder
ir_rc5_decoder ir_nec_decoder snd_compress snd_pcm_dmaengine snd_hwdep
snd_seq snd_seq_device iosf_mbi rc_rc6_mce snd_pcm ite_cir snd_timer
rc_core dw_dmac snd dw_dmac_core regmap_i2c i2c_hid
i2c_designware_platform soundcore rfkill_gpio i2c_designware_core
rfkill snd_soc_sst_acpi nfsd auth_rpcgss nfs_acl lockd grace sunrpc
sdhci_acpi video sdhci mmc_core
[ +0.000532] CPU: 1 PID: 563 Comm: Xorg Tainted: G W
4.0.0-0.rc5.git0.1.fc23.x86_64 #1
[ +0.000071] Hardware name:
\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff
\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff/DN2820FYK,
BIOS FYBYT10H.86A.0034.2014.0513.1413 05/13/2014
[ +0.000109] task: ffff8800b2e2c520 ti: ffff880223588000 task.ti:
ffff880223588000
[ +0.000059] RIP: 0010:[<ffffffff810e37d3>] [<ffffffff810e37d3>]
mutex_optimistic_spin+0x53/0x1f0
[ +0.000076] RSP: 0018:ffff88022358bae8 EFLAGS: 00010206
[ +0.000044] RAX: 00008124f0000118 RBX: 0000000000000000 RCX: 0000000000000002
[ +0.000056] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff880234b46528
[ +0.000057] RBP: ffff88022358bb38 R08: 0000000000000096 R09: 000000000000041f
[ +0.000057] R10: 0000000000000000 R11: 000000000000041f R12: 0000000000000000
[ +0.000056] R13: ffff8800b2e2c520 R14: ffff880234b46d80 R15: ffff880234b46528
[ +0.002152] FS: 00007fd5c325d9c0(0000) GS:ffff88023fd00000(0000)
knlGS:0000000000000000
[ +0.002190] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ +0.002192] CR2: 00007fb821fd8b50 CR3: 0000000228d2a000 CR4: 00000000001007e0
[ +0.002217] Stack:
[ +0.002206] ffff88022358bb58 ffff8800b2e2c520 0000000000000000
0000000000000246
[ +0.002292] ffff88022358bb78 ffff880234b46528 ffff880234b46528
ffff8800b2e2c520
[ +0.002299] ffff880234b46d80 0000000000000000 ffff88022358bb98
ffffffff8177f1aa
[ +0.002310] Call Trace:
[ +0.002262] [<ffffffff8177f1aa>] __mutex_lock_slowpath+0x3a/0x120
[ +0.002297] [<ffffffff81779c67>] ? printk+0x55/0x6b
[ +0.002312] [<ffffffff8177f2b3>] mutex_lock+0x23/0x40
[ +0.002308] [<ffffffffa03209ea>] drm_framebuffer_free+0x2a/0x60 [drm]
[ +0.002329] [<ffffffffa0322095>] drm_framebuffer_unreference+0x35/0x70 [drm]
[ +0.002319] [<ffffffffa03f5bef>]
drm_atomic_helper_plane_destroy_state+0x1f/0x30 [drm_kms_helper]
[ +0.002366] [<ffffffffa0863f6e>] intel_plane_destroy_state+0xe/0x10 [i915]
[ +0.002368] [<ffffffffa0331a2a>] drm_atomic_state_clear+0x10a/0x170 [drm]
[ +0.002378] [<ffffffffa0331aa6>] drm_atomic_state_free+0x16/0x60 [drm]
[ +0.002362] [<ffffffffa03f5743>]
drm_atomic_helper_plane_set_property+0xb3/0xd0 [drm_kms_helper]
[ +0.002411] [<ffffffffa03208ad>] drm_mode_plane_set_obj_prop+0x2d/0x90 [drm]
[ +0.002420] [<ffffffffa03f750b>] restore_fbdev_mode+0x6b/0xf0
[drm_kms_helper]
[ +0.002435] [<ffffffffa03f95c9>]
drm_fb_helper_restore_fbdev_mode_unlocked+0x29/0x80 [drm_kms_helper]
[ +0.002472] [<ffffffffa03f9642>] drm_fb_helper_set_par+0x22/0x50
[drm_kms_helper]
[ +0.002483] [<ffffffffa03f954f>]
drm_fb_helper_hotplug_event+0x8f/0xe0 [drm_kms_helper]
[ +0.002504] [<ffffffffa03f95ec>]
drm_fb_helper_restore_fbdev_mode_unlocked+0x4c/0x80 [drm_kms_helper]
[ +0.002533] [<ffffffffa0860b3e>] intel_fbdev_restore_mode+0x1e/0x50 [i915]
[ +0.002492] [<ffffffffa088795e>] i915_driver_lastclose+0xe/0x20 [i915]
[ +0.002424] [<ffffffffa0314d3e>] drm_lastclose+0x2e/0x150 [drm]
[ +0.002366] [<ffffffffa0315128>] drm_release+0x2c8/0x4b0 [drm]
[ +0.002299] [<ffffffff8121c66f>] __fput+0xdf/0x1f0
[ +0.002241] [<ffffffff8121c7ce>] ____fput+0xe/0x10
[ +0.002171] [<ffffffff810b9727>] task_work_run+0xb7/0xf0
[ +0.002124] [<ffffffff81014cdd>] do_notify_resume+0x8d/0xa0
[ +0.002067] [<ffffffff817815a3>] int_signal+0x12/0x17
[ +0.002016] Code: 8b 04 25 08 b9 00 00 48 8b 80 38 c0 ff ff a8 08 0f
85 c2 00 00 00 49 89 ff 49 89 f4 89 d3 48 8b 47 18 48 85 c0 0f 84 1d
01 00 00 <8b> 40 28 85 c0 0f 84 a2 00 00 00 49 8d 47 20 48 89 c7 48 89
45
[ +0.004217] RIP [<ffffffff810e37d3>] mutex_optimistic_spin+0x53/0x1f0
[ +0.001983] RSP <ffff88022358bae8>
[ +0.009890] ---[ end trace ff7adae285a9d5a9 ]---
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [git pull] drm fixes
@ 2015-03-23 15:33 ` Josh Boyer
0 siblings, 0 replies; 71+ messages in thread
From: Josh Boyer @ 2015-03-23 15:33 UTC (permalink / raw)
To: Dave Airlie, Damien Lespiau, Xi Ruoyao
Cc: Intel Graphics Development, Linus Torvalds,
Linux-Kernel@Vger. Kernel. Org, DRI mailing list
On Fri, Mar 20, 2015 at 5:49 PM, Dave Airlie <airlied@linux.ie> wrote:
>
> Hi Linus,
>
> a bunch of fixes across drivers,
> radeon: disable two ended allocation for now, it breaks some stuff
> amdkfd: misc fixes
> nouveau: fix irq loop problem, add basic support for GM206 (new hw)
> i915: fix some WARNs people were seeing
> exynos: fix some iommu interactions causing boot failures
>
> In other news I've some problem with my git tree and git request-pull
> [airlied@dreadlord-bne-redhat-com linux]$ git request-pull linus/master origin
> warn: No match for commit 8265d4486d5c2448a1c645fdc20d4e62873d9c3d found at origin
> warn: Are you sure you pushed 'HEAD' there?
>
> is happening when I just had my branch on drm-fixes, I've made it master
> to generate this pull request so the branch name isn't missing, this
> might be due to my attempt to remove my own master branch, using
> git symbolic-ref HEAD refs/heads/drm-next, so I'll have to regen it next
> week I suppose.
<snip>
>
> Damien Lespiau (1):
> drm/i915: Make sure the primary plane is enabled before reading out the fb state
> Xi Ruoyao (1):
> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
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.000039] WARNING: CPU: 0 PID: 63 at
drivers/gpu/drm/i915/i915_gem.c:4525 i915_gem_free_object+0x2e5/0x320
[i915]()
[ +0.000002] 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.
josh
Backtrace via 'insmod i915.ko.xz' in headless state with 4.0-rc5:
[ +0.063764] vgaarb: device changed decodes:
PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[ +0.007099] ------------[ cut here ]------------
[ +0.000037] WARNING: CPU: 1 PID: 1486 at include/linux/kref.h:47
drm_framebuffer_reference+0x7a/0x90 [drm]()
[ +0.000003] Modules linked in: i915(+) ip6t_rpfilter ip6t_REJECT
nf_reject_ipv6 xt_conntrack bnep iTCO_wdt iTCO_vendor_support
ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables
ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6
ip6table_mangle ip6table_security ip6table_raw ip6table_filter
ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4
nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw arc4
iwlmvm mac80211 intel_rapl coretemp kvm_intel kvm iwlwifi btusb
bluetooth i2c_algo_bit cfg80211 drm_kms_helper crct10dif_pclmul
snd_hda_codec_hdmi crc32_pclmul crc32c_intel ghash_clmulni_intel
snd_hda_codec_realtek vfat snd_hda_codec_generic snd_intel_sst_acpi
fat serio_raw snd_intel_sst_core snd_hda_intel i2c_i801 drm
snd_soc_sst_mfld_platform snd_hda_controller
[ +0.000046] r8169 lpc_ich snd_soc_rt5640 snd_hda_codec mfd_core
snd_soc_rl6231 mii mei_txe ir_lirc_codec ir_xmp_decoder
ir_mce_kbd_decoder lirc_dev snd_soc_core ir_sharp_decoder shpchp
ir_sanyo_decoder ir_sony_decoder ir_jvc_decoder mei ir_rc6_decoder
ir_rc5_decoder ir_nec_decoder snd_compress snd_pcm_dmaengine snd_hwdep
snd_seq snd_seq_device iosf_mbi rc_rc6_mce snd_pcm ite_cir snd_timer
rc_core dw_dmac snd dw_dmac_core regmap_i2c i2c_hid
i2c_designware_platform soundcore rfkill_gpio i2c_designware_core
rfkill snd_soc_sst_acpi nfsd auth_rpcgss nfs_acl lockd grace sunrpc
sdhci_acpi video sdhci mmc_core
[ +0.000051] CPU: 1 PID: 1486 Comm: insmod Not tainted
4.0.0-0.rc5.git0.1.fc23.x86_64 #1
[ +0.000004] Hardware name:
\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff
\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff/DN2820FYK,
BIOS FYBYT10H.86A.0034.2014.0513.1413 05/13/2014
[ +0.000003] 0000000000000000 00000000ee312e2f ffff8800b7e03688
ffffffff8177ac09
[ +0.000004] 0000000000000000 0000000000000000 ffff8800b7e036c8
ffffffff8109c78a
[ +0.000004] ffff8800b7e036b8 ffff880234b46d80 ffff880228ef4f00
ffff88021a540000
[ +0.000005] Call Trace:
[ +0.000009] [<ffffffff8177ac09>] dump_stack+0x45/0x57
[ +0.000006] [<ffffffff8109c78a>] warn_slowpath_common+0x8a/0xc0
[ +0.000004] [<ffffffff8109c8ba>] warn_slowpath_null+0x1a/0x20
[ +0.000016] [<ffffffffa032022a>] drm_framebuffer_reference+0x7a/0x90 [drm]
[ +0.000018] [<ffffffffa03326fd>] drm_atomic_set_fb_for_plane+0x2d/0x90 [drm]
[ +0.000043] [<ffffffffa08418c5>]
i9xx_get_initial_plane_config+0x295/0x3e0 [i915]
[ +0.000006] [<ffffffff810c9207>] ? wake_up_process+0x27/0x50
[ +0.000031] [<ffffffffa0852721>] intel_modeset_init+0x9f1/0x1a40 [i915]
[ +0.000027] [<ffffffffa081bf5b>] ?
valleyview_irq_postinstall+0x3b/0x50 [i915]
[ +0.000034] [<ffffffffa08873ef>] i915_driver_load+0xe5f/0x10f0 [i915]
[ +0.000006] [<ffffffff816964ab>] ? netlink_broadcast_filtered+0x12b/0x380
[ +0.000005] [<ffffffff8139b730>] ? kobj_ns_drop+0x50/0x50
[ +0.000004] [<ffffffff8139bae8>] ? kobject_uevent_env+0x178/0x540
[ +0.000006] [<ffffffff814d98d9>] ? devtmpfs_create_node+0x109/0x140
[ +0.000004] [<ffffffff814cde27>] ? get_device+0x17/0x30
[ +0.000005] [<ffffffff814d3ce5>] ? klist_class_dev_get+0x15/0x20
[ +0.000005] [<ffffffff81770a22>] ? klist_add_tail+0x32/0x40
[ +0.000004] [<ffffffff814cf85f>] ? device_add+0x19f/0x6a0
[ +0.000018] [<ffffffffa031a825>] drm_dev_register+0xb5/0x110 [drm]
[ +0.000013] [<ffffffffa031d9bd>] drm_get_pci_dev+0x8d/0x200 [drm]
[ +0.000022] [<ffffffffa07de22b>] i915_pci_probe+0x3b/0x60 [i915]
[ +0.000006] [<ffffffff813e4485>] local_pci_probe+0x45/0xa0
[ +0.000005] [<ffffffff81299a72>] ? sysfs_do_create_link_sd.isra.2+0x72/0xc0
[ +0.000005] [<ffffffff813e57e9>] pci_device_probe+0xf9/0x150
[ +0.000004] [<ffffffff814d2d83>] driver_probe_device+0xa3/0x400
[ +0.000004] [<ffffffff814d31bb>] __driver_attach+0x9b/0xa0
[ +0.000005] [<ffffffff814d3120>] ? __device_attach+0x40/0x40
[ +0.000004] [<ffffffff814d0a43>] bus_for_each_dev+0x73/0xc0
[ +0.000004] [<ffffffff814d27ee>] driver_attach+0x1e/0x20
[ +0.000004] [<ffffffff814d23a0>] bus_add_driver+0x180/0x250
[ +0.000004] [<ffffffff814d39b4>] driver_register+0x64/0xf0
[ +0.000005] [<ffffffff813e3d0c>] __pci_register_driver+0x4c/0x50
[ +0.000013] [<ffffffffa031dc2a>] drm_pci_init+0xfa/0x130 [drm]
[ +0.000010] [<ffffffffa08e7000>] ? 0xffffffffa08e7000
[ +0.000022] [<ffffffffa08e70a0>] i915_init+0xa0/0xa8 [i915]
[ +0.000006] [<ffffffff81002148>] do_one_initcall+0xd8/0x210
[ +0.000005] [<ffffffff811ded12>] ? __vunmap+0xa2/0x100
[ +0.000005] [<ffffffff811fc599>] ? kmem_cache_alloc_trace+0x1a9/0x230
[ +0.000005] [<ffffffff81779e0d>] ? do_init_module+0x28/0x1cc
[ +0.000004] [<ffffffff81779e46>] do_init_module+0x61/0x1cc
[ +0.000005] [<ffffffff81120c4b>] load_module+0x20ab/0x2520
[ +0.000004] [<ffffffff8111c550>] ? store_uevent+0x70/0x70
[ +0.000004] [<ffffffff811dd9ec>] ? vmap_page_range_noflush+0x22c/0x350
[ +0.000005] [<ffffffff8112118d>] SyS_init_module+0xcd/0x120
[ +0.000006] [<ffffffff81781349>] system_call_fastpath+0x12/0x17
[ +0.000004] ---[ end trace ff7adae285a9d5a5 ]---
[ +0.026613] i915 0000:00:02.0: No connectors reported connected with modes
[ +0.000012] [drm] Cannot find any crtc or sizes - going 1024x768
[ +0.002192] fbcon: inteldrmfb (fb0) is primary device
[ +0.000122] Console: switching to colour frame buffer device 128x48
[ +0.000014] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
[ +0.000003] i915 0000:00:02.0: registered panic notifier
[ +0.003554] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no)
[ +0.002204] input: Video Bus as
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input13
[ +0.001292] [drm] Initialized i915 1.6.0 20150130 for 0000:00:02.0 on minor 0
[ +0.000873] ------------[ cut here ]------------
[ +0.000037] WARNING: CPU: 0 PID: 563 at
drivers/gpu/drm/drm_atomic.c:482 drm_atomic_check_only+0x33d/0x500
[drm]()
[ +0.000003] Modules linked in: i915(+) ip6t_rpfilter ip6t_REJECT
nf_reject_ipv6 xt_conntrack bnep iTCO_wdt iTCO_vendor_support
ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables
ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6
ip6table_mangle ip6table_security ip6table_raw ip6table_filter
ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4
nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw arc4
iwlmvm mac80211 intel_rapl coretemp kvm_intel kvm iwlwifi btusb
bluetooth i2c_algo_bit cfg80211 drm_kms_helper crct10dif_pclmul
snd_hda_codec_hdmi crc32_pclmul crc32c_intel ghash_clmulni_intel
snd_hda_codec_realtek vfat snd_hda_codec_generic snd_intel_sst_acpi
fat serio_raw snd_intel_sst_core snd_hda_intel i2c_i801 drm
snd_soc_sst_mfld_platform snd_hda_controller
[ +0.000046] r8169 lpc_ich snd_soc_rt5640 snd_hda_codec mfd_core
snd_soc_rl6231 mii mei_txe ir_lirc_codec ir_xmp_decoder
ir_mce_kbd_decoder lirc_dev snd_soc_core ir_sharp_decoder shpchp
ir_sanyo_decoder ir_sony_decoder ir_jvc_decoder mei ir_rc6_decoder
ir_rc5_decoder ir_nec_decoder snd_compress snd_pcm_dmaengine snd_hwdep
snd_seq snd_seq_device iosf_mbi rc_rc6_mce snd_pcm ite_cir snd_timer
rc_core dw_dmac snd dw_dmac_core regmap_i2c i2c_hid
i2c_designware_platform soundcore rfkill_gpio i2c_designware_core
rfkill snd_soc_sst_acpi nfsd auth_rpcgss nfs_acl lockd grace sunrpc
sdhci_acpi video sdhci mmc_core
[ +0.000050] CPU: 0 PID: 563 Comm: Xorg Tainted: G W
4.0.0-0.rc5.git0.1.fc23.x86_64 #1
[ +0.000003] Hardware name:
\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff
\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff/DN2820FYK,
BIOS FYBYT10H.86A.0034.2014.0513.1413 05/13/2014
[ +0.000003] 0000000000000000 000000001fbdeb23 ffff88022358bc28
ffffffff8177ac09
[ +0.000005] 0000000000000000 0000000000000000 ffff88022358bc68
ffffffff8109c78a
[ +0.000004] ffff88021a79fb00 0000000000000040 ffff8802344da000
ffff88021a4482a0
[ +0.000004] Call Trace:
[ +0.000010] [<ffffffff8177ac09>] dump_stack+0x45/0x57
[ +0.000006] [<ffffffff8109c78a>] warn_slowpath_common+0x8a/0xc0
[ +0.000004] [<ffffffff8109c8ba>] warn_slowpath_null+0x1a/0x20
[ +0.000017] [<ffffffffa033213d>] drm_atomic_check_only+0x33d/0x500 [drm]
[ +0.000006] [<ffffffff811bc0a6>] ? kmemdup+0x36/0x50
[ +0.000016] [<ffffffffa0332317>] drm_atomic_commit+0x17/0x60 [drm]
[ +0.000011] [<ffffffffa03f571d>]
drm_atomic_helper_plane_set_property+0x8d/0xd0 [drm_kms_helper]
[ +0.000014] [<ffffffffa03208ad>] drm_mode_plane_set_obj_prop+0x2d/0x90 [drm]
[ +0.000009] [<ffffffffa03f750b>] restore_fbdev_mode+0x6b/0xf0
[drm_kms_helper]
[ +0.000009] [<ffffffffa03f95c9>]
drm_fb_helper_restore_fbdev_mode_unlocked+0x29/0x80 [drm_kms_helper]
[ +0.000041] [<ffffffffa0860b3e>] intel_fbdev_restore_mode+0x1e/0x50 [i915]
[ +0.000034] [<ffffffffa088795e>] i915_driver_lastclose+0xe/0x20 [i915]
[ +0.000036] [<ffffffffa0314d3e>] drm_lastclose+0x2e/0x150 [drm]
[ +0.000012] [<ffffffffa0315128>] drm_release+0x2c8/0x4b0 [drm]
[ +0.000006] [<ffffffff8121c66f>] __fput+0xdf/0x1f0
[ +0.000005] [<ffffffff8121c7ce>] ____fput+0xe/0x10
[ +0.000004] [<ffffffff810b9727>] task_work_run+0xb7/0xf0
[ +0.000006] [<ffffffff81014cdd>] do_notify_resume+0x8d/0xa0
[ +0.000005] [<ffffffff817815a3>] int_signal+0x12/0x17
[ +0.000003] ---[ end trace ff7adae285a9d5a6 ]---
[ +0.097956] ------------[ cut here ]------------
[ +0.000036] WARNING: CPU: 0 PID: 563 at
drivers/gpu/drm/i915/i915_gem.c:4525 i915_gem_free_object+0x2e5/0x320
[i915]()
[ +0.000003] WARN_ON(obj->frontbuffer_bits)
[ +0.000002] Modules linked in:
[ +0.000002] i915 ip6t_rpfilter ip6t_REJECT nf_reject_ipv6
xt_conntrack bnep iTCO_wdt iTCO_vendor_support ebtable_nat
ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat
nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle
ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat
nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack
iptable_mangle iptable_security iptable_raw arc4 iwlmvm mac80211
intel_rapl coretemp kvm_intel kvm iwlwifi btusb bluetooth i2c_algo_bit
cfg80211 drm_kms_helper crct10dif_pclmul snd_hda_codec_hdmi
crc32_pclmul crc32c_intel ghash_clmulni_intel snd_hda_codec_realtek
vfat snd_hda_codec_generic snd_intel_sst_acpi fat serio_raw
snd_intel_sst_core snd_hda_intel i2c_i801 drm
snd_soc_sst_mfld_platform snd_hda_controller r8169 lpc_ich
[ +0.000057] snd_soc_rt5640 snd_hda_codec mfd_core snd_soc_rl6231
mii mei_txe ir_lirc_codec ir_xmp_decoder ir_mce_kbd_decoder lirc_dev
snd_soc_core ir_sharp_decoder shpchp ir_sanyo_decoder ir_sony_decoder
ir_jvc_decoder mei ir_rc6_decoder ir_rc5_decoder ir_nec_decoder
snd_compress snd_pcm_dmaengine snd_hwdep snd_seq snd_seq_device
iosf_mbi rc_rc6_mce snd_pcm ite_cir snd_timer rc_core dw_dmac snd
dw_dmac_core regmap_i2c i2c_hid i2c_designware_platform soundcore
rfkill_gpio i2c_designware_core rfkill snd_soc_sst_acpi nfsd
auth_rpcgss nfs_acl lockd grace sunrpc sdhci_acpi video sdhci mmc_core
[ +0.000048] CPU: 0 PID: 563 Comm: Xorg Tainted: G W
4.0.0-0.rc5.git0.1.fc23.x86_64 #1
[ +0.000003] Hardware name:
\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff
\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff/DN2820FYK,
BIOS FYBYT10H.86A.0034.2014.0513.1413 05/13/2014
[ +0.000003] 0000000000000000 000000001fbdeb23 ffff88022358bbc8
ffffffff8177ac09
[ +0.000004] 0000000000000000 ffff88022358bc20 ffff88022358bc08
ffffffff8109c78a
[ +0.000004] ffff880228d95570 ffff8800ac0fc040 ffff8800ac0fc000
ffff8800ac0fc0c0
[ +0.000005] Call Trace:
[ +0.000009] [<ffffffff8177ac09>] dump_stack+0x45/0x57
[ +0.000006] [<ffffffff8109c78a>] warn_slowpath_common+0x8a/0xc0
[ +0.000004] [<ffffffff8109c815>] warn_slowpath_fmt+0x55/0x70
[ +0.000020] [<ffffffffa080ac6d>] ? i915_vma_unbind+0x24d/0x260 [i915]
[ +0.000018] [<ffffffffa080c4f5>] i915_gem_free_object+0x2e5/0x320 [i915]
[ +0.000006] [<ffffffff813b6451>] ? list_del+0x11/0x40
[ +0.000020] [<ffffffffa0315417>] drm_gem_object_free+0x27/0x40 [drm]
[ +0.000023] [<ffffffffa0840645>]
intel_user_framebuffer_destroy+0x75/0xa0 [i915]
[ +0.000015] [<ffffffffa0320a0e>] drm_framebuffer_free+0x4e/0x60 [drm]
[ +0.000014] [<ffffffffa0322095>] drm_framebuffer_unreference+0x35/0x70 [drm]
[ +0.000014] [<ffffffffa032219a>]
drm_mode_set_config_internal+0xca/0x100 [drm]
[ +0.000010] [<ffffffffa03f7568>] restore_fbdev_mode+0xc8/0xf0
[drm_kms_helper]
[ +0.000010] [<ffffffffa03f95c9>]
drm_fb_helper_restore_fbdev_mode_unlocked+0x29/0x80 [drm_kms_helper]
[ +0.000022] [<ffffffffa0860b3e>] intel_fbdev_restore_mode+0x1e/0x50 [i915]
[ +0.000025] [<ffffffffa088795e>] i915_driver_lastclose+0xe/0x20 [i915]
[ +0.000012] [<ffffffffa0314d3e>] drm_lastclose+0x2e/0x150 [drm]
[ +0.000011] [<ffffffffa0315128>] drm_release+0x2c8/0x4b0 [drm]
[ +0.000006] [<ffffffff8121c66f>] __fput+0xdf/0x1f0
[ +0.000004] [<ffffffff8121c7ce>] ____fput+0xe/0x10
[ +0.000005] [<ffffffff810b9727>] task_work_run+0xb7/0xf0
[ +0.000006] [<ffffffff81014cdd>] do_notify_resume+0x8d/0xa0
[ +0.000005] [<ffffffff817815a3>] int_signal+0x12/0x17
[ +0.000002] ---[ end trace ff7adae285a9d5a7 ]---
[ +0.191566] ------------[ cut here ]------------
[ +0.000041] WARNING: CPU: 1 PID: 563 at
drivers/gpu/drm/drm_atomic.c:482 drm_atomic_check_only+0x33d/0x500
[drm]()
[ +0.000003] Modules linked in: i915 ip6t_rpfilter ip6t_REJECT
nf_reject_ipv6 xt_conntrack bnep iTCO_wdt iTCO_vendor_support
ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables
ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6
ip6table_mangle ip6table_security ip6table_raw ip6table_filter
ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4
nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw arc4
iwlmvm mac80211 intel_rapl coretemp kvm_intel kvm iwlwifi btusb
bluetooth i2c_algo_bit cfg80211 drm_kms_helper crct10dif_pclmul
snd_hda_codec_hdmi crc32_pclmul crc32c_intel ghash_clmulni_intel
snd_hda_codec_realtek vfat snd_hda_codec_generic snd_intel_sst_acpi
fat serio_raw snd_intel_sst_core snd_hda_intel i2c_i801 drm
snd_soc_sst_mfld_platform snd_hda_controller
[ +0.000046] r8169 lpc_ich snd_soc_rt5640 snd_hda_codec mfd_core
snd_soc_rl6231 mii mei_txe ir_lirc_codec ir_xmp_decoder
ir_mce_kbd_decoder lirc_dev snd_soc_core ir_sharp_decoder shpchp
ir_sanyo_decoder ir_sony_decoder ir_jvc_decoder mei ir_rc6_decoder
ir_rc5_decoder ir_nec_decoder snd_compress snd_pcm_dmaengine snd_hwdep
snd_seq snd_seq_device iosf_mbi rc_rc6_mce snd_pcm ite_cir snd_timer
rc_core dw_dmac snd dw_dmac_core regmap_i2c i2c_hid
i2c_designware_platform soundcore rfkill_gpio i2c_designware_core
rfkill snd_soc_sst_acpi nfsd auth_rpcgss nfs_acl lockd grace sunrpc
sdhci_acpi video sdhci mmc_core
[ +0.000051] CPU: 1 PID: 563 Comm: Xorg Tainted: G W
4.0.0-0.rc5.git0.1.fc23.x86_64 #1
[ +0.000002] Hardware name:
\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff
\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff/DN2820FYK,
BIOS FYBYT10H.86A.0034.2014.0513.1413 05/13/2014
[ +0.000003] 0000000000000000 000000001fbdeb23 ffff88022358bbb8
ffffffff8177ac09
[ +0.000005] 0000000000000000 0000000000000000 ffff88022358bbf8
ffffffff8109c78a
[ +0.000004] ffff8800b7e13740 0000000000000040 ffff880228e6c480
ffff88021e70ec60
[ +0.000004] Call Trace:
[ +0.000010] [<ffffffff8177ac09>] dump_stack+0x45/0x57
[ +0.000006] [<ffffffff8109c78a>] warn_slowpath_common+0x8a/0xc0
[ +0.000004] [<ffffffff8109c8ba>] warn_slowpath_null+0x1a/0x20
[ +0.000016] [<ffffffffa033213d>] drm_atomic_check_only+0x33d/0x500 [drm]
[ +0.000006] [<ffffffff811bc0a6>] ? kmemdup+0x36/0x50
[ +0.000016] [<ffffffffa0332317>] drm_atomic_commit+0x17/0x60 [drm]
[ +0.000011] [<ffffffffa03f571d>]
drm_atomic_helper_plane_set_property+0x8d/0xd0 [drm_kms_helper]
[ +0.000014] [<ffffffffa03208ad>] drm_mode_plane_set_obj_prop+0x2d/0x90 [drm]
[ +0.000009] [<ffffffffa03f750b>] restore_fbdev_mode+0x6b/0xf0
[drm_kms_helper]
[ +0.000009] [<ffffffffa03f95c9>]
drm_fb_helper_restore_fbdev_mode_unlocked+0x29/0x80 [drm_kms_helper]
[ +0.000009] [<ffffffffa03f9642>] drm_fb_helper_set_par+0x22/0x50
[drm_kms_helper]
[ +0.000008] [<ffffffffa03f954f>]
drm_fb_helper_hotplug_event+0x8f/0xe0 [drm_kms_helper]
[ +0.000009] [<ffffffffa03f95ec>]
drm_fb_helper_restore_fbdev_mode_unlocked+0x4c/0x80 [drm_kms_helper]
[ +0.000030] [<ffffffffa0860b3e>] intel_fbdev_restore_mode+0x1e/0x50 [i915]
[ +0.000026] [<ffffffffa088795e>] i915_driver_lastclose+0xe/0x20 [i915]
[ +0.000012] [<ffffffffa0314d3e>] drm_lastclose+0x2e/0x150 [drm]
[ +0.000012] [<ffffffffa0315128>] drm_release+0x2c8/0x4b0 [drm]
[ +0.000005] [<ffffffff8121c66f>] __fput+0xdf/0x1f0
[ +0.000005] [<ffffffff8121c7ce>] ____fput+0xe/0x10
[ +0.000004] [<ffffffff810b9727>] task_work_run+0xb7/0xf0
[ +0.000006] [<ffffffff81014cdd>] do_notify_resume+0x8d/0xa0
[ +0.000005] [<ffffffff817815a3>] int_signal+0x12/0x17
[ +0.000003] ---[ end trace ff7adae285a9d5a8 ]---
[ +0.000015] general protection fault: 0000 [#1] SMP
[ +0.000054] Modules linked in: i915 ip6t_rpfilter ip6t_REJECT
nf_reject_ipv6 xt_conntrack bnep iTCO_wdt iTCO_vendor_support
ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables
ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6
ip6table_mangle ip6table_security ip6table_raw ip6table_filter
ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4
nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw arc4
iwlmvm mac80211 intel_rapl coretemp kvm_intel kvm iwlwifi btusb
bluetooth i2c_algo_bit cfg80211 drm_kms_helper crct10dif_pclmul
snd_hda_codec_hdmi crc32_pclmul crc32c_intel ghash_clmulni_intel
snd_hda_codec_realtek vfat snd_hda_codec_generic snd_intel_sst_acpi
fat serio_raw snd_intel_sst_core snd_hda_intel i2c_i801 drm
snd_soc_sst_mfld_platform snd_hda_controller
[ +0.000702] r8169 lpc_ich snd_soc_rt5640 snd_hda_codec mfd_core
snd_soc_rl6231 mii mei_txe ir_lirc_codec ir_xmp_decoder
ir_mce_kbd_decoder lirc_dev snd_soc_core ir_sharp_decoder shpchp
ir_sanyo_decoder ir_sony_decoder ir_jvc_decoder mei ir_rc6_decoder
ir_rc5_decoder ir_nec_decoder snd_compress snd_pcm_dmaengine snd_hwdep
snd_seq snd_seq_device iosf_mbi rc_rc6_mce snd_pcm ite_cir snd_timer
rc_core dw_dmac snd dw_dmac_core regmap_i2c i2c_hid
i2c_designware_platform soundcore rfkill_gpio i2c_designware_core
rfkill snd_soc_sst_acpi nfsd auth_rpcgss nfs_acl lockd grace sunrpc
sdhci_acpi video sdhci mmc_core
[ +0.000532] CPU: 1 PID: 563 Comm: Xorg Tainted: G W
4.0.0-0.rc5.git0.1.fc23.x86_64 #1
[ +0.000071] Hardware name:
\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff
\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff/DN2820FYK,
BIOS FYBYT10H.86A.0034.2014.0513.1413 05/13/2014
[ +0.000109] task: ffff8800b2e2c520 ti: ffff880223588000 task.ti:
ffff880223588000
[ +0.000059] RIP: 0010:[<ffffffff810e37d3>] [<ffffffff810e37d3>]
mutex_optimistic_spin+0x53/0x1f0
[ +0.000076] RSP: 0018:ffff88022358bae8 EFLAGS: 00010206
[ +0.000044] RAX: 00008124f0000118 RBX: 0000000000000000 RCX: 0000000000000002
[ +0.000056] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff880234b46528
[ +0.000057] RBP: ffff88022358bb38 R08: 0000000000000096 R09: 000000000000041f
[ +0.000057] R10: 0000000000000000 R11: 000000000000041f R12: 0000000000000000
[ +0.000056] R13: ffff8800b2e2c520 R14: ffff880234b46d80 R15: ffff880234b46528
[ +0.002152] FS: 00007fd5c325d9c0(0000) GS:ffff88023fd00000(0000)
knlGS:0000000000000000
[ +0.002190] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ +0.002192] CR2: 00007fb821fd8b50 CR3: 0000000228d2a000 CR4: 00000000001007e0
[ +0.002217] Stack:
[ +0.002206] ffff88022358bb58 ffff8800b2e2c520 0000000000000000
0000000000000246
[ +0.002292] ffff88022358bb78 ffff880234b46528 ffff880234b46528
ffff8800b2e2c520
[ +0.002299] ffff880234b46d80 0000000000000000 ffff88022358bb98
ffffffff8177f1aa
[ +0.002310] Call Trace:
[ +0.002262] [<ffffffff8177f1aa>] __mutex_lock_slowpath+0x3a/0x120
[ +0.002297] [<ffffffff81779c67>] ? printk+0x55/0x6b
[ +0.002312] [<ffffffff8177f2b3>] mutex_lock+0x23/0x40
[ +0.002308] [<ffffffffa03209ea>] drm_framebuffer_free+0x2a/0x60 [drm]
[ +0.002329] [<ffffffffa0322095>] drm_framebuffer_unreference+0x35/0x70 [drm]
[ +0.002319] [<ffffffffa03f5bef>]
drm_atomic_helper_plane_destroy_state+0x1f/0x30 [drm_kms_helper]
[ +0.002366] [<ffffffffa0863f6e>] intel_plane_destroy_state+0xe/0x10 [i915]
[ +0.002368] [<ffffffffa0331a2a>] drm_atomic_state_clear+0x10a/0x170 [drm]
[ +0.002378] [<ffffffffa0331aa6>] drm_atomic_state_free+0x16/0x60 [drm]
[ +0.002362] [<ffffffffa03f5743>]
drm_atomic_helper_plane_set_property+0xb3/0xd0 [drm_kms_helper]
[ +0.002411] [<ffffffffa03208ad>] drm_mode_plane_set_obj_prop+0x2d/0x90 [drm]
[ +0.002420] [<ffffffffa03f750b>] restore_fbdev_mode+0x6b/0xf0
[drm_kms_helper]
[ +0.002435] [<ffffffffa03f95c9>]
drm_fb_helper_restore_fbdev_mode_unlocked+0x29/0x80 [drm_kms_helper]
[ +0.002472] [<ffffffffa03f9642>] drm_fb_helper_set_par+0x22/0x50
[drm_kms_helper]
[ +0.002483] [<ffffffffa03f954f>]
drm_fb_helper_hotplug_event+0x8f/0xe0 [drm_kms_helper]
[ +0.002504] [<ffffffffa03f95ec>]
drm_fb_helper_restore_fbdev_mode_unlocked+0x4c/0x80 [drm_kms_helper]
[ +0.002533] [<ffffffffa0860b3e>] intel_fbdev_restore_mode+0x1e/0x50 [i915]
[ +0.002492] [<ffffffffa088795e>] i915_driver_lastclose+0xe/0x20 [i915]
[ +0.002424] [<ffffffffa0314d3e>] drm_lastclose+0x2e/0x150 [drm]
[ +0.002366] [<ffffffffa0315128>] drm_release+0x2c8/0x4b0 [drm]
[ +0.002299] [<ffffffff8121c66f>] __fput+0xdf/0x1f0
[ +0.002241] [<ffffffff8121c7ce>] ____fput+0xe/0x10
[ +0.002171] [<ffffffff810b9727>] task_work_run+0xb7/0xf0
[ +0.002124] [<ffffffff81014cdd>] do_notify_resume+0x8d/0xa0
[ +0.002067] [<ffffffff817815a3>] int_signal+0x12/0x17
[ +0.002016] Code: 8b 04 25 08 b9 00 00 48 8b 80 38 c0 ff ff a8 08 0f
85 c2 00 00 00 49 89 ff 49 89 f4 89 d3 48 8b 47 18 48 85 c0 0f 84 1d
01 00 00 <8b> 40 28 85 c0 0f 84 a2 00 00 00 49 8d 47 20 48 89 c7 48 89
45
[ +0.004217] RIP [<ffffffff810e37d3>] mutex_optimistic_spin+0x53/0x1f0
[ +0.001983] RSP <ffff88022358bae8>
[ +0.009890] ---[ end trace ff7adae285a9d5a9 ]---
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [git pull] drm fixes
2015-03-23 15:33 ` Josh Boyer
@ 2015-03-23 18:34 ` Josh Boyer
-1 siblings, 0 replies; 71+ messages in thread
From: Josh Boyer @ 2015-03-23 18:34 UTC (permalink / raw)
To: Dave Airlie, Xi Ruoyao
Cc: Damien Lespiau, Linus Torvalds, DRI mailing list,
Linux-Kernel@Vger. Kernel. Org, Intel Graphics Development
On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
<snip>
>> Xi Ruoyao (1):
>> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
Turns out to be that commit.
git bisect start 'drivers/gpu/drm/i915/'
# good: [b314acaccd7e0d55314d96be4a33b5f50d0b3344] Merge branch
'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
git bisect good b314acaccd7e0d55314d96be4a33b5f50d0b3344
# bad: [bc465aa9d045feb0e13b4a8f32cc33c1943f62d6] Linux 4.0-rc5
git bisect bad bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
# bad: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] drm/i915: Ensure
plane->state->fb stays in sync with plane->fb
git bisect bad 319c1d420a0b62d9dbb88104afebaabc968cdbfa
# first bad commit: [319c1d420a0b62d9dbb88104afebaabc968cdbfa]
drm/i915: Ensure plane->state->fb stays in sync with plane->fb
Doing a straight revert on top of 4.0-rc5 makes things work again,
albeit with the WARN_ON(obj->frontbuffer_bits) splat still being
there.
josh
> 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.000039] WARNING: CPU: 0 PID: 63 at
> drivers/gpu/drm/i915/i915_gem.c:4525 i915_gem_free_object+0x2e5/0x320
> [i915]()
> [ +0.000002] 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.
>
> josh
>
> Backtrace via 'insmod i915.ko.xz' in headless state with 4.0-rc5:
>
> [ +0.063764] vgaarb: device changed decodes:
> PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
> [ +0.007099] ------------[ cut here ]------------
> [ +0.000037] WARNING: CPU: 1 PID: 1486 at include/linux/kref.h:47
> drm_framebuffer_reference+0x7a/0x90 [drm]()
> [ +0.000003] Modules linked in: i915(+) ip6t_rpfilter ip6t_REJECT
> nf_reject_ipv6 xt_conntrack bnep iTCO_wdt iTCO_vendor_support
> ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables
> ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6
> ip6table_mangle ip6table_security ip6table_raw ip6table_filter
> ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4
> nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw arc4
> iwlmvm mac80211 intel_rapl coretemp kvm_intel kvm iwlwifi btusb
> bluetooth i2c_algo_bit cfg80211 drm_kms_helper crct10dif_pclmul
> snd_hda_codec_hdmi crc32_pclmul crc32c_intel ghash_clmulni_intel
> snd_hda_codec_realtek vfat snd_hda_codec_generic snd_intel_sst_acpi
> fat serio_raw snd_intel_sst_core snd_hda_intel i2c_i801 drm
> snd_soc_sst_mfld_platform snd_hda_controller
> [ +0.000046] r8169 lpc_ich snd_soc_rt5640 snd_hda_codec mfd_core
> snd_soc_rl6231 mii mei_txe ir_lirc_codec ir_xmp_decoder
> ir_mce_kbd_decoder lirc_dev snd_soc_core ir_sharp_decoder shpchp
> ir_sanyo_decoder ir_sony_decoder ir_jvc_decoder mei ir_rc6_decoder
> ir_rc5_decoder ir_nec_decoder snd_compress snd_pcm_dmaengine snd_hwdep
> snd_seq snd_seq_device iosf_mbi rc_rc6_mce snd_pcm ite_cir snd_timer
> rc_core dw_dmac snd dw_dmac_core regmap_i2c i2c_hid
> i2c_designware_platform soundcore rfkill_gpio i2c_designware_core
> rfkill snd_soc_sst_acpi nfsd auth_rpcgss nfs_acl lockd grace sunrpc
> sdhci_acpi video sdhci mmc_core
> [ +0.000051] CPU: 1 PID: 1486 Comm: insmod Not tainted
> 4.0.0-0.rc5.git0.1.fc23.x86_64 #1
> [ +0.000004] Hardware name:
> \xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff
> \xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff/DN2820FYK,
> BIOS FYBYT10H.86A.0034.2014.0513.1413 05/13/2014
> [ +0.000003] 0000000000000000 00000000ee312e2f ffff8800b7e03688
> ffffffff8177ac09
> [ +0.000004] 0000000000000000 0000000000000000 ffff8800b7e036c8
> ffffffff8109c78a
> [ +0.000004] ffff8800b7e036b8 ffff880234b46d80 ffff880228ef4f00
> ffff88021a540000
> [ +0.000005] Call Trace:
> [ +0.000009] [<ffffffff8177ac09>] dump_stack+0x45/0x57
> [ +0.000006] [<ffffffff8109c78a>] warn_slowpath_common+0x8a/0xc0
> [ +0.000004] [<ffffffff8109c8ba>] warn_slowpath_null+0x1a/0x20
> [ +0.000016] [<ffffffffa032022a>] drm_framebuffer_reference+0x7a/0x90 [drm]
> [ +0.000018] [<ffffffffa03326fd>] drm_atomic_set_fb_for_plane+0x2d/0x90 [drm]
> [ +0.000043] [<ffffffffa08418c5>]
> i9xx_get_initial_plane_config+0x295/0x3e0 [i915]
> [ +0.000006] [<ffffffff810c9207>] ? wake_up_process+0x27/0x50
> [ +0.000031] [<ffffffffa0852721>] intel_modeset_init+0x9f1/0x1a40 [i915]
> [ +0.000027] [<ffffffffa081bf5b>] ?
> valleyview_irq_postinstall+0x3b/0x50 [i915]
> [ +0.000034] [<ffffffffa08873ef>] i915_driver_load+0xe5f/0x10f0 [i915]
> [ +0.000006] [<ffffffff816964ab>] ? netlink_broadcast_filtered+0x12b/0x380
> [ +0.000005] [<ffffffff8139b730>] ? kobj_ns_drop+0x50/0x50
> [ +0.000004] [<ffffffff8139bae8>] ? kobject_uevent_env+0x178/0x540
> [ +0.000006] [<ffffffff814d98d9>] ? devtmpfs_create_node+0x109/0x140
> [ +0.000004] [<ffffffff814cde27>] ? get_device+0x17/0x30
> [ +0.000005] [<ffffffff814d3ce5>] ? klist_class_dev_get+0x15/0x20
> [ +0.000005] [<ffffffff81770a22>] ? klist_add_tail+0x32/0x40
> [ +0.000004] [<ffffffff814cf85f>] ? device_add+0x19f/0x6a0
> [ +0.000018] [<ffffffffa031a825>] drm_dev_register+0xb5/0x110 [drm]
> [ +0.000013] [<ffffffffa031d9bd>] drm_get_pci_dev+0x8d/0x200 [drm]
> [ +0.000022] [<ffffffffa07de22b>] i915_pci_probe+0x3b/0x60 [i915]
> [ +0.000006] [<ffffffff813e4485>] local_pci_probe+0x45/0xa0
> [ +0.000005] [<ffffffff81299a72>] ? sysfs_do_create_link_sd.isra.2+0x72/0xc0
> [ +0.000005] [<ffffffff813e57e9>] pci_device_probe+0xf9/0x150
> [ +0.000004] [<ffffffff814d2d83>] driver_probe_device+0xa3/0x400
> [ +0.000004] [<ffffffff814d31bb>] __driver_attach+0x9b/0xa0
> [ +0.000005] [<ffffffff814d3120>] ? __device_attach+0x40/0x40
> [ +0.000004] [<ffffffff814d0a43>] bus_for_each_dev+0x73/0xc0
> [ +0.000004] [<ffffffff814d27ee>] driver_attach+0x1e/0x20
> [ +0.000004] [<ffffffff814d23a0>] bus_add_driver+0x180/0x250
> [ +0.000004] [<ffffffff814d39b4>] driver_register+0x64/0xf0
> [ +0.000005] [<ffffffff813e3d0c>] __pci_register_driver+0x4c/0x50
> [ +0.000013] [<ffffffffa031dc2a>] drm_pci_init+0xfa/0x130 [drm]
> [ +0.000010] [<ffffffffa08e7000>] ? 0xffffffffa08e7000
> [ +0.000022] [<ffffffffa08e70a0>] i915_init+0xa0/0xa8 [i915]
> [ +0.000006] [<ffffffff81002148>] do_one_initcall+0xd8/0x210
> [ +0.000005] [<ffffffff811ded12>] ? __vunmap+0xa2/0x100
> [ +0.000005] [<ffffffff811fc599>] ? kmem_cache_alloc_trace+0x1a9/0x230
> [ +0.000005] [<ffffffff81779e0d>] ? do_init_module+0x28/0x1cc
> [ +0.000004] [<ffffffff81779e46>] do_init_module+0x61/0x1cc
> [ +0.000005] [<ffffffff81120c4b>] load_module+0x20ab/0x2520
> [ +0.000004] [<ffffffff8111c550>] ? store_uevent+0x70/0x70
> [ +0.000004] [<ffffffff811dd9ec>] ? vmap_page_range_noflush+0x22c/0x350
> [ +0.000005] [<ffffffff8112118d>] SyS_init_module+0xcd/0x120
> [ +0.000006] [<ffffffff81781349>] system_call_fastpath+0x12/0x17
> [ +0.000004] ---[ end trace ff7adae285a9d5a5 ]---
> [ +0.026613] i915 0000:00:02.0: No connectors reported connected with modes
> [ +0.000012] [drm] Cannot find any crtc or sizes - going 1024x768
> [ +0.002192] fbcon: inteldrmfb (fb0) is primary device
> [ +0.000122] Console: switching to colour frame buffer device 128x48
> [ +0.000014] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
> [ +0.000003] i915 0000:00:02.0: registered panic notifier
> [ +0.003554] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no)
> [ +0.002204] input: Video Bus as
> /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input13
> [ +0.001292] [drm] Initialized i915 1.6.0 20150130 for 0000:00:02.0 on minor 0
> [ +0.000873] ------------[ cut here ]------------
> [ +0.000037] WARNING: CPU: 0 PID: 563 at
> drivers/gpu/drm/drm_atomic.c:482 drm_atomic_check_only+0x33d/0x500
> [drm]()
> [ +0.000003] Modules linked in: i915(+) ip6t_rpfilter ip6t_REJECT
> nf_reject_ipv6 xt_conntrack bnep iTCO_wdt iTCO_vendor_support
> ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables
> ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6
> ip6table_mangle ip6table_security ip6table_raw ip6table_filter
> ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4
> nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw arc4
> iwlmvm mac80211 intel_rapl coretemp kvm_intel kvm iwlwifi btusb
> bluetooth i2c_algo_bit cfg80211 drm_kms_helper crct10dif_pclmul
> snd_hda_codec_hdmi crc32_pclmul crc32c_intel ghash_clmulni_intel
> snd_hda_codec_realtek vfat snd_hda_codec_generic snd_intel_sst_acpi
> fat serio_raw snd_intel_sst_core snd_hda_intel i2c_i801 drm
> snd_soc_sst_mfld_platform snd_hda_controller
> [ +0.000046] r8169 lpc_ich snd_soc_rt5640 snd_hda_codec mfd_core
> snd_soc_rl6231 mii mei_txe ir_lirc_codec ir_xmp_decoder
> ir_mce_kbd_decoder lirc_dev snd_soc_core ir_sharp_decoder shpchp
> ir_sanyo_decoder ir_sony_decoder ir_jvc_decoder mei ir_rc6_decoder
> ir_rc5_decoder ir_nec_decoder snd_compress snd_pcm_dmaengine snd_hwdep
> snd_seq snd_seq_device iosf_mbi rc_rc6_mce snd_pcm ite_cir snd_timer
> rc_core dw_dmac snd dw_dmac_core regmap_i2c i2c_hid
> i2c_designware_platform soundcore rfkill_gpio i2c_designware_core
> rfkill snd_soc_sst_acpi nfsd auth_rpcgss nfs_acl lockd grace sunrpc
> sdhci_acpi video sdhci mmc_core
> [ +0.000050] CPU: 0 PID: 563 Comm: Xorg Tainted: G W
> 4.0.0-0.rc5.git0.1.fc23.x86_64 #1
> [ +0.000003] Hardware name:
> \xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff
> \xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff/DN2820FYK,
> BIOS FYBYT10H.86A.0034.2014.0513.1413 05/13/2014
> [ +0.000003] 0000000000000000 000000001fbdeb23 ffff88022358bc28
> ffffffff8177ac09
> [ +0.000005] 0000000000000000 0000000000000000 ffff88022358bc68
> ffffffff8109c78a
> [ +0.000004] ffff88021a79fb00 0000000000000040 ffff8802344da000
> ffff88021a4482a0
> [ +0.000004] Call Trace:
> [ +0.000010] [<ffffffff8177ac09>] dump_stack+0x45/0x57
> [ +0.000006] [<ffffffff8109c78a>] warn_slowpath_common+0x8a/0xc0
> [ +0.000004] [<ffffffff8109c8ba>] warn_slowpath_null+0x1a/0x20
> [ +0.000017] [<ffffffffa033213d>] drm_atomic_check_only+0x33d/0x500 [drm]
> [ +0.000006] [<ffffffff811bc0a6>] ? kmemdup+0x36/0x50
> [ +0.000016] [<ffffffffa0332317>] drm_atomic_commit+0x17/0x60 [drm]
> [ +0.000011] [<ffffffffa03f571d>]
> drm_atomic_helper_plane_set_property+0x8d/0xd0 [drm_kms_helper]
> [ +0.000014] [<ffffffffa03208ad>] drm_mode_plane_set_obj_prop+0x2d/0x90 [drm]
> [ +0.000009] [<ffffffffa03f750b>] restore_fbdev_mode+0x6b/0xf0
> [drm_kms_helper]
> [ +0.000009] [<ffffffffa03f95c9>]
> drm_fb_helper_restore_fbdev_mode_unlocked+0x29/0x80 [drm_kms_helper]
> [ +0.000041] [<ffffffffa0860b3e>] intel_fbdev_restore_mode+0x1e/0x50 [i915]
> [ +0.000034] [<ffffffffa088795e>] i915_driver_lastclose+0xe/0x20 [i915]
> [ +0.000036] [<ffffffffa0314d3e>] drm_lastclose+0x2e/0x150 [drm]
> [ +0.000012] [<ffffffffa0315128>] drm_release+0x2c8/0x4b0 [drm]
> [ +0.000006] [<ffffffff8121c66f>] __fput+0xdf/0x1f0
> [ +0.000005] [<ffffffff8121c7ce>] ____fput+0xe/0x10
> [ +0.000004] [<ffffffff810b9727>] task_work_run+0xb7/0xf0
> [ +0.000006] [<ffffffff81014cdd>] do_notify_resume+0x8d/0xa0
> [ +0.000005] [<ffffffff817815a3>] int_signal+0x12/0x17
> [ +0.000003] ---[ end trace ff7adae285a9d5a6 ]---
> [ +0.097956] ------------[ cut here ]------------
> [ +0.000036] WARNING: CPU: 0 PID: 563 at
> drivers/gpu/drm/i915/i915_gem.c:4525 i915_gem_free_object+0x2e5/0x320
> [i915]()
> [ +0.000003] WARN_ON(obj->frontbuffer_bits)
> [ +0.000002] Modules linked in:
> [ +0.000002] i915 ip6t_rpfilter ip6t_REJECT nf_reject_ipv6
> xt_conntrack bnep iTCO_wdt iTCO_vendor_support ebtable_nat
> ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat
> nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle
> ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat
> nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack
> iptable_mangle iptable_security iptable_raw arc4 iwlmvm mac80211
> intel_rapl coretemp kvm_intel kvm iwlwifi btusb bluetooth i2c_algo_bit
> cfg80211 drm_kms_helper crct10dif_pclmul snd_hda_codec_hdmi
> crc32_pclmul crc32c_intel ghash_clmulni_intel snd_hda_codec_realtek
> vfat snd_hda_codec_generic snd_intel_sst_acpi fat serio_raw
> snd_intel_sst_core snd_hda_intel i2c_i801 drm
> snd_soc_sst_mfld_platform snd_hda_controller r8169 lpc_ich
> [ +0.000057] snd_soc_rt5640 snd_hda_codec mfd_core snd_soc_rl6231
> mii mei_txe ir_lirc_codec ir_xmp_decoder ir_mce_kbd_decoder lirc_dev
> snd_soc_core ir_sharp_decoder shpchp ir_sanyo_decoder ir_sony_decoder
> ir_jvc_decoder mei ir_rc6_decoder ir_rc5_decoder ir_nec_decoder
> snd_compress snd_pcm_dmaengine snd_hwdep snd_seq snd_seq_device
> iosf_mbi rc_rc6_mce snd_pcm ite_cir snd_timer rc_core dw_dmac snd
> dw_dmac_core regmap_i2c i2c_hid i2c_designware_platform soundcore
> rfkill_gpio i2c_designware_core rfkill snd_soc_sst_acpi nfsd
> auth_rpcgss nfs_acl lockd grace sunrpc sdhci_acpi video sdhci mmc_core
> [ +0.000048] CPU: 0 PID: 563 Comm: Xorg Tainted: G W
> 4.0.0-0.rc5.git0.1.fc23.x86_64 #1
> [ +0.000003] Hardware name:
> \xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff
> \xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff/DN2820FYK,
> BIOS FYBYT10H.86A.0034.2014.0513.1413 05/13/2014
> [ +0.000003] 0000000000000000 000000001fbdeb23 ffff88022358bbc8
> ffffffff8177ac09
> [ +0.000004] 0000000000000000 ffff88022358bc20 ffff88022358bc08
> ffffffff8109c78a
> [ +0.000004] ffff880228d95570 ffff8800ac0fc040 ffff8800ac0fc000
> ffff8800ac0fc0c0
> [ +0.000005] Call Trace:
> [ +0.000009] [<ffffffff8177ac09>] dump_stack+0x45/0x57
> [ +0.000006] [<ffffffff8109c78a>] warn_slowpath_common+0x8a/0xc0
> [ +0.000004] [<ffffffff8109c815>] warn_slowpath_fmt+0x55/0x70
> [ +0.000020] [<ffffffffa080ac6d>] ? i915_vma_unbind+0x24d/0x260 [i915]
> [ +0.000018] [<ffffffffa080c4f5>] i915_gem_free_object+0x2e5/0x320 [i915]
> [ +0.000006] [<ffffffff813b6451>] ? list_del+0x11/0x40
> [ +0.000020] [<ffffffffa0315417>] drm_gem_object_free+0x27/0x40 [drm]
> [ +0.000023] [<ffffffffa0840645>]
> intel_user_framebuffer_destroy+0x75/0xa0 [i915]
> [ +0.000015] [<ffffffffa0320a0e>] drm_framebuffer_free+0x4e/0x60 [drm]
> [ +0.000014] [<ffffffffa0322095>] drm_framebuffer_unreference+0x35/0x70 [drm]
> [ +0.000014] [<ffffffffa032219a>]
> drm_mode_set_config_internal+0xca/0x100 [drm]
> [ +0.000010] [<ffffffffa03f7568>] restore_fbdev_mode+0xc8/0xf0
> [drm_kms_helper]
> [ +0.000010] [<ffffffffa03f95c9>]
> drm_fb_helper_restore_fbdev_mode_unlocked+0x29/0x80 [drm_kms_helper]
> [ +0.000022] [<ffffffffa0860b3e>] intel_fbdev_restore_mode+0x1e/0x50 [i915]
> [ +0.000025] [<ffffffffa088795e>] i915_driver_lastclose+0xe/0x20 [i915]
> [ +0.000012] [<ffffffffa0314d3e>] drm_lastclose+0x2e/0x150 [drm]
> [ +0.000011] [<ffffffffa0315128>] drm_release+0x2c8/0x4b0 [drm]
> [ +0.000006] [<ffffffff8121c66f>] __fput+0xdf/0x1f0
> [ +0.000004] [<ffffffff8121c7ce>] ____fput+0xe/0x10
> [ +0.000005] [<ffffffff810b9727>] task_work_run+0xb7/0xf0
> [ +0.000006] [<ffffffff81014cdd>] do_notify_resume+0x8d/0xa0
> [ +0.000005] [<ffffffff817815a3>] int_signal+0x12/0x17
> [ +0.000002] ---[ end trace ff7adae285a9d5a7 ]---
> [ +0.191566] ------------[ cut here ]------------
> [ +0.000041] WARNING: CPU: 1 PID: 563 at
> drivers/gpu/drm/drm_atomic.c:482 drm_atomic_check_only+0x33d/0x500
> [drm]()
> [ +0.000003] Modules linked in: i915 ip6t_rpfilter ip6t_REJECT
> nf_reject_ipv6 xt_conntrack bnep iTCO_wdt iTCO_vendor_support
> ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables
> ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6
> ip6table_mangle ip6table_security ip6table_raw ip6table_filter
> ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4
> nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw arc4
> iwlmvm mac80211 intel_rapl coretemp kvm_intel kvm iwlwifi btusb
> bluetooth i2c_algo_bit cfg80211 drm_kms_helper crct10dif_pclmul
> snd_hda_codec_hdmi crc32_pclmul crc32c_intel ghash_clmulni_intel
> snd_hda_codec_realtek vfat snd_hda_codec_generic snd_intel_sst_acpi
> fat serio_raw snd_intel_sst_core snd_hda_intel i2c_i801 drm
> snd_soc_sst_mfld_platform snd_hda_controller
> [ +0.000046] r8169 lpc_ich snd_soc_rt5640 snd_hda_codec mfd_core
> snd_soc_rl6231 mii mei_txe ir_lirc_codec ir_xmp_decoder
> ir_mce_kbd_decoder lirc_dev snd_soc_core ir_sharp_decoder shpchp
> ir_sanyo_decoder ir_sony_decoder ir_jvc_decoder mei ir_rc6_decoder
> ir_rc5_decoder ir_nec_decoder snd_compress snd_pcm_dmaengine snd_hwdep
> snd_seq snd_seq_device iosf_mbi rc_rc6_mce snd_pcm ite_cir snd_timer
> rc_core dw_dmac snd dw_dmac_core regmap_i2c i2c_hid
> i2c_designware_platform soundcore rfkill_gpio i2c_designware_core
> rfkill snd_soc_sst_acpi nfsd auth_rpcgss nfs_acl lockd grace sunrpc
> sdhci_acpi video sdhci mmc_core
> [ +0.000051] CPU: 1 PID: 563 Comm: Xorg Tainted: G W
> 4.0.0-0.rc5.git0.1.fc23.x86_64 #1
> [ +0.000002] Hardware name:
> \xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff
> \xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff/DN2820FYK,
> BIOS FYBYT10H.86A.0034.2014.0513.1413 05/13/2014
> [ +0.000003] 0000000000000000 000000001fbdeb23 ffff88022358bbb8
> ffffffff8177ac09
> [ +0.000005] 0000000000000000 0000000000000000 ffff88022358bbf8
> ffffffff8109c78a
> [ +0.000004] ffff8800b7e13740 0000000000000040 ffff880228e6c480
> ffff88021e70ec60
> [ +0.000004] Call Trace:
> [ +0.000010] [<ffffffff8177ac09>] dump_stack+0x45/0x57
> [ +0.000006] [<ffffffff8109c78a>] warn_slowpath_common+0x8a/0xc0
> [ +0.000004] [<ffffffff8109c8ba>] warn_slowpath_null+0x1a/0x20
> [ +0.000016] [<ffffffffa033213d>] drm_atomic_check_only+0x33d/0x500 [drm]
> [ +0.000006] [<ffffffff811bc0a6>] ? kmemdup+0x36/0x50
> [ +0.000016] [<ffffffffa0332317>] drm_atomic_commit+0x17/0x60 [drm]
> [ +0.000011] [<ffffffffa03f571d>]
> drm_atomic_helper_plane_set_property+0x8d/0xd0 [drm_kms_helper]
> [ +0.000014] [<ffffffffa03208ad>] drm_mode_plane_set_obj_prop+0x2d/0x90 [drm]
> [ +0.000009] [<ffffffffa03f750b>] restore_fbdev_mode+0x6b/0xf0
> [drm_kms_helper]
> [ +0.000009] [<ffffffffa03f95c9>]
> drm_fb_helper_restore_fbdev_mode_unlocked+0x29/0x80 [drm_kms_helper]
> [ +0.000009] [<ffffffffa03f9642>] drm_fb_helper_set_par+0x22/0x50
> [drm_kms_helper]
> [ +0.000008] [<ffffffffa03f954f>]
> drm_fb_helper_hotplug_event+0x8f/0xe0 [drm_kms_helper]
> [ +0.000009] [<ffffffffa03f95ec>]
> drm_fb_helper_restore_fbdev_mode_unlocked+0x4c/0x80 [drm_kms_helper]
> [ +0.000030] [<ffffffffa0860b3e>] intel_fbdev_restore_mode+0x1e/0x50 [i915]
> [ +0.000026] [<ffffffffa088795e>] i915_driver_lastclose+0xe/0x20 [i915]
> [ +0.000012] [<ffffffffa0314d3e>] drm_lastclose+0x2e/0x150 [drm]
> [ +0.000012] [<ffffffffa0315128>] drm_release+0x2c8/0x4b0 [drm]
> [ +0.000005] [<ffffffff8121c66f>] __fput+0xdf/0x1f0
> [ +0.000005] [<ffffffff8121c7ce>] ____fput+0xe/0x10
> [ +0.000004] [<ffffffff810b9727>] task_work_run+0xb7/0xf0
> [ +0.000006] [<ffffffff81014cdd>] do_notify_resume+0x8d/0xa0
> [ +0.000005] [<ffffffff817815a3>] int_signal+0x12/0x17
> [ +0.000003] ---[ end trace ff7adae285a9d5a8 ]---
> [ +0.000015] general protection fault: 0000 [#1] SMP
> [ +0.000054] Modules linked in: i915 ip6t_rpfilter ip6t_REJECT
> nf_reject_ipv6 xt_conntrack bnep iTCO_wdt iTCO_vendor_support
> ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables
> ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6
> ip6table_mangle ip6table_security ip6table_raw ip6table_filter
> ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4
> nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw arc4
> iwlmvm mac80211 intel_rapl coretemp kvm_intel kvm iwlwifi btusb
> bluetooth i2c_algo_bit cfg80211 drm_kms_helper crct10dif_pclmul
> snd_hda_codec_hdmi crc32_pclmul crc32c_intel ghash_clmulni_intel
> snd_hda_codec_realtek vfat snd_hda_codec_generic snd_intel_sst_acpi
> fat serio_raw snd_intel_sst_core snd_hda_intel i2c_i801 drm
> snd_soc_sst_mfld_platform snd_hda_controller
> [ +0.000702] r8169 lpc_ich snd_soc_rt5640 snd_hda_codec mfd_core
> snd_soc_rl6231 mii mei_txe ir_lirc_codec ir_xmp_decoder
> ir_mce_kbd_decoder lirc_dev snd_soc_core ir_sharp_decoder shpchp
> ir_sanyo_decoder ir_sony_decoder ir_jvc_decoder mei ir_rc6_decoder
> ir_rc5_decoder ir_nec_decoder snd_compress snd_pcm_dmaengine snd_hwdep
> snd_seq snd_seq_device iosf_mbi rc_rc6_mce snd_pcm ite_cir snd_timer
> rc_core dw_dmac snd dw_dmac_core regmap_i2c i2c_hid
> i2c_designware_platform soundcore rfkill_gpio i2c_designware_core
> rfkill snd_soc_sst_acpi nfsd auth_rpcgss nfs_acl lockd grace sunrpc
> sdhci_acpi video sdhci mmc_core
> [ +0.000532] CPU: 1 PID: 563 Comm: Xorg Tainted: G W
> 4.0.0-0.rc5.git0.1.fc23.x86_64 #1
> [ +0.000071] Hardware name:
> \xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff
> \xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff/DN2820FYK,
> BIOS FYBYT10H.86A.0034.2014.0513.1413 05/13/2014
> [ +0.000109] task: ffff8800b2e2c520 ti: ffff880223588000 task.ti:
> ffff880223588000
> [ +0.000059] RIP: 0010:[<ffffffff810e37d3>] [<ffffffff810e37d3>]
> mutex_optimistic_spin+0x53/0x1f0
> [ +0.000076] RSP: 0018:ffff88022358bae8 EFLAGS: 00010206
> [ +0.000044] RAX: 00008124f0000118 RBX: 0000000000000000 RCX: 0000000000000002
> [ +0.000056] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff880234b46528
> [ +0.000057] RBP: ffff88022358bb38 R08: 0000000000000096 R09: 000000000000041f
> [ +0.000057] R10: 0000000000000000 R11: 000000000000041f R12: 0000000000000000
> [ +0.000056] R13: ffff8800b2e2c520 R14: ffff880234b46d80 R15: ffff880234b46528
> [ +0.002152] FS: 00007fd5c325d9c0(0000) GS:ffff88023fd00000(0000)
> knlGS:0000000000000000
> [ +0.002190] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ +0.002192] CR2: 00007fb821fd8b50 CR3: 0000000228d2a000 CR4: 00000000001007e0
> [ +0.002217] Stack:
> [ +0.002206] ffff88022358bb58 ffff8800b2e2c520 0000000000000000
> 0000000000000246
> [ +0.002292] ffff88022358bb78 ffff880234b46528 ffff880234b46528
> ffff8800b2e2c520
> [ +0.002299] ffff880234b46d80 0000000000000000 ffff88022358bb98
> ffffffff8177f1aa
> [ +0.002310] Call Trace:
> [ +0.002262] [<ffffffff8177f1aa>] __mutex_lock_slowpath+0x3a/0x120
> [ +0.002297] [<ffffffff81779c67>] ? printk+0x55/0x6b
> [ +0.002312] [<ffffffff8177f2b3>] mutex_lock+0x23/0x40
> [ +0.002308] [<ffffffffa03209ea>] drm_framebuffer_free+0x2a/0x60 [drm]
> [ +0.002329] [<ffffffffa0322095>] drm_framebuffer_unreference+0x35/0x70 [drm]
> [ +0.002319] [<ffffffffa03f5bef>]
> drm_atomic_helper_plane_destroy_state+0x1f/0x30 [drm_kms_helper]
> [ +0.002366] [<ffffffffa0863f6e>] intel_plane_destroy_state+0xe/0x10 [i915]
> [ +0.002368] [<ffffffffa0331a2a>] drm_atomic_state_clear+0x10a/0x170 [drm]
> [ +0.002378] [<ffffffffa0331aa6>] drm_atomic_state_free+0x16/0x60 [drm]
> [ +0.002362] [<ffffffffa03f5743>]
> drm_atomic_helper_plane_set_property+0xb3/0xd0 [drm_kms_helper]
> [ +0.002411] [<ffffffffa03208ad>] drm_mode_plane_set_obj_prop+0x2d/0x90 [drm]
> [ +0.002420] [<ffffffffa03f750b>] restore_fbdev_mode+0x6b/0xf0
> [drm_kms_helper]
> [ +0.002435] [<ffffffffa03f95c9>]
> drm_fb_helper_restore_fbdev_mode_unlocked+0x29/0x80 [drm_kms_helper]
> [ +0.002472] [<ffffffffa03f9642>] drm_fb_helper_set_par+0x22/0x50
> [drm_kms_helper]
> [ +0.002483] [<ffffffffa03f954f>]
> drm_fb_helper_hotplug_event+0x8f/0xe0 [drm_kms_helper]
> [ +0.002504] [<ffffffffa03f95ec>]
> drm_fb_helper_restore_fbdev_mode_unlocked+0x4c/0x80 [drm_kms_helper]
> [ +0.002533] [<ffffffffa0860b3e>] intel_fbdev_restore_mode+0x1e/0x50 [i915]
> [ +0.002492] [<ffffffffa088795e>] i915_driver_lastclose+0xe/0x20 [i915]
> [ +0.002424] [<ffffffffa0314d3e>] drm_lastclose+0x2e/0x150 [drm]
> [ +0.002366] [<ffffffffa0315128>] drm_release+0x2c8/0x4b0 [drm]
> [ +0.002299] [<ffffffff8121c66f>] __fput+0xdf/0x1f0
> [ +0.002241] [<ffffffff8121c7ce>] ____fput+0xe/0x10
> [ +0.002171] [<ffffffff810b9727>] task_work_run+0xb7/0xf0
> [ +0.002124] [<ffffffff81014cdd>] do_notify_resume+0x8d/0xa0
> [ +0.002067] [<ffffffff817815a3>] int_signal+0x12/0x17
> [ +0.002016] Code: 8b 04 25 08 b9 00 00 48 8b 80 38 c0 ff ff a8 08 0f
> 85 c2 00 00 00 49 89 ff 49 89 f4 89 d3 48 8b 47 18 48 85 c0 0f 84 1d
> 01 00 00 <8b> 40 28 85 c0 0f 84 a2 00 00 00 49 8d 47 20 48 89 c7 48 89
> 45
> [ +0.004217] RIP [<ffffffff810e37d3>] mutex_optimistic_spin+0x53/0x1f0
> [ +0.001983] RSP <ffff88022358bae8>
> [ +0.009890] ---[ end trace ff7adae285a9d5a9 ]---
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [git pull] drm fixes
@ 2015-03-23 18:34 ` Josh Boyer
0 siblings, 0 replies; 71+ messages in thread
From: Josh Boyer @ 2015-03-23 18:34 UTC (permalink / raw)
To: Dave Airlie, Xi Ruoyao
Cc: Linus Torvalds, Linux-Kernel@Vger. Kernel. Org, DRI mailing list,
Intel Graphics Development
On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
<snip>
>> Xi Ruoyao (1):
>> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
Turns out to be that commit.
git bisect start 'drivers/gpu/drm/i915/'
# good: [b314acaccd7e0d55314d96be4a33b5f50d0b3344] Merge branch
'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
git bisect good b314acaccd7e0d55314d96be4a33b5f50d0b3344
# bad: [bc465aa9d045feb0e13b4a8f32cc33c1943f62d6] Linux 4.0-rc5
git bisect bad bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
# bad: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] drm/i915: Ensure
plane->state->fb stays in sync with plane->fb
git bisect bad 319c1d420a0b62d9dbb88104afebaabc968cdbfa
# first bad commit: [319c1d420a0b62d9dbb88104afebaabc968cdbfa]
drm/i915: Ensure plane->state->fb stays in sync with plane->fb
Doing a straight revert on top of 4.0-rc5 makes things work again,
albeit with the WARN_ON(obj->frontbuffer_bits) splat still being
there.
josh
> 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.000039] WARNING: CPU: 0 PID: 63 at
> drivers/gpu/drm/i915/i915_gem.c:4525 i915_gem_free_object+0x2e5/0x320
> [i915]()
> [ +0.000002] 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.
>
> josh
>
> Backtrace via 'insmod i915.ko.xz' in headless state with 4.0-rc5:
>
> [ +0.063764] vgaarb: device changed decodes:
> PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
> [ +0.007099] ------------[ cut here ]------------
> [ +0.000037] WARNING: CPU: 1 PID: 1486 at include/linux/kref.h:47
> drm_framebuffer_reference+0x7a/0x90 [drm]()
> [ +0.000003] Modules linked in: i915(+) ip6t_rpfilter ip6t_REJECT
> nf_reject_ipv6 xt_conntrack bnep iTCO_wdt iTCO_vendor_support
> ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables
> ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6
> ip6table_mangle ip6table_security ip6table_raw ip6table_filter
> ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4
> nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw arc4
> iwlmvm mac80211 intel_rapl coretemp kvm_intel kvm iwlwifi btusb
> bluetooth i2c_algo_bit cfg80211 drm_kms_helper crct10dif_pclmul
> snd_hda_codec_hdmi crc32_pclmul crc32c_intel ghash_clmulni_intel
> snd_hda_codec_realtek vfat snd_hda_codec_generic snd_intel_sst_acpi
> fat serio_raw snd_intel_sst_core snd_hda_intel i2c_i801 drm
> snd_soc_sst_mfld_platform snd_hda_controller
> [ +0.000046] r8169 lpc_ich snd_soc_rt5640 snd_hda_codec mfd_core
> snd_soc_rl6231 mii mei_txe ir_lirc_codec ir_xmp_decoder
> ir_mce_kbd_decoder lirc_dev snd_soc_core ir_sharp_decoder shpchp
> ir_sanyo_decoder ir_sony_decoder ir_jvc_decoder mei ir_rc6_decoder
> ir_rc5_decoder ir_nec_decoder snd_compress snd_pcm_dmaengine snd_hwdep
> snd_seq snd_seq_device iosf_mbi rc_rc6_mce snd_pcm ite_cir snd_timer
> rc_core dw_dmac snd dw_dmac_core regmap_i2c i2c_hid
> i2c_designware_platform soundcore rfkill_gpio i2c_designware_core
> rfkill snd_soc_sst_acpi nfsd auth_rpcgss nfs_acl lockd grace sunrpc
> sdhci_acpi video sdhci mmc_core
> [ +0.000051] CPU: 1 PID: 1486 Comm: insmod Not tainted
> 4.0.0-0.rc5.git0.1.fc23.x86_64 #1
> [ +0.000004] Hardware name:
> \xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff
> \xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff/DN2820FYK,
> BIOS FYBYT10H.86A.0034.2014.0513.1413 05/13/2014
> [ +0.000003] 0000000000000000 00000000ee312e2f ffff8800b7e03688
> ffffffff8177ac09
> [ +0.000004] 0000000000000000 0000000000000000 ffff8800b7e036c8
> ffffffff8109c78a
> [ +0.000004] ffff8800b7e036b8 ffff880234b46d80 ffff880228ef4f00
> ffff88021a540000
> [ +0.000005] Call Trace:
> [ +0.000009] [<ffffffff8177ac09>] dump_stack+0x45/0x57
> [ +0.000006] [<ffffffff8109c78a>] warn_slowpath_common+0x8a/0xc0
> [ +0.000004] [<ffffffff8109c8ba>] warn_slowpath_null+0x1a/0x20
> [ +0.000016] [<ffffffffa032022a>] drm_framebuffer_reference+0x7a/0x90 [drm]
> [ +0.000018] [<ffffffffa03326fd>] drm_atomic_set_fb_for_plane+0x2d/0x90 [drm]
> [ +0.000043] [<ffffffffa08418c5>]
> i9xx_get_initial_plane_config+0x295/0x3e0 [i915]
> [ +0.000006] [<ffffffff810c9207>] ? wake_up_process+0x27/0x50
> [ +0.000031] [<ffffffffa0852721>] intel_modeset_init+0x9f1/0x1a40 [i915]
> [ +0.000027] [<ffffffffa081bf5b>] ?
> valleyview_irq_postinstall+0x3b/0x50 [i915]
> [ +0.000034] [<ffffffffa08873ef>] i915_driver_load+0xe5f/0x10f0 [i915]
> [ +0.000006] [<ffffffff816964ab>] ? netlink_broadcast_filtered+0x12b/0x380
> [ +0.000005] [<ffffffff8139b730>] ? kobj_ns_drop+0x50/0x50
> [ +0.000004] [<ffffffff8139bae8>] ? kobject_uevent_env+0x178/0x540
> [ +0.000006] [<ffffffff814d98d9>] ? devtmpfs_create_node+0x109/0x140
> [ +0.000004] [<ffffffff814cde27>] ? get_device+0x17/0x30
> [ +0.000005] [<ffffffff814d3ce5>] ? klist_class_dev_get+0x15/0x20
> [ +0.000005] [<ffffffff81770a22>] ? klist_add_tail+0x32/0x40
> [ +0.000004] [<ffffffff814cf85f>] ? device_add+0x19f/0x6a0
> [ +0.000018] [<ffffffffa031a825>] drm_dev_register+0xb5/0x110 [drm]
> [ +0.000013] [<ffffffffa031d9bd>] drm_get_pci_dev+0x8d/0x200 [drm]
> [ +0.000022] [<ffffffffa07de22b>] i915_pci_probe+0x3b/0x60 [i915]
> [ +0.000006] [<ffffffff813e4485>] local_pci_probe+0x45/0xa0
> [ +0.000005] [<ffffffff81299a72>] ? sysfs_do_create_link_sd.isra.2+0x72/0xc0
> [ +0.000005] [<ffffffff813e57e9>] pci_device_probe+0xf9/0x150
> [ +0.000004] [<ffffffff814d2d83>] driver_probe_device+0xa3/0x400
> [ +0.000004] [<ffffffff814d31bb>] __driver_attach+0x9b/0xa0
> [ +0.000005] [<ffffffff814d3120>] ? __device_attach+0x40/0x40
> [ +0.000004] [<ffffffff814d0a43>] bus_for_each_dev+0x73/0xc0
> [ +0.000004] [<ffffffff814d27ee>] driver_attach+0x1e/0x20
> [ +0.000004] [<ffffffff814d23a0>] bus_add_driver+0x180/0x250
> [ +0.000004] [<ffffffff814d39b4>] driver_register+0x64/0xf0
> [ +0.000005] [<ffffffff813e3d0c>] __pci_register_driver+0x4c/0x50
> [ +0.000013] [<ffffffffa031dc2a>] drm_pci_init+0xfa/0x130 [drm]
> [ +0.000010] [<ffffffffa08e7000>] ? 0xffffffffa08e7000
> [ +0.000022] [<ffffffffa08e70a0>] i915_init+0xa0/0xa8 [i915]
> [ +0.000006] [<ffffffff81002148>] do_one_initcall+0xd8/0x210
> [ +0.000005] [<ffffffff811ded12>] ? __vunmap+0xa2/0x100
> [ +0.000005] [<ffffffff811fc599>] ? kmem_cache_alloc_trace+0x1a9/0x230
> [ +0.000005] [<ffffffff81779e0d>] ? do_init_module+0x28/0x1cc
> [ +0.000004] [<ffffffff81779e46>] do_init_module+0x61/0x1cc
> [ +0.000005] [<ffffffff81120c4b>] load_module+0x20ab/0x2520
> [ +0.000004] [<ffffffff8111c550>] ? store_uevent+0x70/0x70
> [ +0.000004] [<ffffffff811dd9ec>] ? vmap_page_range_noflush+0x22c/0x350
> [ +0.000005] [<ffffffff8112118d>] SyS_init_module+0xcd/0x120
> [ +0.000006] [<ffffffff81781349>] system_call_fastpath+0x12/0x17
> [ +0.000004] ---[ end trace ff7adae285a9d5a5 ]---
> [ +0.026613] i915 0000:00:02.0: No connectors reported connected with modes
> [ +0.000012] [drm] Cannot find any crtc or sizes - going 1024x768
> [ +0.002192] fbcon: inteldrmfb (fb0) is primary device
> [ +0.000122] Console: switching to colour frame buffer device 128x48
> [ +0.000014] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
> [ +0.000003] i915 0000:00:02.0: registered panic notifier
> [ +0.003554] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no)
> [ +0.002204] input: Video Bus as
> /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input13
> [ +0.001292] [drm] Initialized i915 1.6.0 20150130 for 0000:00:02.0 on minor 0
> [ +0.000873] ------------[ cut here ]------------
> [ +0.000037] WARNING: CPU: 0 PID: 563 at
> drivers/gpu/drm/drm_atomic.c:482 drm_atomic_check_only+0x33d/0x500
> [drm]()
> [ +0.000003] Modules linked in: i915(+) ip6t_rpfilter ip6t_REJECT
> nf_reject_ipv6 xt_conntrack bnep iTCO_wdt iTCO_vendor_support
> ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables
> ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6
> ip6table_mangle ip6table_security ip6table_raw ip6table_filter
> ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4
> nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw arc4
> iwlmvm mac80211 intel_rapl coretemp kvm_intel kvm iwlwifi btusb
> bluetooth i2c_algo_bit cfg80211 drm_kms_helper crct10dif_pclmul
> snd_hda_codec_hdmi crc32_pclmul crc32c_intel ghash_clmulni_intel
> snd_hda_codec_realtek vfat snd_hda_codec_generic snd_intel_sst_acpi
> fat serio_raw snd_intel_sst_core snd_hda_intel i2c_i801 drm
> snd_soc_sst_mfld_platform snd_hda_controller
> [ +0.000046] r8169 lpc_ich snd_soc_rt5640 snd_hda_codec mfd_core
> snd_soc_rl6231 mii mei_txe ir_lirc_codec ir_xmp_decoder
> ir_mce_kbd_decoder lirc_dev snd_soc_core ir_sharp_decoder shpchp
> ir_sanyo_decoder ir_sony_decoder ir_jvc_decoder mei ir_rc6_decoder
> ir_rc5_decoder ir_nec_decoder snd_compress snd_pcm_dmaengine snd_hwdep
> snd_seq snd_seq_device iosf_mbi rc_rc6_mce snd_pcm ite_cir snd_timer
> rc_core dw_dmac snd dw_dmac_core regmap_i2c i2c_hid
> i2c_designware_platform soundcore rfkill_gpio i2c_designware_core
> rfkill snd_soc_sst_acpi nfsd auth_rpcgss nfs_acl lockd grace sunrpc
> sdhci_acpi video sdhci mmc_core
> [ +0.000050] CPU: 0 PID: 563 Comm: Xorg Tainted: G W
> 4.0.0-0.rc5.git0.1.fc23.x86_64 #1
> [ +0.000003] Hardware name:
> \xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff
> \xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff/DN2820FYK,
> BIOS FYBYT10H.86A.0034.2014.0513.1413 05/13/2014
> [ +0.000003] 0000000000000000 000000001fbdeb23 ffff88022358bc28
> ffffffff8177ac09
> [ +0.000005] 0000000000000000 0000000000000000 ffff88022358bc68
> ffffffff8109c78a
> [ +0.000004] ffff88021a79fb00 0000000000000040 ffff8802344da000
> ffff88021a4482a0
> [ +0.000004] Call Trace:
> [ +0.000010] [<ffffffff8177ac09>] dump_stack+0x45/0x57
> [ +0.000006] [<ffffffff8109c78a>] warn_slowpath_common+0x8a/0xc0
> [ +0.000004] [<ffffffff8109c8ba>] warn_slowpath_null+0x1a/0x20
> [ +0.000017] [<ffffffffa033213d>] drm_atomic_check_only+0x33d/0x500 [drm]
> [ +0.000006] [<ffffffff811bc0a6>] ? kmemdup+0x36/0x50
> [ +0.000016] [<ffffffffa0332317>] drm_atomic_commit+0x17/0x60 [drm]
> [ +0.000011] [<ffffffffa03f571d>]
> drm_atomic_helper_plane_set_property+0x8d/0xd0 [drm_kms_helper]
> [ +0.000014] [<ffffffffa03208ad>] drm_mode_plane_set_obj_prop+0x2d/0x90 [drm]
> [ +0.000009] [<ffffffffa03f750b>] restore_fbdev_mode+0x6b/0xf0
> [drm_kms_helper]
> [ +0.000009] [<ffffffffa03f95c9>]
> drm_fb_helper_restore_fbdev_mode_unlocked+0x29/0x80 [drm_kms_helper]
> [ +0.000041] [<ffffffffa0860b3e>] intel_fbdev_restore_mode+0x1e/0x50 [i915]
> [ +0.000034] [<ffffffffa088795e>] i915_driver_lastclose+0xe/0x20 [i915]
> [ +0.000036] [<ffffffffa0314d3e>] drm_lastclose+0x2e/0x150 [drm]
> [ +0.000012] [<ffffffffa0315128>] drm_release+0x2c8/0x4b0 [drm]
> [ +0.000006] [<ffffffff8121c66f>] __fput+0xdf/0x1f0
> [ +0.000005] [<ffffffff8121c7ce>] ____fput+0xe/0x10
> [ +0.000004] [<ffffffff810b9727>] task_work_run+0xb7/0xf0
> [ +0.000006] [<ffffffff81014cdd>] do_notify_resume+0x8d/0xa0
> [ +0.000005] [<ffffffff817815a3>] int_signal+0x12/0x17
> [ +0.000003] ---[ end trace ff7adae285a9d5a6 ]---
> [ +0.097956] ------------[ cut here ]------------
> [ +0.000036] WARNING: CPU: 0 PID: 563 at
> drivers/gpu/drm/i915/i915_gem.c:4525 i915_gem_free_object+0x2e5/0x320
> [i915]()
> [ +0.000003] WARN_ON(obj->frontbuffer_bits)
> [ +0.000002] Modules linked in:
> [ +0.000002] i915 ip6t_rpfilter ip6t_REJECT nf_reject_ipv6
> xt_conntrack bnep iTCO_wdt iTCO_vendor_support ebtable_nat
> ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat
> nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle
> ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat
> nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack
> iptable_mangle iptable_security iptable_raw arc4 iwlmvm mac80211
> intel_rapl coretemp kvm_intel kvm iwlwifi btusb bluetooth i2c_algo_bit
> cfg80211 drm_kms_helper crct10dif_pclmul snd_hda_codec_hdmi
> crc32_pclmul crc32c_intel ghash_clmulni_intel snd_hda_codec_realtek
> vfat snd_hda_codec_generic snd_intel_sst_acpi fat serio_raw
> snd_intel_sst_core snd_hda_intel i2c_i801 drm
> snd_soc_sst_mfld_platform snd_hda_controller r8169 lpc_ich
> [ +0.000057] snd_soc_rt5640 snd_hda_codec mfd_core snd_soc_rl6231
> mii mei_txe ir_lirc_codec ir_xmp_decoder ir_mce_kbd_decoder lirc_dev
> snd_soc_core ir_sharp_decoder shpchp ir_sanyo_decoder ir_sony_decoder
> ir_jvc_decoder mei ir_rc6_decoder ir_rc5_decoder ir_nec_decoder
> snd_compress snd_pcm_dmaengine snd_hwdep snd_seq snd_seq_device
> iosf_mbi rc_rc6_mce snd_pcm ite_cir snd_timer rc_core dw_dmac snd
> dw_dmac_core regmap_i2c i2c_hid i2c_designware_platform soundcore
> rfkill_gpio i2c_designware_core rfkill snd_soc_sst_acpi nfsd
> auth_rpcgss nfs_acl lockd grace sunrpc sdhci_acpi video sdhci mmc_core
> [ +0.000048] CPU: 0 PID: 563 Comm: Xorg Tainted: G W
> 4.0.0-0.rc5.git0.1.fc23.x86_64 #1
> [ +0.000003] Hardware name:
> \xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff
> \xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff/DN2820FYK,
> BIOS FYBYT10H.86A.0034.2014.0513.1413 05/13/2014
> [ +0.000003] 0000000000000000 000000001fbdeb23 ffff88022358bbc8
> ffffffff8177ac09
> [ +0.000004] 0000000000000000 ffff88022358bc20 ffff88022358bc08
> ffffffff8109c78a
> [ +0.000004] ffff880228d95570 ffff8800ac0fc040 ffff8800ac0fc000
> ffff8800ac0fc0c0
> [ +0.000005] Call Trace:
> [ +0.000009] [<ffffffff8177ac09>] dump_stack+0x45/0x57
> [ +0.000006] [<ffffffff8109c78a>] warn_slowpath_common+0x8a/0xc0
> [ +0.000004] [<ffffffff8109c815>] warn_slowpath_fmt+0x55/0x70
> [ +0.000020] [<ffffffffa080ac6d>] ? i915_vma_unbind+0x24d/0x260 [i915]
> [ +0.000018] [<ffffffffa080c4f5>] i915_gem_free_object+0x2e5/0x320 [i915]
> [ +0.000006] [<ffffffff813b6451>] ? list_del+0x11/0x40
> [ +0.000020] [<ffffffffa0315417>] drm_gem_object_free+0x27/0x40 [drm]
> [ +0.000023] [<ffffffffa0840645>]
> intel_user_framebuffer_destroy+0x75/0xa0 [i915]
> [ +0.000015] [<ffffffffa0320a0e>] drm_framebuffer_free+0x4e/0x60 [drm]
> [ +0.000014] [<ffffffffa0322095>] drm_framebuffer_unreference+0x35/0x70 [drm]
> [ +0.000014] [<ffffffffa032219a>]
> drm_mode_set_config_internal+0xca/0x100 [drm]
> [ +0.000010] [<ffffffffa03f7568>] restore_fbdev_mode+0xc8/0xf0
> [drm_kms_helper]
> [ +0.000010] [<ffffffffa03f95c9>]
> drm_fb_helper_restore_fbdev_mode_unlocked+0x29/0x80 [drm_kms_helper]
> [ +0.000022] [<ffffffffa0860b3e>] intel_fbdev_restore_mode+0x1e/0x50 [i915]
> [ +0.000025] [<ffffffffa088795e>] i915_driver_lastclose+0xe/0x20 [i915]
> [ +0.000012] [<ffffffffa0314d3e>] drm_lastclose+0x2e/0x150 [drm]
> [ +0.000011] [<ffffffffa0315128>] drm_release+0x2c8/0x4b0 [drm]
> [ +0.000006] [<ffffffff8121c66f>] __fput+0xdf/0x1f0
> [ +0.000004] [<ffffffff8121c7ce>] ____fput+0xe/0x10
> [ +0.000005] [<ffffffff810b9727>] task_work_run+0xb7/0xf0
> [ +0.000006] [<ffffffff81014cdd>] do_notify_resume+0x8d/0xa0
> [ +0.000005] [<ffffffff817815a3>] int_signal+0x12/0x17
> [ +0.000002] ---[ end trace ff7adae285a9d5a7 ]---
> [ +0.191566] ------------[ cut here ]------------
> [ +0.000041] WARNING: CPU: 1 PID: 563 at
> drivers/gpu/drm/drm_atomic.c:482 drm_atomic_check_only+0x33d/0x500
> [drm]()
> [ +0.000003] Modules linked in: i915 ip6t_rpfilter ip6t_REJECT
> nf_reject_ipv6 xt_conntrack bnep iTCO_wdt iTCO_vendor_support
> ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables
> ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6
> ip6table_mangle ip6table_security ip6table_raw ip6table_filter
> ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4
> nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw arc4
> iwlmvm mac80211 intel_rapl coretemp kvm_intel kvm iwlwifi btusb
> bluetooth i2c_algo_bit cfg80211 drm_kms_helper crct10dif_pclmul
> snd_hda_codec_hdmi crc32_pclmul crc32c_intel ghash_clmulni_intel
> snd_hda_codec_realtek vfat snd_hda_codec_generic snd_intel_sst_acpi
> fat serio_raw snd_intel_sst_core snd_hda_intel i2c_i801 drm
> snd_soc_sst_mfld_platform snd_hda_controller
> [ +0.000046] r8169 lpc_ich snd_soc_rt5640 snd_hda_codec mfd_core
> snd_soc_rl6231 mii mei_txe ir_lirc_codec ir_xmp_decoder
> ir_mce_kbd_decoder lirc_dev snd_soc_core ir_sharp_decoder shpchp
> ir_sanyo_decoder ir_sony_decoder ir_jvc_decoder mei ir_rc6_decoder
> ir_rc5_decoder ir_nec_decoder snd_compress snd_pcm_dmaengine snd_hwdep
> snd_seq snd_seq_device iosf_mbi rc_rc6_mce snd_pcm ite_cir snd_timer
> rc_core dw_dmac snd dw_dmac_core regmap_i2c i2c_hid
> i2c_designware_platform soundcore rfkill_gpio i2c_designware_core
> rfkill snd_soc_sst_acpi nfsd auth_rpcgss nfs_acl lockd grace sunrpc
> sdhci_acpi video sdhci mmc_core
> [ +0.000051] CPU: 1 PID: 563 Comm: Xorg Tainted: G W
> 4.0.0-0.rc5.git0.1.fc23.x86_64 #1
> [ +0.000002] Hardware name:
> \xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff
> \xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff/DN2820FYK,
> BIOS FYBYT10H.86A.0034.2014.0513.1413 05/13/2014
> [ +0.000003] 0000000000000000 000000001fbdeb23 ffff88022358bbb8
> ffffffff8177ac09
> [ +0.000005] 0000000000000000 0000000000000000 ffff88022358bbf8
> ffffffff8109c78a
> [ +0.000004] ffff8800b7e13740 0000000000000040 ffff880228e6c480
> ffff88021e70ec60
> [ +0.000004] Call Trace:
> [ +0.000010] [<ffffffff8177ac09>] dump_stack+0x45/0x57
> [ +0.000006] [<ffffffff8109c78a>] warn_slowpath_common+0x8a/0xc0
> [ +0.000004] [<ffffffff8109c8ba>] warn_slowpath_null+0x1a/0x20
> [ +0.000016] [<ffffffffa033213d>] drm_atomic_check_only+0x33d/0x500 [drm]
> [ +0.000006] [<ffffffff811bc0a6>] ? kmemdup+0x36/0x50
> [ +0.000016] [<ffffffffa0332317>] drm_atomic_commit+0x17/0x60 [drm]
> [ +0.000011] [<ffffffffa03f571d>]
> drm_atomic_helper_plane_set_property+0x8d/0xd0 [drm_kms_helper]
> [ +0.000014] [<ffffffffa03208ad>] drm_mode_plane_set_obj_prop+0x2d/0x90 [drm]
> [ +0.000009] [<ffffffffa03f750b>] restore_fbdev_mode+0x6b/0xf0
> [drm_kms_helper]
> [ +0.000009] [<ffffffffa03f95c9>]
> drm_fb_helper_restore_fbdev_mode_unlocked+0x29/0x80 [drm_kms_helper]
> [ +0.000009] [<ffffffffa03f9642>] drm_fb_helper_set_par+0x22/0x50
> [drm_kms_helper]
> [ +0.000008] [<ffffffffa03f954f>]
> drm_fb_helper_hotplug_event+0x8f/0xe0 [drm_kms_helper]
> [ +0.000009] [<ffffffffa03f95ec>]
> drm_fb_helper_restore_fbdev_mode_unlocked+0x4c/0x80 [drm_kms_helper]
> [ +0.000030] [<ffffffffa0860b3e>] intel_fbdev_restore_mode+0x1e/0x50 [i915]
> [ +0.000026] [<ffffffffa088795e>] i915_driver_lastclose+0xe/0x20 [i915]
> [ +0.000012] [<ffffffffa0314d3e>] drm_lastclose+0x2e/0x150 [drm]
> [ +0.000012] [<ffffffffa0315128>] drm_release+0x2c8/0x4b0 [drm]
> [ +0.000005] [<ffffffff8121c66f>] __fput+0xdf/0x1f0
> [ +0.000005] [<ffffffff8121c7ce>] ____fput+0xe/0x10
> [ +0.000004] [<ffffffff810b9727>] task_work_run+0xb7/0xf0
> [ +0.000006] [<ffffffff81014cdd>] do_notify_resume+0x8d/0xa0
> [ +0.000005] [<ffffffff817815a3>] int_signal+0x12/0x17
> [ +0.000003] ---[ end trace ff7adae285a9d5a8 ]---
> [ +0.000015] general protection fault: 0000 [#1] SMP
> [ +0.000054] Modules linked in: i915 ip6t_rpfilter ip6t_REJECT
> nf_reject_ipv6 xt_conntrack bnep iTCO_wdt iTCO_vendor_support
> ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables
> ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6
> ip6table_mangle ip6table_security ip6table_raw ip6table_filter
> ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4
> nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw arc4
> iwlmvm mac80211 intel_rapl coretemp kvm_intel kvm iwlwifi btusb
> bluetooth i2c_algo_bit cfg80211 drm_kms_helper crct10dif_pclmul
> snd_hda_codec_hdmi crc32_pclmul crc32c_intel ghash_clmulni_intel
> snd_hda_codec_realtek vfat snd_hda_codec_generic snd_intel_sst_acpi
> fat serio_raw snd_intel_sst_core snd_hda_intel i2c_i801 drm
> snd_soc_sst_mfld_platform snd_hda_controller
> [ +0.000702] r8169 lpc_ich snd_soc_rt5640 snd_hda_codec mfd_core
> snd_soc_rl6231 mii mei_txe ir_lirc_codec ir_xmp_decoder
> ir_mce_kbd_decoder lirc_dev snd_soc_core ir_sharp_decoder shpchp
> ir_sanyo_decoder ir_sony_decoder ir_jvc_decoder mei ir_rc6_decoder
> ir_rc5_decoder ir_nec_decoder snd_compress snd_pcm_dmaengine snd_hwdep
> snd_seq snd_seq_device iosf_mbi rc_rc6_mce snd_pcm ite_cir snd_timer
> rc_core dw_dmac snd dw_dmac_core regmap_i2c i2c_hid
> i2c_designware_platform soundcore rfkill_gpio i2c_designware_core
> rfkill snd_soc_sst_acpi nfsd auth_rpcgss nfs_acl lockd grace sunrpc
> sdhci_acpi video sdhci mmc_core
> [ +0.000532] CPU: 1 PID: 563 Comm: Xorg Tainted: G W
> 4.0.0-0.rc5.git0.1.fc23.x86_64 #1
> [ +0.000071] Hardware name:
> \xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff
> \xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff/DN2820FYK,
> BIOS FYBYT10H.86A.0034.2014.0513.1413 05/13/2014
> [ +0.000109] task: ffff8800b2e2c520 ti: ffff880223588000 task.ti:
> ffff880223588000
> [ +0.000059] RIP: 0010:[<ffffffff810e37d3>] [<ffffffff810e37d3>]
> mutex_optimistic_spin+0x53/0x1f0
> [ +0.000076] RSP: 0018:ffff88022358bae8 EFLAGS: 00010206
> [ +0.000044] RAX: 00008124f0000118 RBX: 0000000000000000 RCX: 0000000000000002
> [ +0.000056] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff880234b46528
> [ +0.000057] RBP: ffff88022358bb38 R08: 0000000000000096 R09: 000000000000041f
> [ +0.000057] R10: 0000000000000000 R11: 000000000000041f R12: 0000000000000000
> [ +0.000056] R13: ffff8800b2e2c520 R14: ffff880234b46d80 R15: ffff880234b46528
> [ +0.002152] FS: 00007fd5c325d9c0(0000) GS:ffff88023fd00000(0000)
> knlGS:0000000000000000
> [ +0.002190] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ +0.002192] CR2: 00007fb821fd8b50 CR3: 0000000228d2a000 CR4: 00000000001007e0
> [ +0.002217] Stack:
> [ +0.002206] ffff88022358bb58 ffff8800b2e2c520 0000000000000000
> 0000000000000246
> [ +0.002292] ffff88022358bb78 ffff880234b46528 ffff880234b46528
> ffff8800b2e2c520
> [ +0.002299] ffff880234b46d80 0000000000000000 ffff88022358bb98
> ffffffff8177f1aa
> [ +0.002310] Call Trace:
> [ +0.002262] [<ffffffff8177f1aa>] __mutex_lock_slowpath+0x3a/0x120
> [ +0.002297] [<ffffffff81779c67>] ? printk+0x55/0x6b
> [ +0.002312] [<ffffffff8177f2b3>] mutex_lock+0x23/0x40
> [ +0.002308] [<ffffffffa03209ea>] drm_framebuffer_free+0x2a/0x60 [drm]
> [ +0.002329] [<ffffffffa0322095>] drm_framebuffer_unreference+0x35/0x70 [drm]
> [ +0.002319] [<ffffffffa03f5bef>]
> drm_atomic_helper_plane_destroy_state+0x1f/0x30 [drm_kms_helper]
> [ +0.002366] [<ffffffffa0863f6e>] intel_plane_destroy_state+0xe/0x10 [i915]
> [ +0.002368] [<ffffffffa0331a2a>] drm_atomic_state_clear+0x10a/0x170 [drm]
> [ +0.002378] [<ffffffffa0331aa6>] drm_atomic_state_free+0x16/0x60 [drm]
> [ +0.002362] [<ffffffffa03f5743>]
> drm_atomic_helper_plane_set_property+0xb3/0xd0 [drm_kms_helper]
> [ +0.002411] [<ffffffffa03208ad>] drm_mode_plane_set_obj_prop+0x2d/0x90 [drm]
> [ +0.002420] [<ffffffffa03f750b>] restore_fbdev_mode+0x6b/0xf0
> [drm_kms_helper]
> [ +0.002435] [<ffffffffa03f95c9>]
> drm_fb_helper_restore_fbdev_mode_unlocked+0x29/0x80 [drm_kms_helper]
> [ +0.002472] [<ffffffffa03f9642>] drm_fb_helper_set_par+0x22/0x50
> [drm_kms_helper]
> [ +0.002483] [<ffffffffa03f954f>]
> drm_fb_helper_hotplug_event+0x8f/0xe0 [drm_kms_helper]
> [ +0.002504] [<ffffffffa03f95ec>]
> drm_fb_helper_restore_fbdev_mode_unlocked+0x4c/0x80 [drm_kms_helper]
> [ +0.002533] [<ffffffffa0860b3e>] intel_fbdev_restore_mode+0x1e/0x50 [i915]
> [ +0.002492] [<ffffffffa088795e>] i915_driver_lastclose+0xe/0x20 [i915]
> [ +0.002424] [<ffffffffa0314d3e>] drm_lastclose+0x2e/0x150 [drm]
> [ +0.002366] [<ffffffffa0315128>] drm_release+0x2c8/0x4b0 [drm]
> [ +0.002299] [<ffffffff8121c66f>] __fput+0xdf/0x1f0
> [ +0.002241] [<ffffffff8121c7ce>] ____fput+0xe/0x10
> [ +0.002171] [<ffffffff810b9727>] task_work_run+0xb7/0xf0
> [ +0.002124] [<ffffffff81014cdd>] do_notify_resume+0x8d/0xa0
> [ +0.002067] [<ffffffff817815a3>] int_signal+0x12/0x17
> [ +0.002016] Code: 8b 04 25 08 b9 00 00 48 8b 80 38 c0 ff ff a8 08 0f
> 85 c2 00 00 00 49 89 ff 49 89 f4 89 d3 48 8b 47 18 48 85 c0 0f 84 1d
> 01 00 00 <8b> 40 28 85 c0 0f 84 a2 00 00 00 49 8d 47 20 48 89 c7 48 89
> 45
> [ +0.004217] RIP [<ffffffff810e37d3>] mutex_optimistic_spin+0x53/0x1f0
> [ +0.001983] RSP <ffff88022358bae8>
> [ +0.009890] ---[ end trace ff7adae285a9d5a9 ]---
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [git pull] drm fixes
2015-03-23 15:33 ` Josh Boyer
(?)
(?)
@ 2015-03-24 1:41 ` Dave Jones
2015-03-25 8:56 ` Daniel Vetter
-1 siblings, 1 reply; 71+ messages in thread
From: Dave Jones @ 2015-03-24 1:41 UTC (permalink / raw)
To: Josh Boyer
Cc: Dave Airlie, Damien Lespiau, Xi Ruoyao, Linus Torvalds,
DRI mailing list, Linux-Kernel@Vger. Kernel. Org,
Intel Graphics Development
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.000039] WARNING: CPU: 0 PID: 63 at
> drivers/gpu/drm/i915/i915_gem.c:4525 i915_gem_free_object+0x2e5/0x320
> [i915]()
> [ +0.000002] 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.000037] WARNING: CPU: 1 PID: 1486 at include/linux/kref.h:47
> drm_framebuffer_reference+0x7a/0x90 [drm]()
..
> [ +0.000037] 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: G W ): Poison overwritten
-----------------------------------------------------------------------------
Disabling lock debugging due to kernel taint
INFO: 0xffff8804277e5c78-0xffff8804277e5c78. 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 0xffffea00109df900 objects=31 used=31 fp=0x (null) flags=0x8000000000004080
INFO: Object 0xffff8804277e5c70 @offset=7280 fp=0xffff8804277e6288
Bytes b4 ffff8804277e5c60: 54 7a fb ff 00 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a Tz......ZZZZZZZZ
Object ffff8804277e5c70: 6b 6b 6b 6b 6b 6b 6b 6b 6a 6b 6b 6b 6b 6b 6b 6b kkkkkkkkjkkkkkkk
Object ffff8804277e5c80: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8804277e5c90: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8804277e5ca0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8804277e5cb0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8804277e5cc0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8804277e5cd0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8804277e5ce0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8804277e5cf0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8804277e5d00: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8804277e5d10: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8804277e5d20: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 kkkkkkkkkkkkkkk.
Redzone ffff8804277e5d30: bb bb bb bb bb bb bb bb ........
Padding ffff8804277e5e70: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ
CPU: 4 PID: 128 Comm: kworker/u16:4 Tainted: G B W 4.0.0-rc5-backupdebug+ #1
Workqueue: events_unbound async_run_entry_fn
ffff8804277e5c70 000000002ebc2945 ffff8800b780f578 ffffffff90780cc3
0000000000000000 ffff88042b804900 ffff8800b780f5b8 ffffffff901e76cc
0000000000000008 ffff880400000001 ffff8804277e5c79 ffff88042b804900
Call Trace:
[<ffffffff90780cc3>] dump_stack+0x4c/0x65
[<ffffffff901e76cc>] print_trailer+0x14c/0x200
[<ffffffff901e784f>] check_bytes_and_report+0xcf/0x110
[<ffffffff901e8717>] check_object+0x1d7/0x250
[<ffffffffc0335cac>] ? intel_plane_duplicate_state+0x2c/0xa0 [i915]
[<ffffffff901e8c14>] alloc_debug_processing+0xa4/0x1a0
[<ffffffff901eb5c9>] __slab_alloc.constprop.79+0x5a9/0x670
[<ffffffffc0335cac>] ? intel_plane_duplicate_state+0x2c/0xa0 [i915]
[<ffffffffc0335cac>] ? intel_plane_duplicate_state+0x2c/0xa0 [i915]
[<ffffffff901edc0e>] __kmalloc_track_caller+0x2ee/0x380
[<ffffffff901b2e40>] kmemdup+0x20/0x50
[<ffffffffc0335cac>] intel_plane_duplicate_state+0x2c/0xa0 [i915]
[<ffffffffc0239be8>] drm_atomic_get_plane_state+0x78/0xf0 [drm]
[<ffffffffc028d428>] drm_atomic_helper_plane_set_property+0x68/0xd0 [drm_kms_helper]
[<ffffffffc022824d>] drm_mode_plane_set_obj_prop+0x2d/0x90 [drm]
[<ffffffffc028ee4b>] restore_fbdev_mode+0x6b/0xf0 [drm_kms_helper]
[<ffffffffc0290f09>] drm_fb_helper_restore_fbdev_mode_unlocked+0x29/0x80 [drm_kms_helper]
[<ffffffffc0290f82>] drm_fb_helper_set_par+0x22/0x50 [drm_kms_helper]
[<ffffffffc0290e91>] drm_fb_helper_hotplug_event+0x91/0xe0 [drm_kms_helper]
[<ffffffffc0290f2c>] drm_fb_helper_restore_fbdev_mode_unlocked+0x4c/0x80 [drm_kms_helper]
[<ffffffffc0290f82>] drm_fb_helper_set_par+0x22/0x50 [drm_kms_helper]
[<ffffffffc03313ba>] intel_fbdev_set_par+0x1a/0x60 [i915]
[<ffffffff9047e488>] fbcon_init+0x588/0x610
[<ffffffff90500f4c>] visual_init+0xbc/0x120
[<ffffffff9050376e>] do_bind_con_driver+0x17e/0x3b0
[<ffffffff90503ef4>] do_take_over_console+0xb4/0x1e0
[<ffffffff90479283>] do_fbcon_takeover+0x63/0xd0
[<ffffffff9047efbd>] fbcon_event_notify+0x6cd/0x7d0
[<ffffffff9009d0e2>] notifier_call_chain+0x62/0x100
[<ffffffff9009d391>] __blocking_notifier_call_chain+0x51/0x70
[<ffffffff9009d3c6>] blocking_notifier_call_chain+0x16/0x20
[<ffffffff90484f1b>] fb_notifier_call_chain+0x1b/0x20
[<ffffffff90487267>] register_framebuffer+0x207/0x340
[<ffffffffc0291214>] drm_fb_helper_initial_config+0x264/0x3c0 [drm_kms_helper]
[<ffffffffc03326db>] intel_fbdev_initial_config+0x1b/0x20 [i915]
[<ffffffff9009f69a>] async_run_entry_fn+0x4a/0x150
[<ffffffff90095819>] process_one_work+0x209/0x810
[<ffffffff90095780>] ? process_one_work+0x170/0x810
[<ffffffff90095e8b>] worker_thread+0x6b/0x490
[<ffffffff90095e20>] ? process_one_work+0x810/0x810
[<ffffffff9009ba79>] kthread+0x119/0x130
[<ffffffff9009b960>] ? kthread_create_on_node+0x240/0x240
[<ffffffff90789888>] ret_from_fork+0x58/0x90
[<ffffffff9009b960>] ? kthread_create_on_node+0x240/0x240
FIX kmalloc-192: Restoring 0xffff8804277e5c78-0xffff8804277e5c78=0x6b
FIX kmalloc-192: Marking all objects used
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [Intel-gfx] [git pull] drm fixes
2015-03-23 18:34 ` Josh Boyer
@ 2015-03-24 7:32 ` Daniel Vetter
-1 siblings, 0 replies; 71+ messages in thread
From: Daniel Vetter @ 2015-03-24 7:32 UTC (permalink / raw)
To: Josh Boyer
Cc: Dave Airlie, Xi Ruoyao, Linus Torvalds,
Linux-Kernel@Vger. Kernel. Org, DRI mailing list,
Intel Graphics Development
On Mon, Mar 23, 2015 at 02:34:27PM -0400, Josh Boyer wrote:
> On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
>
> <snip>
>
> >> Xi Ruoyao (1):
> >> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
>
> Turns out to be that commit.
>
> git bisect start 'drivers/gpu/drm/i915/'
> # good: [b314acaccd7e0d55314d96be4a33b5f50d0b3344] Merge branch
> 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
> git bisect good b314acaccd7e0d55314d96be4a33b5f50d0b3344
> # bad: [bc465aa9d045feb0e13b4a8f32cc33c1943f62d6] Linux 4.0-rc5
> git bisect bad bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
> # bad: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] drm/i915: Ensure
> plane->state->fb stays in sync with plane->fb
> git bisect bad 319c1d420a0b62d9dbb88104afebaabc968cdbfa
> # first bad commit: [319c1d420a0b62d9dbb88104afebaabc968cdbfa]
> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
>
> Doing a straight revert on top of 4.0-rc5 makes things work again,
> albeit with the WARN_ON(obj->frontbuffer_bits) splat still being
> there.
Can you please test the tip of drm-fixes:
commit 8218c3f4df3bb1c637c17552405039a6dd3c1ee1
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Fri Feb 27 12:58:13 2015 +0100
drm: Fixup racy refcounting in plane_force_disable
http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes&id=8218c3f4df3bb1c637c17552405039a6dd3c1ee1
Because fumble that patch didn't make it to drm-fixes a while ago and
instead landed in drm-next.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [git pull] drm fixes
@ 2015-03-24 7:32 ` Daniel Vetter
0 siblings, 0 replies; 71+ messages in thread
From: Daniel Vetter @ 2015-03-24 7:32 UTC (permalink / raw)
To: Josh Boyer
Cc: Dave Airlie, Intel Graphics Development,
Linux-Kernel@Vger. Kernel. Org, DRI mailing list, Xi Ruoyao,
Linus Torvalds
On Mon, Mar 23, 2015 at 02:34:27PM -0400, Josh Boyer wrote:
> On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
>
> <snip>
>
> >> Xi Ruoyao (1):
> >> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
>
> Turns out to be that commit.
>
> git bisect start 'drivers/gpu/drm/i915/'
> # good: [b314acaccd7e0d55314d96be4a33b5f50d0b3344] Merge branch
> 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
> git bisect good b314acaccd7e0d55314d96be4a33b5f50d0b3344
> # bad: [bc465aa9d045feb0e13b4a8f32cc33c1943f62d6] Linux 4.0-rc5
> git bisect bad bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
> # bad: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] drm/i915: Ensure
> plane->state->fb stays in sync with plane->fb
> git bisect bad 319c1d420a0b62d9dbb88104afebaabc968cdbfa
> # first bad commit: [319c1d420a0b62d9dbb88104afebaabc968cdbfa]
> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
>
> Doing a straight revert on top of 4.0-rc5 makes things work again,
> albeit with the WARN_ON(obj->frontbuffer_bits) splat still being
> there.
Can you please test the tip of drm-fixes:
commit 8218c3f4df3bb1c637c17552405039a6dd3c1ee1
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Fri Feb 27 12:58:13 2015 +0100
drm: Fixup racy refcounting in plane_force_disable
http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes&id=8218c3f4df3bb1c637c17552405039a6dd3c1ee1
Because fumble that patch didn't make it to drm-fixes a while ago and
instead landed in drm-next.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [Intel-gfx] [git pull] drm fixes
2015-03-24 7:32 ` Daniel Vetter
@ 2015-03-24 13:15 ` Josh Boyer
-1 siblings, 0 replies; 71+ messages in thread
From: Josh Boyer @ 2015-03-24 13:15 UTC (permalink / raw)
To: Daniel Vetter, Dave Airlie, Xi Ruoyao, Linus Torvalds,
Linux-Kernel@Vger. Kernel. Org, DRI mailing list,
Intel Graphics Development
On Tue, Mar 24, 2015 at 3:32 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Mon, Mar 23, 2015 at 02:34:27PM -0400, Josh Boyer wrote:
>> On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
>>
>> <snip>
>>
>> >> Xi Ruoyao (1):
>> >> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
>>
>> Turns out to be that commit.
>>
>> git bisect start 'drivers/gpu/drm/i915/'
>> # good: [b314acaccd7e0d55314d96be4a33b5f50d0b3344] Merge branch
>> 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
>> git bisect good b314acaccd7e0d55314d96be4a33b5f50d0b3344
>> # bad: [bc465aa9d045feb0e13b4a8f32cc33c1943f62d6] Linux 4.0-rc5
>> git bisect bad bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
>> # bad: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] drm/i915: Ensure
>> plane->state->fb stays in sync with plane->fb
>> git bisect bad 319c1d420a0b62d9dbb88104afebaabc968cdbfa
>> # first bad commit: [319c1d420a0b62d9dbb88104afebaabc968cdbfa]
>> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
>>
>> Doing a straight revert on top of 4.0-rc5 makes things work again,
>> albeit with the WARN_ON(obj->frontbuffer_bits) splat still being
>> there.
>
> Can you please test the tip of drm-fixes:
>
> commit 8218c3f4df3bb1c637c17552405039a6dd3c1ee1
> Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> Date: Fri Feb 27 12:58:13 2015 +0100
>
> drm: Fixup racy refcounting in plane_force_disable
>
> http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes&id=8218c3f4df3bb1c637c17552405039a6dd3c1ee1
>
> Because fumble that patch didn't make it to drm-fixes a while ago and
> instead landed in drm-next.
That seems to have helped with totally different issues a macbook I
have was seeing. However, it still doesn't fix the issue with the
Celeron based NUC machine.
I built a kernel based on Linus' latest tree as of this morning,
without reverting 319c1d4 and adding the commit you pointed to. The
NUC still won't boot without HDMI connected. With HDMI connected I
still see the trace below. If I do the blacklist and then insmod
dance with HDMI unplugged it shows the same spew I reported yesterday
which starts with the same backtrace.
I'll try building a kernel with 319c1d4 reverted + your patch. I
suspect things will work fine with that combination because the two
issues are unrelated.
josh
[ +0.000027] WARNING: CPU: 1 PID: 144 at include/linux/kref.h:47
drm_framebuffer_reference+0x7a/0x90 [drm]()
[ +0.000003] Modules linked in: i915(+) i2c_algo_bit drm_kms_helper
drm sdhci_acpi sdhci mmc_core video
[ +0.000012] CPU: 1 PID: 144 Comm: systemd-udevd Not tainted
4.0.0-0.rc5.git1.1.fc23.x86_64 #1
[ +0.000003] Hardware name:
\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff
\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff/DN2820FYK,
BIOS FYBYT10H.86A.0034.2014.0513.1413 05/13/2014
[ +0.000003] 0000000000000000 00000000b82c27d6 ffff88003f98f688
ffffffff8177ada9
[ +0.000004] 0000000000000000 0000000000000000 ffff88003f98f6c8
ffffffff8109c78a
[ +0.000004] ffff8802345c91a8 ffff880234b0bd80 ffff880234b923c0
ffff88003fae0000
[ +0.000004] Call Trace:
[ +0.000010] [<ffffffff8177ada9>] dump_stack+0x45/0x57
[ +0.000005] [<ffffffff8109c78a>] warn_slowpath_common+0x8a/0xc0
[ +0.000004] [<ffffffff8109c8ba>] warn_slowpath_null+0x1a/0x20
[ +0.000012] [<ffffffffa00a822a>] drm_framebuffer_reference+0x7a/0x90 [drm]
[ +0.000016] [<ffffffffa00ba6ad>] drm_atomic_set_fb_for_plane+0x2d/0x90 [drm]
[ +0.000048] [<ffffffffa014e8c5>]
i9xx_get_initial_plane_config+0x295/0x3e0 [i915]
[ +0.000015] [<ffffffffa00b8ed6>] ? drm_modeset_unlock_all+0x36/0x70 [drm]
[ +0.000031] [<ffffffffa015f721>] intel_modeset_init+0x9f1/0x1a40 [i915]
[ +0.000027] [<ffffffffa0128f5b>] ?
valleyview_irq_postinstall+0x3b/0x50 [i915]
[ +0.000034] [<ffffffffa01943ef>] i915_driver_load+0xe5f/0x10f0 [i915]
[ +0.000005] [<ffffffff8169654b>] ? netlink_broadcast_filtered+0x12b/0x380
[ +0.000006] [<ffffffff8139b730>] ? kobj_ns_drop+0x50/0x50
[ +0.000004] [<ffffffff8139bae8>] ? kobject_uevent_env+0x178/0x540
[ +0.000006] [<ffffffff814d98d9>] ? devtmpfs_create_node+0x109/0x140
[ +0.000004] [<ffffffff814cde27>] ? get_device+0x17/0x30
[ +0.000005] [<ffffffff814d3ce5>] ? klist_class_dev_get+0x15/0x20
[ +0.000005] [<ffffffff81770bc2>] ? klist_add_tail+0x32/0x40
[ +0.000004] [<ffffffff814cf85f>] ? device_add+0x19f/0x6a0
[ +0.000012] [<ffffffffa00a2825>] drm_dev_register+0xb5/0x110 [drm]
[ +0.000011] [<ffffffffa00a59bd>] drm_get_pci_dev+0x8d/0x200 [drm]
[ +0.000022] [<ffffffffa00eb22b>] i915_pci_probe+0x3b/0x60 [i915]
[ +0.000006] [<ffffffff813e4485>] local_pci_probe+0x45/0xa0
[ +0.000005] [<ffffffff81299a72>] ? sysfs_do_create_link_sd.isra.2+0x72/0xc0
[ +0.000004] [<ffffffff813e57e9>] pci_device_probe+0xf9/0x150
[ +0.000005] [<ffffffff814d2d83>] driver_probe_device+0xa3/0x400
[ +0.000004] [<ffffffff814d31bb>] __driver_attach+0x9b/0xa0
[ +0.000004] [<ffffffff814d3120>] ? __device_attach+0x40/0x40
[ +0.000004] [<ffffffff814d0a43>] bus_for_each_dev+0x73/0xc0
[ +0.000004] [<ffffffff814d27ee>] driver_attach+0x1e/0x20
[ +0.000004] [<ffffffff814d23a0>] bus_add_driver+0x180/0x250
[ +0.000004] [<ffffffff814d39b4>] driver_register+0x64/0xf0
[ +0.000004] [<ffffffff813e3d0c>] __pci_register_driver+0x4c/0x50
[ +0.000012] [<ffffffffa00a5c2a>] drm_pci_init+0xfa/0x130 [drm]
[ +0.000004] [<ffffffffa01f4000>] ? 0xffffffffa01f4000
[ +0.000022] [<ffffffffa01f40a0>] i915_init+0xa0/0xa8 [i915]
[ +0.000006] [<ffffffff81002148>] do_one_initcall+0xd8/0x210
[ +0.000005] [<ffffffff811fc599>] ? kmem_cache_alloc_trace+0x1a9/0x230
[ +0.000004] [<ffffffff81779fad>] ? do_init_module+0x28/0x1cc
[ +0.000004] [<ffffffff81779fe6>] do_init_module+0x61/0x1cc
[ +0.000005] [<ffffffff81120c4b>] load_module+0x20ab/0x2520
[ +0.000004] [<ffffffff8111c550>] ? store_uevent+0x70/0x70
[ +0.000005] [<ffffffff811dd9ec>] ? vmap_page_range_noflush+0x22c/0x350
[ +0.000006] [<ffffffff8112118d>] SyS_init_module+0xcd/0x120
[ +0.000006] [<ffffffff81781509>] system_call_fastpath+0x12/0x17
[ +0.000003] ---[ end trace fde4b7d97a3cd3f5 ]---
[ +0.022245] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no)
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [git pull] drm fixes
@ 2015-03-24 13:15 ` Josh Boyer
0 siblings, 0 replies; 71+ messages in thread
From: Josh Boyer @ 2015-03-24 13:15 UTC (permalink / raw)
To: Daniel Vetter, Dave Airlie, Xi Ruoyao, Linus Torvalds,
Linux-Kernel@Vger. Kernel. Org, DRI mailing list,
Intel Graphics Development
On Tue, Mar 24, 2015 at 3:32 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Mon, Mar 23, 2015 at 02:34:27PM -0400, Josh Boyer wrote:
>> On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
>>
>> <snip>
>>
>> >> Xi Ruoyao (1):
>> >> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
>>
>> Turns out to be that commit.
>>
>> git bisect start 'drivers/gpu/drm/i915/'
>> # good: [b314acaccd7e0d55314d96be4a33b5f50d0b3344] Merge branch
>> 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
>> git bisect good b314acaccd7e0d55314d96be4a33b5f50d0b3344
>> # bad: [bc465aa9d045feb0e13b4a8f32cc33c1943f62d6] Linux 4.0-rc5
>> git bisect bad bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
>> # bad: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] drm/i915: Ensure
>> plane->state->fb stays in sync with plane->fb
>> git bisect bad 319c1d420a0b62d9dbb88104afebaabc968cdbfa
>> # first bad commit: [319c1d420a0b62d9dbb88104afebaabc968cdbfa]
>> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
>>
>> Doing a straight revert on top of 4.0-rc5 makes things work again,
>> albeit with the WARN_ON(obj->frontbuffer_bits) splat still being
>> there.
>
> Can you please test the tip of drm-fixes:
>
> commit 8218c3f4df3bb1c637c17552405039a6dd3c1ee1
> Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> Date: Fri Feb 27 12:58:13 2015 +0100
>
> drm: Fixup racy refcounting in plane_force_disable
>
> http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes&id=8218c3f4df3bb1c637c17552405039a6dd3c1ee1
>
> Because fumble that patch didn't make it to drm-fixes a while ago and
> instead landed in drm-next.
That seems to have helped with totally different issues a macbook I
have was seeing. However, it still doesn't fix the issue with the
Celeron based NUC machine.
I built a kernel based on Linus' latest tree as of this morning,
without reverting 319c1d4 and adding the commit you pointed to. The
NUC still won't boot without HDMI connected. With HDMI connected I
still see the trace below. If I do the blacklist and then insmod
dance with HDMI unplugged it shows the same spew I reported yesterday
which starts with the same backtrace.
I'll try building a kernel with 319c1d4 reverted + your patch. I
suspect things will work fine with that combination because the two
issues are unrelated.
josh
[ +0.000027] WARNING: CPU: 1 PID: 144 at include/linux/kref.h:47
drm_framebuffer_reference+0x7a/0x90 [drm]()
[ +0.000003] Modules linked in: i915(+) i2c_algo_bit drm_kms_helper
drm sdhci_acpi sdhci mmc_core video
[ +0.000012] CPU: 1 PID: 144 Comm: systemd-udevd Not tainted
4.0.0-0.rc5.git1.1.fc23.x86_64 #1
[ +0.000003] Hardware name:
\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff
\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff/DN2820FYK,
BIOS FYBYT10H.86A.0034.2014.0513.1413 05/13/2014
[ +0.000003] 0000000000000000 00000000b82c27d6 ffff88003f98f688
ffffffff8177ada9
[ +0.000004] 0000000000000000 0000000000000000 ffff88003f98f6c8
ffffffff8109c78a
[ +0.000004] ffff8802345c91a8 ffff880234b0bd80 ffff880234b923c0
ffff88003fae0000
[ +0.000004] Call Trace:
[ +0.000010] [<ffffffff8177ada9>] dump_stack+0x45/0x57
[ +0.000005] [<ffffffff8109c78a>] warn_slowpath_common+0x8a/0xc0
[ +0.000004] [<ffffffff8109c8ba>] warn_slowpath_null+0x1a/0x20
[ +0.000012] [<ffffffffa00a822a>] drm_framebuffer_reference+0x7a/0x90 [drm]
[ +0.000016] [<ffffffffa00ba6ad>] drm_atomic_set_fb_for_plane+0x2d/0x90 [drm]
[ +0.000048] [<ffffffffa014e8c5>]
i9xx_get_initial_plane_config+0x295/0x3e0 [i915]
[ +0.000015] [<ffffffffa00b8ed6>] ? drm_modeset_unlock_all+0x36/0x70 [drm]
[ +0.000031] [<ffffffffa015f721>] intel_modeset_init+0x9f1/0x1a40 [i915]
[ +0.000027] [<ffffffffa0128f5b>] ?
valleyview_irq_postinstall+0x3b/0x50 [i915]
[ +0.000034] [<ffffffffa01943ef>] i915_driver_load+0xe5f/0x10f0 [i915]
[ +0.000005] [<ffffffff8169654b>] ? netlink_broadcast_filtered+0x12b/0x380
[ +0.000006] [<ffffffff8139b730>] ? kobj_ns_drop+0x50/0x50
[ +0.000004] [<ffffffff8139bae8>] ? kobject_uevent_env+0x178/0x540
[ +0.000006] [<ffffffff814d98d9>] ? devtmpfs_create_node+0x109/0x140
[ +0.000004] [<ffffffff814cde27>] ? get_device+0x17/0x30
[ +0.000005] [<ffffffff814d3ce5>] ? klist_class_dev_get+0x15/0x20
[ +0.000005] [<ffffffff81770bc2>] ? klist_add_tail+0x32/0x40
[ +0.000004] [<ffffffff814cf85f>] ? device_add+0x19f/0x6a0
[ +0.000012] [<ffffffffa00a2825>] drm_dev_register+0xb5/0x110 [drm]
[ +0.000011] [<ffffffffa00a59bd>] drm_get_pci_dev+0x8d/0x200 [drm]
[ +0.000022] [<ffffffffa00eb22b>] i915_pci_probe+0x3b/0x60 [i915]
[ +0.000006] [<ffffffff813e4485>] local_pci_probe+0x45/0xa0
[ +0.000005] [<ffffffff81299a72>] ? sysfs_do_create_link_sd.isra.2+0x72/0xc0
[ +0.000004] [<ffffffff813e57e9>] pci_device_probe+0xf9/0x150
[ +0.000005] [<ffffffff814d2d83>] driver_probe_device+0xa3/0x400
[ +0.000004] [<ffffffff814d31bb>] __driver_attach+0x9b/0xa0
[ +0.000004] [<ffffffff814d3120>] ? __device_attach+0x40/0x40
[ +0.000004] [<ffffffff814d0a43>] bus_for_each_dev+0x73/0xc0
[ +0.000004] [<ffffffff814d27ee>] driver_attach+0x1e/0x20
[ +0.000004] [<ffffffff814d23a0>] bus_add_driver+0x180/0x250
[ +0.000004] [<ffffffff814d39b4>] driver_register+0x64/0xf0
[ +0.000004] [<ffffffff813e3d0c>] __pci_register_driver+0x4c/0x50
[ +0.000012] [<ffffffffa00a5c2a>] drm_pci_init+0xfa/0x130 [drm]
[ +0.000004] [<ffffffffa01f4000>] ? 0xffffffffa01f4000
[ +0.000022] [<ffffffffa01f40a0>] i915_init+0xa0/0xa8 [i915]
[ +0.000006] [<ffffffff81002148>] do_one_initcall+0xd8/0x210
[ +0.000005] [<ffffffff811fc599>] ? kmem_cache_alloc_trace+0x1a9/0x230
[ +0.000004] [<ffffffff81779fad>] ? do_init_module+0x28/0x1cc
[ +0.000004] [<ffffffff81779fe6>] do_init_module+0x61/0x1cc
[ +0.000005] [<ffffffff81120c4b>] load_module+0x20ab/0x2520
[ +0.000004] [<ffffffff8111c550>] ? store_uevent+0x70/0x70
[ +0.000005] [<ffffffff811dd9ec>] ? vmap_page_range_noflush+0x22c/0x350
[ +0.000006] [<ffffffff8112118d>] SyS_init_module+0xcd/0x120
[ +0.000006] [<ffffffff81781509>] system_call_fastpath+0x12/0x17
[ +0.000003] ---[ end trace fde4b7d97a3cd3f5 ]---
[ +0.022245] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no)
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [Intel-gfx] [git pull] drm fixes
2015-03-24 13:15 ` Josh Boyer
@ 2015-03-24 13:40 ` Daniel Vetter
-1 siblings, 0 replies; 71+ messages in thread
From: Daniel Vetter @ 2015-03-24 13:40 UTC (permalink / raw)
To: Josh Boyer
Cc: Daniel Vetter, Dave Airlie, Xi Ruoyao, Linus Torvalds,
Linux-Kernel@Vger. Kernel. Org, DRI mailing list,
Intel Graphics Development
On Tue, Mar 24, 2015 at 09:15:32AM -0400, Josh Boyer wrote:
> On Tue, Mar 24, 2015 at 3:32 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> > On Mon, Mar 23, 2015 at 02:34:27PM -0400, Josh Boyer wrote:
> >> On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> >>
> >> <snip>
> >>
> >> >> Xi Ruoyao (1):
> >> >> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
> >>
> >> Turns out to be that commit.
> >>
> >> git bisect start 'drivers/gpu/drm/i915/'
> >> # good: [b314acaccd7e0d55314d96be4a33b5f50d0b3344] Merge branch
> >> 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
> >> git bisect good b314acaccd7e0d55314d96be4a33b5f50d0b3344
> >> # bad: [bc465aa9d045feb0e13b4a8f32cc33c1943f62d6] Linux 4.0-rc5
> >> git bisect bad bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
> >> # bad: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] drm/i915: Ensure
> >> plane->state->fb stays in sync with plane->fb
> >> git bisect bad 319c1d420a0b62d9dbb88104afebaabc968cdbfa
> >> # first bad commit: [319c1d420a0b62d9dbb88104afebaabc968cdbfa]
> >> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
> >>
> >> Doing a straight revert on top of 4.0-rc5 makes things work again,
> >> albeit with the WARN_ON(obj->frontbuffer_bits) splat still being
> >> there.
> >
> > Can you please test the tip of drm-fixes:
> >
> > commit 8218c3f4df3bb1c637c17552405039a6dd3c1ee1
> > Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> > Date: Fri Feb 27 12:58:13 2015 +0100
> >
> > drm: Fixup racy refcounting in plane_force_disable
> >
> > http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes&id=8218c3f4df3bb1c637c17552405039a6dd3c1ee1
> >
> > Because fumble that patch didn't make it to drm-fixes a while ago and
> > instead landed in drm-next.
>
> That seems to have helped with totally different issues a macbook I
> have was seeing. However, it still doesn't fix the issue with the
> Celeron based NUC machine.
>
> I built a kernel based on Linus' latest tree as of this morning,
> without reverting 319c1d4 and adding the commit you pointed to. The
> NUC still won't boot without HDMI connected. With HDMI connected I
> still see the trace below. If I do the blacklist and then insmod
> dance with HDMI unplugged it shows the same spew I reported yesterday
> which starts with the same backtrace.
>
> I'll try building a kernel with 319c1d4 reverted + your patch. I
> suspect things will work fine with that combination because the two
> issues are unrelated.
Can you please boot with drm.debug=0xff for the below case and grab
complete dmesg? There'll be a lot of crap in the logs, you might need to
blow up the logbuf size massively. But that log should contain everything
I need to figure out where that framebuffer we're blowing up on is going.
Thanks, Daniel
>
> josh
>
> [ +0.000027] WARNING: CPU: 1 PID: 144 at include/linux/kref.h:47
> drm_framebuffer_reference+0x7a/0x90 [drm]()
> [ +0.000003] Modules linked in: i915(+) i2c_algo_bit drm_kms_helper
> drm sdhci_acpi sdhci mmc_core video
> [ +0.000012] CPU: 1 PID: 144 Comm: systemd-udevd Not tainted
> 4.0.0-0.rc5.git1.1.fc23.x86_64 #1
> [ +0.000003] Hardware name:
> \xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff
> \xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff/DN2820FYK,
> BIOS FYBYT10H.86A.0034.2014.0513.1413 05/13/2014
> [ +0.000003] 0000000000000000 00000000b82c27d6 ffff88003f98f688
> ffffffff8177ada9
> [ +0.000004] 0000000000000000 0000000000000000 ffff88003f98f6c8
> ffffffff8109c78a
> [ +0.000004] ffff8802345c91a8 ffff880234b0bd80 ffff880234b923c0
> ffff88003fae0000
> [ +0.000004] Call Trace:
> [ +0.000010] [<ffffffff8177ada9>] dump_stack+0x45/0x57
> [ +0.000005] [<ffffffff8109c78a>] warn_slowpath_common+0x8a/0xc0
> [ +0.000004] [<ffffffff8109c8ba>] warn_slowpath_null+0x1a/0x20
> [ +0.000012] [<ffffffffa00a822a>] drm_framebuffer_reference+0x7a/0x90 [drm]
> [ +0.000016] [<ffffffffa00ba6ad>] drm_atomic_set_fb_for_plane+0x2d/0x90 [drm]
> [ +0.000048] [<ffffffffa014e8c5>]
> i9xx_get_initial_plane_config+0x295/0x3e0 [i915]
> [ +0.000015] [<ffffffffa00b8ed6>] ? drm_modeset_unlock_all+0x36/0x70 [drm]
> [ +0.000031] [<ffffffffa015f721>] intel_modeset_init+0x9f1/0x1a40 [i915]
> [ +0.000027] [<ffffffffa0128f5b>] ?
> valleyview_irq_postinstall+0x3b/0x50 [i915]
> [ +0.000034] [<ffffffffa01943ef>] i915_driver_load+0xe5f/0x10f0 [i915]
> [ +0.000005] [<ffffffff8169654b>] ? netlink_broadcast_filtered+0x12b/0x380
> [ +0.000006] [<ffffffff8139b730>] ? kobj_ns_drop+0x50/0x50
> [ +0.000004] [<ffffffff8139bae8>] ? kobject_uevent_env+0x178/0x540
> [ +0.000006] [<ffffffff814d98d9>] ? devtmpfs_create_node+0x109/0x140
> [ +0.000004] [<ffffffff814cde27>] ? get_device+0x17/0x30
> [ +0.000005] [<ffffffff814d3ce5>] ? klist_class_dev_get+0x15/0x20
> [ +0.000005] [<ffffffff81770bc2>] ? klist_add_tail+0x32/0x40
> [ +0.000004] [<ffffffff814cf85f>] ? device_add+0x19f/0x6a0
> [ +0.000012] [<ffffffffa00a2825>] drm_dev_register+0xb5/0x110 [drm]
> [ +0.000011] [<ffffffffa00a59bd>] drm_get_pci_dev+0x8d/0x200 [drm]
> [ +0.000022] [<ffffffffa00eb22b>] i915_pci_probe+0x3b/0x60 [i915]
> [ +0.000006] [<ffffffff813e4485>] local_pci_probe+0x45/0xa0
> [ +0.000005] [<ffffffff81299a72>] ? sysfs_do_create_link_sd.isra.2+0x72/0xc0
> [ +0.000004] [<ffffffff813e57e9>] pci_device_probe+0xf9/0x150
> [ +0.000005] [<ffffffff814d2d83>] driver_probe_device+0xa3/0x400
> [ +0.000004] [<ffffffff814d31bb>] __driver_attach+0x9b/0xa0
> [ +0.000004] [<ffffffff814d3120>] ? __device_attach+0x40/0x40
> [ +0.000004] [<ffffffff814d0a43>] bus_for_each_dev+0x73/0xc0
> [ +0.000004] [<ffffffff814d27ee>] driver_attach+0x1e/0x20
> [ +0.000004] [<ffffffff814d23a0>] bus_add_driver+0x180/0x250
> [ +0.000004] [<ffffffff814d39b4>] driver_register+0x64/0xf0
> [ +0.000004] [<ffffffff813e3d0c>] __pci_register_driver+0x4c/0x50
> [ +0.000012] [<ffffffffa00a5c2a>] drm_pci_init+0xfa/0x130 [drm]
> [ +0.000004] [<ffffffffa01f4000>] ? 0xffffffffa01f4000
> [ +0.000022] [<ffffffffa01f40a0>] i915_init+0xa0/0xa8 [i915]
> [ +0.000006] [<ffffffff81002148>] do_one_initcall+0xd8/0x210
> [ +0.000005] [<ffffffff811fc599>] ? kmem_cache_alloc_trace+0x1a9/0x230
> [ +0.000004] [<ffffffff81779fad>] ? do_init_module+0x28/0x1cc
> [ +0.000004] [<ffffffff81779fe6>] do_init_module+0x61/0x1cc
> [ +0.000005] [<ffffffff81120c4b>] load_module+0x20ab/0x2520
> [ +0.000004] [<ffffffff8111c550>] ? store_uevent+0x70/0x70
> [ +0.000005] [<ffffffff811dd9ec>] ? vmap_page_range_noflush+0x22c/0x350
> [ +0.000006] [<ffffffff8112118d>] SyS_init_module+0xcd/0x120
> [ +0.000006] [<ffffffff81781509>] system_call_fastpath+0x12/0x17
> [ +0.000003] ---[ end trace fde4b7d97a3cd3f5 ]---
> [ +0.022245] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no)
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [Intel-gfx] [git pull] drm fixes
@ 2015-03-24 13:40 ` Daniel Vetter
0 siblings, 0 replies; 71+ messages in thread
From: Daniel Vetter @ 2015-03-24 13:40 UTC (permalink / raw)
To: Josh Boyer
Cc: Intel Graphics Development, Linux-Kernel@Vger. Kernel. Org,
DRI mailing list, Xi Ruoyao, Linus Torvalds
On Tue, Mar 24, 2015 at 09:15:32AM -0400, Josh Boyer wrote:
> On Tue, Mar 24, 2015 at 3:32 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> > On Mon, Mar 23, 2015 at 02:34:27PM -0400, Josh Boyer wrote:
> >> On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> >>
> >> <snip>
> >>
> >> >> Xi Ruoyao (1):
> >> >> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
> >>
> >> Turns out to be that commit.
> >>
> >> git bisect start 'drivers/gpu/drm/i915/'
> >> # good: [b314acaccd7e0d55314d96be4a33b5f50d0b3344] Merge branch
> >> 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
> >> git bisect good b314acaccd7e0d55314d96be4a33b5f50d0b3344
> >> # bad: [bc465aa9d045feb0e13b4a8f32cc33c1943f62d6] Linux 4.0-rc5
> >> git bisect bad bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
> >> # bad: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] drm/i915: Ensure
> >> plane->state->fb stays in sync with plane->fb
> >> git bisect bad 319c1d420a0b62d9dbb88104afebaabc968cdbfa
> >> # first bad commit: [319c1d420a0b62d9dbb88104afebaabc968cdbfa]
> >> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
> >>
> >> Doing a straight revert on top of 4.0-rc5 makes things work again,
> >> albeit with the WARN_ON(obj->frontbuffer_bits) splat still being
> >> there.
> >
> > Can you please test the tip of drm-fixes:
> >
> > commit 8218c3f4df3bb1c637c17552405039a6dd3c1ee1
> > Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> > Date: Fri Feb 27 12:58:13 2015 +0100
> >
> > drm: Fixup racy refcounting in plane_force_disable
> >
> > http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes&id=8218c3f4df3bb1c637c17552405039a6dd3c1ee1
> >
> > Because fumble that patch didn't make it to drm-fixes a while ago and
> > instead landed in drm-next.
>
> That seems to have helped with totally different issues a macbook I
> have was seeing. However, it still doesn't fix the issue with the
> Celeron based NUC machine.
>
> I built a kernel based on Linus' latest tree as of this morning,
> without reverting 319c1d4 and adding the commit you pointed to. The
> NUC still won't boot without HDMI connected. With HDMI connected I
> still see the trace below. If I do the blacklist and then insmod
> dance with HDMI unplugged it shows the same spew I reported yesterday
> which starts with the same backtrace.
>
> I'll try building a kernel with 319c1d4 reverted + your patch. I
> suspect things will work fine with that combination because the two
> issues are unrelated.
Can you please boot with drm.debug=0xff for the below case and grab
complete dmesg? There'll be a lot of crap in the logs, you might need to
blow up the logbuf size massively. But that log should contain everything
I need to figure out where that framebuffer we're blowing up on is going.
Thanks, Daniel
>
> josh
>
> [ +0.000027] WARNING: CPU: 1 PID: 144 at include/linux/kref.h:47
> drm_framebuffer_reference+0x7a/0x90 [drm]()
> [ +0.000003] Modules linked in: i915(+) i2c_algo_bit drm_kms_helper
> drm sdhci_acpi sdhci mmc_core video
> [ +0.000012] CPU: 1 PID: 144 Comm: systemd-udevd Not tainted
> 4.0.0-0.rc5.git1.1.fc23.x86_64 #1
> [ +0.000003] Hardware name:
> \xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff
> \xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff/DN2820FYK,
> BIOS FYBYT10H.86A.0034.2014.0513.1413 05/13/2014
> [ +0.000003] 0000000000000000 00000000b82c27d6 ffff88003f98f688
> ffffffff8177ada9
> [ +0.000004] 0000000000000000 0000000000000000 ffff88003f98f6c8
> ffffffff8109c78a
> [ +0.000004] ffff8802345c91a8 ffff880234b0bd80 ffff880234b923c0
> ffff88003fae0000
> [ +0.000004] Call Trace:
> [ +0.000010] [<ffffffff8177ada9>] dump_stack+0x45/0x57
> [ +0.000005] [<ffffffff8109c78a>] warn_slowpath_common+0x8a/0xc0
> [ +0.000004] [<ffffffff8109c8ba>] warn_slowpath_null+0x1a/0x20
> [ +0.000012] [<ffffffffa00a822a>] drm_framebuffer_reference+0x7a/0x90 [drm]
> [ +0.000016] [<ffffffffa00ba6ad>] drm_atomic_set_fb_for_plane+0x2d/0x90 [drm]
> [ +0.000048] [<ffffffffa014e8c5>]
> i9xx_get_initial_plane_config+0x295/0x3e0 [i915]
> [ +0.000015] [<ffffffffa00b8ed6>] ? drm_modeset_unlock_all+0x36/0x70 [drm]
> [ +0.000031] [<ffffffffa015f721>] intel_modeset_init+0x9f1/0x1a40 [i915]
> [ +0.000027] [<ffffffffa0128f5b>] ?
> valleyview_irq_postinstall+0x3b/0x50 [i915]
> [ +0.000034] [<ffffffffa01943ef>] i915_driver_load+0xe5f/0x10f0 [i915]
> [ +0.000005] [<ffffffff8169654b>] ? netlink_broadcast_filtered+0x12b/0x380
> [ +0.000006] [<ffffffff8139b730>] ? kobj_ns_drop+0x50/0x50
> [ +0.000004] [<ffffffff8139bae8>] ? kobject_uevent_env+0x178/0x540
> [ +0.000006] [<ffffffff814d98d9>] ? devtmpfs_create_node+0x109/0x140
> [ +0.000004] [<ffffffff814cde27>] ? get_device+0x17/0x30
> [ +0.000005] [<ffffffff814d3ce5>] ? klist_class_dev_get+0x15/0x20
> [ +0.000005] [<ffffffff81770bc2>] ? klist_add_tail+0x32/0x40
> [ +0.000004] [<ffffffff814cf85f>] ? device_add+0x19f/0x6a0
> [ +0.000012] [<ffffffffa00a2825>] drm_dev_register+0xb5/0x110 [drm]
> [ +0.000011] [<ffffffffa00a59bd>] drm_get_pci_dev+0x8d/0x200 [drm]
> [ +0.000022] [<ffffffffa00eb22b>] i915_pci_probe+0x3b/0x60 [i915]
> [ +0.000006] [<ffffffff813e4485>] local_pci_probe+0x45/0xa0
> [ +0.000005] [<ffffffff81299a72>] ? sysfs_do_create_link_sd.isra.2+0x72/0xc0
> [ +0.000004] [<ffffffff813e57e9>] pci_device_probe+0xf9/0x150
> [ +0.000005] [<ffffffff814d2d83>] driver_probe_device+0xa3/0x400
> [ +0.000004] [<ffffffff814d31bb>] __driver_attach+0x9b/0xa0
> [ +0.000004] [<ffffffff814d3120>] ? __device_attach+0x40/0x40
> [ +0.000004] [<ffffffff814d0a43>] bus_for_each_dev+0x73/0xc0
> [ +0.000004] [<ffffffff814d27ee>] driver_attach+0x1e/0x20
> [ +0.000004] [<ffffffff814d23a0>] bus_add_driver+0x180/0x250
> [ +0.000004] [<ffffffff814d39b4>] driver_register+0x64/0xf0
> [ +0.000004] [<ffffffff813e3d0c>] __pci_register_driver+0x4c/0x50
> [ +0.000012] [<ffffffffa00a5c2a>] drm_pci_init+0xfa/0x130 [drm]
> [ +0.000004] [<ffffffffa01f4000>] ? 0xffffffffa01f4000
> [ +0.000022] [<ffffffffa01f40a0>] i915_init+0xa0/0xa8 [i915]
> [ +0.000006] [<ffffffff81002148>] do_one_initcall+0xd8/0x210
> [ +0.000005] [<ffffffff811fc599>] ? kmem_cache_alloc_trace+0x1a9/0x230
> [ +0.000004] [<ffffffff81779fad>] ? do_init_module+0x28/0x1cc
> [ +0.000004] [<ffffffff81779fe6>] do_init_module+0x61/0x1cc
> [ +0.000005] [<ffffffff81120c4b>] load_module+0x20ab/0x2520
> [ +0.000004] [<ffffffff8111c550>] ? store_uevent+0x70/0x70
> [ +0.000005] [<ffffffff811dd9ec>] ? vmap_page_range_noflush+0x22c/0x350
> [ +0.000006] [<ffffffff8112118d>] SyS_init_module+0xcd/0x120
> [ +0.000006] [<ffffffff81781509>] system_call_fastpath+0x12/0x17
> [ +0.000003] ---[ end trace fde4b7d97a3cd3f5 ]---
> [ +0.022245] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no)
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [Intel-gfx] [git pull] drm fixes
2015-03-24 13:40 ` Daniel Vetter
@ 2015-03-24 13:57 ` Josh Boyer
-1 siblings, 0 replies; 71+ messages in thread
From: Josh Boyer @ 2015-03-24 13:57 UTC (permalink / raw)
To: Daniel Vetter, Dave Airlie, Xi Ruoyao, Linus Torvalds,
Linux-Kernel@Vger. Kernel. Org, DRI mailing list,
Intel Graphics Development
On Tue, Mar 24, 2015 at 9:40 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Tue, Mar 24, 2015 at 09:15:32AM -0400, Josh Boyer wrote:
>> On Tue, Mar 24, 2015 at 3:32 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> > On Mon, Mar 23, 2015 at 02:34:27PM -0400, Josh Boyer wrote:
>> >> On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
>> >>
>> >> <snip>
>> >>
>> >> >> Xi Ruoyao (1):
>> >> >> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
>> >>
>> >> Turns out to be that commit.
>> >>
>> >> git bisect start 'drivers/gpu/drm/i915/'
>> >> # good: [b314acaccd7e0d55314d96be4a33b5f50d0b3344] Merge branch
>> >> 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
>> >> git bisect good b314acaccd7e0d55314d96be4a33b5f50d0b3344
>> >> # bad: [bc465aa9d045feb0e13b4a8f32cc33c1943f62d6] Linux 4.0-rc5
>> >> git bisect bad bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
>> >> # bad: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] drm/i915: Ensure
>> >> plane->state->fb stays in sync with plane->fb
>> >> git bisect bad 319c1d420a0b62d9dbb88104afebaabc968cdbfa
>> >> # first bad commit: [319c1d420a0b62d9dbb88104afebaabc968cdbfa]
>> >> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
>> >>
>> >> Doing a straight revert on top of 4.0-rc5 makes things work again,
>> >> albeit with the WARN_ON(obj->frontbuffer_bits) splat still being
>> >> there.
>> >
>> > Can you please test the tip of drm-fixes:
>> >
>> > commit 8218c3f4df3bb1c637c17552405039a6dd3c1ee1
>> > Author: Daniel Vetter <daniel.vetter@ffwll.ch>
>> > Date: Fri Feb 27 12:58:13 2015 +0100
>> >
>> > drm: Fixup racy refcounting in plane_force_disable
>> >
>> > http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes&id=8218c3f4df3bb1c637c17552405039a6dd3c1ee1
>> >
>> > Because fumble that patch didn't make it to drm-fixes a while ago and
>> > instead landed in drm-next.
>>
>> That seems to have helped with totally different issues a macbook I
>> have was seeing. However, it still doesn't fix the issue with the
>> Celeron based NUC machine.
>>
>> I built a kernel based on Linus' latest tree as of this morning,
>> without reverting 319c1d4 and adding the commit you pointed to. The
>> NUC still won't boot without HDMI connected. With HDMI connected I
>> still see the trace below. If I do the blacklist and then insmod
>> dance with HDMI unplugged it shows the same spew I reported yesterday
>> which starts with the same backtrace.
>>
>> I'll try building a kernel with 319c1d4 reverted + your patch. I
>> suspect things will work fine with that combination because the two
>> issues are unrelated.
>
> Can you please boot with drm.debug=0xff for the below case and grab
> complete dmesg? There'll be a lot of crap in the logs, you might need to
> blow up the logbuf size massively. But that log should contain everything
> I need to figure out where that framebuffer we're blowing up on is going.
I provided both with HDMI attached and without (via insmod). If you
want them emailed directly let me know, but they were large.
Boot with drm.debug=0xff and HDMI connected:
https://jwboyer.fedorapeople.org/pub/drm-ff-dmesg.txt
Boot with drm.debug=0xff without HDMI connected and i915 loaded via
manual insmod after boot:
https://jwboyer.fedorapeople.org/pub/drm-ff-no-hdmi-insmod.txt
josh
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [git pull] drm fixes
@ 2015-03-24 13:57 ` Josh Boyer
0 siblings, 0 replies; 71+ messages in thread
From: Josh Boyer @ 2015-03-24 13:57 UTC (permalink / raw)
To: Daniel Vetter, Dave Airlie, Xi Ruoyao, Linus Torvalds,
Linux-Kernel@Vger. Kernel. Org, DRI mailing list,
Intel Graphics Development
On Tue, Mar 24, 2015 at 9:40 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Tue, Mar 24, 2015 at 09:15:32AM -0400, Josh Boyer wrote:
>> On Tue, Mar 24, 2015 at 3:32 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> > On Mon, Mar 23, 2015 at 02:34:27PM -0400, Josh Boyer wrote:
>> >> On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
>> >>
>> >> <snip>
>> >>
>> >> >> Xi Ruoyao (1):
>> >> >> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
>> >>
>> >> Turns out to be that commit.
>> >>
>> >> git bisect start 'drivers/gpu/drm/i915/'
>> >> # good: [b314acaccd7e0d55314d96be4a33b5f50d0b3344] Merge branch
>> >> 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
>> >> git bisect good b314acaccd7e0d55314d96be4a33b5f50d0b3344
>> >> # bad: [bc465aa9d045feb0e13b4a8f32cc33c1943f62d6] Linux 4.0-rc5
>> >> git bisect bad bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
>> >> # bad: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] drm/i915: Ensure
>> >> plane->state->fb stays in sync with plane->fb
>> >> git bisect bad 319c1d420a0b62d9dbb88104afebaabc968cdbfa
>> >> # first bad commit: [319c1d420a0b62d9dbb88104afebaabc968cdbfa]
>> >> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
>> >>
>> >> Doing a straight revert on top of 4.0-rc5 makes things work again,
>> >> albeit with the WARN_ON(obj->frontbuffer_bits) splat still being
>> >> there.
>> >
>> > Can you please test the tip of drm-fixes:
>> >
>> > commit 8218c3f4df3bb1c637c17552405039a6dd3c1ee1
>> > Author: Daniel Vetter <daniel.vetter@ffwll.ch>
>> > Date: Fri Feb 27 12:58:13 2015 +0100
>> >
>> > drm: Fixup racy refcounting in plane_force_disable
>> >
>> > http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes&id=8218c3f4df3bb1c637c17552405039a6dd3c1ee1
>> >
>> > Because fumble that patch didn't make it to drm-fixes a while ago and
>> > instead landed in drm-next.
>>
>> That seems to have helped with totally different issues a macbook I
>> have was seeing. However, it still doesn't fix the issue with the
>> Celeron based NUC machine.
>>
>> I built a kernel based on Linus' latest tree as of this morning,
>> without reverting 319c1d4 and adding the commit you pointed to. The
>> NUC still won't boot without HDMI connected. With HDMI connected I
>> still see the trace below. If I do the blacklist and then insmod
>> dance with HDMI unplugged it shows the same spew I reported yesterday
>> which starts with the same backtrace.
>>
>> I'll try building a kernel with 319c1d4 reverted + your patch. I
>> suspect things will work fine with that combination because the two
>> issues are unrelated.
>
> Can you please boot with drm.debug=0xff for the below case and grab
> complete dmesg? There'll be a lot of crap in the logs, you might need to
> blow up the logbuf size massively. But that log should contain everything
> I need to figure out where that framebuffer we're blowing up on is going.
I provided both with HDMI attached and without (via insmod). If you
want them emailed directly let me know, but they were large.
Boot with drm.debug=0xff and HDMI connected:
https://jwboyer.fedorapeople.org/pub/drm-ff-dmesg.txt
Boot with drm.debug=0xff without HDMI connected and i915 loaded via
manual insmod after boot:
https://jwboyer.fedorapeople.org/pub/drm-ff-no-hdmi-insmod.txt
josh
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [Intel-gfx] [git pull] drm fixes
2015-03-24 13:57 ` Josh Boyer
@ 2015-03-24 14:22 ` Josh Boyer
-1 siblings, 0 replies; 71+ messages in thread
From: Josh Boyer @ 2015-03-24 14:22 UTC (permalink / raw)
To: Daniel Vetter
Cc: Dave Airlie, Xi Ruoyao, Linus Torvalds,
Linux-Kernel@Vger. Kernel. Org, DRI mailing list,
Intel Graphics Development
On Tue, Mar 24, 2015 at 9:57 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> On Tue, Mar 24, 2015 at 9:40 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> On Tue, Mar 24, 2015 at 09:15:32AM -0400, Josh Boyer wrote:
>>> On Tue, Mar 24, 2015 at 3:32 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>>> > On Mon, Mar 23, 2015 at 02:34:27PM -0400, Josh Boyer wrote:
>>> >> On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
>>> >>
>>> >> <snip>
>>> >>
>>> >> >> Xi Ruoyao (1):
>>> >> >> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
>>> >>
>>> >> Turns out to be that commit.
>>> >>
>>> >> git bisect start 'drivers/gpu/drm/i915/'
>>> >> # good: [b314acaccd7e0d55314d96be4a33b5f50d0b3344] Merge branch
>>> >> 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
>>> >> git bisect good b314acaccd7e0d55314d96be4a33b5f50d0b3344
>>> >> # bad: [bc465aa9d045feb0e13b4a8f32cc33c1943f62d6] Linux 4.0-rc5
>>> >> git bisect bad bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
>>> >> # bad: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] drm/i915: Ensure
>>> >> plane->state->fb stays in sync with plane->fb
>>> >> git bisect bad 319c1d420a0b62d9dbb88104afebaabc968cdbfa
>>> >> # first bad commit: [319c1d420a0b62d9dbb88104afebaabc968cdbfa]
>>> >> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
>>> >>
>>> >> Doing a straight revert on top of 4.0-rc5 makes things work again,
>>> >> albeit with the WARN_ON(obj->frontbuffer_bits) splat still being
>>> >> there.
>>> >
>>> > Can you please test the tip of drm-fixes:
>>> >
>>> > commit 8218c3f4df3bb1c637c17552405039a6dd3c1ee1
>>> > Author: Daniel Vetter <daniel.vetter@ffwll.ch>
>>> > Date: Fri Feb 27 12:58:13 2015 +0100
>>> >
>>> > drm: Fixup racy refcounting in plane_force_disable
>>> >
>>> > http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes&id=8218c3f4df3bb1c637c17552405039a6dd3c1ee1
>>> >
>>> > Because fumble that patch didn't make it to drm-fixes a while ago and
>>> > instead landed in drm-next.
>>>
>>> That seems to have helped with totally different issues a macbook I
>>> have was seeing. However, it still doesn't fix the issue with the
>>> Celeron based NUC machine.
>>>
>>> I built a kernel based on Linus' latest tree as of this morning,
>>> without reverting 319c1d4 and adding the commit you pointed to. The
>>> NUC still won't boot without HDMI connected. With HDMI connected I
>>> still see the trace below. If I do the blacklist and then insmod
>>> dance with HDMI unplugged it shows the same spew I reported yesterday
>>> which starts with the same backtrace.
>>>
>>> I'll try building a kernel with 319c1d4 reverted + your patch. I
>>> suspect things will work fine with that combination because the two
>>> issues are unrelated.
>>
>> Can you please boot with drm.debug=0xff for the below case and grab
>> complete dmesg? There'll be a lot of crap in the logs, you might need to
>> blow up the logbuf size massively. But that log should contain everything
>> I need to figure out where that framebuffer we're blowing up on is going.
>
> I provided both with HDMI attached and without (via insmod). If you
> want them emailed directly let me know, but they were large.
>
> Boot with drm.debug=0xff and HDMI connected:
>
> https://jwboyer.fedorapeople.org/pub/drm-ff-dmesg.txt
>
> Boot with drm.debug=0xff without HDMI connected and i915 loaded via
> manual insmod after boot:
>
> https://jwboyer.fedorapeople.org/pub/drm-ff-no-hdmi-insmod.txt
Here's one more from the macbook I mentioned. It's showing the same
kref.h splat:
https://jwboyer.fedorapeople.org/pub/drm-ff-macbook.txt
josh
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [git pull] drm fixes
@ 2015-03-24 14:22 ` Josh Boyer
0 siblings, 0 replies; 71+ messages in thread
From: Josh Boyer @ 2015-03-24 14:22 UTC (permalink / raw)
To: Daniel Vetter
Cc: Dave Airlie, Intel Graphics Development,
Linux-Kernel@Vger. Kernel. Org, DRI mailing list, Xi Ruoyao,
Linus Torvalds
On Tue, Mar 24, 2015 at 9:57 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> On Tue, Mar 24, 2015 at 9:40 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> On Tue, Mar 24, 2015 at 09:15:32AM -0400, Josh Boyer wrote:
>>> On Tue, Mar 24, 2015 at 3:32 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>>> > On Mon, Mar 23, 2015 at 02:34:27PM -0400, Josh Boyer wrote:
>>> >> On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
>>> >>
>>> >> <snip>
>>> >>
>>> >> >> Xi Ruoyao (1):
>>> >> >> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
>>> >>
>>> >> Turns out to be that commit.
>>> >>
>>> >> git bisect start 'drivers/gpu/drm/i915/'
>>> >> # good: [b314acaccd7e0d55314d96be4a33b5f50d0b3344] Merge branch
>>> >> 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
>>> >> git bisect good b314acaccd7e0d55314d96be4a33b5f50d0b3344
>>> >> # bad: [bc465aa9d045feb0e13b4a8f32cc33c1943f62d6] Linux 4.0-rc5
>>> >> git bisect bad bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
>>> >> # bad: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] drm/i915: Ensure
>>> >> plane->state->fb stays in sync with plane->fb
>>> >> git bisect bad 319c1d420a0b62d9dbb88104afebaabc968cdbfa
>>> >> # first bad commit: [319c1d420a0b62d9dbb88104afebaabc968cdbfa]
>>> >> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
>>> >>
>>> >> Doing a straight revert on top of 4.0-rc5 makes things work again,
>>> >> albeit with the WARN_ON(obj->frontbuffer_bits) splat still being
>>> >> there.
>>> >
>>> > Can you please test the tip of drm-fixes:
>>> >
>>> > commit 8218c3f4df3bb1c637c17552405039a6dd3c1ee1
>>> > Author: Daniel Vetter <daniel.vetter@ffwll.ch>
>>> > Date: Fri Feb 27 12:58:13 2015 +0100
>>> >
>>> > drm: Fixup racy refcounting in plane_force_disable
>>> >
>>> > http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes&id=8218c3f4df3bb1c637c17552405039a6dd3c1ee1
>>> >
>>> > Because fumble that patch didn't make it to drm-fixes a while ago and
>>> > instead landed in drm-next.
>>>
>>> That seems to have helped with totally different issues a macbook I
>>> have was seeing. However, it still doesn't fix the issue with the
>>> Celeron based NUC machine.
>>>
>>> I built a kernel based on Linus' latest tree as of this morning,
>>> without reverting 319c1d4 and adding the commit you pointed to. The
>>> NUC still won't boot without HDMI connected. With HDMI connected I
>>> still see the trace below. If I do the blacklist and then insmod
>>> dance with HDMI unplugged it shows the same spew I reported yesterday
>>> which starts with the same backtrace.
>>>
>>> I'll try building a kernel with 319c1d4 reverted + your patch. I
>>> suspect things will work fine with that combination because the two
>>> issues are unrelated.
>>
>> Can you please boot with drm.debug=0xff for the below case and grab
>> complete dmesg? There'll be a lot of crap in the logs, you might need to
>> blow up the logbuf size massively. But that log should contain everything
>> I need to figure out where that framebuffer we're blowing up on is going.
>
> I provided both with HDMI attached and without (via insmod). If you
> want them emailed directly let me know, but they were large.
>
> Boot with drm.debug=0xff and HDMI connected:
>
> https://jwboyer.fedorapeople.org/pub/drm-ff-dmesg.txt
>
> Boot with drm.debug=0xff without HDMI connected and i915 loaded via
> manual insmod after boot:
>
> https://jwboyer.fedorapeople.org/pub/drm-ff-no-hdmi-insmod.txt
Here's one more from the macbook I mentioned. It's showing the same
kref.h splat:
https://jwboyer.fedorapeople.org/pub/drm-ff-macbook.txt
josh
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [Intel-gfx] [git pull] drm fixes
2015-03-24 14:22 ` Josh Boyer
@ 2015-03-24 14:34 ` Daniel Vetter
-1 siblings, 0 replies; 71+ messages in thread
From: Daniel Vetter @ 2015-03-24 14:34 UTC (permalink / raw)
To: Josh Boyer
Cc: Daniel Vetter, Dave Airlie, Xi Ruoyao, Linus Torvalds,
Linux-Kernel@Vger. Kernel. Org, DRI mailing list,
Intel Graphics Development
On Tue, Mar 24, 2015 at 10:22:30AM -0400, Josh Boyer wrote:
> On Tue, Mar 24, 2015 at 9:57 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> > On Tue, Mar 24, 2015 at 9:40 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> >> On Tue, Mar 24, 2015 at 09:15:32AM -0400, Josh Boyer wrote:
> >>> On Tue, Mar 24, 2015 at 3:32 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> >>> > On Mon, Mar 23, 2015 at 02:34:27PM -0400, Josh Boyer wrote:
> >>> >> On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> >>> >>
> >>> >> <snip>
> >>> >>
> >>> >> >> Xi Ruoyao (1):
> >>> >> >> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
> >>> >>
> >>> >> Turns out to be that commit.
> >>> >>
> >>> >> git bisect start 'drivers/gpu/drm/i915/'
> >>> >> # good: [b314acaccd7e0d55314d96be4a33b5f50d0b3344] Merge branch
> >>> >> 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
> >>> >> git bisect good b314acaccd7e0d55314d96be4a33b5f50d0b3344
> >>> >> # bad: [bc465aa9d045feb0e13b4a8f32cc33c1943f62d6] Linux 4.0-rc5
> >>> >> git bisect bad bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
> >>> >> # bad: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] drm/i915: Ensure
> >>> >> plane->state->fb stays in sync with plane->fb
> >>> >> git bisect bad 319c1d420a0b62d9dbb88104afebaabc968cdbfa
> >>> >> # first bad commit: [319c1d420a0b62d9dbb88104afebaabc968cdbfa]
> >>> >> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
> >>> >>
> >>> >> Doing a straight revert on top of 4.0-rc5 makes things work again,
> >>> >> albeit with the WARN_ON(obj->frontbuffer_bits) splat still being
> >>> >> there.
> >>> >
> >>> > Can you please test the tip of drm-fixes:
> >>> >
> >>> > commit 8218c3f4df3bb1c637c17552405039a6dd3c1ee1
> >>> > Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> >>> > Date: Fri Feb 27 12:58:13 2015 +0100
> >>> >
> >>> > drm: Fixup racy refcounting in plane_force_disable
> >>> >
> >>> > http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes&id=8218c3f4df3bb1c637c17552405039a6dd3c1ee1
> >>> >
> >>> > Because fumble that patch didn't make it to drm-fixes a while ago and
> >>> > instead landed in drm-next.
> >>>
> >>> That seems to have helped with totally different issues a macbook I
> >>> have was seeing. However, it still doesn't fix the issue with the
> >>> Celeron based NUC machine.
> >>>
> >>> I built a kernel based on Linus' latest tree as of this morning,
> >>> without reverting 319c1d4 and adding the commit you pointed to. The
> >>> NUC still won't boot without HDMI connected. With HDMI connected I
> >>> still see the trace below. If I do the blacklist and then insmod
> >>> dance with HDMI unplugged it shows the same spew I reported yesterday
> >>> which starts with the same backtrace.
> >>>
> >>> I'll try building a kernel with 319c1d4 reverted + your patch. I
> >>> suspect things will work fine with that combination because the two
> >>> issues are unrelated.
> >>
> >> Can you please boot with drm.debug=0xff for the below case and grab
> >> complete dmesg? There'll be a lot of crap in the logs, you might need to
> >> blow up the logbuf size massively. But that log should contain everything
> >> I need to figure out where that framebuffer we're blowing up on is going.
> >
> > I provided both with HDMI attached and without (via insmod). If you
> > want them emailed directly let me know, but they were large.
> >
> > Boot with drm.debug=0xff and HDMI connected:
> >
> > https://jwboyer.fedorapeople.org/pub/drm-ff-dmesg.txt
> >
> > Boot with drm.debug=0xff without HDMI connected and i915 loaded via
> > manual insmod after boot:
> >
> > https://jwboyer.fedorapeople.org/pub/drm-ff-no-hdmi-insmod.txt
>
> Here's one more from the macbook I mentioned. It's showing the same
> kref.h splat:
>
> https://jwboyer.fedorapeople.org/pub/drm-ff-macbook.txt
Ok there's at least one fixup for which we've failed to apply when porting
the fb refcounting fix from -next. Can you please cherry-pick
commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
Author: Damien Lespiau <damien.lespiau@intel.com>
Date: Thu Feb 5 18:30:20 2015 +0000
drm/i915: Don't try to reference the fb in get_initial_plane_config()
>From linux-next?
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [Intel-gfx] [git pull] drm fixes
@ 2015-03-24 14:34 ` Daniel Vetter
0 siblings, 0 replies; 71+ messages in thread
From: Daniel Vetter @ 2015-03-24 14:34 UTC (permalink / raw)
To: Josh Boyer
Cc: Intel Graphics Development, Linux-Kernel@Vger. Kernel. Org,
DRI mailing list, Xi Ruoyao, Linus Torvalds
On Tue, Mar 24, 2015 at 10:22:30AM -0400, Josh Boyer wrote:
> On Tue, Mar 24, 2015 at 9:57 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> > On Tue, Mar 24, 2015 at 9:40 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> >> On Tue, Mar 24, 2015 at 09:15:32AM -0400, Josh Boyer wrote:
> >>> On Tue, Mar 24, 2015 at 3:32 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> >>> > On Mon, Mar 23, 2015 at 02:34:27PM -0400, Josh Boyer wrote:
> >>> >> On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> >>> >>
> >>> >> <snip>
> >>> >>
> >>> >> >> Xi Ruoyao (1):
> >>> >> >> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
> >>> >>
> >>> >> Turns out to be that commit.
> >>> >>
> >>> >> git bisect start 'drivers/gpu/drm/i915/'
> >>> >> # good: [b314acaccd7e0d55314d96be4a33b5f50d0b3344] Merge branch
> >>> >> 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
> >>> >> git bisect good b314acaccd7e0d55314d96be4a33b5f50d0b3344
> >>> >> # bad: [bc465aa9d045feb0e13b4a8f32cc33c1943f62d6] Linux 4.0-rc5
> >>> >> git bisect bad bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
> >>> >> # bad: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] drm/i915: Ensure
> >>> >> plane->state->fb stays in sync with plane->fb
> >>> >> git bisect bad 319c1d420a0b62d9dbb88104afebaabc968cdbfa
> >>> >> # first bad commit: [319c1d420a0b62d9dbb88104afebaabc968cdbfa]
> >>> >> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
> >>> >>
> >>> >> Doing a straight revert on top of 4.0-rc5 makes things work again,
> >>> >> albeit with the WARN_ON(obj->frontbuffer_bits) splat still being
> >>> >> there.
> >>> >
> >>> > Can you please test the tip of drm-fixes:
> >>> >
> >>> > commit 8218c3f4df3bb1c637c17552405039a6dd3c1ee1
> >>> > Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> >>> > Date: Fri Feb 27 12:58:13 2015 +0100
> >>> >
> >>> > drm: Fixup racy refcounting in plane_force_disable
> >>> >
> >>> > http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes&id=8218c3f4df3bb1c637c17552405039a6dd3c1ee1
> >>> >
> >>> > Because fumble that patch didn't make it to drm-fixes a while ago and
> >>> > instead landed in drm-next.
> >>>
> >>> That seems to have helped with totally different issues a macbook I
> >>> have was seeing. However, it still doesn't fix the issue with the
> >>> Celeron based NUC machine.
> >>>
> >>> I built a kernel based on Linus' latest tree as of this morning,
> >>> without reverting 319c1d4 and adding the commit you pointed to. The
> >>> NUC still won't boot without HDMI connected. With HDMI connected I
> >>> still see the trace below. If I do the blacklist and then insmod
> >>> dance with HDMI unplugged it shows the same spew I reported yesterday
> >>> which starts with the same backtrace.
> >>>
> >>> I'll try building a kernel with 319c1d4 reverted + your patch. I
> >>> suspect things will work fine with that combination because the two
> >>> issues are unrelated.
> >>
> >> Can you please boot with drm.debug=0xff for the below case and grab
> >> complete dmesg? There'll be a lot of crap in the logs, you might need to
> >> blow up the logbuf size massively. But that log should contain everything
> >> I need to figure out where that framebuffer we're blowing up on is going.
> >
> > I provided both with HDMI attached and without (via insmod). If you
> > want them emailed directly let me know, but they were large.
> >
> > Boot with drm.debug=0xff and HDMI connected:
> >
> > https://jwboyer.fedorapeople.org/pub/drm-ff-dmesg.txt
> >
> > Boot with drm.debug=0xff without HDMI connected and i915 loaded via
> > manual insmod after boot:
> >
> > https://jwboyer.fedorapeople.org/pub/drm-ff-no-hdmi-insmod.txt
>
> Here's one more from the macbook I mentioned. It's showing the same
> kref.h splat:
>
> https://jwboyer.fedorapeople.org/pub/drm-ff-macbook.txt
Ok there's at least one fixup for which we've failed to apply when porting
the fb refcounting fix from -next. Can you please cherry-pick
commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
Author: Damien Lespiau <damien.lespiau@intel.com>
Date: Thu Feb 5 18:30:20 2015 +0000
drm/i915: Don't try to reference the fb in get_initial_plane_config()
From linux-next?
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [Intel-gfx] [git pull] drm fixes
2015-03-24 14:34 ` Daniel Vetter
(?)
@ 2015-03-24 14:46 ` Josh Boyer
2015-03-24 16:10 ` Josh Boyer
-1 siblings, 1 reply; 71+ messages in thread
From: Josh Boyer @ 2015-03-24 14:46 UTC (permalink / raw)
To: Daniel Vetter, Dave Airlie, Xi Ruoyao, Linus Torvalds,
Linux-Kernel@Vger. Kernel. Org, DRI mailing list,
Intel Graphics Development
On Tue, Mar 24, 2015 at 10:34 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Tue, Mar 24, 2015 at 10:22:30AM -0400, Josh Boyer wrote:
>> On Tue, Mar 24, 2015 at 9:57 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
>> > On Tue, Mar 24, 2015 at 9:40 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> >> On Tue, Mar 24, 2015 at 09:15:32AM -0400, Josh Boyer wrote:
>> >>> On Tue, Mar 24, 2015 at 3:32 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> >>> > On Mon, Mar 23, 2015 at 02:34:27PM -0400, Josh Boyer wrote:
>> >>> >> On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
>> >>> >>
>> >>> >> <snip>
>> >>> >>
>> >>> >> >> Xi Ruoyao (1):
>> >>> >> >> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
>> >>> >>
>> >>> >> Turns out to be that commit.
>> >>> >>
>> >>> >> git bisect start 'drivers/gpu/drm/i915/'
>> >>> >> # good: [b314acaccd7e0d55314d96be4a33b5f50d0b3344] Merge branch
>> >>> >> 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
>> >>> >> git bisect good b314acaccd7e0d55314d96be4a33b5f50d0b3344
>> >>> >> # bad: [bc465aa9d045feb0e13b4a8f32cc33c1943f62d6] Linux 4.0-rc5
>> >>> >> git bisect bad bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
>> >>> >> # bad: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] drm/i915: Ensure
>> >>> >> plane->state->fb stays in sync with plane->fb
>> >>> >> git bisect bad 319c1d420a0b62d9dbb88104afebaabc968cdbfa
>> >>> >> # first bad commit: [319c1d420a0b62d9dbb88104afebaabc968cdbfa]
>> >>> >> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
>> >>> >>
>> >>> >> Doing a straight revert on top of 4.0-rc5 makes things work again,
>> >>> >> albeit with the WARN_ON(obj->frontbuffer_bits) splat still being
>> >>> >> there.
>> >>> >
>> >>> > Can you please test the tip of drm-fixes:
>> >>> >
>> >>> > commit 8218c3f4df3bb1c637c17552405039a6dd3c1ee1
>> >>> > Author: Daniel Vetter <daniel.vetter@ffwll.ch>
>> >>> > Date: Fri Feb 27 12:58:13 2015 +0100
>> >>> >
>> >>> > drm: Fixup racy refcounting in plane_force_disable
>> >>> >
>> >>> > http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes&id=8218c3f4df3bb1c637c17552405039a6dd3c1ee1
>> >>> >
>> >>> > Because fumble that patch didn't make it to drm-fixes a while ago and
>> >>> > instead landed in drm-next.
>> >>>
>> >>> That seems to have helped with totally different issues a macbook I
>> >>> have was seeing. However, it still doesn't fix the issue with the
>> >>> Celeron based NUC machine.
>> >>>
>> >>> I built a kernel based on Linus' latest tree as of this morning,
>> >>> without reverting 319c1d4 and adding the commit you pointed to. The
>> >>> NUC still won't boot without HDMI connected. With HDMI connected I
>> >>> still see the trace below. If I do the blacklist and then insmod
>> >>> dance with HDMI unplugged it shows the same spew I reported yesterday
>> >>> which starts with the same backtrace.
>> >>>
>> >>> I'll try building a kernel with 319c1d4 reverted + your patch. I
>> >>> suspect things will work fine with that combination because the two
>> >>> issues are unrelated.
>> >>
>> >> Can you please boot with drm.debug=0xff for the below case and grab
>> >> complete dmesg? There'll be a lot of crap in the logs, you might need to
>> >> blow up the logbuf size massively. But that log should contain everything
>> >> I need to figure out where that framebuffer we're blowing up on is going.
>> >
>> > I provided both with HDMI attached and without (via insmod). If you
>> > want them emailed directly let me know, but they were large.
>> >
>> > Boot with drm.debug=0xff and HDMI connected:
>> >
>> > https://jwboyer.fedorapeople.org/pub/drm-ff-dmesg.txt
>> >
>> > Boot with drm.debug=0xff without HDMI connected and i915 loaded via
>> > manual insmod after boot:
>> >
>> > https://jwboyer.fedorapeople.org/pub/drm-ff-no-hdmi-insmod.txt
>>
>> Here's one more from the macbook I mentioned. It's showing the same
>> kref.h splat:
>>
>> https://jwboyer.fedorapeople.org/pub/drm-ff-macbook.txt
>
> Ok there's at least one fixup for which we've failed to apply when porting
> the fb refcounting fix from -next. Can you please cherry-pick
>
> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
> Author: Damien Lespiau <damien.lespiau@intel.com>
> Date: Thu Feb 5 18:30:20 2015 +0000
>
> drm/i915: Don't try to reference the fb in get_initial_plane_config()
>
> From linux-next?
Yes, building now. Will let you know as soon as I test it on both machines.
josh
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [Intel-gfx] [git pull] drm fixes
2015-03-24 14:46 ` Josh Boyer
@ 2015-03-24 16:10 ` Josh Boyer
0 siblings, 0 replies; 71+ messages in thread
From: Josh Boyer @ 2015-03-24 16:10 UTC (permalink / raw)
To: Daniel Vetter
Cc: Dave Airlie, Xi Ruoyao, Linus Torvalds,
Linux-Kernel@Vger. Kernel. Org, DRI mailing list,
Intel Graphics Development
On Tue, Mar 24, 2015 at 10:46 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> On Tue, Mar 24, 2015 at 10:34 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> On Tue, Mar 24, 2015 at 10:22:30AM -0400, Josh Boyer wrote:
>>> On Tue, Mar 24, 2015 at 9:57 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
>>> > On Tue, Mar 24, 2015 at 9:40 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>>> >> On Tue, Mar 24, 2015 at 09:15:32AM -0400, Josh Boyer wrote:
>>> >>> On Tue, Mar 24, 2015 at 3:32 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>>> >>> > On Mon, Mar 23, 2015 at 02:34:27PM -0400, Josh Boyer wrote:
>>> >>> >> On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
>>> >>> >>
>>> >>> >> <snip>
>>> >>> >>
>>> >>> >> >> Xi Ruoyao (1):
>>> >>> >> >> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
>>> >>> >>
>>> >>> >> Turns out to be that commit.
>>> >>> >>
>>> >>> >> git bisect start 'drivers/gpu/drm/i915/'
>>> >>> >> # good: [b314acaccd7e0d55314d96be4a33b5f50d0b3344] Merge branch
>>> >>> >> 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
>>> >>> >> git bisect good b314acaccd7e0d55314d96be4a33b5f50d0b3344
>>> >>> >> # bad: [bc465aa9d045feb0e13b4a8f32cc33c1943f62d6] Linux 4.0-rc5
>>> >>> >> git bisect bad bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
>>> >>> >> # bad: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] drm/i915: Ensure
>>> >>> >> plane->state->fb stays in sync with plane->fb
>>> >>> >> git bisect bad 319c1d420a0b62d9dbb88104afebaabc968cdbfa
>>> >>> >> # first bad commit: [319c1d420a0b62d9dbb88104afebaabc968cdbfa]
>>> >>> >> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
>>> >>> >>
>>> >>> >> Doing a straight revert on top of 4.0-rc5 makes things work again,
>>> >>> >> albeit with the WARN_ON(obj->frontbuffer_bits) splat still being
>>> >>> >> there.
>>> >>> >
>>> >>> > Can you please test the tip of drm-fixes:
>>> >>> >
>>> >>> > commit 8218c3f4df3bb1c637c17552405039a6dd3c1ee1
>>> >>> > Author: Daniel Vetter <daniel.vetter@ffwll.ch>
>>> >>> > Date: Fri Feb 27 12:58:13 2015 +0100
>>> >>> >
>>> >>> > drm: Fixup racy refcounting in plane_force_disable
>>> >>> >
>>> >>> > http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes&id=8218c3f4df3bb1c637c17552405039a6dd3c1ee1
>>> >>> >
>>> >>> > Because fumble that patch didn't make it to drm-fixes a while ago and
>>> >>> > instead landed in drm-next.
>>> >>>
>>> >>> That seems to have helped with totally different issues a macbook I
>>> >>> have was seeing. However, it still doesn't fix the issue with the
>>> >>> Celeron based NUC machine.
>>> >>>
>>> >>> I built a kernel based on Linus' latest tree as of this morning,
>>> >>> without reverting 319c1d4 and adding the commit you pointed to. The
>>> >>> NUC still won't boot without HDMI connected. With HDMI connected I
>>> >>> still see the trace below. If I do the blacklist and then insmod
>>> >>> dance with HDMI unplugged it shows the same spew I reported yesterday
>>> >>> which starts with the same backtrace.
>>> >>>
>>> >>> I'll try building a kernel with 319c1d4 reverted + your patch. I
>>> >>> suspect things will work fine with that combination because the two
>>> >>> issues are unrelated.
>>> >>
>>> >> Can you please boot with drm.debug=0xff for the below case and grab
>>> >> complete dmesg? There'll be a lot of crap in the logs, you might need to
>>> >> blow up the logbuf size massively. But that log should contain everything
>>> >> I need to figure out where that framebuffer we're blowing up on is going.
>>> >
>>> > I provided both with HDMI attached and without (via insmod). If you
>>> > want them emailed directly let me know, but they were large.
>>> >
>>> > Boot with drm.debug=0xff and HDMI connected:
>>> >
>>> > https://jwboyer.fedorapeople.org/pub/drm-ff-dmesg.txt
>>> >
>>> > Boot with drm.debug=0xff without HDMI connected and i915 loaded via
>>> > manual insmod after boot:
>>> >
>>> > https://jwboyer.fedorapeople.org/pub/drm-ff-no-hdmi-insmod.txt
>>>
>>> Here's one more from the macbook I mentioned. It's showing the same
>>> kref.h splat:
>>>
>>> https://jwboyer.fedorapeople.org/pub/drm-ff-macbook.txt
>>
>> Ok there's at least one fixup for which we've failed to apply when porting
>> the fb refcounting fix from -next. Can you please cherry-pick
>>
>> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
>> Author: Damien Lespiau <damien.lespiau@intel.com>
>> Date: Thu Feb 5 18:30:20 2015 +0000
>>
>> drm/i915: Don't try to reference the fb in get_initial_plane_config()
>>
>> From linux-next?
>
> Yes, building now. Will let you know as soon as I test it on both machines.
OK, with that commit applied I no longer get the kref.h splat and the
NUC machine boots headless. I still see the backtrace below on both
the NUC and the macbook. I have a copy of it with drm.debug=0xff from
the NUC here:
https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
Getting better at least :).
josh
[ +0.000372] [drm] Initialized i915 1.6.0 20150130 for 0000:00:02.0 on minor 0
[ +0.059774] [drm] GMBUS [i915 gmbus vga] timed out, falling back to
bit banging on pin 2
[ +0.012442] fbcon: inteldrmfb (fb0) is primary device
[ +0.000103] ------------[ cut here ]------------
[ +0.000024] WARNING: CPU: 1 PID: 109 at
drivers/gpu/drm/drm_atomic.c:482 drm_atomic_check_only+0x33d/0x500
[drm]()
[ +0.000006] Modules linked in: i915 i2c_algo_bit drm_kms_helper drm
sdhci_pci sdhci mmc_core video
[ +0.000004] CPU: 1 PID: 109 Comm: kworker/u16:7 Not tainted
4.0.0-0.rc5.git1.3.fc23.x86_64 #1
[ +0.000001] Hardware name: Apple Inc.
MacBookPro10,2/Mac-AFD8A9D944EA4843, BIOS
MBP102.88Z.0106.B03.1211161133 11/16/2012
[ +0.000005] Workqueue: events_unbound async_run_entry_fn
[ +0.000003] 0000000000000000 00000000cbdcc84e ffff8802628bb868
ffffffff8177ada9
[ +0.000002] 0000000000000000 0000000000000000 ffff8802628bb8a8
ffffffff8109c78a
[ +0.000002] ffff88026154c940 0000000000000048 ffff880262b1e600
ffff88026229e2a0
[ +0.000001] Call Trace:
[ +0.000007] [<ffffffff8177ada9>] dump_stack+0x45/0x57
[ +0.000003] [<ffffffff8109c78a>] warn_slowpath_common+0x8a/0xc0
[ +0.000003] [<ffffffff8109c8ba>] warn_slowpath_null+0x1a/0x20
[ +0.000014] [<ffffffffa00700ed>] drm_atomic_check_only+0x33d/0x500 [drm]
[ +0.000005] [<ffffffff811bc0a6>] ? kmemdup+0x36/0x50
[ +0.000013] [<ffffffffa00702c7>] drm_atomic_commit+0x17/0x60 [drm]
[ +0.000008] [<ffffffffa00c371d>]
drm_atomic_helper_plane_set_property+0x8d/0xd0 [drm_kms_helper]
[ +0.000013] [<ffffffffa005e89d>] drm_mode_plane_set_obj_prop+0x2d/0x90 [drm]
[ +0.000006] [<ffffffffa00c550b>] restore_fbdev_mode+0x6b/0xf0
[drm_kms_helper]
[ +0.000006] [<ffffffffa00c75c9>]
drm_fb_helper_restore_fbdev_mode_unlocked+0x29/0x80 [drm_kms_helper]
[ +0.000006] [<ffffffffa00c7642>] drm_fb_helper_set_par+0x22/0x50
[drm_kms_helper]
[ +0.000042] [<ffffffffa016959a>] intel_fbdev_set_par+0x1a/0x60 [i915]
[ +0.000005] [<ffffffff8140c328>] fbcon_init+0x578/0x600
[ +0.000005] [<ffffffff8148ceac>] visual_init+0xbc/0x120
[ +0.000004] [<ffffffff8148f84e>] do_bind_con_driver+0x17e/0x3b0
[ +0.000007] [<ffffffff8148ffd4>] do_take_over_console+0xb4/0x1b0
[ +0.000013] [<ffffffff81407163>] do_fbcon_takeover+0x63/0xd0
[ +0.000003] [<ffffffff8140ce4d>] fbcon_event_notify+0x6cd/0x7d0
[ +0.000005] [<ffffffff810bc18f>] notifier_call_chain+0x4f/0x80
[ +0.000003] [<ffffffff810bc50b>] __blocking_notifier_call_chain+0x4b/0x70
[ +0.000002] [<ffffffff810bc546>] blocking_notifier_call_chain+0x16/0x20
[ +0.000003] [<ffffffff81412dbb>] fb_notifier_call_chain+0x1b/0x20
[ +0.000013] [<ffffffff81415184>] register_framebuffer+0x214/0x360
[ +0.000007] [<ffffffffa00c78d4>]
drm_fb_helper_initial_config+0x264/0x3c0 [drm_kms_helper]
[ +0.000004] [<ffffffff810d8401>] ? pick_next_task_fair+0x121/0x8b0
[ +0.000034] [<ffffffffa016a89b>] intel_fbdev_initial_config+0x1b/0x20 [i915]
[ +0.000002] [<ffffffff810bdd1a>] async_run_entry_fn+0x4a/0x150
[ +0.000002] [<ffffffff810b552c>] process_one_work+0x14c/0x400
[ +0.000002] [<ffffffff810b5fb3>] worker_thread+0x53/0x470
[ +0.000003] [<ffffffff810b5f60>] ? rescuer_thread+0x300/0x300
[ +0.000002] [<ffffffff810b5f60>] ? rescuer_thread+0x300/0x300
[ +0.000002] [<ffffffff810bb1f8>] kthread+0xd8/0xf0
[ +0.000004] [<ffffffff810bb120>] ? kthread_create_on_node+0x1b0/0x1b0
[ +0.000004] [<ffffffff81781458>] ret_from_fork+0x58/0x90
[ +0.000003] [<ffffffff810bb120>] ? kthread_create_on_node+0x1b0/0x1b0
[ +0.000002] ---[ end trace a73ba186968c6ec8 ]---
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [git pull] drm fixes
@ 2015-03-24 16:10 ` Josh Boyer
0 siblings, 0 replies; 71+ messages in thread
From: Josh Boyer @ 2015-03-24 16:10 UTC (permalink / raw)
To: Daniel Vetter
Cc: Dave Airlie, Intel Graphics Development,
Linux-Kernel@Vger. Kernel. Org, DRI mailing list, Xi Ruoyao,
Linus Torvalds
On Tue, Mar 24, 2015 at 10:46 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> On Tue, Mar 24, 2015 at 10:34 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> On Tue, Mar 24, 2015 at 10:22:30AM -0400, Josh Boyer wrote:
>>> On Tue, Mar 24, 2015 at 9:57 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
>>> > On Tue, Mar 24, 2015 at 9:40 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>>> >> On Tue, Mar 24, 2015 at 09:15:32AM -0400, Josh Boyer wrote:
>>> >>> On Tue, Mar 24, 2015 at 3:32 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>>> >>> > On Mon, Mar 23, 2015 at 02:34:27PM -0400, Josh Boyer wrote:
>>> >>> >> On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
>>> >>> >>
>>> >>> >> <snip>
>>> >>> >>
>>> >>> >> >> Xi Ruoyao (1):
>>> >>> >> >> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
>>> >>> >>
>>> >>> >> Turns out to be that commit.
>>> >>> >>
>>> >>> >> git bisect start 'drivers/gpu/drm/i915/'
>>> >>> >> # good: [b314acaccd7e0d55314d96be4a33b5f50d0b3344] Merge branch
>>> >>> >> 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
>>> >>> >> git bisect good b314acaccd7e0d55314d96be4a33b5f50d0b3344
>>> >>> >> # bad: [bc465aa9d045feb0e13b4a8f32cc33c1943f62d6] Linux 4.0-rc5
>>> >>> >> git bisect bad bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
>>> >>> >> # bad: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] drm/i915: Ensure
>>> >>> >> plane->state->fb stays in sync with plane->fb
>>> >>> >> git bisect bad 319c1d420a0b62d9dbb88104afebaabc968cdbfa
>>> >>> >> # first bad commit: [319c1d420a0b62d9dbb88104afebaabc968cdbfa]
>>> >>> >> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
>>> >>> >>
>>> >>> >> Doing a straight revert on top of 4.0-rc5 makes things work again,
>>> >>> >> albeit with the WARN_ON(obj->frontbuffer_bits) splat still being
>>> >>> >> there.
>>> >>> >
>>> >>> > Can you please test the tip of drm-fixes:
>>> >>> >
>>> >>> > commit 8218c3f4df3bb1c637c17552405039a6dd3c1ee1
>>> >>> > Author: Daniel Vetter <daniel.vetter@ffwll.ch>
>>> >>> > Date: Fri Feb 27 12:58:13 2015 +0100
>>> >>> >
>>> >>> > drm: Fixup racy refcounting in plane_force_disable
>>> >>> >
>>> >>> > http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes&id=8218c3f4df3bb1c637c17552405039a6dd3c1ee1
>>> >>> >
>>> >>> > Because fumble that patch didn't make it to drm-fixes a while ago and
>>> >>> > instead landed in drm-next.
>>> >>>
>>> >>> That seems to have helped with totally different issues a macbook I
>>> >>> have was seeing. However, it still doesn't fix the issue with the
>>> >>> Celeron based NUC machine.
>>> >>>
>>> >>> I built a kernel based on Linus' latest tree as of this morning,
>>> >>> without reverting 319c1d4 and adding the commit you pointed to. The
>>> >>> NUC still won't boot without HDMI connected. With HDMI connected I
>>> >>> still see the trace below. If I do the blacklist and then insmod
>>> >>> dance with HDMI unplugged it shows the same spew I reported yesterday
>>> >>> which starts with the same backtrace.
>>> >>>
>>> >>> I'll try building a kernel with 319c1d4 reverted + your patch. I
>>> >>> suspect things will work fine with that combination because the two
>>> >>> issues are unrelated.
>>> >>
>>> >> Can you please boot with drm.debug=0xff for the below case and grab
>>> >> complete dmesg? There'll be a lot of crap in the logs, you might need to
>>> >> blow up the logbuf size massively. But that log should contain everything
>>> >> I need to figure out where that framebuffer we're blowing up on is going.
>>> >
>>> > I provided both with HDMI attached and without (via insmod). If you
>>> > want them emailed directly let me know, but they were large.
>>> >
>>> > Boot with drm.debug=0xff and HDMI connected:
>>> >
>>> > https://jwboyer.fedorapeople.org/pub/drm-ff-dmesg.txt
>>> >
>>> > Boot with drm.debug=0xff without HDMI connected and i915 loaded via
>>> > manual insmod after boot:
>>> >
>>> > https://jwboyer.fedorapeople.org/pub/drm-ff-no-hdmi-insmod.txt
>>>
>>> Here's one more from the macbook I mentioned. It's showing the same
>>> kref.h splat:
>>>
>>> https://jwboyer.fedorapeople.org/pub/drm-ff-macbook.txt
>>
>> Ok there's at least one fixup for which we've failed to apply when porting
>> the fb refcounting fix from -next. Can you please cherry-pick
>>
>> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
>> Author: Damien Lespiau <damien.lespiau@intel.com>
>> Date: Thu Feb 5 18:30:20 2015 +0000
>>
>> drm/i915: Don't try to reference the fb in get_initial_plane_config()
>>
>> From linux-next?
>
> Yes, building now. Will let you know as soon as I test it on both machines.
OK, with that commit applied I no longer get the kref.h splat and the
NUC machine boots headless. I still see the backtrace below on both
the NUC and the macbook. I have a copy of it with drm.debug=0xff from
the NUC here:
https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
Getting better at least :).
josh
[ +0.000372] [drm] Initialized i915 1.6.0 20150130 for 0000:00:02.0 on minor 0
[ +0.059774] [drm] GMBUS [i915 gmbus vga] timed out, falling back to
bit banging on pin 2
[ +0.012442] fbcon: inteldrmfb (fb0) is primary device
[ +0.000103] ------------[ cut here ]------------
[ +0.000024] WARNING: CPU: 1 PID: 109 at
drivers/gpu/drm/drm_atomic.c:482 drm_atomic_check_only+0x33d/0x500
[drm]()
[ +0.000006] Modules linked in: i915 i2c_algo_bit drm_kms_helper drm
sdhci_pci sdhci mmc_core video
[ +0.000004] CPU: 1 PID: 109 Comm: kworker/u16:7 Not tainted
4.0.0-0.rc5.git1.3.fc23.x86_64 #1
[ +0.000001] Hardware name: Apple Inc.
MacBookPro10,2/Mac-AFD8A9D944EA4843, BIOS
MBP102.88Z.0106.B03.1211161133 11/16/2012
[ +0.000005] Workqueue: events_unbound async_run_entry_fn
[ +0.000003] 0000000000000000 00000000cbdcc84e ffff8802628bb868
ffffffff8177ada9
[ +0.000002] 0000000000000000 0000000000000000 ffff8802628bb8a8
ffffffff8109c78a
[ +0.000002] ffff88026154c940 0000000000000048 ffff880262b1e600
ffff88026229e2a0
[ +0.000001] Call Trace:
[ +0.000007] [<ffffffff8177ada9>] dump_stack+0x45/0x57
[ +0.000003] [<ffffffff8109c78a>] warn_slowpath_common+0x8a/0xc0
[ +0.000003] [<ffffffff8109c8ba>] warn_slowpath_null+0x1a/0x20
[ +0.000014] [<ffffffffa00700ed>] drm_atomic_check_only+0x33d/0x500 [drm]
[ +0.000005] [<ffffffff811bc0a6>] ? kmemdup+0x36/0x50
[ +0.000013] [<ffffffffa00702c7>] drm_atomic_commit+0x17/0x60 [drm]
[ +0.000008] [<ffffffffa00c371d>]
drm_atomic_helper_plane_set_property+0x8d/0xd0 [drm_kms_helper]
[ +0.000013] [<ffffffffa005e89d>] drm_mode_plane_set_obj_prop+0x2d/0x90 [drm]
[ +0.000006] [<ffffffffa00c550b>] restore_fbdev_mode+0x6b/0xf0
[drm_kms_helper]
[ +0.000006] [<ffffffffa00c75c9>]
drm_fb_helper_restore_fbdev_mode_unlocked+0x29/0x80 [drm_kms_helper]
[ +0.000006] [<ffffffffa00c7642>] drm_fb_helper_set_par+0x22/0x50
[drm_kms_helper]
[ +0.000042] [<ffffffffa016959a>] intel_fbdev_set_par+0x1a/0x60 [i915]
[ +0.000005] [<ffffffff8140c328>] fbcon_init+0x578/0x600
[ +0.000005] [<ffffffff8148ceac>] visual_init+0xbc/0x120
[ +0.000004] [<ffffffff8148f84e>] do_bind_con_driver+0x17e/0x3b0
[ +0.000007] [<ffffffff8148ffd4>] do_take_over_console+0xb4/0x1b0
[ +0.000013] [<ffffffff81407163>] do_fbcon_takeover+0x63/0xd0
[ +0.000003] [<ffffffff8140ce4d>] fbcon_event_notify+0x6cd/0x7d0
[ +0.000005] [<ffffffff810bc18f>] notifier_call_chain+0x4f/0x80
[ +0.000003] [<ffffffff810bc50b>] __blocking_notifier_call_chain+0x4b/0x70
[ +0.000002] [<ffffffff810bc546>] blocking_notifier_call_chain+0x16/0x20
[ +0.000003] [<ffffffff81412dbb>] fb_notifier_call_chain+0x1b/0x20
[ +0.000013] [<ffffffff81415184>] register_framebuffer+0x214/0x360
[ +0.000007] [<ffffffffa00c78d4>]
drm_fb_helper_initial_config+0x264/0x3c0 [drm_kms_helper]
[ +0.000004] [<ffffffff810d8401>] ? pick_next_task_fair+0x121/0x8b0
[ +0.000034] [<ffffffffa016a89b>] intel_fbdev_initial_config+0x1b/0x20 [i915]
[ +0.000002] [<ffffffff810bdd1a>] async_run_entry_fn+0x4a/0x150
[ +0.000002] [<ffffffff810b552c>] process_one_work+0x14c/0x400
[ +0.000002] [<ffffffff810b5fb3>] worker_thread+0x53/0x470
[ +0.000003] [<ffffffff810b5f60>] ? rescuer_thread+0x300/0x300
[ +0.000002] [<ffffffff810b5f60>] ? rescuer_thread+0x300/0x300
[ +0.000002] [<ffffffff810bb1f8>] kthread+0xd8/0xf0
[ +0.000004] [<ffffffff810bb120>] ? kthread_create_on_node+0x1b0/0x1b0
[ +0.000004] [<ffffffff81781458>] ret_from_fork+0x58/0x90
[ +0.000003] [<ffffffff810bb120>] ? kthread_create_on_node+0x1b0/0x1b0
[ +0.000002] ---[ end trace a73ba186968c6ec8 ]---
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [Intel-gfx] [git pull] drm fixes
2015-03-24 16:10 ` Josh Boyer
@ 2015-03-24 16:48 ` Daniel Vetter
-1 siblings, 0 replies; 71+ messages in thread
From: Daniel Vetter @ 2015-03-24 16:48 UTC (permalink / raw)
To: Josh Boyer
Cc: Daniel Vetter, Dave Airlie, Xi Ruoyao, Linus Torvalds,
Linux-Kernel@Vger. Kernel. Org, DRI mailing list,
Intel Graphics Development
On Tue, Mar 24, 2015 at 12:10:28PM -0400, Josh Boyer wrote:
> On Tue, Mar 24, 2015 at 10:46 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> > On Tue, Mar 24, 2015 at 10:34 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> >> On Tue, Mar 24, 2015 at 10:22:30AM -0400, Josh Boyer wrote:
> >>> On Tue, Mar 24, 2015 at 9:57 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> >>> > On Tue, Mar 24, 2015 at 9:40 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> >>> >> On Tue, Mar 24, 2015 at 09:15:32AM -0400, Josh Boyer wrote:
> >>> >>> On Tue, Mar 24, 2015 at 3:32 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> >>> >>> > On Mon, Mar 23, 2015 at 02:34:27PM -0400, Josh Boyer wrote:
> >>> >>> >> On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> >>> >>> >>
> >>> >>> >> <snip>
> >>> >>> >>
> >>> >>> >> >> Xi Ruoyao (1):
> >>> >>> >> >> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
> >>> >>> >>
> >>> >>> >> Turns out to be that commit.
> >>> >>> >>
> >>> >>> >> git bisect start 'drivers/gpu/drm/i915/'
> >>> >>> >> # good: [b314acaccd7e0d55314d96be4a33b5f50d0b3344] Merge branch
> >>> >>> >> 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
> >>> >>> >> git bisect good b314acaccd7e0d55314d96be4a33b5f50d0b3344
> >>> >>> >> # bad: [bc465aa9d045feb0e13b4a8f32cc33c1943f62d6] Linux 4.0-rc5
> >>> >>> >> git bisect bad bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
> >>> >>> >> # bad: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] drm/i915: Ensure
> >>> >>> >> plane->state->fb stays in sync with plane->fb
> >>> >>> >> git bisect bad 319c1d420a0b62d9dbb88104afebaabc968cdbfa
> >>> >>> >> # first bad commit: [319c1d420a0b62d9dbb88104afebaabc968cdbfa]
> >>> >>> >> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
> >>> >>> >>
> >>> >>> >> Doing a straight revert on top of 4.0-rc5 makes things work again,
> >>> >>> >> albeit with the WARN_ON(obj->frontbuffer_bits) splat still being
> >>> >>> >> there.
> >>> >>> >
> >>> >>> > Can you please test the tip of drm-fixes:
> >>> >>> >
> >>> >>> > commit 8218c3f4df3bb1c637c17552405039a6dd3c1ee1
> >>> >>> > Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> >>> >>> > Date: Fri Feb 27 12:58:13 2015 +0100
> >>> >>> >
> >>> >>> > drm: Fixup racy refcounting in plane_force_disable
> >>> >>> >
> >>> >>> > http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes&id=8218c3f4df3bb1c637c17552405039a6dd3c1ee1
> >>> >>> >
> >>> >>> > Because fumble that patch didn't make it to drm-fixes a while ago and
> >>> >>> > instead landed in drm-next.
> >>> >>>
> >>> >>> That seems to have helped with totally different issues a macbook I
> >>> >>> have was seeing. However, it still doesn't fix the issue with the
> >>> >>> Celeron based NUC machine.
> >>> >>>
> >>> >>> I built a kernel based on Linus' latest tree as of this morning,
> >>> >>> without reverting 319c1d4 and adding the commit you pointed to. The
> >>> >>> NUC still won't boot without HDMI connected. With HDMI connected I
> >>> >>> still see the trace below. If I do the blacklist and then insmod
> >>> >>> dance with HDMI unplugged it shows the same spew I reported yesterday
> >>> >>> which starts with the same backtrace.
> >>> >>>
> >>> >>> I'll try building a kernel with 319c1d4 reverted + your patch. I
> >>> >>> suspect things will work fine with that combination because the two
> >>> >>> issues are unrelated.
> >>> >>
> >>> >> Can you please boot with drm.debug=0xff for the below case and grab
> >>> >> complete dmesg? There'll be a lot of crap in the logs, you might need to
> >>> >> blow up the logbuf size massively. But that log should contain everything
> >>> >> I need to figure out where that framebuffer we're blowing up on is going.
> >>> >
> >>> > I provided both with HDMI attached and without (via insmod). If you
> >>> > want them emailed directly let me know, but they were large.
> >>> >
> >>> > Boot with drm.debug=0xff and HDMI connected:
> >>> >
> >>> > https://jwboyer.fedorapeople.org/pub/drm-ff-dmesg.txt
> >>> >
> >>> > Boot with drm.debug=0xff without HDMI connected and i915 loaded via
> >>> > manual insmod after boot:
> >>> >
> >>> > https://jwboyer.fedorapeople.org/pub/drm-ff-no-hdmi-insmod.txt
> >>>
> >>> Here's one more from the macbook I mentioned. It's showing the same
> >>> kref.h splat:
> >>>
> >>> https://jwboyer.fedorapeople.org/pub/drm-ff-macbook.txt
> >>
> >> Ok there's at least one fixup for which we've failed to apply when porting
> >> the fb refcounting fix from -next. Can you please cherry-pick
> >>
> >> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
> >> Author: Damien Lespiau <damien.lespiau@intel.com>
> >> Date: Thu Feb 5 18:30:20 2015 +0000
> >>
> >> drm/i915: Don't try to reference the fb in get_initial_plane_config()
> >>
> >> From linux-next?
> >
> > Yes, building now. Will let you know as soon as I test it on both machines.
>
> OK, with that commit applied I no longer get the kref.h splat and the
> NUC machine boots headless. I still see the backtrace below on both
> the NUC and the macbook. I have a copy of it with drm.debug=0xff from
> the NUC here:
>
> https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
>
> Getting better at least :).
Ok thanks for testing. I'll look at that one tomorrow, wasted too much
time with trying to resurrect a few machines that should have matched the
common parts of what goes wrong here.
Jani, can you please cherry-pick the above commit to -fixes?
One more question: Is the frontbuffer_bits splat now also gone? That was
the one I have no clue about, but since somewhere around 4.0-rc it started
poppping up in a few places ... Thus far it was always the canary for some
other bug though.
Thanks, Daniel
>
> josh
>
> [ +0.000372] [drm] Initialized i915 1.6.0 20150130 for 0000:00:02.0 on minor 0
> [ +0.059774] [drm] GMBUS [i915 gmbus vga] timed out, falling back to
> bit banging on pin 2
> [ +0.012442] fbcon: inteldrmfb (fb0) is primary device
> [ +0.000103] ------------[ cut here ]------------
> [ +0.000024] WARNING: CPU: 1 PID: 109 at
> drivers/gpu/drm/drm_atomic.c:482 drm_atomic_check_only+0x33d/0x500
> [drm]()
> [ +0.000006] Modules linked in: i915 i2c_algo_bit drm_kms_helper drm
> sdhci_pci sdhci mmc_core video
> [ +0.000004] CPU: 1 PID: 109 Comm: kworker/u16:7 Not tainted
> 4.0.0-0.rc5.git1.3.fc23.x86_64 #1
> [ +0.000001] Hardware name: Apple Inc.
> MacBookPro10,2/Mac-AFD8A9D944EA4843, BIOS
> MBP102.88Z.0106.B03.1211161133 11/16/2012
> [ +0.000005] Workqueue: events_unbound async_run_entry_fn
> [ +0.000003] 0000000000000000 00000000cbdcc84e ffff8802628bb868
> ffffffff8177ada9
> [ +0.000002] 0000000000000000 0000000000000000 ffff8802628bb8a8
> ffffffff8109c78a
> [ +0.000002] ffff88026154c940 0000000000000048 ffff880262b1e600
> ffff88026229e2a0
> [ +0.000001] Call Trace:
> [ +0.000007] [<ffffffff8177ada9>] dump_stack+0x45/0x57
> [ +0.000003] [<ffffffff8109c78a>] warn_slowpath_common+0x8a/0xc0
> [ +0.000003] [<ffffffff8109c8ba>] warn_slowpath_null+0x1a/0x20
> [ +0.000014] [<ffffffffa00700ed>] drm_atomic_check_only+0x33d/0x500 [drm]
> [ +0.000005] [<ffffffff811bc0a6>] ? kmemdup+0x36/0x50
> [ +0.000013] [<ffffffffa00702c7>] drm_atomic_commit+0x17/0x60 [drm]
> [ +0.000008] [<ffffffffa00c371d>]
> drm_atomic_helper_plane_set_property+0x8d/0xd0 [drm_kms_helper]
> [ +0.000013] [<ffffffffa005e89d>] drm_mode_plane_set_obj_prop+0x2d/0x90 [drm]
> [ +0.000006] [<ffffffffa00c550b>] restore_fbdev_mode+0x6b/0xf0
> [drm_kms_helper]
> [ +0.000006] [<ffffffffa00c75c9>]
> drm_fb_helper_restore_fbdev_mode_unlocked+0x29/0x80 [drm_kms_helper]
> [ +0.000006] [<ffffffffa00c7642>] drm_fb_helper_set_par+0x22/0x50
> [drm_kms_helper]
> [ +0.000042] [<ffffffffa016959a>] intel_fbdev_set_par+0x1a/0x60 [i915]
> [ +0.000005] [<ffffffff8140c328>] fbcon_init+0x578/0x600
> [ +0.000005] [<ffffffff8148ceac>] visual_init+0xbc/0x120
> [ +0.000004] [<ffffffff8148f84e>] do_bind_con_driver+0x17e/0x3b0
> [ +0.000007] [<ffffffff8148ffd4>] do_take_over_console+0xb4/0x1b0
> [ +0.000013] [<ffffffff81407163>] do_fbcon_takeover+0x63/0xd0
> [ +0.000003] [<ffffffff8140ce4d>] fbcon_event_notify+0x6cd/0x7d0
> [ +0.000005] [<ffffffff810bc18f>] notifier_call_chain+0x4f/0x80
> [ +0.000003] [<ffffffff810bc50b>] __blocking_notifier_call_chain+0x4b/0x70
> [ +0.000002] [<ffffffff810bc546>] blocking_notifier_call_chain+0x16/0x20
> [ +0.000003] [<ffffffff81412dbb>] fb_notifier_call_chain+0x1b/0x20
> [ +0.000013] [<ffffffff81415184>] register_framebuffer+0x214/0x360
> [ +0.000007] [<ffffffffa00c78d4>]
> drm_fb_helper_initial_config+0x264/0x3c0 [drm_kms_helper]
> [ +0.000004] [<ffffffff810d8401>] ? pick_next_task_fair+0x121/0x8b0
> [ +0.000034] [<ffffffffa016a89b>] intel_fbdev_initial_config+0x1b/0x20 [i915]
> [ +0.000002] [<ffffffff810bdd1a>] async_run_entry_fn+0x4a/0x150
> [ +0.000002] [<ffffffff810b552c>] process_one_work+0x14c/0x400
> [ +0.000002] [<ffffffff810b5fb3>] worker_thread+0x53/0x470
> [ +0.000003] [<ffffffff810b5f60>] ? rescuer_thread+0x300/0x300
> [ +0.000002] [<ffffffff810b5f60>] ? rescuer_thread+0x300/0x300
> [ +0.000002] [<ffffffff810bb1f8>] kthread+0xd8/0xf0
> [ +0.000004] [<ffffffff810bb120>] ? kthread_create_on_node+0x1b0/0x1b0
> [ +0.000004] [<ffffffff81781458>] ret_from_fork+0x58/0x90
> [ +0.000003] [<ffffffff810bb120>] ? kthread_create_on_node+0x1b0/0x1b0
> [ +0.000002] ---[ end trace a73ba186968c6ec8 ]---
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [git pull] drm fixes
@ 2015-03-24 16:48 ` Daniel Vetter
0 siblings, 0 replies; 71+ messages in thread
From: Daniel Vetter @ 2015-03-24 16:48 UTC (permalink / raw)
To: Josh Boyer
Cc: Dave Airlie, Intel Graphics Development,
Linux-Kernel@Vger. Kernel. Org, DRI mailing list, Xi Ruoyao,
Linus Torvalds
On Tue, Mar 24, 2015 at 12:10:28PM -0400, Josh Boyer wrote:
> On Tue, Mar 24, 2015 at 10:46 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> > On Tue, Mar 24, 2015 at 10:34 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> >> On Tue, Mar 24, 2015 at 10:22:30AM -0400, Josh Boyer wrote:
> >>> On Tue, Mar 24, 2015 at 9:57 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> >>> > On Tue, Mar 24, 2015 at 9:40 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> >>> >> On Tue, Mar 24, 2015 at 09:15:32AM -0400, Josh Boyer wrote:
> >>> >>> On Tue, Mar 24, 2015 at 3:32 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> >>> >>> > On Mon, Mar 23, 2015 at 02:34:27PM -0400, Josh Boyer wrote:
> >>> >>> >> On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> >>> >>> >>
> >>> >>> >> <snip>
> >>> >>> >>
> >>> >>> >> >> Xi Ruoyao (1):
> >>> >>> >> >> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
> >>> >>> >>
> >>> >>> >> Turns out to be that commit.
> >>> >>> >>
> >>> >>> >> git bisect start 'drivers/gpu/drm/i915/'
> >>> >>> >> # good: [b314acaccd7e0d55314d96be4a33b5f50d0b3344] Merge branch
> >>> >>> >> 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
> >>> >>> >> git bisect good b314acaccd7e0d55314d96be4a33b5f50d0b3344
> >>> >>> >> # bad: [bc465aa9d045feb0e13b4a8f32cc33c1943f62d6] Linux 4.0-rc5
> >>> >>> >> git bisect bad bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
> >>> >>> >> # bad: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] drm/i915: Ensure
> >>> >>> >> plane->state->fb stays in sync with plane->fb
> >>> >>> >> git bisect bad 319c1d420a0b62d9dbb88104afebaabc968cdbfa
> >>> >>> >> # first bad commit: [319c1d420a0b62d9dbb88104afebaabc968cdbfa]
> >>> >>> >> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
> >>> >>> >>
> >>> >>> >> Doing a straight revert on top of 4.0-rc5 makes things work again,
> >>> >>> >> albeit with the WARN_ON(obj->frontbuffer_bits) splat still being
> >>> >>> >> there.
> >>> >>> >
> >>> >>> > Can you please test the tip of drm-fixes:
> >>> >>> >
> >>> >>> > commit 8218c3f4df3bb1c637c17552405039a6dd3c1ee1
> >>> >>> > Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> >>> >>> > Date: Fri Feb 27 12:58:13 2015 +0100
> >>> >>> >
> >>> >>> > drm: Fixup racy refcounting in plane_force_disable
> >>> >>> >
> >>> >>> > http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes&id=8218c3f4df3bb1c637c17552405039a6dd3c1ee1
> >>> >>> >
> >>> >>> > Because fumble that patch didn't make it to drm-fixes a while ago and
> >>> >>> > instead landed in drm-next.
> >>> >>>
> >>> >>> That seems to have helped with totally different issues a macbook I
> >>> >>> have was seeing. However, it still doesn't fix the issue with the
> >>> >>> Celeron based NUC machine.
> >>> >>>
> >>> >>> I built a kernel based on Linus' latest tree as of this morning,
> >>> >>> without reverting 319c1d4 and adding the commit you pointed to. The
> >>> >>> NUC still won't boot without HDMI connected. With HDMI connected I
> >>> >>> still see the trace below. If I do the blacklist and then insmod
> >>> >>> dance with HDMI unplugged it shows the same spew I reported yesterday
> >>> >>> which starts with the same backtrace.
> >>> >>>
> >>> >>> I'll try building a kernel with 319c1d4 reverted + your patch. I
> >>> >>> suspect things will work fine with that combination because the two
> >>> >>> issues are unrelated.
> >>> >>
> >>> >> Can you please boot with drm.debug=0xff for the below case and grab
> >>> >> complete dmesg? There'll be a lot of crap in the logs, you might need to
> >>> >> blow up the logbuf size massively. But that log should contain everything
> >>> >> I need to figure out where that framebuffer we're blowing up on is going.
> >>> >
> >>> > I provided both with HDMI attached and without (via insmod). If you
> >>> > want them emailed directly let me know, but they were large.
> >>> >
> >>> > Boot with drm.debug=0xff and HDMI connected:
> >>> >
> >>> > https://jwboyer.fedorapeople.org/pub/drm-ff-dmesg.txt
> >>> >
> >>> > Boot with drm.debug=0xff without HDMI connected and i915 loaded via
> >>> > manual insmod after boot:
> >>> >
> >>> > https://jwboyer.fedorapeople.org/pub/drm-ff-no-hdmi-insmod.txt
> >>>
> >>> Here's one more from the macbook I mentioned. It's showing the same
> >>> kref.h splat:
> >>>
> >>> https://jwboyer.fedorapeople.org/pub/drm-ff-macbook.txt
> >>
> >> Ok there's at least one fixup for which we've failed to apply when porting
> >> the fb refcounting fix from -next. Can you please cherry-pick
> >>
> >> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
> >> Author: Damien Lespiau <damien.lespiau@intel.com>
> >> Date: Thu Feb 5 18:30:20 2015 +0000
> >>
> >> drm/i915: Don't try to reference the fb in get_initial_plane_config()
> >>
> >> From linux-next?
> >
> > Yes, building now. Will let you know as soon as I test it on both machines.
>
> OK, with that commit applied I no longer get the kref.h splat and the
> NUC machine boots headless. I still see the backtrace below on both
> the NUC and the macbook. I have a copy of it with drm.debug=0xff from
> the NUC here:
>
> https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
>
> Getting better at least :).
Ok thanks for testing. I'll look at that one tomorrow, wasted too much
time with trying to resurrect a few machines that should have matched the
common parts of what goes wrong here.
Jani, can you please cherry-pick the above commit to -fixes?
One more question: Is the frontbuffer_bits splat now also gone? That was
the one I have no clue about, but since somewhere around 4.0-rc it started
poppping up in a few places ... Thus far it was always the canary for some
other bug though.
Thanks, Daniel
>
> josh
>
> [ +0.000372] [drm] Initialized i915 1.6.0 20150130 for 0000:00:02.0 on minor 0
> [ +0.059774] [drm] GMBUS [i915 gmbus vga] timed out, falling back to
> bit banging on pin 2
> [ +0.012442] fbcon: inteldrmfb (fb0) is primary device
> [ +0.000103] ------------[ cut here ]------------
> [ +0.000024] WARNING: CPU: 1 PID: 109 at
> drivers/gpu/drm/drm_atomic.c:482 drm_atomic_check_only+0x33d/0x500
> [drm]()
> [ +0.000006] Modules linked in: i915 i2c_algo_bit drm_kms_helper drm
> sdhci_pci sdhci mmc_core video
> [ +0.000004] CPU: 1 PID: 109 Comm: kworker/u16:7 Not tainted
> 4.0.0-0.rc5.git1.3.fc23.x86_64 #1
> [ +0.000001] Hardware name: Apple Inc.
> MacBookPro10,2/Mac-AFD8A9D944EA4843, BIOS
> MBP102.88Z.0106.B03.1211161133 11/16/2012
> [ +0.000005] Workqueue: events_unbound async_run_entry_fn
> [ +0.000003] 0000000000000000 00000000cbdcc84e ffff8802628bb868
> ffffffff8177ada9
> [ +0.000002] 0000000000000000 0000000000000000 ffff8802628bb8a8
> ffffffff8109c78a
> [ +0.000002] ffff88026154c940 0000000000000048 ffff880262b1e600
> ffff88026229e2a0
> [ +0.000001] Call Trace:
> [ +0.000007] [<ffffffff8177ada9>] dump_stack+0x45/0x57
> [ +0.000003] [<ffffffff8109c78a>] warn_slowpath_common+0x8a/0xc0
> [ +0.000003] [<ffffffff8109c8ba>] warn_slowpath_null+0x1a/0x20
> [ +0.000014] [<ffffffffa00700ed>] drm_atomic_check_only+0x33d/0x500 [drm]
> [ +0.000005] [<ffffffff811bc0a6>] ? kmemdup+0x36/0x50
> [ +0.000013] [<ffffffffa00702c7>] drm_atomic_commit+0x17/0x60 [drm]
> [ +0.000008] [<ffffffffa00c371d>]
> drm_atomic_helper_plane_set_property+0x8d/0xd0 [drm_kms_helper]
> [ +0.000013] [<ffffffffa005e89d>] drm_mode_plane_set_obj_prop+0x2d/0x90 [drm]
> [ +0.000006] [<ffffffffa00c550b>] restore_fbdev_mode+0x6b/0xf0
> [drm_kms_helper]
> [ +0.000006] [<ffffffffa00c75c9>]
> drm_fb_helper_restore_fbdev_mode_unlocked+0x29/0x80 [drm_kms_helper]
> [ +0.000006] [<ffffffffa00c7642>] drm_fb_helper_set_par+0x22/0x50
> [drm_kms_helper]
> [ +0.000042] [<ffffffffa016959a>] intel_fbdev_set_par+0x1a/0x60 [i915]
> [ +0.000005] [<ffffffff8140c328>] fbcon_init+0x578/0x600
> [ +0.000005] [<ffffffff8148ceac>] visual_init+0xbc/0x120
> [ +0.000004] [<ffffffff8148f84e>] do_bind_con_driver+0x17e/0x3b0
> [ +0.000007] [<ffffffff8148ffd4>] do_take_over_console+0xb4/0x1b0
> [ +0.000013] [<ffffffff81407163>] do_fbcon_takeover+0x63/0xd0
> [ +0.000003] [<ffffffff8140ce4d>] fbcon_event_notify+0x6cd/0x7d0
> [ +0.000005] [<ffffffff810bc18f>] notifier_call_chain+0x4f/0x80
> [ +0.000003] [<ffffffff810bc50b>] __blocking_notifier_call_chain+0x4b/0x70
> [ +0.000002] [<ffffffff810bc546>] blocking_notifier_call_chain+0x16/0x20
> [ +0.000003] [<ffffffff81412dbb>] fb_notifier_call_chain+0x1b/0x20
> [ +0.000013] [<ffffffff81415184>] register_framebuffer+0x214/0x360
> [ +0.000007] [<ffffffffa00c78d4>]
> drm_fb_helper_initial_config+0x264/0x3c0 [drm_kms_helper]
> [ +0.000004] [<ffffffff810d8401>] ? pick_next_task_fair+0x121/0x8b0
> [ +0.000034] [<ffffffffa016a89b>] intel_fbdev_initial_config+0x1b/0x20 [i915]
> [ +0.000002] [<ffffffff810bdd1a>] async_run_entry_fn+0x4a/0x150
> [ +0.000002] [<ffffffff810b552c>] process_one_work+0x14c/0x400
> [ +0.000002] [<ffffffff810b5fb3>] worker_thread+0x53/0x470
> [ +0.000003] [<ffffffff810b5f60>] ? rescuer_thread+0x300/0x300
> [ +0.000002] [<ffffffff810b5f60>] ? rescuer_thread+0x300/0x300
> [ +0.000002] [<ffffffff810bb1f8>] kthread+0xd8/0xf0
> [ +0.000004] [<ffffffff810bb120>] ? kthread_create_on_node+0x1b0/0x1b0
> [ +0.000004] [<ffffffff81781458>] ret_from_fork+0x58/0x90
> [ +0.000003] [<ffffffff810bb120>] ? kthread_create_on_node+0x1b0/0x1b0
> [ +0.000002] ---[ end trace a73ba186968c6ec8 ]---
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [Intel-gfx] [git pull] drm fixes
2015-03-24 16:48 ` Daniel Vetter
(?)
@ 2015-03-24 16:49 ` Daniel Vetter
2015-03-24 16:54 ` Josh Boyer
-1 siblings, 1 reply; 71+ messages in thread
From: Daniel Vetter @ 2015-03-24 16:49 UTC (permalink / raw)
To: Josh Boyer, Dave Airlie, Xi Ruoyao, Linus Torvalds,
Linux-Kernel@Vger. Kernel. Org, DRI mailing list,
Intel Graphics Development
Cc: Jani Nikula
On Tue, Mar 24, 2015 at 05:48:31PM +0100, Daniel Vetter wrote:
> On Tue, Mar 24, 2015 at 12:10:28PM -0400, Josh Boyer wrote:
> > On Tue, Mar 24, 2015 at 10:46 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> > > On Tue, Mar 24, 2015 at 10:34 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> > >> On Tue, Mar 24, 2015 at 10:22:30AM -0400, Josh Boyer wrote:
> > >>> On Tue, Mar 24, 2015 at 9:57 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> > >>> > On Tue, Mar 24, 2015 at 9:40 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> > >>> >> On Tue, Mar 24, 2015 at 09:15:32AM -0400, Josh Boyer wrote:
> > >>> >>> On Tue, Mar 24, 2015 at 3:32 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> > >>> >>> > On Mon, Mar 23, 2015 at 02:34:27PM -0400, Josh Boyer wrote:
> > >>> >>> >> On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> > >>> >>> >>
> > >>> >>> >> <snip>
> > >>> >>> >>
> > >>> >>> >> >> Xi Ruoyao (1):
> > >>> >>> >> >> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
> > >>> >>> >>
> > >>> >>> >> Turns out to be that commit.
> > >>> >>> >>
> > >>> >>> >> git bisect start 'drivers/gpu/drm/i915/'
> > >>> >>> >> # good: [b314acaccd7e0d55314d96be4a33b5f50d0b3344] Merge branch
> > >>> >>> >> 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
> > >>> >>> >> git bisect good b314acaccd7e0d55314d96be4a33b5f50d0b3344
> > >>> >>> >> # bad: [bc465aa9d045feb0e13b4a8f32cc33c1943f62d6] Linux 4.0-rc5
> > >>> >>> >> git bisect bad bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
> > >>> >>> >> # bad: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] drm/i915: Ensure
> > >>> >>> >> plane->state->fb stays in sync with plane->fb
> > >>> >>> >> git bisect bad 319c1d420a0b62d9dbb88104afebaabc968cdbfa
> > >>> >>> >> # first bad commit: [319c1d420a0b62d9dbb88104afebaabc968cdbfa]
> > >>> >>> >> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
> > >>> >>> >>
> > >>> >>> >> Doing a straight revert on top of 4.0-rc5 makes things work again,
> > >>> >>> >> albeit with the WARN_ON(obj->frontbuffer_bits) splat still being
> > >>> >>> >> there.
> > >>> >>> >
> > >>> >>> > Can you please test the tip of drm-fixes:
> > >>> >>> >
> > >>> >>> > commit 8218c3f4df3bb1c637c17552405039a6dd3c1ee1
> > >>> >>> > Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> > >>> >>> > Date: Fri Feb 27 12:58:13 2015 +0100
> > >>> >>> >
> > >>> >>> > drm: Fixup racy refcounting in plane_force_disable
> > >>> >>> >
> > >>> >>> > http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes&id=8218c3f4df3bb1c637c17552405039a6dd3c1ee1
> > >>> >>> >
> > >>> >>> > Because fumble that patch didn't make it to drm-fixes a while ago and
> > >>> >>> > instead landed in drm-next.
> > >>> >>>
> > >>> >>> That seems to have helped with totally different issues a macbook I
> > >>> >>> have was seeing. However, it still doesn't fix the issue with the
> > >>> >>> Celeron based NUC machine.
> > >>> >>>
> > >>> >>> I built a kernel based on Linus' latest tree as of this morning,
> > >>> >>> without reverting 319c1d4 and adding the commit you pointed to. The
> > >>> >>> NUC still won't boot without HDMI connected. With HDMI connected I
> > >>> >>> still see the trace below. If I do the blacklist and then insmod
> > >>> >>> dance with HDMI unplugged it shows the same spew I reported yesterday
> > >>> >>> which starts with the same backtrace.
> > >>> >>>
> > >>> >>> I'll try building a kernel with 319c1d4 reverted + your patch. I
> > >>> >>> suspect things will work fine with that combination because the two
> > >>> >>> issues are unrelated.
> > >>> >>
> > >>> >> Can you please boot with drm.debug=0xff for the below case and grab
> > >>> >> complete dmesg? There'll be a lot of crap in the logs, you might need to
> > >>> >> blow up the logbuf size massively. But that log should contain everything
> > >>> >> I need to figure out where that framebuffer we're blowing up on is going.
> > >>> >
> > >>> > I provided both with HDMI attached and without (via insmod). If you
> > >>> > want them emailed directly let me know, but they were large.
> > >>> >
> > >>> > Boot with drm.debug=0xff and HDMI connected:
> > >>> >
> > >>> > https://jwboyer.fedorapeople.org/pub/drm-ff-dmesg.txt
> > >>> >
> > >>> > Boot with drm.debug=0xff without HDMI connected and i915 loaded via
> > >>> > manual insmod after boot:
> > >>> >
> > >>> > https://jwboyer.fedorapeople.org/pub/drm-ff-no-hdmi-insmod.txt
> > >>>
> > >>> Here's one more from the macbook I mentioned. It's showing the same
> > >>> kref.h splat:
> > >>>
> > >>> https://jwboyer.fedorapeople.org/pub/drm-ff-macbook.txt
> > >>
> > >> Ok there's at least one fixup for which we've failed to apply when porting
> > >> the fb refcounting fix from -next. Can you please cherry-pick
> > >>
> > >> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
> > >> Author: Damien Lespiau <damien.lespiau@intel.com>
> > >> Date: Thu Feb 5 18:30:20 2015 +0000
> > >>
> > >> drm/i915: Don't try to reference the fb in get_initial_plane_config()
> > >>
> > >> From linux-next?
> > >
> > > Yes, building now. Will let you know as soon as I test it on both machines.
> >
> > OK, with that commit applied I no longer get the kref.h splat and the
> > NUC machine boots headless. I still see the backtrace below on both
> > the NUC and the macbook. I have a copy of it with drm.debug=0xff from
> > the NUC here:
> >
> > https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
> >
> > Getting better at least :).
>
> Ok thanks for testing. I'll look at that one tomorrow, wasted too much
> time with trying to resurrect a few machines that should have matched the
> common parts of what goes wrong here.
>
> Jani, can you please cherry-pick the above commit to -fixes?
Actually add Jani this time around ...
-Daniel
>
> One more question: Is the frontbuffer_bits splat now also gone? That was
> the one I have no clue about, but since somewhere around 4.0-rc it started
> poppping up in a few places ... Thus far it was always the canary for some
> other bug though.
>
> Thanks, Daniel
>
> >
> > josh
> >
> > [ +0.000372] [drm] Initialized i915 1.6.0 20150130 for 0000:00:02.0 on minor 0
> > [ +0.059774] [drm] GMBUS [i915 gmbus vga] timed out, falling back to
> > bit banging on pin 2
> > [ +0.012442] fbcon: inteldrmfb (fb0) is primary device
> > [ +0.000103] ------------[ cut here ]------------
> > [ +0.000024] WARNING: CPU: 1 PID: 109 at
> > drivers/gpu/drm/drm_atomic.c:482 drm_atomic_check_only+0x33d/0x500
> > [drm]()
> > [ +0.000006] Modules linked in: i915 i2c_algo_bit drm_kms_helper drm
> > sdhci_pci sdhci mmc_core video
> > [ +0.000004] CPU: 1 PID: 109 Comm: kworker/u16:7 Not tainted
> > 4.0.0-0.rc5.git1.3.fc23.x86_64 #1
> > [ +0.000001] Hardware name: Apple Inc.
> > MacBookPro10,2/Mac-AFD8A9D944EA4843, BIOS
> > MBP102.88Z.0106.B03.1211161133 11/16/2012
> > [ +0.000005] Workqueue: events_unbound async_run_entry_fn
> > [ +0.000003] 0000000000000000 00000000cbdcc84e ffff8802628bb868
> > ffffffff8177ada9
> > [ +0.000002] 0000000000000000 0000000000000000 ffff8802628bb8a8
> > ffffffff8109c78a
> > [ +0.000002] ffff88026154c940 0000000000000048 ffff880262b1e600
> > ffff88026229e2a0
> > [ +0.000001] Call Trace:
> > [ +0.000007] [<ffffffff8177ada9>] dump_stack+0x45/0x57
> > [ +0.000003] [<ffffffff8109c78a>] warn_slowpath_common+0x8a/0xc0
> > [ +0.000003] [<ffffffff8109c8ba>] warn_slowpath_null+0x1a/0x20
> > [ +0.000014] [<ffffffffa00700ed>] drm_atomic_check_only+0x33d/0x500 [drm]
> > [ +0.000005] [<ffffffff811bc0a6>] ? kmemdup+0x36/0x50
> > [ +0.000013] [<ffffffffa00702c7>] drm_atomic_commit+0x17/0x60 [drm]
> > [ +0.000008] [<ffffffffa00c371d>]
> > drm_atomic_helper_plane_set_property+0x8d/0xd0 [drm_kms_helper]
> > [ +0.000013] [<ffffffffa005e89d>] drm_mode_plane_set_obj_prop+0x2d/0x90 [drm]
> > [ +0.000006] [<ffffffffa00c550b>] restore_fbdev_mode+0x6b/0xf0
> > [drm_kms_helper]
> > [ +0.000006] [<ffffffffa00c75c9>]
> > drm_fb_helper_restore_fbdev_mode_unlocked+0x29/0x80 [drm_kms_helper]
> > [ +0.000006] [<ffffffffa00c7642>] drm_fb_helper_set_par+0x22/0x50
> > [drm_kms_helper]
> > [ +0.000042] [<ffffffffa016959a>] intel_fbdev_set_par+0x1a/0x60 [i915]
> > [ +0.000005] [<ffffffff8140c328>] fbcon_init+0x578/0x600
> > [ +0.000005] [<ffffffff8148ceac>] visual_init+0xbc/0x120
> > [ +0.000004] [<ffffffff8148f84e>] do_bind_con_driver+0x17e/0x3b0
> > [ +0.000007] [<ffffffff8148ffd4>] do_take_over_console+0xb4/0x1b0
> > [ +0.000013] [<ffffffff81407163>] do_fbcon_takeover+0x63/0xd0
> > [ +0.000003] [<ffffffff8140ce4d>] fbcon_event_notify+0x6cd/0x7d0
> > [ +0.000005] [<ffffffff810bc18f>] notifier_call_chain+0x4f/0x80
> > [ +0.000003] [<ffffffff810bc50b>] __blocking_notifier_call_chain+0x4b/0x70
> > [ +0.000002] [<ffffffff810bc546>] blocking_notifier_call_chain+0x16/0x20
> > [ +0.000003] [<ffffffff81412dbb>] fb_notifier_call_chain+0x1b/0x20
> > [ +0.000013] [<ffffffff81415184>] register_framebuffer+0x214/0x360
> > [ +0.000007] [<ffffffffa00c78d4>]
> > drm_fb_helper_initial_config+0x264/0x3c0 [drm_kms_helper]
> > [ +0.000004] [<ffffffff810d8401>] ? pick_next_task_fair+0x121/0x8b0
> > [ +0.000034] [<ffffffffa016a89b>] intel_fbdev_initial_config+0x1b/0x20 [i915]
> > [ +0.000002] [<ffffffff810bdd1a>] async_run_entry_fn+0x4a/0x150
> > [ +0.000002] [<ffffffff810b552c>] process_one_work+0x14c/0x400
> > [ +0.000002] [<ffffffff810b5fb3>] worker_thread+0x53/0x470
> > [ +0.000003] [<ffffffff810b5f60>] ? rescuer_thread+0x300/0x300
> > [ +0.000002] [<ffffffff810b5f60>] ? rescuer_thread+0x300/0x300
> > [ +0.000002] [<ffffffff810bb1f8>] kthread+0xd8/0xf0
> > [ +0.000004] [<ffffffff810bb120>] ? kthread_create_on_node+0x1b0/0x1b0
> > [ +0.000004] [<ffffffff81781458>] ret_from_fork+0x58/0x90
> > [ +0.000003] [<ffffffff810bb120>] ? kthread_create_on_node+0x1b0/0x1b0
> > [ +0.000002] ---[ end trace a73ba186968c6ec8 ]---
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [Intel-gfx] [git pull] drm fixes
2015-03-24 16:49 ` [Intel-gfx] " Daniel Vetter
@ 2015-03-24 16:54 ` Josh Boyer
2015-03-25 3:49 ` Xi Ruoyao
0 siblings, 1 reply; 71+ messages in thread
From: Josh Boyer @ 2015-03-24 16:54 UTC (permalink / raw)
To: Dave Airlie, Xi Ruoyao, Linus Torvalds,
Linux-Kernel@Vger. Kernel. Org, DRI mailing list,
Intel Graphics Development, Jani Nikula, Daniel Vetter
On Tue, Mar 24, 2015 at 12:49 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Tue, Mar 24, 2015 at 05:48:31PM +0100, Daniel Vetter wrote:
>> On Tue, Mar 24, 2015 at 12:10:28PM -0400, Josh Boyer wrote:
>> > On Tue, Mar 24, 2015 at 10:46 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
>> > > On Tue, Mar 24, 2015 at 10:34 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> > >> On Tue, Mar 24, 2015 at 10:22:30AM -0400, Josh Boyer wrote:
>> > >>> On Tue, Mar 24, 2015 at 9:57 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
>> > >>> > On Tue, Mar 24, 2015 at 9:40 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> > >>> >> On Tue, Mar 24, 2015 at 09:15:32AM -0400, Josh Boyer wrote:
>> > >>> >>> On Tue, Mar 24, 2015 at 3:32 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> > >>> >>> > On Mon, Mar 23, 2015 at 02:34:27PM -0400, Josh Boyer wrote:
>> > >>> >>> >> On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
>> > >>> >>> >>
>> > >>> >>> >> <snip>
>> > >>> >>> >>
>> > >>> >>> >> >> Xi Ruoyao (1):
>> > >>> >>> >> >> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
>> > >>> >>> >>
>> > >>> >>> >> Turns out to be that commit.
>> > >>> >>> >>
>> > >>> >>> >> git bisect start 'drivers/gpu/drm/i915/'
>> > >>> >>> >> # good: [b314acaccd7e0d55314d96be4a33b5f50d0b3344] Merge branch
>> > >>> >>> >> 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
>> > >>> >>> >> git bisect good b314acaccd7e0d55314d96be4a33b5f50d0b3344
>> > >>> >>> >> # bad: [bc465aa9d045feb0e13b4a8f32cc33c1943f62d6] Linux 4.0-rc5
>> > >>> >>> >> git bisect bad bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
>> > >>> >>> >> # bad: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] drm/i915: Ensure
>> > >>> >>> >> plane->state->fb stays in sync with plane->fb
>> > >>> >>> >> git bisect bad 319c1d420a0b62d9dbb88104afebaabc968cdbfa
>> > >>> >>> >> # first bad commit: [319c1d420a0b62d9dbb88104afebaabc968cdbfa]
>> > >>> >>> >> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
>> > >>> >>> >>
>> > >>> >>> >> Doing a straight revert on top of 4.0-rc5 makes things work again,
>> > >>> >>> >> albeit with the WARN_ON(obj->frontbuffer_bits) splat still being
>> > >>> >>> >> there.
>> > >>> >>> >
>> > >>> >>> > Can you please test the tip of drm-fixes:
>> > >>> >>> >
>> > >>> >>> > commit 8218c3f4df3bb1c637c17552405039a6dd3c1ee1
>> > >>> >>> > Author: Daniel Vetter <daniel.vetter@ffwll.ch>
>> > >>> >>> > Date: Fri Feb 27 12:58:13 2015 +0100
>> > >>> >>> >
>> > >>> >>> > drm: Fixup racy refcounting in plane_force_disable
>> > >>> >>> >
>> > >>> >>> > http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes&id=8218c3f4df3bb1c637c17552405039a6dd3c1ee1
>> > >>> >>> >
>> > >>> >>> > Because fumble that patch didn't make it to drm-fixes a while ago and
>> > >>> >>> > instead landed in drm-next.
>> > >>> >>>
>> > >>> >>> That seems to have helped with totally different issues a macbook I
>> > >>> >>> have was seeing. However, it still doesn't fix the issue with the
>> > >>> >>> Celeron based NUC machine.
>> > >>> >>>
>> > >>> >>> I built a kernel based on Linus' latest tree as of this morning,
>> > >>> >>> without reverting 319c1d4 and adding the commit you pointed to. The
>> > >>> >>> NUC still won't boot without HDMI connected. With HDMI connected I
>> > >>> >>> still see the trace below. If I do the blacklist and then insmod
>> > >>> >>> dance with HDMI unplugged it shows the same spew I reported yesterday
>> > >>> >>> which starts with the same backtrace.
>> > >>> >>>
>> > >>> >>> I'll try building a kernel with 319c1d4 reverted + your patch. I
>> > >>> >>> suspect things will work fine with that combination because the two
>> > >>> >>> issues are unrelated.
>> > >>> >>
>> > >>> >> Can you please boot with drm.debug=0xff for the below case and grab
>> > >>> >> complete dmesg? There'll be a lot of crap in the logs, you might need to
>> > >>> >> blow up the logbuf size massively. But that log should contain everything
>> > >>> >> I need to figure out where that framebuffer we're blowing up on is going.
>> > >>> >
>> > >>> > I provided both with HDMI attached and without (via insmod). If you
>> > >>> > want them emailed directly let me know, but they were large.
>> > >>> >
>> > >>> > Boot with drm.debug=0xff and HDMI connected:
>> > >>> >
>> > >>> > https://jwboyer.fedorapeople.org/pub/drm-ff-dmesg.txt
>> > >>> >
>> > >>> > Boot with drm.debug=0xff without HDMI connected and i915 loaded via
>> > >>> > manual insmod after boot:
>> > >>> >
>> > >>> > https://jwboyer.fedorapeople.org/pub/drm-ff-no-hdmi-insmod.txt
>> > >>>
>> > >>> Here's one more from the macbook I mentioned. It's showing the same
>> > >>> kref.h splat:
>> > >>>
>> > >>> https://jwboyer.fedorapeople.org/pub/drm-ff-macbook.txt
>> > >>
>> > >> Ok there's at least one fixup for which we've failed to apply when porting
>> > >> the fb refcounting fix from -next. Can you please cherry-pick
>> > >>
>> > >> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
>> > >> Author: Damien Lespiau <damien.lespiau@intel.com>
>> > >> Date: Thu Feb 5 18:30:20 2015 +0000
>> > >>
>> > >> drm/i915: Don't try to reference the fb in get_initial_plane_config()
>> > >>
>> > >> From linux-next?
>> > >
>> > > Yes, building now. Will let you know as soon as I test it on both machines.
>> >
>> > OK, with that commit applied I no longer get the kref.h splat and the
>> > NUC machine boots headless. I still see the backtrace below on both
>> > the NUC and the macbook. I have a copy of it with drm.debug=0xff from
>> > the NUC here:
>> >
>> > https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
>> >
>> > Getting better at least :).
>>
>> Ok thanks for testing. I'll look at that one tomorrow, wasted too much
>> time with trying to resurrect a few machines that should have matched the
>> common parts of what goes wrong here.
>>
>> Jani, can you please cherry-pick the above commit to -fixes?
>
> Actually add Jani this time around ...
> -Daniel
>
>>
>> One more question: Is the frontbuffer_bits splat now also gone? That was
>> the one I have no clue about, but since somewhere around 4.0-rc it started
>> poppping up in a few places ... Thus far it was always the canary for some
>> other bug though.
As far as I can tell, it's gone. I don't see it on any of my i915
machines running the kernel with those two patches. I'll keep an eye
out for it as we work through 4.0-rcX.
josh
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [Intel-gfx] [git pull] drm fixes
2015-03-24 16:54 ` Josh Boyer
@ 2015-03-25 3:49 ` Xi Ruoyao
0 siblings, 0 replies; 71+ messages in thread
From: Xi Ruoyao @ 2015-03-25 3:49 UTC (permalink / raw)
To: Josh Boyer, Dave Airlie
Cc: Linus Torvalds, Linux-Kernel@Vger. Kernel. Org, DRI mailing list,
Intel Graphics Development, Jani Nikula, Daniel Vetter
On 03/25/2015 at 12:54 AM, Josh Boyer wrote:
> On Tue, Mar 24, 2015 at 12:49 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> On Tue, Mar 24, 2015 at 05:48:31PM +0100, Daniel Vetter wrote:
>>> On Tue, Mar 24, 2015 at 12:10:28PM -0400, Josh Boyer wrote:
>>>> On Tue, Mar 24, 2015 at 10:46 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
>>>>> On Tue, Mar 24, 2015 at 10:34 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>>>>>> On Tue, Mar 24, 2015 at 10:22:30AM -0400, Josh Boyer wrote:
>>>>>>> On Tue, Mar 24, 2015 at 9:57 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
>>>>>>>> On Tue, Mar 24, 2015 at 9:40 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>>>>>>>>> On Tue, Mar 24, 2015 at 09:15:32AM -0400, Josh Boyer wrote:
>>>>>>>>>> On Tue, Mar 24, 2015 at 3:32 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>>>>>>>>>>> On Mon, Mar 23, 2015 at 02:34:27PM -0400, Josh Boyer wrote:
>>>>>>>>>>>> On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> <snip>
>>>>>>>>>>>>
>>>>>>>>>>>>>> Xi Ruoyao (1):
>>>>>>>>>>>>>> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
>>>>>>>>>>>> Turns out to be that commit.
>>>>>>>>>>>>
>>>>>>>>>>>> git bisect start 'drivers/gpu/drm/i915/'
>>>>>>>>>>>> # good: [b314acaccd7e0d55314d96be4a33b5f50d0b3344] Merge branch
>>>>>>>>>>>> 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
>>>>>>>>>>>> git bisect good b314acaccd7e0d55314d96be4a33b5f50d0b3344
>>>>>>>>>>>> # bad: [bc465aa9d045feb0e13b4a8f32cc33c1943f62d6] Linux 4.0-rc5
>>>>>>>>>>>> git bisect bad bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
>>>>>>>>>>>> # bad: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] drm/i915: Ensure
>>>>>>>>>>>> plane->state->fb stays in sync with plane->fb
>>>>>>>>>>>> git bisect bad 319c1d420a0b62d9dbb88104afebaabc968cdbfa
>>>>>>>>>>>> # first bad commit: [319c1d420a0b62d9dbb88104afebaabc968cdbfa]
>>>>>>>>>>>> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
>>>>>>>>>>>>
>>>>>>>>>>>> Doing a straight revert on top of 4.0-rc5 makes things work again,
>>>>>>>>>>>> albeit with the WARN_ON(obj->frontbuffer_bits) splat still being
>>>>>>>>>>>> there.
>>>>>>>>>>> Can you please test the tip of drm-fixes:
>>>>>>>>>>>
>>>>>>>>>>> commit 8218c3f4df3bb1c637c17552405039a6dd3c1ee1
>>>>>>>>>>> Author: Daniel Vetter <daniel.vetter@ffwll.ch>
>>>>>>>>>>> Date: Fri Feb 27 12:58:13 2015 +0100
>>>>>>>>>>>
>>>>>>>>>>> drm: Fixup racy refcounting in plane_force_disable
>>>>>>>>>>>
>>>>>>>>>>> http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes&id=8218c3f4df3bb1c637c17552405039a6dd3c1ee1
>>>>>>>>>>>
>>>>>>>>>>> Because fumble that patch didn't make it to drm-fixes a while ago and
>>>>>>>>>>> instead landed in drm-next.
>>>>>>>>>> That seems to have helped with totally different issues a macbook I
>>>>>>>>>> have was seeing. However, it still doesn't fix the issue with the
>>>>>>>>>> Celeron based NUC machine.
>>>>>>>>>>
>>>>>>>>>> I built a kernel based on Linus' latest tree as of this morning,
>>>>>>>>>> without reverting 319c1d4 and adding the commit you pointed to. The
>>>>>>>>>> NUC still won't boot without HDMI connected. With HDMI connected I
>>>>>>>>>> still see the trace below. If I do the blacklist and then insmod
>>>>>>>>>> dance with HDMI unplugged it shows the same spew I reported yesterday
>>>>>>>>>> which starts with the same backtrace.
>>>>>>>>>>
>>>>>>>>>> I'll try building a kernel with 319c1d4 reverted + your patch. I
>>>>>>>>>> suspect things will work fine with that combination because the two
>>>>>>>>>> issues are unrelated.
>>>>>>>>> Can you please boot with drm.debug=0xff for the below case and grab
>>>>>>>>> complete dmesg? There'll be a lot of crap in the logs, you might need to
>>>>>>>>> blow up the logbuf size massively. But that log should contain everything
>>>>>>>>> I need to figure out where that framebuffer we're blowing up on is going.
>>>>>>>> I provided both with HDMI attached and without (via insmod). If you
>>>>>>>> want them emailed directly let me know, but they were large.
>>>>>>>>
>>>>>>>> Boot with drm.debug=0xff and HDMI connected:
>>>>>>>>
>>>>>>>> https://jwboyer.fedorapeople.org/pub/drm-ff-dmesg.txt
>>>>>>>>
>>>>>>>> Boot with drm.debug=0xff without HDMI connected and i915 loaded via
>>>>>>>> manual insmod after boot:
>>>>>>>>
>>>>>>>> https://jwboyer.fedorapeople.org/pub/drm-ff-no-hdmi-insmod.txt
>>>>>>> Here's one more from the macbook I mentioned. It's showing the same
>>>>>>> kref.h splat:
>>>>>>>
>>>>>>> https://jwboyer.fedorapeople.org/pub/drm-ff-macbook.txt
>>>>>> Ok there's at least one fixup for which we've failed to apply when porting
>>>>>> the fb refcounting fix from -next. Can you please cherry-pick
>>>>>>
>>>>>> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
>>>>>> Author: Damien Lespiau <damien.lespiau@intel.com>
>>>>>> Date: Thu Feb 5 18:30:20 2015 +0000
>>>>>>
>>>>>> drm/i915: Don't try to reference the fb in get_initial_plane_config()
>>>>>>
>>>>>> From linux-next?
>>>>> Yes, building now. Will let you know as soon as I test it on both machines.
>>>> OK, with that commit applied I no longer get the kref.h splat and the
>>>> NUC machine boots headless. I still see the backtrace below on both
>>>> the NUC and the macbook. I have a copy of it with drm.debug=0xff from
>>>> the NUC here:
>>>>
>>>> https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
>>>>
>>>> Getting better at least :).
>>> Ok thanks for testing. I'll look at that one tomorrow, wasted too much
>>> time with trying to resurrect a few machines that should have matched the
>>> common parts of what goes wrong here.
>>>
>>> Jani, can you please cherry-pick the above commit to -fixes?
>> Actually add Jani this time around ...
>> -Daniel
>>
>>> One more question: Is the frontbuffer_bits splat now also gone? That was
>>> the one I have no clue about, but since somewhere around 4.0-rc it started
>>> poppping up in a few places ... Thus far it was always the canary for some
>>> other bug though.
> As far as I can tell, it's gone. I don't see it on any of my i915
> machines running the kernel with those two patches. I'll keep an eye
> out for it as we work through 4.0-rcX.
>
> josh
It's fortunately my computer didn't stuck. But it's unfortuantely
my patch causing so much trouble. I should've research commit
in linux-next more before applying it to mainline.
I found many WARNINGs in kernel log after Josh reported this bug.
I will try Damien's solution.
--
Xi Ruoyao
School of Aerospace Science and Technology
Xidian University, Xi'an, China
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [git pull] drm fixes
@ 2015-03-25 3:49 ` Xi Ruoyao
0 siblings, 0 replies; 71+ messages in thread
From: Xi Ruoyao @ 2015-03-25 3:49 UTC (permalink / raw)
To: Josh Boyer, Dave Airlie
Cc: Intel Graphics Development, Linux-Kernel@Vger. Kernel. Org,
DRI mailing list, Linus Torvalds
On 03/25/2015 at 12:54 AM, Josh Boyer wrote:
> On Tue, Mar 24, 2015 at 12:49 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> On Tue, Mar 24, 2015 at 05:48:31PM +0100, Daniel Vetter wrote:
>>> On Tue, Mar 24, 2015 at 12:10:28PM -0400, Josh Boyer wrote:
>>>> On Tue, Mar 24, 2015 at 10:46 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
>>>>> On Tue, Mar 24, 2015 at 10:34 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>>>>>> On Tue, Mar 24, 2015 at 10:22:30AM -0400, Josh Boyer wrote:
>>>>>>> On Tue, Mar 24, 2015 at 9:57 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
>>>>>>>> On Tue, Mar 24, 2015 at 9:40 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>>>>>>>>> On Tue, Mar 24, 2015 at 09:15:32AM -0400, Josh Boyer wrote:
>>>>>>>>>> On Tue, Mar 24, 2015 at 3:32 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>>>>>>>>>>> On Mon, Mar 23, 2015 at 02:34:27PM -0400, Josh Boyer wrote:
>>>>>>>>>>>> On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> <snip>
>>>>>>>>>>>>
>>>>>>>>>>>>>> Xi Ruoyao (1):
>>>>>>>>>>>>>> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
>>>>>>>>>>>> Turns out to be that commit.
>>>>>>>>>>>>
>>>>>>>>>>>> git bisect start 'drivers/gpu/drm/i915/'
>>>>>>>>>>>> # good: [b314acaccd7e0d55314d96be4a33b5f50d0b3344] Merge branch
>>>>>>>>>>>> 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
>>>>>>>>>>>> git bisect good b314acaccd7e0d55314d96be4a33b5f50d0b3344
>>>>>>>>>>>> # bad: [bc465aa9d045feb0e13b4a8f32cc33c1943f62d6] Linux 4.0-rc5
>>>>>>>>>>>> git bisect bad bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
>>>>>>>>>>>> # bad: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] drm/i915: Ensure
>>>>>>>>>>>> plane->state->fb stays in sync with plane->fb
>>>>>>>>>>>> git bisect bad 319c1d420a0b62d9dbb88104afebaabc968cdbfa
>>>>>>>>>>>> # first bad commit: [319c1d420a0b62d9dbb88104afebaabc968cdbfa]
>>>>>>>>>>>> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
>>>>>>>>>>>>
>>>>>>>>>>>> Doing a straight revert on top of 4.0-rc5 makes things work again,
>>>>>>>>>>>> albeit with the WARN_ON(obj->frontbuffer_bits) splat still being
>>>>>>>>>>>> there.
>>>>>>>>>>> Can you please test the tip of drm-fixes:
>>>>>>>>>>>
>>>>>>>>>>> commit 8218c3f4df3bb1c637c17552405039a6dd3c1ee1
>>>>>>>>>>> Author: Daniel Vetter <daniel.vetter@ffwll.ch>
>>>>>>>>>>> Date: Fri Feb 27 12:58:13 2015 +0100
>>>>>>>>>>>
>>>>>>>>>>> drm: Fixup racy refcounting in plane_force_disable
>>>>>>>>>>>
>>>>>>>>>>> http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes&id=8218c3f4df3bb1c637c17552405039a6dd3c1ee1
>>>>>>>>>>>
>>>>>>>>>>> Because fumble that patch didn't make it to drm-fixes a while ago and
>>>>>>>>>>> instead landed in drm-next.
>>>>>>>>>> That seems to have helped with totally different issues a macbook I
>>>>>>>>>> have was seeing. However, it still doesn't fix the issue with the
>>>>>>>>>> Celeron based NUC machine.
>>>>>>>>>>
>>>>>>>>>> I built a kernel based on Linus' latest tree as of this morning,
>>>>>>>>>> without reverting 319c1d4 and adding the commit you pointed to. The
>>>>>>>>>> NUC still won't boot without HDMI connected. With HDMI connected I
>>>>>>>>>> still see the trace below. If I do the blacklist and then insmod
>>>>>>>>>> dance with HDMI unplugged it shows the same spew I reported yesterday
>>>>>>>>>> which starts with the same backtrace.
>>>>>>>>>>
>>>>>>>>>> I'll try building a kernel with 319c1d4 reverted + your patch. I
>>>>>>>>>> suspect things will work fine with that combination because the two
>>>>>>>>>> issues are unrelated.
>>>>>>>>> Can you please boot with drm.debug=0xff for the below case and grab
>>>>>>>>> complete dmesg? There'll be a lot of crap in the logs, you might need to
>>>>>>>>> blow up the logbuf size massively. But that log should contain everything
>>>>>>>>> I need to figure out where that framebuffer we're blowing up on is going.
>>>>>>>> I provided both with HDMI attached and without (via insmod). If you
>>>>>>>> want them emailed directly let me know, but they were large.
>>>>>>>>
>>>>>>>> Boot with drm.debug=0xff and HDMI connected:
>>>>>>>>
>>>>>>>> https://jwboyer.fedorapeople.org/pub/drm-ff-dmesg.txt
>>>>>>>>
>>>>>>>> Boot with drm.debug=0xff without HDMI connected and i915 loaded via
>>>>>>>> manual insmod after boot:
>>>>>>>>
>>>>>>>> https://jwboyer.fedorapeople.org/pub/drm-ff-no-hdmi-insmod.txt
>>>>>>> Here's one more from the macbook I mentioned. It's showing the same
>>>>>>> kref.h splat:
>>>>>>>
>>>>>>> https://jwboyer.fedorapeople.org/pub/drm-ff-macbook.txt
>>>>>> Ok there's at least one fixup for which we've failed to apply when porting
>>>>>> the fb refcounting fix from -next. Can you please cherry-pick
>>>>>>
>>>>>> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
>>>>>> Author: Damien Lespiau <damien.lespiau@intel.com>
>>>>>> Date: Thu Feb 5 18:30:20 2015 +0000
>>>>>>
>>>>>> drm/i915: Don't try to reference the fb in get_initial_plane_config()
>>>>>>
>>>>>> From linux-next?
>>>>> Yes, building now. Will let you know as soon as I test it on both machines.
>>>> OK, with that commit applied I no longer get the kref.h splat and the
>>>> NUC machine boots headless. I still see the backtrace below on both
>>>> the NUC and the macbook. I have a copy of it with drm.debug=0xff from
>>>> the NUC here:
>>>>
>>>> https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
>>>>
>>>> Getting better at least :).
>>> Ok thanks for testing. I'll look at that one tomorrow, wasted too much
>>> time with trying to resurrect a few machines that should have matched the
>>> common parts of what goes wrong here.
>>>
>>> Jani, can you please cherry-pick the above commit to -fixes?
>> Actually add Jani this time around ...
>> -Daniel
>>
>>> One more question: Is the frontbuffer_bits splat now also gone? That was
>>> the one I have no clue about, but since somewhere around 4.0-rc it started
>>> poppping up in a few places ... Thus far it was always the canary for some
>>> other bug though.
> As far as I can tell, it's gone. I don't see it on any of my i915
> machines running the kernel with those two patches. I'll keep an eye
> out for it as we work through 4.0-rcX.
>
> josh
It's fortunately my computer didn't stuck. But it's unfortuantely
my patch causing so much trouble. I should've research commit
in linux-next more before applying it to mainline.
I found many WARNINGs in kernel log after Josh reported this bug.
I will try Damien's solution.
--
Xi Ruoyao
School of Aerospace Science and Technology
Xidian University, Xi'an, China
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [Intel-gfx] [git pull] drm fixes
2015-03-24 16:10 ` Josh Boyer
@ 2015-03-25 8:54 ` Daniel Vetter
-1 siblings, 0 replies; 71+ messages in thread
From: Daniel Vetter @ 2015-03-25 8:54 UTC (permalink / raw)
To: Josh Boyer
Cc: Daniel Vetter, Dave Airlie, Xi Ruoyao, Linus Torvalds,
Linux-Kernel@Vger. Kernel. Org, DRI mailing list,
Intel Graphics Development
On Tue, Mar 24, 2015 at 12:10:28PM -0400, Josh Boyer wrote:
> On Tue, Mar 24, 2015 at 10:46 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> > On Tue, Mar 24, 2015 at 10:34 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> >> On Tue, Mar 24, 2015 at 10:22:30AM -0400, Josh Boyer wrote:
> >>> On Tue, Mar 24, 2015 at 9:57 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> >>> > On Tue, Mar 24, 2015 at 9:40 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> >>> >> On Tue, Mar 24, 2015 at 09:15:32AM -0400, Josh Boyer wrote:
> >>> >>> On Tue, Mar 24, 2015 at 3:32 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> >>> >>> > On Mon, Mar 23, 2015 at 02:34:27PM -0400, Josh Boyer wrote:
> >>> >>> >> On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> >>> >>> >>
> >>> >>> >> <snip>
> >>> >>> >>
> >>> >>> >> >> Xi Ruoyao (1):
> >>> >>> >> >> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
> >>> >>> >>
> >>> >>> >> Turns out to be that commit.
> >>> >>> >>
> >>> >>> >> git bisect start 'drivers/gpu/drm/i915/'
> >>> >>> >> # good: [b314acaccd7e0d55314d96be4a33b5f50d0b3344] Merge branch
> >>> >>> >> 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
> >>> >>> >> git bisect good b314acaccd7e0d55314d96be4a33b5f50d0b3344
> >>> >>> >> # bad: [bc465aa9d045feb0e13b4a8f32cc33c1943f62d6] Linux 4.0-rc5
> >>> >>> >> git bisect bad bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
> >>> >>> >> # bad: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] drm/i915: Ensure
> >>> >>> >> plane->state->fb stays in sync with plane->fb
> >>> >>> >> git bisect bad 319c1d420a0b62d9dbb88104afebaabc968cdbfa
> >>> >>> >> # first bad commit: [319c1d420a0b62d9dbb88104afebaabc968cdbfa]
> >>> >>> >> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
> >>> >>> >>
> >>> >>> >> Doing a straight revert on top of 4.0-rc5 makes things work again,
> >>> >>> >> albeit with the WARN_ON(obj->frontbuffer_bits) splat still being
> >>> >>> >> there.
> >>> >>> >
> >>> >>> > Can you please test the tip of drm-fixes:
> >>> >>> >
> >>> >>> > commit 8218c3f4df3bb1c637c17552405039a6dd3c1ee1
> >>> >>> > Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> >>> >>> > Date: Fri Feb 27 12:58:13 2015 +0100
> >>> >>> >
> >>> >>> > drm: Fixup racy refcounting in plane_force_disable
> >>> >>> >
> >>> >>> > http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes&id=8218c3f4df3bb1c637c17552405039a6dd3c1ee1
> >>> >>> >
> >>> >>> > Because fumble that patch didn't make it to drm-fixes a while ago and
> >>> >>> > instead landed in drm-next.
> >>> >>>
> >>> >>> That seems to have helped with totally different issues a macbook I
> >>> >>> have was seeing. However, it still doesn't fix the issue with the
> >>> >>> Celeron based NUC machine.
> >>> >>>
> >>> >>> I built a kernel based on Linus' latest tree as of this morning,
> >>> >>> without reverting 319c1d4 and adding the commit you pointed to. The
> >>> >>> NUC still won't boot without HDMI connected. With HDMI connected I
> >>> >>> still see the trace below. If I do the blacklist and then insmod
> >>> >>> dance with HDMI unplugged it shows the same spew I reported yesterday
> >>> >>> which starts with the same backtrace.
> >>> >>>
> >>> >>> I'll try building a kernel with 319c1d4 reverted + your patch. I
> >>> >>> suspect things will work fine with that combination because the two
> >>> >>> issues are unrelated.
> >>> >>
> >>> >> Can you please boot with drm.debug=0xff for the below case and grab
> >>> >> complete dmesg? There'll be a lot of crap in the logs, you might need to
> >>> >> blow up the logbuf size massively. But that log should contain everything
> >>> >> I need to figure out where that framebuffer we're blowing up on is going.
> >>> >
> >>> > I provided both with HDMI attached and without (via insmod). If you
> >>> > want them emailed directly let me know, but they were large.
> >>> >
> >>> > Boot with drm.debug=0xff and HDMI connected:
> >>> >
> >>> > https://jwboyer.fedorapeople.org/pub/drm-ff-dmesg.txt
> >>> >
> >>> > Boot with drm.debug=0xff without HDMI connected and i915 loaded via
> >>> > manual insmod after boot:
> >>> >
> >>> > https://jwboyer.fedorapeople.org/pub/drm-ff-no-hdmi-insmod.txt
> >>>
> >>> Here's one more from the macbook I mentioned. It's showing the same
> >>> kref.h splat:
> >>>
> >>> https://jwboyer.fedorapeople.org/pub/drm-ff-macbook.txt
> >>
> >> Ok there's at least one fixup for which we've failed to apply when porting
> >> the fb refcounting fix from -next. Can you please cherry-pick
> >>
> >> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
> >> Author: Damien Lespiau <damien.lespiau@intel.com>
> >> Date: Thu Feb 5 18:30:20 2015 +0000
> >>
> >> drm/i915: Don't try to reference the fb in get_initial_plane_config()
> >>
> >> From linux-next?
> >
> > Yes, building now. Will let you know as soon as I test it on both machines.
>
> OK, with that commit applied I no longer get the kref.h splat and the
> NUC machine boots headless. I still see the backtrace below on both
> the NUC and the macbook. I have a copy of it with drm.debug=0xff from
> the NUC here:
>
> https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
>
> Getting better at least :).
On top of what you currently have please also cherry-pick
commit fb9981aa675eb7b398849915364916fd98833cfa
Author: Damien Lespiau <damien.lespiau@intel.com>
Date: Thu Feb 5 19:24:25 2015 +0000
drm/i915: Fix atomic state when reusing the firmware fb
from -next. Let's hope this terminates eventually ;-)
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [git pull] drm fixes
@ 2015-03-25 8:54 ` Daniel Vetter
0 siblings, 0 replies; 71+ messages in thread
From: Daniel Vetter @ 2015-03-25 8:54 UTC (permalink / raw)
To: Josh Boyer
Cc: Dave Airlie, Intel Graphics Development,
Linux-Kernel@Vger. Kernel. Org, DRI mailing list, Xi Ruoyao,
Linus Torvalds
On Tue, Mar 24, 2015 at 12:10:28PM -0400, Josh Boyer wrote:
> On Tue, Mar 24, 2015 at 10:46 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> > On Tue, Mar 24, 2015 at 10:34 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> >> On Tue, Mar 24, 2015 at 10:22:30AM -0400, Josh Boyer wrote:
> >>> On Tue, Mar 24, 2015 at 9:57 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> >>> > On Tue, Mar 24, 2015 at 9:40 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> >>> >> On Tue, Mar 24, 2015 at 09:15:32AM -0400, Josh Boyer wrote:
> >>> >>> On Tue, Mar 24, 2015 at 3:32 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> >>> >>> > On Mon, Mar 23, 2015 at 02:34:27PM -0400, Josh Boyer wrote:
> >>> >>> >> On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> >>> >>> >>
> >>> >>> >> <snip>
> >>> >>> >>
> >>> >>> >> >> Xi Ruoyao (1):
> >>> >>> >> >> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
> >>> >>> >>
> >>> >>> >> Turns out to be that commit.
> >>> >>> >>
> >>> >>> >> git bisect start 'drivers/gpu/drm/i915/'
> >>> >>> >> # good: [b314acaccd7e0d55314d96be4a33b5f50d0b3344] Merge branch
> >>> >>> >> 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
> >>> >>> >> git bisect good b314acaccd7e0d55314d96be4a33b5f50d0b3344
> >>> >>> >> # bad: [bc465aa9d045feb0e13b4a8f32cc33c1943f62d6] Linux 4.0-rc5
> >>> >>> >> git bisect bad bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
> >>> >>> >> # bad: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] drm/i915: Ensure
> >>> >>> >> plane->state->fb stays in sync with plane->fb
> >>> >>> >> git bisect bad 319c1d420a0b62d9dbb88104afebaabc968cdbfa
> >>> >>> >> # first bad commit: [319c1d420a0b62d9dbb88104afebaabc968cdbfa]
> >>> >>> >> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
> >>> >>> >>
> >>> >>> >> Doing a straight revert on top of 4.0-rc5 makes things work again,
> >>> >>> >> albeit with the WARN_ON(obj->frontbuffer_bits) splat still being
> >>> >>> >> there.
> >>> >>> >
> >>> >>> > Can you please test the tip of drm-fixes:
> >>> >>> >
> >>> >>> > commit 8218c3f4df3bb1c637c17552405039a6dd3c1ee1
> >>> >>> > Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> >>> >>> > Date: Fri Feb 27 12:58:13 2015 +0100
> >>> >>> >
> >>> >>> > drm: Fixup racy refcounting in plane_force_disable
> >>> >>> >
> >>> >>> > http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes&id=8218c3f4df3bb1c637c17552405039a6dd3c1ee1
> >>> >>> >
> >>> >>> > Because fumble that patch didn't make it to drm-fixes a while ago and
> >>> >>> > instead landed in drm-next.
> >>> >>>
> >>> >>> That seems to have helped with totally different issues a macbook I
> >>> >>> have was seeing. However, it still doesn't fix the issue with the
> >>> >>> Celeron based NUC machine.
> >>> >>>
> >>> >>> I built a kernel based on Linus' latest tree as of this morning,
> >>> >>> without reverting 319c1d4 and adding the commit you pointed to. The
> >>> >>> NUC still won't boot without HDMI connected. With HDMI connected I
> >>> >>> still see the trace below. If I do the blacklist and then insmod
> >>> >>> dance with HDMI unplugged it shows the same spew I reported yesterday
> >>> >>> which starts with the same backtrace.
> >>> >>>
> >>> >>> I'll try building a kernel with 319c1d4 reverted + your patch. I
> >>> >>> suspect things will work fine with that combination because the two
> >>> >>> issues are unrelated.
> >>> >>
> >>> >> Can you please boot with drm.debug=0xff for the below case and grab
> >>> >> complete dmesg? There'll be a lot of crap in the logs, you might need to
> >>> >> blow up the logbuf size massively. But that log should contain everything
> >>> >> I need to figure out where that framebuffer we're blowing up on is going.
> >>> >
> >>> > I provided both with HDMI attached and without (via insmod). If you
> >>> > want them emailed directly let me know, but they were large.
> >>> >
> >>> > Boot with drm.debug=0xff and HDMI connected:
> >>> >
> >>> > https://jwboyer.fedorapeople.org/pub/drm-ff-dmesg.txt
> >>> >
> >>> > Boot with drm.debug=0xff without HDMI connected and i915 loaded via
> >>> > manual insmod after boot:
> >>> >
> >>> > https://jwboyer.fedorapeople.org/pub/drm-ff-no-hdmi-insmod.txt
> >>>
> >>> Here's one more from the macbook I mentioned. It's showing the same
> >>> kref.h splat:
> >>>
> >>> https://jwboyer.fedorapeople.org/pub/drm-ff-macbook.txt
> >>
> >> Ok there's at least one fixup for which we've failed to apply when porting
> >> the fb refcounting fix from -next. Can you please cherry-pick
> >>
> >> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
> >> Author: Damien Lespiau <damien.lespiau@intel.com>
> >> Date: Thu Feb 5 18:30:20 2015 +0000
> >>
> >> drm/i915: Don't try to reference the fb in get_initial_plane_config()
> >>
> >> From linux-next?
> >
> > Yes, building now. Will let you know as soon as I test it on both machines.
>
> OK, with that commit applied I no longer get the kref.h splat and the
> NUC machine boots headless. I still see the backtrace below on both
> the NUC and the macbook. I have a copy of it with drm.debug=0xff from
> the NUC here:
>
> https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
>
> Getting better at least :).
On top of what you currently have please also cherry-pick
commit fb9981aa675eb7b398849915364916fd98833cfa
Author: Damien Lespiau <damien.lespiau@intel.com>
Date: Thu Feb 5 19:24:25 2015 +0000
drm/i915: Fix atomic state when reusing the firmware fb
from -next. Let's hope this terminates eventually ;-)
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [git pull] drm fixes
2015-03-24 1:41 ` Dave Jones
@ 2015-03-25 8:56 ` Daniel Vetter
0 siblings, 0 replies; 71+ messages in thread
From: Daniel Vetter @ 2015-03-25 8:56 UTC (permalink / raw)
To: Dave Jones, Josh Boyer, Dave Airlie, Damien Lespiau, Xi Ruoyao,
Linus Torvalds, DRI mailing list, Linux-Kernel@Vger. Kernel. Org,
Intel Graphics Development
On Mon, Mar 23, 2015 at 09:41:20PM -0400, Dave Jones wrote:
> 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.000039] WARNING: CPU: 0 PID: 63 at
> > drivers/gpu/drm/i915/i915_gem.c:4525 i915_gem_free_object+0x2e5/0x320
> > [i915]()
> > [ +0.000002] 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.000037] WARNING: CPU: 1 PID: 1486 at include/linux/kref.h:47
> > drm_framebuffer_reference+0x7a/0x90 [drm]()
> ..
> > [ +0.000037] 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..
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 <damien.lespiau@intel.com>
Date: Thu Feb 5 18:30:20 2015 +0000
drm/i915: Don't try to reference the fb in get_initial_plane_config()
and
commit fb9981aa675eb7b398849915364916fd98833cfa
Author: Damien Lespiau <damien.lespiau@intel.com>
Date: Thu Feb 5 19:24:25 2015 +0000
drm/i915: Fix atomic state when reusing the firmware fb
from linux-next and then check what's left?
Thanks, Daniel
>
>
> =============================================================================
> BUG kmalloc-192 (Tainted: G W ): Poison overwritten
> -----------------------------------------------------------------------------
> Disabling lock debugging due to kernel taint
> INFO: 0xffff8804277e5c78-0xffff8804277e5c78. 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 0xffffea00109df900 objects=31 used=31 fp=0x (null) flags=0x8000000000004080
> INFO: Object 0xffff8804277e5c70 @offset=7280 fp=0xffff8804277e6288
> Bytes b4 ffff8804277e5c60: 54 7a fb ff 00 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a Tz......ZZZZZZZZ
> Object ffff8804277e5c70: 6b 6b 6b 6b 6b 6b 6b 6b 6a 6b 6b 6b 6b 6b 6b 6b kkkkkkkkjkkkkkkk
> Object ffff8804277e5c80: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff8804277e5c90: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff8804277e5ca0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff8804277e5cb0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff8804277e5cc0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff8804277e5cd0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff8804277e5ce0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff8804277e5cf0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff8804277e5d00: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff8804277e5d10: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff8804277e5d20: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 kkkkkkkkkkkkkkk.
> Redzone ffff8804277e5d30: bb bb bb bb bb bb bb bb ........
> Padding ffff8804277e5e70: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ
> CPU: 4 PID: 128 Comm: kworker/u16:4 Tainted: G B W 4.0.0-rc5-backupdebug+ #1
> Workqueue: events_unbound async_run_entry_fn
> ffff8804277e5c70 000000002ebc2945 ffff8800b780f578 ffffffff90780cc3
> 0000000000000000 ffff88042b804900 ffff8800b780f5b8 ffffffff901e76cc
> 0000000000000008 ffff880400000001 ffff8804277e5c79 ffff88042b804900
> Call Trace:
> [<ffffffff90780cc3>] dump_stack+0x4c/0x65
> [<ffffffff901e76cc>] print_trailer+0x14c/0x200
> [<ffffffff901e784f>] check_bytes_and_report+0xcf/0x110
> [<ffffffff901e8717>] check_object+0x1d7/0x250
> [<ffffffffc0335cac>] ? intel_plane_duplicate_state+0x2c/0xa0 [i915]
> [<ffffffff901e8c14>] alloc_debug_processing+0xa4/0x1a0
> [<ffffffff901eb5c9>] __slab_alloc.constprop.79+0x5a9/0x670
> [<ffffffffc0335cac>] ? intel_plane_duplicate_state+0x2c/0xa0 [i915]
> [<ffffffffc0335cac>] ? intel_plane_duplicate_state+0x2c/0xa0 [i915]
> [<ffffffff901edc0e>] __kmalloc_track_caller+0x2ee/0x380
> [<ffffffff901b2e40>] kmemdup+0x20/0x50
> [<ffffffffc0335cac>] intel_plane_duplicate_state+0x2c/0xa0 [i915]
> [<ffffffffc0239be8>] drm_atomic_get_plane_state+0x78/0xf0 [drm]
> [<ffffffffc028d428>] drm_atomic_helper_plane_set_property+0x68/0xd0 [drm_kms_helper]
> [<ffffffffc022824d>] drm_mode_plane_set_obj_prop+0x2d/0x90 [drm]
> [<ffffffffc028ee4b>] restore_fbdev_mode+0x6b/0xf0 [drm_kms_helper]
> [<ffffffffc0290f09>] drm_fb_helper_restore_fbdev_mode_unlocked+0x29/0x80 [drm_kms_helper]
> [<ffffffffc0290f82>] drm_fb_helper_set_par+0x22/0x50 [drm_kms_helper]
> [<ffffffffc0290e91>] drm_fb_helper_hotplug_event+0x91/0xe0 [drm_kms_helper]
> [<ffffffffc0290f2c>] drm_fb_helper_restore_fbdev_mode_unlocked+0x4c/0x80 [drm_kms_helper]
> [<ffffffffc0290f82>] drm_fb_helper_set_par+0x22/0x50 [drm_kms_helper]
> [<ffffffffc03313ba>] intel_fbdev_set_par+0x1a/0x60 [i915]
> [<ffffffff9047e488>] fbcon_init+0x588/0x610
> [<ffffffff90500f4c>] visual_init+0xbc/0x120
> [<ffffffff9050376e>] do_bind_con_driver+0x17e/0x3b0
> [<ffffffff90503ef4>] do_take_over_console+0xb4/0x1e0
> [<ffffffff90479283>] do_fbcon_takeover+0x63/0xd0
> [<ffffffff9047efbd>] fbcon_event_notify+0x6cd/0x7d0
> [<ffffffff9009d0e2>] notifier_call_chain+0x62/0x100
> [<ffffffff9009d391>] __blocking_notifier_call_chain+0x51/0x70
> [<ffffffff9009d3c6>] blocking_notifier_call_chain+0x16/0x20
> [<ffffffff90484f1b>] fb_notifier_call_chain+0x1b/0x20
> [<ffffffff90487267>] register_framebuffer+0x207/0x340
> [<ffffffffc0291214>] drm_fb_helper_initial_config+0x264/0x3c0 [drm_kms_helper]
> [<ffffffffc03326db>] intel_fbdev_initial_config+0x1b/0x20 [i915]
> [<ffffffff9009f69a>] async_run_entry_fn+0x4a/0x150
> [<ffffffff90095819>] process_one_work+0x209/0x810
> [<ffffffff90095780>] ? process_one_work+0x170/0x810
> [<ffffffff90095e8b>] worker_thread+0x6b/0x490
> [<ffffffff90095e20>] ? process_one_work+0x810/0x810
> [<ffffffff9009ba79>] kthread+0x119/0x130
> [<ffffffff9009b960>] ? kthread_create_on_node+0x240/0x240
> [<ffffffff90789888>] ret_from_fork+0x58/0x90
> [<ffffffff9009b960>] ? kthread_create_on_node+0x240/0x240
> FIX kmalloc-192: Restoring 0xffff8804277e5c78-0xffff8804277e5c78=0x6b
> FIX kmalloc-192: Marking all objects used
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [git pull] drm fixes
@ 2015-03-25 8:56 ` Daniel Vetter
0 siblings, 0 replies; 71+ messages in thread
From: Daniel Vetter @ 2015-03-25 8:56 UTC (permalink / raw)
To: Dave Jones, Josh Boyer, Dave Airlie, Damien Lespiau, Xi Ruoyao,
Linus Torvalds, DRI mailing list, Linux-Kernel@Vger. Kernel. Org,
Intel Graphics Development
On Mon, Mar 23, 2015 at 09:41:20PM -0400, Dave Jones wrote:
> 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.000039] WARNING: CPU: 0 PID: 63 at
> > drivers/gpu/drm/i915/i915_gem.c:4525 i915_gem_free_object+0x2e5/0x320
> > [i915]()
> > [ +0.000002] 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.000037] WARNING: CPU: 1 PID: 1486 at include/linux/kref.h:47
> > drm_framebuffer_reference+0x7a/0x90 [drm]()
> ..
> > [ +0.000037] 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..
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 <damien.lespiau@intel.com>
Date: Thu Feb 5 18:30:20 2015 +0000
drm/i915: Don't try to reference the fb in get_initial_plane_config()
and
commit fb9981aa675eb7b398849915364916fd98833cfa
Author: Damien Lespiau <damien.lespiau@intel.com>
Date: Thu Feb 5 19:24:25 2015 +0000
drm/i915: Fix atomic state when reusing the firmware fb
from linux-next and then check what's left?
Thanks, Daniel
>
>
> =============================================================================
> BUG kmalloc-192 (Tainted: G W ): Poison overwritten
> -----------------------------------------------------------------------------
> Disabling lock debugging due to kernel taint
> INFO: 0xffff8804277e5c78-0xffff8804277e5c78. 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 0xffffea00109df900 objects=31 used=31 fp=0x (null) flags=0x8000000000004080
> INFO: Object 0xffff8804277e5c70 @offset=7280 fp=0xffff8804277e6288
> Bytes b4 ffff8804277e5c60: 54 7a fb ff 00 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a Tz......ZZZZZZZZ
> Object ffff8804277e5c70: 6b 6b 6b 6b 6b 6b 6b 6b 6a 6b 6b 6b 6b 6b 6b 6b kkkkkkkkjkkkkkkk
> Object ffff8804277e5c80: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff8804277e5c90: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff8804277e5ca0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff8804277e5cb0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff8804277e5cc0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff8804277e5cd0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff8804277e5ce0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff8804277e5cf0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff8804277e5d00: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff8804277e5d10: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff8804277e5d20: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 kkkkkkkkkkkkkkk.
> Redzone ffff8804277e5d30: bb bb bb bb bb bb bb bb ........
> Padding ffff8804277e5e70: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ
> CPU: 4 PID: 128 Comm: kworker/u16:4 Tainted: G B W 4.0.0-rc5-backupdebug+ #1
> Workqueue: events_unbound async_run_entry_fn
> ffff8804277e5c70 000000002ebc2945 ffff8800b780f578 ffffffff90780cc3
> 0000000000000000 ffff88042b804900 ffff8800b780f5b8 ffffffff901e76cc
> 0000000000000008 ffff880400000001 ffff8804277e5c79 ffff88042b804900
> Call Trace:
> [<ffffffff90780cc3>] dump_stack+0x4c/0x65
> [<ffffffff901e76cc>] print_trailer+0x14c/0x200
> [<ffffffff901e784f>] check_bytes_and_report+0xcf/0x110
> [<ffffffff901e8717>] check_object+0x1d7/0x250
> [<ffffffffc0335cac>] ? intel_plane_duplicate_state+0x2c/0xa0 [i915]
> [<ffffffff901e8c14>] alloc_debug_processing+0xa4/0x1a0
> [<ffffffff901eb5c9>] __slab_alloc.constprop.79+0x5a9/0x670
> [<ffffffffc0335cac>] ? intel_plane_duplicate_state+0x2c/0xa0 [i915]
> [<ffffffffc0335cac>] ? intel_plane_duplicate_state+0x2c/0xa0 [i915]
> [<ffffffff901edc0e>] __kmalloc_track_caller+0x2ee/0x380
> [<ffffffff901b2e40>] kmemdup+0x20/0x50
> [<ffffffffc0335cac>] intel_plane_duplicate_state+0x2c/0xa0 [i915]
> [<ffffffffc0239be8>] drm_atomic_get_plane_state+0x78/0xf0 [drm]
> [<ffffffffc028d428>] drm_atomic_helper_plane_set_property+0x68/0xd0 [drm_kms_helper]
> [<ffffffffc022824d>] drm_mode_plane_set_obj_prop+0x2d/0x90 [drm]
> [<ffffffffc028ee4b>] restore_fbdev_mode+0x6b/0xf0 [drm_kms_helper]
> [<ffffffffc0290f09>] drm_fb_helper_restore_fbdev_mode_unlocked+0x29/0x80 [drm_kms_helper]
> [<ffffffffc0290f82>] drm_fb_helper_set_par+0x22/0x50 [drm_kms_helper]
> [<ffffffffc0290e91>] drm_fb_helper_hotplug_event+0x91/0xe0 [drm_kms_helper]
> [<ffffffffc0290f2c>] drm_fb_helper_restore_fbdev_mode_unlocked+0x4c/0x80 [drm_kms_helper]
> [<ffffffffc0290f82>] drm_fb_helper_set_par+0x22/0x50 [drm_kms_helper]
> [<ffffffffc03313ba>] intel_fbdev_set_par+0x1a/0x60 [i915]
> [<ffffffff9047e488>] fbcon_init+0x588/0x610
> [<ffffffff90500f4c>] visual_init+0xbc/0x120
> [<ffffffff9050376e>] do_bind_con_driver+0x17e/0x3b0
> [<ffffffff90503ef4>] do_take_over_console+0xb4/0x1e0
> [<ffffffff90479283>] do_fbcon_takeover+0x63/0xd0
> [<ffffffff9047efbd>] fbcon_event_notify+0x6cd/0x7d0
> [<ffffffff9009d0e2>] notifier_call_chain+0x62/0x100
> [<ffffffff9009d391>] __blocking_notifier_call_chain+0x51/0x70
> [<ffffffff9009d3c6>] blocking_notifier_call_chain+0x16/0x20
> [<ffffffff90484f1b>] fb_notifier_call_chain+0x1b/0x20
> [<ffffffff90487267>] register_framebuffer+0x207/0x340
> [<ffffffffc0291214>] drm_fb_helper_initial_config+0x264/0x3c0 [drm_kms_helper]
> [<ffffffffc03326db>] intel_fbdev_initial_config+0x1b/0x20 [i915]
> [<ffffffff9009f69a>] async_run_entry_fn+0x4a/0x150
> [<ffffffff90095819>] process_one_work+0x209/0x810
> [<ffffffff90095780>] ? process_one_work+0x170/0x810
> [<ffffffff90095e8b>] worker_thread+0x6b/0x490
> [<ffffffff90095e20>] ? process_one_work+0x810/0x810
> [<ffffffff9009ba79>] kthread+0x119/0x130
> [<ffffffff9009b960>] ? kthread_create_on_node+0x240/0x240
> [<ffffffff90789888>] ret_from_fork+0x58/0x90
> [<ffffffff9009b960>] ? kthread_create_on_node+0x240/0x240
> FIX kmalloc-192: Restoring 0xffff8804277e5c78-0xffff8804277e5c78=0x6b
> FIX kmalloc-192: Marking all objects used
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [Intel-gfx] [git pull] drm fixes
2015-03-25 8:54 ` Daniel Vetter
(?)
@ 2015-03-25 13:11 ` Josh Boyer
2015-03-25 14:00 ` Daniel Vetter
-1 siblings, 1 reply; 71+ messages in thread
From: Josh Boyer @ 2015-03-25 13:11 UTC (permalink / raw)
To: Daniel Vetter, Dave Airlie, Xi Ruoyao, Linus Torvalds,
Linux-Kernel@Vger. Kernel. Org, DRI mailing list,
Intel Graphics Development
On Wed, Mar 25, 2015 at 4:54 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> >> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
>> >> Author: Damien Lespiau <damien.lespiau@intel.com>
>> >> Date: Thu Feb 5 18:30:20 2015 +0000
>> >>
>> >> drm/i915: Don't try to reference the fb in get_initial_plane_config()
>> >>
>> >> From linux-next?
>> >
>> > Yes, building now. Will let you know as soon as I test it on both machines.
>>
>> OK, with that commit applied I no longer get the kref.h splat and the
>> NUC machine boots headless. I still see the backtrace below on both
>> the NUC and the macbook. I have a copy of it with drm.debug=0xff from
>> the NUC here:
>>
>> https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
>>
>> Getting better at least :).
>
> On top of what you currently have please also cherry-pick
>
> commit fb9981aa675eb7b398849915364916fd98833cfa
> Author: Damien Lespiau <damien.lespiau@intel.com>
> Date: Thu Feb 5 19:24:25 2015 +0000
>
> drm/i915: Fix atomic state when reusing the firmware fb
>
> from -next. Let's hope this terminates eventually ;-)
Hm. That one doesn't apply cleanly. I think because it needs:
>From 2d14030b1a9d0e89cfdca6f16851e2eac8cb4de0 Mon Sep 17 00:00:00 2001
From: Damien Lespiau <damien.lespiau@intel.com>
Date: Thu, 5 Feb 2015 17:22:18 +0000
Subject: drm/i915: Store the initial framebuffer in initial_plane_config
first. Do you want me to grab both, or should I try and figure out
how to backport fb9981aa67 without it?
josh
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [Intel-gfx] [git pull] drm fixes
2015-03-25 13:11 ` [Intel-gfx] " Josh Boyer
@ 2015-03-25 14:00 ` Daniel Vetter
0 siblings, 0 replies; 71+ messages in thread
From: Daniel Vetter @ 2015-03-25 14:00 UTC (permalink / raw)
To: Josh Boyer
Cc: Daniel Vetter, Dave Airlie, Xi Ruoyao, Linus Torvalds,
Linux-Kernel@Vger. Kernel. Org, DRI mailing list,
Intel Graphics Development
On Wed, Mar 25, 2015 at 09:11:17AM -0400, Josh Boyer wrote:
> On Wed, Mar 25, 2015 at 4:54 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> >> >> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
> >> >> Author: Damien Lespiau <damien.lespiau@intel.com>
> >> >> Date: Thu Feb 5 18:30:20 2015 +0000
> >> >>
> >> >> drm/i915: Don't try to reference the fb in get_initial_plane_config()
> >> >>
> >> >> From linux-next?
> >> >
> >> > Yes, building now. Will let you know as soon as I test it on both machines.
> >>
> >> OK, with that commit applied I no longer get the kref.h splat and the
> >> NUC machine boots headless. I still see the backtrace below on both
> >> the NUC and the macbook. I have a copy of it with drm.debug=0xff from
> >> the NUC here:
> >>
> >> https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
> >>
> >> Getting better at least :).
> >
> > On top of what you currently have please also cherry-pick
> >
> > commit fb9981aa675eb7b398849915364916fd98833cfa
> > Author: Damien Lespiau <damien.lespiau@intel.com>
> > Date: Thu Feb 5 19:24:25 2015 +0000
> >
> > drm/i915: Fix atomic state when reusing the firmware fb
> >
> > from -next. Let's hope this terminates eventually ;-)
>
> Hm. That one doesn't apply cleanly. I think because it needs:
>
> From 2d14030b1a9d0e89cfdca6f16851e2eac8cb4de0 Mon Sep 17 00:00:00 2001
> From: Damien Lespiau <damien.lespiau@intel.com>
> Date: Thu, 5 Feb 2015 17:22:18 +0000
> Subject: drm/i915: Store the initial framebuffer in initial_plane_config
>
> first. Do you want me to grab both, or should I try and figure out
> how to backport fb9981aa67 without it?
Oops missed that. The active ingredient is setting crtc->primary->state->crtc like this:
-Daniel
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 1c12262029fb..bfc14a6046ea 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2439,6 +2439,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
return;
if (intel_alloc_plane_obj(intel_crtc, plane_config)) {
+ intel_crtc->base.primary->state->crtc = &intel_crtc->base;
update_state_fb(intel_crtc->base.primary);
return;
}
@@ -2469,6 +2470,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
drm_framebuffer_reference(c->primary->fb);
intel_crtc->base.primary->fb = c->primary->fb;
+ intel_crtc->base.primary->state->crtc = &intel_crtc->base;
obj->frontbuffer_bits |= INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
break;
}
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply related [flat|nested] 71+ messages in thread
* Re: [git pull] drm fixes
@ 2015-03-25 14:00 ` Daniel Vetter
0 siblings, 0 replies; 71+ messages in thread
From: Daniel Vetter @ 2015-03-25 14:00 UTC (permalink / raw)
To: Josh Boyer
Cc: Dave Airlie, Intel Graphics Development,
Linux-Kernel@Vger. Kernel. Org, DRI mailing list, Xi Ruoyao,
Linus Torvalds
On Wed, Mar 25, 2015 at 09:11:17AM -0400, Josh Boyer wrote:
> On Wed, Mar 25, 2015 at 4:54 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> >> >> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
> >> >> Author: Damien Lespiau <damien.lespiau@intel.com>
> >> >> Date: Thu Feb 5 18:30:20 2015 +0000
> >> >>
> >> >> drm/i915: Don't try to reference the fb in get_initial_plane_config()
> >> >>
> >> >> From linux-next?
> >> >
> >> > Yes, building now. Will let you know as soon as I test it on both machines.
> >>
> >> OK, with that commit applied I no longer get the kref.h splat and the
> >> NUC machine boots headless. I still see the backtrace below on both
> >> the NUC and the macbook. I have a copy of it with drm.debug=0xff from
> >> the NUC here:
> >>
> >> https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
> >>
> >> Getting better at least :).
> >
> > On top of what you currently have please also cherry-pick
> >
> > commit fb9981aa675eb7b398849915364916fd98833cfa
> > Author: Damien Lespiau <damien.lespiau@intel.com>
> > Date: Thu Feb 5 19:24:25 2015 +0000
> >
> > drm/i915: Fix atomic state when reusing the firmware fb
> >
> > from -next. Let's hope this terminates eventually ;-)
>
> Hm. That one doesn't apply cleanly. I think because it needs:
>
> From 2d14030b1a9d0e89cfdca6f16851e2eac8cb4de0 Mon Sep 17 00:00:00 2001
> From: Damien Lespiau <damien.lespiau@intel.com>
> Date: Thu, 5 Feb 2015 17:22:18 +0000
> Subject: drm/i915: Store the initial framebuffer in initial_plane_config
>
> first. Do you want me to grab both, or should I try and figure out
> how to backport fb9981aa67 without it?
Oops missed that. The active ingredient is setting crtc->primary->state->crtc like this:
-Daniel
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 1c12262029fb..bfc14a6046ea 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2439,6 +2439,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
return;
if (intel_alloc_plane_obj(intel_crtc, plane_config)) {
+ intel_crtc->base.primary->state->crtc = &intel_crtc->base;
update_state_fb(intel_crtc->base.primary);
return;
}
@@ -2469,6 +2470,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
drm_framebuffer_reference(c->primary->fb);
intel_crtc->base.primary->fb = c->primary->fb;
+ intel_crtc->base.primary->state->crtc = &intel_crtc->base;
obj->frontbuffer_bits |= INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
break;
}
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 71+ messages in thread
* Re: [git pull] drm fixes
2015-03-25 8:56 ` Daniel Vetter
@ 2015-03-25 14:34 ` Dave Jones
-1 siblings, 0 replies; 71+ messages in thread
From: Dave Jones @ 2015-03-25 14:34 UTC (permalink / raw)
To: Josh Boyer, Dave Airlie, Damien Lespiau, Xi Ruoyao,
Linus Torvalds, DRI mailing list, Linux-Kernel@Vger. Kernel. Org,
Intel Graphics Development
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 <damien.lespiau@intel.com>
> Date: Thu Feb 5 18:30:20 2015 +0000
>
> drm/i915: Don't try to reference the fb in get_initial_plane_config()
>
> and
>
> commit fb9981aa675eb7b398849915364916fd98833cfa
> Author: Damien Lespiau <damien.lespiau@intel.com>
> Date: Thu Feb 5 19:24:25 2015 +0000
>
> 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
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [git pull] drm fixes
@ 2015-03-25 14:34 ` Dave Jones
0 siblings, 0 replies; 71+ messages in thread
From: Dave Jones @ 2015-03-25 14:34 UTC (permalink / raw)
To: Josh Boyer, Dave Airlie, Damien Lespiau, Xi Ruoyao,
Linus Torvalds, DRI mailing list, Linux-Kernel@Vger. Kernel. Org,
Intel Graphics Development
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 <damien.lespiau@intel.com>
> Date: Thu Feb 5 18:30:20 2015 +0000
>
> drm/i915: Don't try to reference the fb in get_initial_plane_config()
>
> and
>
> commit fb9981aa675eb7b398849915364916fd98833cfa
> Author: Damien Lespiau <damien.lespiau@intel.com>
> Date: Thu Feb 5 19:24:25 2015 +0000
>
> 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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [Intel-gfx] [git pull] drm fixes
2015-03-25 14:00 ` Daniel Vetter
@ 2015-03-25 14:56 ` Xi Ruoyao
-1 siblings, 0 replies; 71+ messages in thread
From: Xi Ruoyao @ 2015-03-25 14:56 UTC (permalink / raw)
To: Josh Boyer, Dave Airlie, Stephen Rothwell
Cc: Linus Torvalds, Linux-Kernel@Vger. Kernel. Org, DRI mailing list,
Intel Graphics Development
On 03/25/2015 at 10:00 PM, Daniel Vetter wrote:
> On Wed, Mar 25, 2015 at 09:11:17AM -0400, Josh Boyer wrote:
>> On Wed, Mar 25, 2015 at 4:54 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>>>>>> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
>>>>>> Author: Damien Lespiau <damien.lespiau@intel.com>
>>>>>> Date: Thu Feb 5 18:30:20 2015 +0000
>>>>>>
>>>>>> drm/i915: Don't try to reference the fb in get_initial_plane_config()
>>>>>>
>>>>>> From linux-next?
>>>>> Yes, building now. Will let you know as soon as I test it on both machines.
>>>> OK, with that commit applied I no longer get the kref.h splat and the
>>>> NUC machine boots headless. I still see the backtrace below on both
>>>> the NUC and the macbook. I have a copy of it with drm.debug=0xff from
>>>> the NUC here:
>>>>
>>>> https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
>>>>
>>>> Getting better at least :).
>>> On top of what you currently have please also cherry-pick
>>>
>>> commit fb9981aa675eb7b398849915364916fd98833cfa
>>> Author: Damien Lespiau <damien.lespiau@intel.com>
>>> Date: Thu Feb 5 19:24:25 2015 +0000
>>>
>>> drm/i915: Fix atomic state when reusing the firmware fb
>>>
>>> from -next. Let's hope this terminates eventually ;-)
>> Hm. That one doesn't apply cleanly. I think because it needs:
>>
>> From 2d14030b1a9d0e89cfdca6f16851e2eac8cb4de0 Mon Sep 17 00:00:00 2001
>> From: Damien Lespiau <damien.lespiau@intel.com>
>> Date: Thu, 5 Feb 2015 17:22:18 +0000
>> Subject: drm/i915: Store the initial framebuffer in initial_plane_config
>>
>> first. Do you want me to grab both, or should I try and figure out
>> how to backport fb9981aa67 without it?
> Oops missed that. The active ingredient is setting crtc->primary->state->crtc like this:
> -Daniel
>
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index 1c12262029fb..bfc14a6046ea 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2439,6 +2439,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
> return;
>
> if (intel_alloc_plane_obj(intel_crtc, plane_config)) {
> + intel_crtc->base.primary->state->crtc = &intel_crtc->base;
> update_state_fb(intel_crtc->base.primary);
> return;
> }
> @@ -2469,6 +2470,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>
> drm_framebuffer_reference(c->primary->fb);
> intel_crtc->base.primary->fb = c->primary->fb;
> + intel_crtc->base.primary->state->crtc = &intel_crtc->base;
> obj->frontbuffer_bits |= INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
> break;
> }
I found a bad thing. My buggy code also affects linux-next now because of
the manual merge on 2014-03-16.
So, Daniel and Stephen please check it and end this mess...
It's annoying to see my code caused so much trouble. I didn't test my code
with a HDMI device or I should've found this trouble before commiting. I
apologize for that again.
--
Xi Ruoyao
School of Aerospace Science and Technology
Xidian University, Xi'an, China
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [git pull] drm fixes
@ 2015-03-25 14:56 ` Xi Ruoyao
0 siblings, 0 replies; 71+ messages in thread
From: Xi Ruoyao @ 2015-03-25 14:56 UTC (permalink / raw)
To: Josh Boyer, Dave Airlie, Stephen Rothwell
Cc: Intel Graphics Development, Linus Torvalds,
Linux-Kernel@Vger. Kernel. Org, DRI mailing list
On 03/25/2015 at 10:00 PM, Daniel Vetter wrote:
> On Wed, Mar 25, 2015 at 09:11:17AM -0400, Josh Boyer wrote:
>> On Wed, Mar 25, 2015 at 4:54 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>>>>>> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
>>>>>> Author: Damien Lespiau <damien.lespiau@intel.com>
>>>>>> Date: Thu Feb 5 18:30:20 2015 +0000
>>>>>>
>>>>>> drm/i915: Don't try to reference the fb in get_initial_plane_config()
>>>>>>
>>>>>> From linux-next?
>>>>> Yes, building now. Will let you know as soon as I test it on both machines.
>>>> OK, with that commit applied I no longer get the kref.h splat and the
>>>> NUC machine boots headless. I still see the backtrace below on both
>>>> the NUC and the macbook. I have a copy of it with drm.debug=0xff from
>>>> the NUC here:
>>>>
>>>> https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
>>>>
>>>> Getting better at least :).
>>> On top of what you currently have please also cherry-pick
>>>
>>> commit fb9981aa675eb7b398849915364916fd98833cfa
>>> Author: Damien Lespiau <damien.lespiau@intel.com>
>>> Date: Thu Feb 5 19:24:25 2015 +0000
>>>
>>> drm/i915: Fix atomic state when reusing the firmware fb
>>>
>>> from -next. Let's hope this terminates eventually ;-)
>> Hm. That one doesn't apply cleanly. I think because it needs:
>>
>> From 2d14030b1a9d0e89cfdca6f16851e2eac8cb4de0 Mon Sep 17 00:00:00 2001
>> From: Damien Lespiau <damien.lespiau@intel.com>
>> Date: Thu, 5 Feb 2015 17:22:18 +0000
>> Subject: drm/i915: Store the initial framebuffer in initial_plane_config
>>
>> first. Do you want me to grab both, or should I try and figure out
>> how to backport fb9981aa67 without it?
> Oops missed that. The active ingredient is setting crtc->primary->state->crtc like this:
> -Daniel
>
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index 1c12262029fb..bfc14a6046ea 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2439,6 +2439,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
> return;
>
> if (intel_alloc_plane_obj(intel_crtc, plane_config)) {
> + intel_crtc->base.primary->state->crtc = &intel_crtc->base;
> update_state_fb(intel_crtc->base.primary);
> return;
> }
> @@ -2469,6 +2470,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>
> drm_framebuffer_reference(c->primary->fb);
> intel_crtc->base.primary->fb = c->primary->fb;
> + intel_crtc->base.primary->state->crtc = &intel_crtc->base;
> obj->frontbuffer_bits |= INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
> break;
> }
I found a bad thing. My buggy code also affects linux-next now because of
the manual merge on 2014-03-16.
So, Daniel and Stephen please check it and end this mess...
It's annoying to see my code caused so much trouble. I didn't test my code
with a HDMI device or I should've found this trouble before commiting. I
apologize for that again.
--
Xi Ruoyao
School of Aerospace Science and Technology
Xidian University, Xi'an, China
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [Intel-gfx] [git pull] drm fixes
2015-03-25 14:56 ` Xi Ruoyao
@ 2015-03-25 15:12 ` Xi Ruoyao
-1 siblings, 0 replies; 71+ messages in thread
From: Xi Ruoyao @ 2015-03-25 15:12 UTC (permalink / raw)
To: Josh Boyer, Dave Airlie, Stephen Rothwell
Cc: Linus Torvalds, Linux-Kernel@Vger. Kernel. Org, DRI mailing list,
Intel Graphics Development
On 03/25/2015 at 10:56 PM, Xi Ruoyao wrote:
>
> On 03/25/2015 at 10:00 PM, Daniel Vetter wrote:
>> On Wed, Mar 25, 2015 at 09:11:17AM -0400, Josh Boyer wrote:
>>> On Wed, Mar 25, 2015 at 4:54 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>>>>>>> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
>>>>>>> Author: Damien Lespiau <damien.lespiau@intel.com>
>>>>>>> Date: Thu Feb 5 18:30:20 2015 +0000
>>>>>>>
>>>>>>> drm/i915: Don't try to reference the fb in
>>>>>>> get_initial_plane_config()
>>>>>>>
>>>>>>> From linux-next?
>>>>>> Yes, building now. Will let you know as soon as I test it on
>>>>>> both machines.
>>>>> OK, with that commit applied I no longer get the kref.h splat and the
>>>>> NUC machine boots headless. I still see the backtrace below on both
>>>>> the NUC and the macbook. I have a copy of it with drm.debug=0xff
>>>>> from
>>>>> the NUC here:
>>>>>
>>>>> https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
>>>>>
>>>>> Getting better at least :).
>>>> On top of what you currently have please also cherry-pick
>>>>
>>>> commit fb9981aa675eb7b398849915364916fd98833cfa
>>>> Author: Damien Lespiau <damien.lespiau@intel.com>
>>>> Date: Thu Feb 5 19:24:25 2015 +0000
>>>>
>>>> drm/i915: Fix atomic state when reusing the firmware fb
>>>>
>>>> from -next. Let's hope this terminates eventually ;-)
>>> Hm. That one doesn't apply cleanly. I think because it needs:
>>>
>>> From 2d14030b1a9d0e89cfdca6f16851e2eac8cb4de0 Mon Sep 17 00:00:00 2001
>>> From: Damien Lespiau <damien.lespiau@intel.com>
>>> Date: Thu, 5 Feb 2015 17:22:18 +0000
>>> Subject: drm/i915: Store the initial framebuffer in
>>> initial_plane_config
>>>
>>> first. Do you want me to grab both, or should I try and figure out
>>> how to backport fb9981aa67 without it?
>> Oops missed that. The active ingredient is setting
>> crtc->primary->state->crtc like this:
>> -Daniel
>>
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>> b/drivers/gpu/drm/i915/intel_display.c
>> index 1c12262029fb..bfc14a6046ea 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -2439,6 +2439,7 @@ intel_find_plane_obj(struct intel_crtc
>> *intel_crtc,
>> return;
>> if (intel_alloc_plane_obj(intel_crtc, plane_config)) {
>> + intel_crtc->base.primary->state->crtc = &intel_crtc->base;
>> update_state_fb(intel_crtc->base.primary);
>> return;
>> }
>> @@ -2469,6 +2470,7 @@ intel_find_plane_obj(struct intel_crtc
>> *intel_crtc,
>> drm_framebuffer_reference(c->primary->fb);
>> intel_crtc->base.primary->fb = c->primary->fb;
>> + intel_crtc->base.primary->state->crtc = &intel_crtc->base;
>> obj->frontbuffer_bits |=
>> INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
>> break;
>> }
> I found a bad thing. My buggy code also affects linux-next now because of
> the manual merge on 2014-03-16.
>
> So, Daniel and Stephen please check it and end this mess...
>
I reviewed linux-next. Stephen has dealed with it correctly.
> It's annoying to see my code caused so much trouble. I didn't test my
> code
> with a HDMI device or I should've found this trouble before commiting. I
> apologize for that again.
I am very upset because of my error now (>_<). I think the only thing I can
help now is view linux-next and find all commits about my 319c1d420a0b,
since my commit is a cheery-picking from linux-next.
--
Xi Ruoyao
School of Aerospace Science and Technology
Xidian University, Xi'an, China
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [git pull] drm fixes
@ 2015-03-25 15:12 ` Xi Ruoyao
0 siblings, 0 replies; 71+ messages in thread
From: Xi Ruoyao @ 2015-03-25 15:12 UTC (permalink / raw)
To: Josh Boyer, Dave Airlie, Stephen Rothwell
Cc: Intel Graphics Development, Linus Torvalds,
Linux-Kernel@Vger. Kernel. Org, DRI mailing list
On 03/25/2015 at 10:56 PM, Xi Ruoyao wrote:
>
> On 03/25/2015 at 10:00 PM, Daniel Vetter wrote:
>> On Wed, Mar 25, 2015 at 09:11:17AM -0400, Josh Boyer wrote:
>>> On Wed, Mar 25, 2015 at 4:54 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>>>>>>> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
>>>>>>> Author: Damien Lespiau <damien.lespiau@intel.com>
>>>>>>> Date: Thu Feb 5 18:30:20 2015 +0000
>>>>>>>
>>>>>>> drm/i915: Don't try to reference the fb in
>>>>>>> get_initial_plane_config()
>>>>>>>
>>>>>>> From linux-next?
>>>>>> Yes, building now. Will let you know as soon as I test it on
>>>>>> both machines.
>>>>> OK, with that commit applied I no longer get the kref.h splat and the
>>>>> NUC machine boots headless. I still see the backtrace below on both
>>>>> the NUC and the macbook. I have a copy of it with drm.debug=0xff
>>>>> from
>>>>> the NUC here:
>>>>>
>>>>> https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
>>>>>
>>>>> Getting better at least :).
>>>> On top of what you currently have please also cherry-pick
>>>>
>>>> commit fb9981aa675eb7b398849915364916fd98833cfa
>>>> Author: Damien Lespiau <damien.lespiau@intel.com>
>>>> Date: Thu Feb 5 19:24:25 2015 +0000
>>>>
>>>> drm/i915: Fix atomic state when reusing the firmware fb
>>>>
>>>> from -next. Let's hope this terminates eventually ;-)
>>> Hm. That one doesn't apply cleanly. I think because it needs:
>>>
>>> From 2d14030b1a9d0e89cfdca6f16851e2eac8cb4de0 Mon Sep 17 00:00:00 2001
>>> From: Damien Lespiau <damien.lespiau@intel.com>
>>> Date: Thu, 5 Feb 2015 17:22:18 +0000
>>> Subject: drm/i915: Store the initial framebuffer in
>>> initial_plane_config
>>>
>>> first. Do you want me to grab both, or should I try and figure out
>>> how to backport fb9981aa67 without it?
>> Oops missed that. The active ingredient is setting
>> crtc->primary->state->crtc like this:
>> -Daniel
>>
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>> b/drivers/gpu/drm/i915/intel_display.c
>> index 1c12262029fb..bfc14a6046ea 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -2439,6 +2439,7 @@ intel_find_plane_obj(struct intel_crtc
>> *intel_crtc,
>> return;
>> if (intel_alloc_plane_obj(intel_crtc, plane_config)) {
>> + intel_crtc->base.primary->state->crtc = &intel_crtc->base;
>> update_state_fb(intel_crtc->base.primary);
>> return;
>> }
>> @@ -2469,6 +2470,7 @@ intel_find_plane_obj(struct intel_crtc
>> *intel_crtc,
>> drm_framebuffer_reference(c->primary->fb);
>> intel_crtc->base.primary->fb = c->primary->fb;
>> + intel_crtc->base.primary->state->crtc = &intel_crtc->base;
>> obj->frontbuffer_bits |=
>> INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
>> break;
>> }
> I found a bad thing. My buggy code also affects linux-next now because of
> the manual merge on 2014-03-16.
>
> So, Daniel and Stephen please check it and end this mess...
>
I reviewed linux-next. Stephen has dealed with it correctly.
> It's annoying to see my code caused so much trouble. I didn't test my
> code
> with a HDMI device or I should've found this trouble before commiting. I
> apologize for that again.
I am very upset because of my error now (>_<). I think the only thing I can
help now is view linux-next and find all commits about my 319c1d420a0b,
since my commit is a cheery-picking from linux-next.
--
Xi Ruoyao
School of Aerospace Science and Technology
Xidian University, Xi'an, China
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [Intel-gfx] [git pull] drm fixes
2015-03-25 14:56 ` Xi Ruoyao
@ 2015-03-25 15:19 ` Jani Nikula
-1 siblings, 0 replies; 71+ messages in thread
From: Jani Nikula @ 2015-03-25 15:19 UTC (permalink / raw)
To: Xi Ruoyao, Josh Boyer, Dave Airlie, Stephen Rothwell
Cc: Intel Graphics Development, Linus Torvalds,
Linux-Kernel@Vger. Kernel. Org, DRI mailing list
On Wed, 25 Mar 2015, Xi Ruoyao <xry111@outlook.com> wrote:
> It's annoying to see my code caused so much trouble. I didn't test my code
> with a HDMI device or I should've found this trouble before commiting. I
> apologize for that again.
Don't worry about it. It's our fail, not yours.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [Intel-gfx] [git pull] drm fixes
@ 2015-03-25 15:19 ` Jani Nikula
0 siblings, 0 replies; 71+ messages in thread
From: Jani Nikula @ 2015-03-25 15:19 UTC (permalink / raw)
To: Xi Ruoyao, Josh Boyer, Dave Airlie, Stephen Rothwell
Cc: Intel Graphics Development, Linus Torvalds,
Linux-Kernel@Vger. Kernel. Org, DRI mailing list
On Wed, 25 Mar 2015, Xi Ruoyao <xry111@outlook.com> wrote:
> It's annoying to see my code caused so much trouble. I didn't test my code
> with a HDMI device or I should've found this trouble before commiting. I
> apologize for that again.
Don't worry about it. It's our fail, not yours.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [Intel-gfx] [git pull] drm fixes
2015-03-25 14:00 ` Daniel Vetter
@ 2015-03-25 15:26 ` Takashi Iwai
-1 siblings, 0 replies; 71+ messages in thread
From: Takashi Iwai @ 2015-03-25 15:26 UTC (permalink / raw)
To: Daniel Vetter
Cc: Josh Boyer, Dave Airlie, Intel Graphics Development,
Linux-Kernel@Vger. Kernel. Org, DRI mailing list, Xi Ruoyao,
Linus Torvalds
At Wed, 25 Mar 2015 15:00:08 +0100,
Daniel Vetter wrote:
>
> On Wed, Mar 25, 2015 at 09:11:17AM -0400, Josh Boyer wrote:
> > On Wed, Mar 25, 2015 at 4:54 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> > >> >> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
> > >> >> Author: Damien Lespiau <damien.lespiau@intel.com>
> > >> >> Date: Thu Feb 5 18:30:20 2015 +0000
> > >> >>
> > >> >> drm/i915: Don't try to reference the fb in get_initial_plane_config()
> > >> >>
> > >> >> From linux-next?
> > >> >
> > >> > Yes, building now. Will let you know as soon as I test it on both machines.
> > >>
> > >> OK, with that commit applied I no longer get the kref.h splat and the
> > >> NUC machine boots headless. I still see the backtrace below on both
> > >> the NUC and the macbook. I have a copy of it with drm.debug=0xff from
> > >> the NUC here:
> > >>
> > >> https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
> > >>
> > >> Getting better at least :).
> > >
> > > On top of what you currently have please also cherry-pick
> > >
> > > commit fb9981aa675eb7b398849915364916fd98833cfa
> > > Author: Damien Lespiau <damien.lespiau@intel.com>
> > > Date: Thu Feb 5 19:24:25 2015 +0000
> > >
> > > drm/i915: Fix atomic state when reusing the firmware fb
> > >
> > > from -next. Let's hope this terminates eventually ;-)
> >
> > Hm. That one doesn't apply cleanly. I think because it needs:
> >
> > From 2d14030b1a9d0e89cfdca6f16851e2eac8cb4de0 Mon Sep 17 00:00:00 2001
> > From: Damien Lespiau <damien.lespiau@intel.com>
> > Date: Thu, 5 Feb 2015 17:22:18 +0000
> > Subject: drm/i915: Store the initial framebuffer in initial_plane_config
> >
> > first. Do you want me to grab both, or should I try and figure out
> > how to backport fb9981aa67 without it?
>
> Oops missed that. The active ingredient is setting crtc->primary->state->crtc like this:
As I wrote in another mail, I can confirm that cherry-picking of three
commits (and manual compile fixes) fixed the problem on my machine.
Takashi
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [Intel-gfx] [git pull] drm fixes
@ 2015-03-25 15:26 ` Takashi Iwai
0 siblings, 0 replies; 71+ messages in thread
From: Takashi Iwai @ 2015-03-25 15:26 UTC (permalink / raw)
To: Daniel Vetter
Cc: Josh Boyer, Intel Graphics Development,
Linux-Kernel@Vger. Kernel. Org, DRI mailing list, Xi Ruoyao,
Linus Torvalds
At Wed, 25 Mar 2015 15:00:08 +0100,
Daniel Vetter wrote:
>
> On Wed, Mar 25, 2015 at 09:11:17AM -0400, Josh Boyer wrote:
> > On Wed, Mar 25, 2015 at 4:54 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> > >> >> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
> > >> >> Author: Damien Lespiau <damien.lespiau@intel.com>
> > >> >> Date: Thu Feb 5 18:30:20 2015 +0000
> > >> >>
> > >> >> drm/i915: Don't try to reference the fb in get_initial_plane_config()
> > >> >>
> > >> >> From linux-next?
> > >> >
> > >> > Yes, building now. Will let you know as soon as I test it on both machines.
> > >>
> > >> OK, with that commit applied I no longer get the kref.h splat and the
> > >> NUC machine boots headless. I still see the backtrace below on both
> > >> the NUC and the macbook. I have a copy of it with drm.debug=0xff from
> > >> the NUC here:
> > >>
> > >> https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
> > >>
> > >> Getting better at least :).
> > >
> > > On top of what you currently have please also cherry-pick
> > >
> > > commit fb9981aa675eb7b398849915364916fd98833cfa
> > > Author: Damien Lespiau <damien.lespiau@intel.com>
> > > Date: Thu Feb 5 19:24:25 2015 +0000
> > >
> > > drm/i915: Fix atomic state when reusing the firmware fb
> > >
> > > from -next. Let's hope this terminates eventually ;-)
> >
> > Hm. That one doesn't apply cleanly. I think because it needs:
> >
> > From 2d14030b1a9d0e89cfdca6f16851e2eac8cb4de0 Mon Sep 17 00:00:00 2001
> > From: Damien Lespiau <damien.lespiau@intel.com>
> > Date: Thu, 5 Feb 2015 17:22:18 +0000
> > Subject: drm/i915: Store the initial framebuffer in initial_plane_config
> >
> > first. Do you want me to grab both, or should I try and figure out
> > how to backport fb9981aa67 without it?
>
> Oops missed that. The active ingredient is setting crtc->primary->state->crtc like this:
As I wrote in another mail, I can confirm that cherry-picking of three
commits (and manual compile fixes) fixed the problem on my machine.
Takashi
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [Intel-gfx] [git pull] drm fixes
2015-03-25 14:00 ` Daniel Vetter
` (2 preceding siblings ...)
(?)
@ 2015-03-25 15:37 ` Josh Boyer
2015-03-25 15:50 ` Daniel Vetter
-1 siblings, 1 reply; 71+ messages in thread
From: Josh Boyer @ 2015-03-25 15:37 UTC (permalink / raw)
To: Daniel Vetter, Dave Airlie, Xi Ruoyao, Linus Torvalds,
Linux-Kernel@Vger. Kernel. Org, DRI mailing list,
Intel Graphics Development
On Wed, Mar 25, 2015 at 10:00 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Wed, Mar 25, 2015 at 09:11:17AM -0400, Josh Boyer wrote:
>> On Wed, Mar 25, 2015 at 4:54 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> >> >> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
>> >> >> Author: Damien Lespiau <damien.lespiau@intel.com>
>> >> >> Date: Thu Feb 5 18:30:20 2015 +0000
>> >> >>
>> >> >> drm/i915: Don't try to reference the fb in get_initial_plane_config()
>> >> >>
>> >> >> From linux-next?
>> >> >
>> >> > Yes, building now. Will let you know as soon as I test it on both machines.
>> >>
>> >> OK, with that commit applied I no longer get the kref.h splat and the
>> >> NUC machine boots headless. I still see the backtrace below on both
>> >> the NUC and the macbook. I have a copy of it with drm.debug=0xff from
>> >> the NUC here:
>> >>
>> >> https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
>> >>
>> >> Getting better at least :).
>> >
>> > On top of what you currently have please also cherry-pick
>> >
>> > commit fb9981aa675eb7b398849915364916fd98833cfa
>> > Author: Damien Lespiau <damien.lespiau@intel.com>
>> > Date: Thu Feb 5 19:24:25 2015 +0000
>> >
>> > drm/i915: Fix atomic state when reusing the firmware fb
>> >
>> > from -next. Let's hope this terminates eventually ;-)
>>
>> Hm. That one doesn't apply cleanly. I think because it needs:
>>
>> From 2d14030b1a9d0e89cfdca6f16851e2eac8cb4de0 Mon Sep 17 00:00:00 2001
>> From: Damien Lespiau <damien.lespiau@intel.com>
>> Date: Thu, 5 Feb 2015 17:22:18 +0000
>> Subject: drm/i915: Store the initial framebuffer in initial_plane_config
>>
>> first. Do you want me to grab both, or should I try and figure out
>> how to backport fb9981aa67 without it?
>
> Oops missed that. The active ingredient is setting crtc->primary->state->crtc like this:
> -Daniel
>
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index 1c12262029fb..bfc14a6046ea 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2439,6 +2439,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
> return;
>
> if (intel_alloc_plane_obj(intel_crtc, plane_config)) {
> + intel_crtc->base.primary->state->crtc = &intel_crtc->base;
> update_state_fb(intel_crtc->base.primary);
> return;
> }
> @@ -2469,6 +2470,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>
> drm_framebuffer_reference(c->primary->fb);
> intel_crtc->base.primary->fb = c->primary->fb;
> + intel_crtc->base.primary->state->crtc = &intel_crtc->base;
> obj->frontbuffer_bits |= INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
> break;
> }
Hm. So I used your patch above. The macbook boots fine and all the
oops/WARNS are gone except the audio one that was unrelated and
present before all of this.
However, the NUC is back to not booting without HDMI plugged in. I
did the drm.debug=0xff+blacklist/insmod trick again and put the
results up here:
https://jwboyer.fedorapeople.org/pub/vetters.txt
The frontbuffer splat is back now.
I confirmed multiple times that the NUC boots fine with the kernel
that doesn't include the above patch but has the other two included
(albeit with the drm_atomic WARN still).
Not sure what to make of this one.
josh
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [Intel-gfx] [git pull] drm fixes
2015-03-25 15:37 ` Josh Boyer
@ 2015-03-25 15:50 ` Daniel Vetter
0 siblings, 0 replies; 71+ messages in thread
From: Daniel Vetter @ 2015-03-25 15:50 UTC (permalink / raw)
To: Josh Boyer
Cc: Daniel Vetter, Dave Airlie, Xi Ruoyao, Linus Torvalds,
Linux-Kernel@Vger. Kernel. Org, DRI mailing list,
Intel Graphics Development
On Wed, Mar 25, 2015 at 11:37:35AM -0400, Josh Boyer wrote:
> On Wed, Mar 25, 2015 at 10:00 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> > On Wed, Mar 25, 2015 at 09:11:17AM -0400, Josh Boyer wrote:
> >> On Wed, Mar 25, 2015 at 4:54 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> >> >> >> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
> >> >> >> Author: Damien Lespiau <damien.lespiau@intel.com>
> >> >> >> Date: Thu Feb 5 18:30:20 2015 +0000
> >> >> >>
> >> >> >> drm/i915: Don't try to reference the fb in get_initial_plane_config()
> >> >> >>
> >> >> >> From linux-next?
> >> >> >
> >> >> > Yes, building now. Will let you know as soon as I test it on both machines.
> >> >>
> >> >> OK, with that commit applied I no longer get the kref.h splat and the
> >> >> NUC machine boots headless. I still see the backtrace below on both
> >> >> the NUC and the macbook. I have a copy of it with drm.debug=0xff from
> >> >> the NUC here:
> >> >>
> >> >> https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
> >> >>
> >> >> Getting better at least :).
> >> >
> >> > On top of what you currently have please also cherry-pick
> >> >
> >> > commit fb9981aa675eb7b398849915364916fd98833cfa
> >> > Author: Damien Lespiau <damien.lespiau@intel.com>
> >> > Date: Thu Feb 5 19:24:25 2015 +0000
> >> >
> >> > drm/i915: Fix atomic state when reusing the firmware fb
> >> >
> >> > from -next. Let's hope this terminates eventually ;-)
> >>
> >> Hm. That one doesn't apply cleanly. I think because it needs:
> >>
> >> From 2d14030b1a9d0e89cfdca6f16851e2eac8cb4de0 Mon Sep 17 00:00:00 2001
> >> From: Damien Lespiau <damien.lespiau@intel.com>
> >> Date: Thu, 5 Feb 2015 17:22:18 +0000
> >> Subject: drm/i915: Store the initial framebuffer in initial_plane_config
> >>
> >> first. Do you want me to grab both, or should I try and figure out
> >> how to backport fb9981aa67 without it?
> >
> > Oops missed that. The active ingredient is setting crtc->primary->state->crtc like this:
> > -Daniel
> >
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> > index 1c12262029fb..bfc14a6046ea 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -2439,6 +2439,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
> > return;
> >
> > if (intel_alloc_plane_obj(intel_crtc, plane_config)) {
> > + intel_crtc->base.primary->state->crtc = &intel_crtc->base;
> > update_state_fb(intel_crtc->base.primary);
> > return;
> > }
> > @@ -2469,6 +2470,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
> >
> > drm_framebuffer_reference(c->primary->fb);
> > intel_crtc->base.primary->fb = c->primary->fb;
> > + intel_crtc->base.primary->state->crtc = &intel_crtc->base;
> > obj->frontbuffer_bits |= INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
> > break;
> > }
>
> Hm. So I used your patch above. The macbook boots fine and all the
> oops/WARNS are gone except the audio one that was unrelated and
> present before all of this.
>
> However, the NUC is back to not booting without HDMI plugged in. I
> did the drm.debug=0xff+blacklist/insmod trick again and put the
> results up here:
>
> https://jwboyer.fedorapeople.org/pub/vetters.txt
>
> The frontbuffer splat is back now.
>
> I confirmed multiple times that the NUC boots fine with the kernel
> that doesn't include the above patch but has the other two included
> (albeit with the drm_atomic WARN still).
>
> Not sure what to make of this one.
Yeah that fail looks like we're freeing an fb that's still in use.
Hilarity happens and since that happens under console_lock at boot-up your
machine dies.
Does that machine die the same way in drm-intel-nightly/linux-next?
I'll try to figure out meanwhile what's amiss here ...
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [Intel-gfx] [git pull] drm fixes
@ 2015-03-25 15:50 ` Daniel Vetter
0 siblings, 0 replies; 71+ messages in thread
From: Daniel Vetter @ 2015-03-25 15:50 UTC (permalink / raw)
To: Josh Boyer
Cc: Intel Graphics Development, Linux-Kernel@Vger. Kernel. Org,
DRI mailing list, Xi Ruoyao, Linus Torvalds
On Wed, Mar 25, 2015 at 11:37:35AM -0400, Josh Boyer wrote:
> On Wed, Mar 25, 2015 at 10:00 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> > On Wed, Mar 25, 2015 at 09:11:17AM -0400, Josh Boyer wrote:
> >> On Wed, Mar 25, 2015 at 4:54 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> >> >> >> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
> >> >> >> Author: Damien Lespiau <damien.lespiau@intel.com>
> >> >> >> Date: Thu Feb 5 18:30:20 2015 +0000
> >> >> >>
> >> >> >> drm/i915: Don't try to reference the fb in get_initial_plane_config()
> >> >> >>
> >> >> >> From linux-next?
> >> >> >
> >> >> > Yes, building now. Will let you know as soon as I test it on both machines.
> >> >>
> >> >> OK, with that commit applied I no longer get the kref.h splat and the
> >> >> NUC machine boots headless. I still see the backtrace below on both
> >> >> the NUC and the macbook. I have a copy of it with drm.debug=0xff from
> >> >> the NUC here:
> >> >>
> >> >> https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
> >> >>
> >> >> Getting better at least :).
> >> >
> >> > On top of what you currently have please also cherry-pick
> >> >
> >> > commit fb9981aa675eb7b398849915364916fd98833cfa
> >> > Author: Damien Lespiau <damien.lespiau@intel.com>
> >> > Date: Thu Feb 5 19:24:25 2015 +0000
> >> >
> >> > drm/i915: Fix atomic state when reusing the firmware fb
> >> >
> >> > from -next. Let's hope this terminates eventually ;-)
> >>
> >> Hm. That one doesn't apply cleanly. I think because it needs:
> >>
> >> From 2d14030b1a9d0e89cfdca6f16851e2eac8cb4de0 Mon Sep 17 00:00:00 2001
> >> From: Damien Lespiau <damien.lespiau@intel.com>
> >> Date: Thu, 5 Feb 2015 17:22:18 +0000
> >> Subject: drm/i915: Store the initial framebuffer in initial_plane_config
> >>
> >> first. Do you want me to grab both, or should I try and figure out
> >> how to backport fb9981aa67 without it?
> >
> > Oops missed that. The active ingredient is setting crtc->primary->state->crtc like this:
> > -Daniel
> >
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> > index 1c12262029fb..bfc14a6046ea 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -2439,6 +2439,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
> > return;
> >
> > if (intel_alloc_plane_obj(intel_crtc, plane_config)) {
> > + intel_crtc->base.primary->state->crtc = &intel_crtc->base;
> > update_state_fb(intel_crtc->base.primary);
> > return;
> > }
> > @@ -2469,6 +2470,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
> >
> > drm_framebuffer_reference(c->primary->fb);
> > intel_crtc->base.primary->fb = c->primary->fb;
> > + intel_crtc->base.primary->state->crtc = &intel_crtc->base;
> > obj->frontbuffer_bits |= INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
> > break;
> > }
>
> Hm. So I used your patch above. The macbook boots fine and all the
> oops/WARNS are gone except the audio one that was unrelated and
> present before all of this.
>
> However, the NUC is back to not booting without HDMI plugged in. I
> did the drm.debug=0xff+blacklist/insmod trick again and put the
> results up here:
>
> https://jwboyer.fedorapeople.org/pub/vetters.txt
>
> The frontbuffer splat is back now.
>
> I confirmed multiple times that the NUC boots fine with the kernel
> that doesn't include the above patch but has the other two included
> (albeit with the drm_atomic WARN still).
>
> Not sure what to make of this one.
Yeah that fail looks like we're freeing an fb that's still in use.
Hilarity happens and since that happens under console_lock at boot-up your
machine dies.
Does that machine die the same way in drm-intel-nightly/linux-next?
I'll try to figure out meanwhile what's amiss here ...
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [Intel-gfx] [git pull] drm fixes
2015-03-25 15:50 ` Daniel Vetter
@ 2015-03-25 15:53 ` Josh Boyer
-1 siblings, 0 replies; 71+ messages in thread
From: Josh Boyer @ 2015-03-25 15:53 UTC (permalink / raw)
To: Daniel Vetter, Dave Airlie, Xi Ruoyao, Linus Torvalds,
Linux-Kernel@Vger. Kernel. Org, DRI mailing list,
Intel Graphics Development
On Wed, Mar 25, 2015 at 11:50 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Wed, Mar 25, 2015 at 11:37:35AM -0400, Josh Boyer wrote:
>> On Wed, Mar 25, 2015 at 10:00 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> > On Wed, Mar 25, 2015 at 09:11:17AM -0400, Josh Boyer wrote:
>> >> On Wed, Mar 25, 2015 at 4:54 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> >> >> >> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
>> >> >> >> Author: Damien Lespiau <damien.lespiau@intel.com>
>> >> >> >> Date: Thu Feb 5 18:30:20 2015 +0000
>> >> >> >>
>> >> >> >> drm/i915: Don't try to reference the fb in get_initial_plane_config()
>> >> >> >>
>> >> >> >> From linux-next?
>> >> >> >
>> >> >> > Yes, building now. Will let you know as soon as I test it on both machines.
>> >> >>
>> >> >> OK, with that commit applied I no longer get the kref.h splat and the
>> >> >> NUC machine boots headless. I still see the backtrace below on both
>> >> >> the NUC and the macbook. I have a copy of it with drm.debug=0xff from
>> >> >> the NUC here:
>> >> >>
>> >> >> https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
>> >> >>
>> >> >> Getting better at least :).
>> >> >
>> >> > On top of what you currently have please also cherry-pick
>> >> >
>> >> > commit fb9981aa675eb7b398849915364916fd98833cfa
>> >> > Author: Damien Lespiau <damien.lespiau@intel.com>
>> >> > Date: Thu Feb 5 19:24:25 2015 +0000
>> >> >
>> >> > drm/i915: Fix atomic state when reusing the firmware fb
>> >> >
>> >> > from -next. Let's hope this terminates eventually ;-)
>> >>
>> >> Hm. That one doesn't apply cleanly. I think because it needs:
>> >>
>> >> From 2d14030b1a9d0e89cfdca6f16851e2eac8cb4de0 Mon Sep 17 00:00:00 2001
>> >> From: Damien Lespiau <damien.lespiau@intel.com>
>> >> Date: Thu, 5 Feb 2015 17:22:18 +0000
>> >> Subject: drm/i915: Store the initial framebuffer in initial_plane_config
>> >>
>> >> first. Do you want me to grab both, or should I try and figure out
>> >> how to backport fb9981aa67 without it?
>> >
>> > Oops missed that. The active ingredient is setting crtc->primary->state->crtc like this:
>> > -Daniel
>> >
>> >
>> > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
>> > index 1c12262029fb..bfc14a6046ea 100644
>> > --- a/drivers/gpu/drm/i915/intel_display.c
>> > +++ b/drivers/gpu/drm/i915/intel_display.c
>> > @@ -2439,6 +2439,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>> > return;
>> >
>> > if (intel_alloc_plane_obj(intel_crtc, plane_config)) {
>> > + intel_crtc->base.primary->state->crtc = &intel_crtc->base;
>> > update_state_fb(intel_crtc->base.primary);
>> > return;
>> > }
>> > @@ -2469,6 +2470,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>> >
>> > drm_framebuffer_reference(c->primary->fb);
>> > intel_crtc->base.primary->fb = c->primary->fb;
>> > + intel_crtc->base.primary->state->crtc = &intel_crtc->base;
>> > obj->frontbuffer_bits |= INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
>> > break;
>> > }
>>
>> Hm. So I used your patch above. The macbook boots fine and all the
>> oops/WARNS are gone except the audio one that was unrelated and
>> present before all of this.
>>
>> However, the NUC is back to not booting without HDMI plugged in. I
>> did the drm.debug=0xff+blacklist/insmod trick again and put the
>> results up here:
>>
>> https://jwboyer.fedorapeople.org/pub/vetters.txt
>>
>> The frontbuffer splat is back now.
>>
>> I confirmed multiple times that the NUC boots fine with the kernel
>> that doesn't include the above patch but has the other two included
>> (albeit with the drm_atomic WARN still).
>>
>> Not sure what to make of this one.
>
> Yeah that fail looks like we're freeing an fb that's still in use.
> Hilarity happens and since that happens under console_lock at boot-up your
> machine dies.
>
> Does that machine die the same way in drm-intel-nightly/linux-next?
I'll try that a bit later today. Out of sheer curiosity, I folded
commit5ba76c41e55c (drm/i915: Put update_state_fb() next to the fb
update) into the patch above and kicked off a build. The theory is
that we're picking up a bunch of other changes right in that range of
commits, why not try one more. I'll let you know if that fixes
anything. Otherwise, I'll try building drm-intel-nightly and/or
linux-next after that.
josh
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [git pull] drm fixes
@ 2015-03-25 15:53 ` Josh Boyer
0 siblings, 0 replies; 71+ messages in thread
From: Josh Boyer @ 2015-03-25 15:53 UTC (permalink / raw)
To: Daniel Vetter, Dave Airlie, Xi Ruoyao, Linus Torvalds,
Linux-Kernel@Vger. Kernel. Org, DRI mailing list,
Intel Graphics Development
On Wed, Mar 25, 2015 at 11:50 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Wed, Mar 25, 2015 at 11:37:35AM -0400, Josh Boyer wrote:
>> On Wed, Mar 25, 2015 at 10:00 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> > On Wed, Mar 25, 2015 at 09:11:17AM -0400, Josh Boyer wrote:
>> >> On Wed, Mar 25, 2015 at 4:54 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> >> >> >> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
>> >> >> >> Author: Damien Lespiau <damien.lespiau@intel.com>
>> >> >> >> Date: Thu Feb 5 18:30:20 2015 +0000
>> >> >> >>
>> >> >> >> drm/i915: Don't try to reference the fb in get_initial_plane_config()
>> >> >> >>
>> >> >> >> From linux-next?
>> >> >> >
>> >> >> > Yes, building now. Will let you know as soon as I test it on both machines.
>> >> >>
>> >> >> OK, with that commit applied I no longer get the kref.h splat and the
>> >> >> NUC machine boots headless. I still see the backtrace below on both
>> >> >> the NUC and the macbook. I have a copy of it with drm.debug=0xff from
>> >> >> the NUC here:
>> >> >>
>> >> >> https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
>> >> >>
>> >> >> Getting better at least :).
>> >> >
>> >> > On top of what you currently have please also cherry-pick
>> >> >
>> >> > commit fb9981aa675eb7b398849915364916fd98833cfa
>> >> > Author: Damien Lespiau <damien.lespiau@intel.com>
>> >> > Date: Thu Feb 5 19:24:25 2015 +0000
>> >> >
>> >> > drm/i915: Fix atomic state when reusing the firmware fb
>> >> >
>> >> > from -next. Let's hope this terminates eventually ;-)
>> >>
>> >> Hm. That one doesn't apply cleanly. I think because it needs:
>> >>
>> >> From 2d14030b1a9d0e89cfdca6f16851e2eac8cb4de0 Mon Sep 17 00:00:00 2001
>> >> From: Damien Lespiau <damien.lespiau@intel.com>
>> >> Date: Thu, 5 Feb 2015 17:22:18 +0000
>> >> Subject: drm/i915: Store the initial framebuffer in initial_plane_config
>> >>
>> >> first. Do you want me to grab both, or should I try and figure out
>> >> how to backport fb9981aa67 without it?
>> >
>> > Oops missed that. The active ingredient is setting crtc->primary->state->crtc like this:
>> > -Daniel
>> >
>> >
>> > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
>> > index 1c12262029fb..bfc14a6046ea 100644
>> > --- a/drivers/gpu/drm/i915/intel_display.c
>> > +++ b/drivers/gpu/drm/i915/intel_display.c
>> > @@ -2439,6 +2439,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>> > return;
>> >
>> > if (intel_alloc_plane_obj(intel_crtc, plane_config)) {
>> > + intel_crtc->base.primary->state->crtc = &intel_crtc->base;
>> > update_state_fb(intel_crtc->base.primary);
>> > return;
>> > }
>> > @@ -2469,6 +2470,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>> >
>> > drm_framebuffer_reference(c->primary->fb);
>> > intel_crtc->base.primary->fb = c->primary->fb;
>> > + intel_crtc->base.primary->state->crtc = &intel_crtc->base;
>> > obj->frontbuffer_bits |= INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
>> > break;
>> > }
>>
>> Hm. So I used your patch above. The macbook boots fine and all the
>> oops/WARNS are gone except the audio one that was unrelated and
>> present before all of this.
>>
>> However, the NUC is back to not booting without HDMI plugged in. I
>> did the drm.debug=0xff+blacklist/insmod trick again and put the
>> results up here:
>>
>> https://jwboyer.fedorapeople.org/pub/vetters.txt
>>
>> The frontbuffer splat is back now.
>>
>> I confirmed multiple times that the NUC boots fine with the kernel
>> that doesn't include the above patch but has the other two included
>> (albeit with the drm_atomic WARN still).
>>
>> Not sure what to make of this one.
>
> Yeah that fail looks like we're freeing an fb that's still in use.
> Hilarity happens and since that happens under console_lock at boot-up your
> machine dies.
>
> Does that machine die the same way in drm-intel-nightly/linux-next?
I'll try that a bit later today. Out of sheer curiosity, I folded
commit5ba76c41e55c (drm/i915: Put update_state_fb() next to the fb
update) into the patch above and kicked off a build. The theory is
that we're picking up a bunch of other changes right in that range of
commits, why not try one more. I'll let you know if that fixes
anything. Otherwise, I'll try building drm-intel-nightly and/or
linux-next after that.
josh
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [Intel-gfx] [git pull] drm fixes
2015-03-25 15:53 ` Josh Boyer
@ 2015-03-25 16:42 ` Josh Boyer
-1 siblings, 0 replies; 71+ messages in thread
From: Josh Boyer @ 2015-03-25 16:42 UTC (permalink / raw)
To: Daniel Vetter
Cc: Dave Airlie, Xi Ruoyao, Linus Torvalds,
Linux-Kernel@Vger. Kernel. Org, DRI mailing list,
Intel Graphics Development
On Wed, Mar 25, 2015 at 11:53 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> On Wed, Mar 25, 2015 at 11:50 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> On Wed, Mar 25, 2015 at 11:37:35AM -0400, Josh Boyer wrote:
>>> On Wed, Mar 25, 2015 at 10:00 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>>> > On Wed, Mar 25, 2015 at 09:11:17AM -0400, Josh Boyer wrote:
>>> >> On Wed, Mar 25, 2015 at 4:54 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>>> >> >> >> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
>>> >> >> >> Author: Damien Lespiau <damien.lespiau@intel.com>
>>> >> >> >> Date: Thu Feb 5 18:30:20 2015 +0000
>>> >> >> >>
>>> >> >> >> drm/i915: Don't try to reference the fb in get_initial_plane_config()
>>> >> >> >>
>>> >> >> >> From linux-next?
>>> >> >> >
>>> >> >> > Yes, building now. Will let you know as soon as I test it on both machines.
>>> >> >>
>>> >> >> OK, with that commit applied I no longer get the kref.h splat and the
>>> >> >> NUC machine boots headless. I still see the backtrace below on both
>>> >> >> the NUC and the macbook. I have a copy of it with drm.debug=0xff from
>>> >> >> the NUC here:
>>> >> >>
>>> >> >> https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
>>> >> >>
>>> >> >> Getting better at least :).
>>> >> >
>>> >> > On top of what you currently have please also cherry-pick
>>> >> >
>>> >> > commit fb9981aa675eb7b398849915364916fd98833cfa
>>> >> > Author: Damien Lespiau <damien.lespiau@intel.com>
>>> >> > Date: Thu Feb 5 19:24:25 2015 +0000
>>> >> >
>>> >> > drm/i915: Fix atomic state when reusing the firmware fb
>>> >> >
>>> >> > from -next. Let's hope this terminates eventually ;-)
>>> >>
>>> >> Hm. That one doesn't apply cleanly. I think because it needs:
>>> >>
>>> >> From 2d14030b1a9d0e89cfdca6f16851e2eac8cb4de0 Mon Sep 17 00:00:00 2001
>>> >> From: Damien Lespiau <damien.lespiau@intel.com>
>>> >> Date: Thu, 5 Feb 2015 17:22:18 +0000
>>> >> Subject: drm/i915: Store the initial framebuffer in initial_plane_config
>>> >>
>>> >> first. Do you want me to grab both, or should I try and figure out
>>> >> how to backport fb9981aa67 without it?
>>> >
>>> > Oops missed that. The active ingredient is setting crtc->primary->state->crtc like this:
>>> > -Daniel
>>> >
>>> >
>>> > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
>>> > index 1c12262029fb..bfc14a6046ea 100644
>>> > --- a/drivers/gpu/drm/i915/intel_display.c
>>> > +++ b/drivers/gpu/drm/i915/intel_display.c
>>> > @@ -2439,6 +2439,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>>> > return;
>>> >
>>> > if (intel_alloc_plane_obj(intel_crtc, plane_config)) {
>>> > + intel_crtc->base.primary->state->crtc = &intel_crtc->base;
>>> > update_state_fb(intel_crtc->base.primary);
>>> > return;
>>> > }
>>> > @@ -2469,6 +2470,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>>> >
>>> > drm_framebuffer_reference(c->primary->fb);
>>> > intel_crtc->base.primary->fb = c->primary->fb;
>>> > + intel_crtc->base.primary->state->crtc = &intel_crtc->base;
>>> > obj->frontbuffer_bits |= INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
>>> > break;
>>> > }
>>>
>>> Hm. So I used your patch above. The macbook boots fine and all the
>>> oops/WARNS are gone except the audio one that was unrelated and
>>> present before all of this.
>>>
>>> However, the NUC is back to not booting without HDMI plugged in. I
>>> did the drm.debug=0xff+blacklist/insmod trick again and put the
>>> results up here:
>>>
>>> https://jwboyer.fedorapeople.org/pub/vetters.txt
>>>
>>> The frontbuffer splat is back now.
>>>
>>> I confirmed multiple times that the NUC boots fine with the kernel
>>> that doesn't include the above patch but has the other two included
>>> (albeit with the drm_atomic WARN still).
>>>
>>> Not sure what to make of this one.
>>
>> Yeah that fail looks like we're freeing an fb that's still in use.
>> Hilarity happens and since that happens under console_lock at boot-up your
>> machine dies.
>>
>> Does that machine die the same way in drm-intel-nightly/linux-next?
>
> I'll try that a bit later today. Out of sheer curiosity, I folded
> commit5ba76c41e55c (drm/i915: Put update_state_fb() next to the fb
> update) into the patch above and kicked off a build. The theory is
> that we're picking up a bunch of other changes right in that range of
> commits, why not try one more. I'll let you know if that fixes
> anything. Otherwise, I'll try building drm-intel-nightly and/or
> linux-next after that.
The drm-intel-nightly build finished first. It boots without HDMI
plugged in, but it has pretty much the same splats as the previous
kernel. Confused. Full log here:
https://jwboyer.fedorapeople.org/pub/intel-nightly.txt
I don't have much hope for my other build.
josh
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [git pull] drm fixes
@ 2015-03-25 16:42 ` Josh Boyer
0 siblings, 0 replies; 71+ messages in thread
From: Josh Boyer @ 2015-03-25 16:42 UTC (permalink / raw)
To: Daniel Vetter
Cc: Dave Airlie, Intel Graphics Development,
Linux-Kernel@Vger. Kernel. Org, DRI mailing list, Xi Ruoyao,
Linus Torvalds
On Wed, Mar 25, 2015 at 11:53 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> On Wed, Mar 25, 2015 at 11:50 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> On Wed, Mar 25, 2015 at 11:37:35AM -0400, Josh Boyer wrote:
>>> On Wed, Mar 25, 2015 at 10:00 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>>> > On Wed, Mar 25, 2015 at 09:11:17AM -0400, Josh Boyer wrote:
>>> >> On Wed, Mar 25, 2015 at 4:54 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>>> >> >> >> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
>>> >> >> >> Author: Damien Lespiau <damien.lespiau@intel.com>
>>> >> >> >> Date: Thu Feb 5 18:30:20 2015 +0000
>>> >> >> >>
>>> >> >> >> drm/i915: Don't try to reference the fb in get_initial_plane_config()
>>> >> >> >>
>>> >> >> >> From linux-next?
>>> >> >> >
>>> >> >> > Yes, building now. Will let you know as soon as I test it on both machines.
>>> >> >>
>>> >> >> OK, with that commit applied I no longer get the kref.h splat and the
>>> >> >> NUC machine boots headless. I still see the backtrace below on both
>>> >> >> the NUC and the macbook. I have a copy of it with drm.debug=0xff from
>>> >> >> the NUC here:
>>> >> >>
>>> >> >> https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
>>> >> >>
>>> >> >> Getting better at least :).
>>> >> >
>>> >> > On top of what you currently have please also cherry-pick
>>> >> >
>>> >> > commit fb9981aa675eb7b398849915364916fd98833cfa
>>> >> > Author: Damien Lespiau <damien.lespiau@intel.com>
>>> >> > Date: Thu Feb 5 19:24:25 2015 +0000
>>> >> >
>>> >> > drm/i915: Fix atomic state when reusing the firmware fb
>>> >> >
>>> >> > from -next. Let's hope this terminates eventually ;-)
>>> >>
>>> >> Hm. That one doesn't apply cleanly. I think because it needs:
>>> >>
>>> >> From 2d14030b1a9d0e89cfdca6f16851e2eac8cb4de0 Mon Sep 17 00:00:00 2001
>>> >> From: Damien Lespiau <damien.lespiau@intel.com>
>>> >> Date: Thu, 5 Feb 2015 17:22:18 +0000
>>> >> Subject: drm/i915: Store the initial framebuffer in initial_plane_config
>>> >>
>>> >> first. Do you want me to grab both, or should I try and figure out
>>> >> how to backport fb9981aa67 without it?
>>> >
>>> > Oops missed that. The active ingredient is setting crtc->primary->state->crtc like this:
>>> > -Daniel
>>> >
>>> >
>>> > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
>>> > index 1c12262029fb..bfc14a6046ea 100644
>>> > --- a/drivers/gpu/drm/i915/intel_display.c
>>> > +++ b/drivers/gpu/drm/i915/intel_display.c
>>> > @@ -2439,6 +2439,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>>> > return;
>>> >
>>> > if (intel_alloc_plane_obj(intel_crtc, plane_config)) {
>>> > + intel_crtc->base.primary->state->crtc = &intel_crtc->base;
>>> > update_state_fb(intel_crtc->base.primary);
>>> > return;
>>> > }
>>> > @@ -2469,6 +2470,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>>> >
>>> > drm_framebuffer_reference(c->primary->fb);
>>> > intel_crtc->base.primary->fb = c->primary->fb;
>>> > + intel_crtc->base.primary->state->crtc = &intel_crtc->base;
>>> > obj->frontbuffer_bits |= INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
>>> > break;
>>> > }
>>>
>>> Hm. So I used your patch above. The macbook boots fine and all the
>>> oops/WARNS are gone except the audio one that was unrelated and
>>> present before all of this.
>>>
>>> However, the NUC is back to not booting without HDMI plugged in. I
>>> did the drm.debug=0xff+blacklist/insmod trick again and put the
>>> results up here:
>>>
>>> https://jwboyer.fedorapeople.org/pub/vetters.txt
>>>
>>> The frontbuffer splat is back now.
>>>
>>> I confirmed multiple times that the NUC boots fine with the kernel
>>> that doesn't include the above patch but has the other two included
>>> (albeit with the drm_atomic WARN still).
>>>
>>> Not sure what to make of this one.
>>
>> Yeah that fail looks like we're freeing an fb that's still in use.
>> Hilarity happens and since that happens under console_lock at boot-up your
>> machine dies.
>>
>> Does that machine die the same way in drm-intel-nightly/linux-next?
>
> I'll try that a bit later today. Out of sheer curiosity, I folded
> commit5ba76c41e55c (drm/i915: Put update_state_fb() next to the fb
> update) into the patch above and kicked off a build. The theory is
> that we're picking up a bunch of other changes right in that range of
> commits, why not try one more. I'll let you know if that fixes
> anything. Otherwise, I'll try building drm-intel-nightly and/or
> linux-next after that.
The drm-intel-nightly build finished first. It boots without HDMI
plugged in, but it has pretty much the same splats as the previous
kernel. Confused. Full log here:
https://jwboyer.fedorapeople.org/pub/intel-nightly.txt
I don't have much hope for my other build.
josh
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [Intel-gfx] [git pull] drm fixes
2015-03-25 16:42 ` Josh Boyer
@ 2015-03-25 17:17 ` Daniel Vetter
-1 siblings, 0 replies; 71+ messages in thread
From: Daniel Vetter @ 2015-03-25 17:17 UTC (permalink / raw)
To: Josh Boyer
Cc: Daniel Vetter, Dave Airlie, Xi Ruoyao, Linus Torvalds,
Linux-Kernel@Vger. Kernel. Org, DRI mailing list,
Intel Graphics Development
On Wed, Mar 25, 2015 at 12:42:46PM -0400, Josh Boyer wrote:
> On Wed, Mar 25, 2015 at 11:53 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> > On Wed, Mar 25, 2015 at 11:50 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> >> On Wed, Mar 25, 2015 at 11:37:35AM -0400, Josh Boyer wrote:
> >>> On Wed, Mar 25, 2015 at 10:00 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> >>> > On Wed, Mar 25, 2015 at 09:11:17AM -0400, Josh Boyer wrote:
> >>> >> On Wed, Mar 25, 2015 at 4:54 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> >>> >> >> >> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
> >>> >> >> >> Author: Damien Lespiau <damien.lespiau@intel.com>
> >>> >> >> >> Date: Thu Feb 5 18:30:20 2015 +0000
> >>> >> >> >>
> >>> >> >> >> drm/i915: Don't try to reference the fb in get_initial_plane_config()
> >>> >> >> >>
> >>> >> >> >> From linux-next?
> >>> >> >> >
> >>> >> >> > Yes, building now. Will let you know as soon as I test it on both machines.
> >>> >> >>
> >>> >> >> OK, with that commit applied I no longer get the kref.h splat and the
> >>> >> >> NUC machine boots headless. I still see the backtrace below on both
> >>> >> >> the NUC and the macbook. I have a copy of it with drm.debug=0xff from
> >>> >> >> the NUC here:
> >>> >> >>
> >>> >> >> https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
> >>> >> >>
> >>> >> >> Getting better at least :).
> >>> >> >
> >>> >> > On top of what you currently have please also cherry-pick
> >>> >> >
> >>> >> > commit fb9981aa675eb7b398849915364916fd98833cfa
> >>> >> > Author: Damien Lespiau <damien.lespiau@intel.com>
> >>> >> > Date: Thu Feb 5 19:24:25 2015 +0000
> >>> >> >
> >>> >> > drm/i915: Fix atomic state when reusing the firmware fb
> >>> >> >
> >>> >> > from -next. Let's hope this terminates eventually ;-)
> >>> >>
> >>> >> Hm. That one doesn't apply cleanly. I think because it needs:
> >>> >>
> >>> >> From 2d14030b1a9d0e89cfdca6f16851e2eac8cb4de0 Mon Sep 17 00:00:00 2001
> >>> >> From: Damien Lespiau <damien.lespiau@intel.com>
> >>> >> Date: Thu, 5 Feb 2015 17:22:18 +0000
> >>> >> Subject: drm/i915: Store the initial framebuffer in initial_plane_config
> >>> >>
> >>> >> first. Do you want me to grab both, or should I try and figure out
> >>> >> how to backport fb9981aa67 without it?
> >>> >
> >>> > Oops missed that. The active ingredient is setting crtc->primary->state->crtc like this:
> >>> > -Daniel
> >>> >
> >>> >
> >>> > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> >>> > index 1c12262029fb..bfc14a6046ea 100644
> >>> > --- a/drivers/gpu/drm/i915/intel_display.c
> >>> > +++ b/drivers/gpu/drm/i915/intel_display.c
> >>> > @@ -2439,6 +2439,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
> >>> > return;
> >>> >
> >>> > if (intel_alloc_plane_obj(intel_crtc, plane_config)) {
> >>> > + intel_crtc->base.primary->state->crtc = &intel_crtc->base;
> >>> > update_state_fb(intel_crtc->base.primary);
> >>> > return;
> >>> > }
> >>> > @@ -2469,6 +2470,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
> >>> >
> >>> > drm_framebuffer_reference(c->primary->fb);
> >>> > intel_crtc->base.primary->fb = c->primary->fb;
> >>> > + intel_crtc->base.primary->state->crtc = &intel_crtc->base;
> >>> > obj->frontbuffer_bits |= INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
> >>> > break;
> >>> > }
> >>>
> >>> Hm. So I used your patch above. The macbook boots fine and all the
> >>> oops/WARNS are gone except the audio one that was unrelated and
> >>> present before all of this.
> >>>
> >>> However, the NUC is back to not booting without HDMI plugged in. I
> >>> did the drm.debug=0xff+blacklist/insmod trick again and put the
> >>> results up here:
> >>>
> >>> https://jwboyer.fedorapeople.org/pub/vetters.txt
> >>>
> >>> The frontbuffer splat is back now.
> >>>
> >>> I confirmed multiple times that the NUC boots fine with the kernel
> >>> that doesn't include the above patch but has the other two included
> >>> (albeit with the drm_atomic WARN still).
> >>>
> >>> Not sure what to make of this one.
> >>
> >> Yeah that fail looks like we're freeing an fb that's still in use.
> >> Hilarity happens and since that happens under console_lock at boot-up your
> >> machine dies.
> >>
> >> Does that machine die the same way in drm-intel-nightly/linux-next?
> >
> > I'll try that a bit later today. Out of sheer curiosity, I folded
> > commit5ba76c41e55c (drm/i915: Put update_state_fb() next to the fb
> > update) into the patch above and kicked off a build. The theory is
> > that we're picking up a bunch of other changes right in that range of
> > commits, why not try one more. I'll let you know if that fixes
> > anything. Otherwise, I'll try building drm-intel-nightly and/or
> > linux-next after that.
>
> The drm-intel-nightly build finished first. It boots without HDMI
> plugged in, but it has pretty much the same splats as the previous
> kernel. Confused. Full log here:
>
> https://jwboyer.fedorapeople.org/pub/intel-nightly.txt
>
> I don't have much hope for my other build.
Yeah that's at least good news for the theory I've been cooking meanwhile.
Can you try the below diff (on top of next/nightly)? For the current
cherry-pick pile on top of 4.0-rc you'd need to prepend intel_crtc->base.
to primary->...
Thanks, Daniel
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index ceb2e61b4c91..cb508542c6ab 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2594,6 +2594,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
primary->fb = &plane_config->fb->base;
primary->state->crtc = &intel_crtc->base;
+ primary->crtc = &intel_crtc->base;
update_state_fb(primary);
return;
@@ -2627,6 +2628,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
drm_framebuffer_reference(c->primary->fb);
primary->fb = c->primary->fb;
primary->state->crtc = &intel_crtc->base;
+ primary->crtc = &intel_crtc->base;
update_state_fb(intel_crtc->base.primary);
obj->frontbuffer_bits |= INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
break;
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply related [flat|nested] 71+ messages in thread
* Re: [git pull] drm fixes
@ 2015-03-25 17:17 ` Daniel Vetter
0 siblings, 0 replies; 71+ messages in thread
From: Daniel Vetter @ 2015-03-25 17:17 UTC (permalink / raw)
To: Josh Boyer
Cc: Dave Airlie, Intel Graphics Development,
Linux-Kernel@Vger. Kernel. Org, DRI mailing list, Xi Ruoyao,
Linus Torvalds
On Wed, Mar 25, 2015 at 12:42:46PM -0400, Josh Boyer wrote:
> On Wed, Mar 25, 2015 at 11:53 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> > On Wed, Mar 25, 2015 at 11:50 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> >> On Wed, Mar 25, 2015 at 11:37:35AM -0400, Josh Boyer wrote:
> >>> On Wed, Mar 25, 2015 at 10:00 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> >>> > On Wed, Mar 25, 2015 at 09:11:17AM -0400, Josh Boyer wrote:
> >>> >> On Wed, Mar 25, 2015 at 4:54 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> >>> >> >> >> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
> >>> >> >> >> Author: Damien Lespiau <damien.lespiau@intel.com>
> >>> >> >> >> Date: Thu Feb 5 18:30:20 2015 +0000
> >>> >> >> >>
> >>> >> >> >> drm/i915: Don't try to reference the fb in get_initial_plane_config()
> >>> >> >> >>
> >>> >> >> >> From linux-next?
> >>> >> >> >
> >>> >> >> > Yes, building now. Will let you know as soon as I test it on both machines.
> >>> >> >>
> >>> >> >> OK, with that commit applied I no longer get the kref.h splat and the
> >>> >> >> NUC machine boots headless. I still see the backtrace below on both
> >>> >> >> the NUC and the macbook. I have a copy of it with drm.debug=0xff from
> >>> >> >> the NUC here:
> >>> >> >>
> >>> >> >> https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
> >>> >> >>
> >>> >> >> Getting better at least :).
> >>> >> >
> >>> >> > On top of what you currently have please also cherry-pick
> >>> >> >
> >>> >> > commit fb9981aa675eb7b398849915364916fd98833cfa
> >>> >> > Author: Damien Lespiau <damien.lespiau@intel.com>
> >>> >> > Date: Thu Feb 5 19:24:25 2015 +0000
> >>> >> >
> >>> >> > drm/i915: Fix atomic state when reusing the firmware fb
> >>> >> >
> >>> >> > from -next. Let's hope this terminates eventually ;-)
> >>> >>
> >>> >> Hm. That one doesn't apply cleanly. I think because it needs:
> >>> >>
> >>> >> From 2d14030b1a9d0e89cfdca6f16851e2eac8cb4de0 Mon Sep 17 00:00:00 2001
> >>> >> From: Damien Lespiau <damien.lespiau@intel.com>
> >>> >> Date: Thu, 5 Feb 2015 17:22:18 +0000
> >>> >> Subject: drm/i915: Store the initial framebuffer in initial_plane_config
> >>> >>
> >>> >> first. Do you want me to grab both, or should I try and figure out
> >>> >> how to backport fb9981aa67 without it?
> >>> >
> >>> > Oops missed that. The active ingredient is setting crtc->primary->state->crtc like this:
> >>> > -Daniel
> >>> >
> >>> >
> >>> > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> >>> > index 1c12262029fb..bfc14a6046ea 100644
> >>> > --- a/drivers/gpu/drm/i915/intel_display.c
> >>> > +++ b/drivers/gpu/drm/i915/intel_display.c
> >>> > @@ -2439,6 +2439,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
> >>> > return;
> >>> >
> >>> > if (intel_alloc_plane_obj(intel_crtc, plane_config)) {
> >>> > + intel_crtc->base.primary->state->crtc = &intel_crtc->base;
> >>> > update_state_fb(intel_crtc->base.primary);
> >>> > return;
> >>> > }
> >>> > @@ -2469,6 +2470,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
> >>> >
> >>> > drm_framebuffer_reference(c->primary->fb);
> >>> > intel_crtc->base.primary->fb = c->primary->fb;
> >>> > + intel_crtc->base.primary->state->crtc = &intel_crtc->base;
> >>> > obj->frontbuffer_bits |= INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
> >>> > break;
> >>> > }
> >>>
> >>> Hm. So I used your patch above. The macbook boots fine and all the
> >>> oops/WARNS are gone except the audio one that was unrelated and
> >>> present before all of this.
> >>>
> >>> However, the NUC is back to not booting without HDMI plugged in. I
> >>> did the drm.debug=0xff+blacklist/insmod trick again and put the
> >>> results up here:
> >>>
> >>> https://jwboyer.fedorapeople.org/pub/vetters.txt
> >>>
> >>> The frontbuffer splat is back now.
> >>>
> >>> I confirmed multiple times that the NUC boots fine with the kernel
> >>> that doesn't include the above patch but has the other two included
> >>> (albeit with the drm_atomic WARN still).
> >>>
> >>> Not sure what to make of this one.
> >>
> >> Yeah that fail looks like we're freeing an fb that's still in use.
> >> Hilarity happens and since that happens under console_lock at boot-up your
> >> machine dies.
> >>
> >> Does that machine die the same way in drm-intel-nightly/linux-next?
> >
> > I'll try that a bit later today. Out of sheer curiosity, I folded
> > commit5ba76c41e55c (drm/i915: Put update_state_fb() next to the fb
> > update) into the patch above and kicked off a build. The theory is
> > that we're picking up a bunch of other changes right in that range of
> > commits, why not try one more. I'll let you know if that fixes
> > anything. Otherwise, I'll try building drm-intel-nightly and/or
> > linux-next after that.
>
> The drm-intel-nightly build finished first. It boots without HDMI
> plugged in, but it has pretty much the same splats as the previous
> kernel. Confused. Full log here:
>
> https://jwboyer.fedorapeople.org/pub/intel-nightly.txt
>
> I don't have much hope for my other build.
Yeah that's at least good news for the theory I've been cooking meanwhile.
Can you try the below diff (on top of next/nightly)? For the current
cherry-pick pile on top of 4.0-rc you'd need to prepend intel_crtc->base.
to primary->...
Thanks, Daniel
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index ceb2e61b4c91..cb508542c6ab 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2594,6 +2594,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
primary->fb = &plane_config->fb->base;
primary->state->crtc = &intel_crtc->base;
+ primary->crtc = &intel_crtc->base;
update_state_fb(primary);
return;
@@ -2627,6 +2628,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
drm_framebuffer_reference(c->primary->fb);
primary->fb = c->primary->fb;
primary->state->crtc = &intel_crtc->base;
+ primary->crtc = &intel_crtc->base;
update_state_fb(intel_crtc->base.primary);
obj->frontbuffer_bits |= INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
break;
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 71+ messages in thread
* Re: [Intel-gfx] [git pull] drm fixes
2015-03-25 17:17 ` Daniel Vetter
@ 2015-03-25 17:37 ` Josh Boyer
-1 siblings, 0 replies; 71+ messages in thread
From: Josh Boyer @ 2015-03-25 17:37 UTC (permalink / raw)
To: Daniel Vetter, Dave Airlie, Xi Ruoyao, Linus Torvalds,
Linux-Kernel@Vger. Kernel. Org, DRI mailing list,
Intel Graphics Development
On Wed, Mar 25, 2015 at 1:17 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Wed, Mar 25, 2015 at 12:42:46PM -0400, Josh Boyer wrote:
>> On Wed, Mar 25, 2015 at 11:53 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
>> > On Wed, Mar 25, 2015 at 11:50 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> >> On Wed, Mar 25, 2015 at 11:37:35AM -0400, Josh Boyer wrote:
>> >>> On Wed, Mar 25, 2015 at 10:00 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> >>> > On Wed, Mar 25, 2015 at 09:11:17AM -0400, Josh Boyer wrote:
>> >>> >> On Wed, Mar 25, 2015 at 4:54 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> >>> >> >> >> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
>> >>> >> >> >> Author: Damien Lespiau <damien.lespiau@intel.com>
>> >>> >> >> >> Date: Thu Feb 5 18:30:20 2015 +0000
>> >>> >> >> >>
>> >>> >> >> >> drm/i915: Don't try to reference the fb in get_initial_plane_config()
>> >>> >> >> >>
>> >>> >> >> >> From linux-next?
>> >>> >> >> >
>> >>> >> >> > Yes, building now. Will let you know as soon as I test it on both machines.
>> >>> >> >>
>> >>> >> >> OK, with that commit applied I no longer get the kref.h splat and the
>> >>> >> >> NUC machine boots headless. I still see the backtrace below on both
>> >>> >> >> the NUC and the macbook. I have a copy of it with drm.debug=0xff from
>> >>> >> >> the NUC here:
>> >>> >> >>
>> >>> >> >> https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
>> >>> >> >>
>> >>> >> >> Getting better at least :).
>> >>> >> >
>> >>> >> > On top of what you currently have please also cherry-pick
>> >>> >> >
>> >>> >> > commit fb9981aa675eb7b398849915364916fd98833cfa
>> >>> >> > Author: Damien Lespiau <damien.lespiau@intel.com>
>> >>> >> > Date: Thu Feb 5 19:24:25 2015 +0000
>> >>> >> >
>> >>> >> > drm/i915: Fix atomic state when reusing the firmware fb
>> >>> >> >
>> >>> >> > from -next. Let's hope this terminates eventually ;-)
>> >>> >>
>> >>> >> Hm. That one doesn't apply cleanly. I think because it needs:
>> >>> >>
>> >>> >> From 2d14030b1a9d0e89cfdca6f16851e2eac8cb4de0 Mon Sep 17 00:00:00 2001
>> >>> >> From: Damien Lespiau <damien.lespiau@intel.com>
>> >>> >> Date: Thu, 5 Feb 2015 17:22:18 +0000
>> >>> >> Subject: drm/i915: Store the initial framebuffer in initial_plane_config
>> >>> >>
>> >>> >> first. Do you want me to grab both, or should I try and figure out
>> >>> >> how to backport fb9981aa67 without it?
>> >>> >
>> >>> > Oops missed that. The active ingredient is setting crtc->primary->state->crtc like this:
>> >>> > -Daniel
>> >>> >
>> >>> >
>> >>> > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
>> >>> > index 1c12262029fb..bfc14a6046ea 100644
>> >>> > --- a/drivers/gpu/drm/i915/intel_display.c
>> >>> > +++ b/drivers/gpu/drm/i915/intel_display.c
>> >>> > @@ -2439,6 +2439,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>> >>> > return;
>> >>> >
>> >>> > if (intel_alloc_plane_obj(intel_crtc, plane_config)) {
>> >>> > + intel_crtc->base.primary->state->crtc = &intel_crtc->base;
>> >>> > update_state_fb(intel_crtc->base.primary);
>> >>> > return;
>> >>> > }
>> >>> > @@ -2469,6 +2470,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>> >>> >
>> >>> > drm_framebuffer_reference(c->primary->fb);
>> >>> > intel_crtc->base.primary->fb = c->primary->fb;
>> >>> > + intel_crtc->base.primary->state->crtc = &intel_crtc->base;
>> >>> > obj->frontbuffer_bits |= INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
>> >>> > break;
>> >>> > }
>> >>>
>> >>> Hm. So I used your patch above. The macbook boots fine and all the
>> >>> oops/WARNS are gone except the audio one that was unrelated and
>> >>> present before all of this.
>> >>>
>> >>> However, the NUC is back to not booting without HDMI plugged in. I
>> >>> did the drm.debug=0xff+blacklist/insmod trick again and put the
>> >>> results up here:
>> >>>
>> >>> https://jwboyer.fedorapeople.org/pub/vetters.txt
>> >>>
>> >>> The frontbuffer splat is back now.
>> >>>
>> >>> I confirmed multiple times that the NUC boots fine with the kernel
>> >>> that doesn't include the above patch but has the other two included
>> >>> (albeit with the drm_atomic WARN still).
>> >>>
>> >>> Not sure what to make of this one.
>> >>
>> >> Yeah that fail looks like we're freeing an fb that's still in use.
>> >> Hilarity happens and since that happens under console_lock at boot-up your
>> >> machine dies.
>> >>
>> >> Does that machine die the same way in drm-intel-nightly/linux-next?
>> >
>> > I'll try that a bit later today. Out of sheer curiosity, I folded
>> > commit5ba76c41e55c (drm/i915: Put update_state_fb() next to the fb
>> > update) into the patch above and kicked off a build. The theory is
>> > that we're picking up a bunch of other changes right in that range of
>> > commits, why not try one more. I'll let you know if that fixes
>> > anything. Otherwise, I'll try building drm-intel-nightly and/or
>> > linux-next after that.
>>
>> The drm-intel-nightly build finished first. It boots without HDMI
>> plugged in, but it has pretty much the same splats as the previous
>> kernel. Confused. Full log here:
>>
>> https://jwboyer.fedorapeople.org/pub/intel-nightly.txt
>>
>> I don't have much hope for my other build.
>
> Yeah that's at least good news for the theory I've been cooking meanwhile.
> Can you try the below diff (on top of next/nightly)? For the current
> cherry-pick pile on top of 4.0-rc you'd need to prepend intel_crtc->base.
> to primary->...
>
> Thanks, Daniel
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index ceb2e61b4c91..cb508542c6ab 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2594,6 +2594,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>
> primary->fb = &plane_config->fb->base;
> primary->state->crtc = &intel_crtc->base;
> + primary->crtc = &intel_crtc->base;
> update_state_fb(primary);
>
> return;
> @@ -2627,6 +2628,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
> drm_framebuffer_reference(c->primary->fb);
> primary->fb = c->primary->fb;
> primary->state->crtc = &intel_crtc->base;
> + primary->crtc = &intel_crtc->base;
> update_state_fb(intel_crtc->base.primary);
> obj->frontbuffer_bits |= INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
> break;
Hey, that seems to do the trick on the NUC machine. Boots without
HDMI connected and there are no backtraces. Nice!
Let me go and munge it around for a backport on top of -rc5 with the
rest of the pile and see if both the macbook and NUC machines work
then. Will be a bit for it to build.
josh
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [git pull] drm fixes
@ 2015-03-25 17:37 ` Josh Boyer
0 siblings, 0 replies; 71+ messages in thread
From: Josh Boyer @ 2015-03-25 17:37 UTC (permalink / raw)
To: Daniel Vetter, Dave Airlie, Xi Ruoyao, Linus Torvalds,
Linux-Kernel@Vger. Kernel. Org, DRI mailing list,
Intel Graphics Development
On Wed, Mar 25, 2015 at 1:17 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Wed, Mar 25, 2015 at 12:42:46PM -0400, Josh Boyer wrote:
>> On Wed, Mar 25, 2015 at 11:53 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
>> > On Wed, Mar 25, 2015 at 11:50 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> >> On Wed, Mar 25, 2015 at 11:37:35AM -0400, Josh Boyer wrote:
>> >>> On Wed, Mar 25, 2015 at 10:00 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> >>> > On Wed, Mar 25, 2015 at 09:11:17AM -0400, Josh Boyer wrote:
>> >>> >> On Wed, Mar 25, 2015 at 4:54 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> >>> >> >> >> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
>> >>> >> >> >> Author: Damien Lespiau <damien.lespiau@intel.com>
>> >>> >> >> >> Date: Thu Feb 5 18:30:20 2015 +0000
>> >>> >> >> >>
>> >>> >> >> >> drm/i915: Don't try to reference the fb in get_initial_plane_config()
>> >>> >> >> >>
>> >>> >> >> >> From linux-next?
>> >>> >> >> >
>> >>> >> >> > Yes, building now. Will let you know as soon as I test it on both machines.
>> >>> >> >>
>> >>> >> >> OK, with that commit applied I no longer get the kref.h splat and the
>> >>> >> >> NUC machine boots headless. I still see the backtrace below on both
>> >>> >> >> the NUC and the macbook. I have a copy of it with drm.debug=0xff from
>> >>> >> >> the NUC here:
>> >>> >> >>
>> >>> >> >> https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
>> >>> >> >>
>> >>> >> >> Getting better at least :).
>> >>> >> >
>> >>> >> > On top of what you currently have please also cherry-pick
>> >>> >> >
>> >>> >> > commit fb9981aa675eb7b398849915364916fd98833cfa
>> >>> >> > Author: Damien Lespiau <damien.lespiau@intel.com>
>> >>> >> > Date: Thu Feb 5 19:24:25 2015 +0000
>> >>> >> >
>> >>> >> > drm/i915: Fix atomic state when reusing the firmware fb
>> >>> >> >
>> >>> >> > from -next. Let's hope this terminates eventually ;-)
>> >>> >>
>> >>> >> Hm. That one doesn't apply cleanly. I think because it needs:
>> >>> >>
>> >>> >> From 2d14030b1a9d0e89cfdca6f16851e2eac8cb4de0 Mon Sep 17 00:00:00 2001
>> >>> >> From: Damien Lespiau <damien.lespiau@intel.com>
>> >>> >> Date: Thu, 5 Feb 2015 17:22:18 +0000
>> >>> >> Subject: drm/i915: Store the initial framebuffer in initial_plane_config
>> >>> >>
>> >>> >> first. Do you want me to grab both, or should I try and figure out
>> >>> >> how to backport fb9981aa67 without it?
>> >>> >
>> >>> > Oops missed that. The active ingredient is setting crtc->primary->state->crtc like this:
>> >>> > -Daniel
>> >>> >
>> >>> >
>> >>> > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
>> >>> > index 1c12262029fb..bfc14a6046ea 100644
>> >>> > --- a/drivers/gpu/drm/i915/intel_display.c
>> >>> > +++ b/drivers/gpu/drm/i915/intel_display.c
>> >>> > @@ -2439,6 +2439,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>> >>> > return;
>> >>> >
>> >>> > if (intel_alloc_plane_obj(intel_crtc, plane_config)) {
>> >>> > + intel_crtc->base.primary->state->crtc = &intel_crtc->base;
>> >>> > update_state_fb(intel_crtc->base.primary);
>> >>> > return;
>> >>> > }
>> >>> > @@ -2469,6 +2470,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>> >>> >
>> >>> > drm_framebuffer_reference(c->primary->fb);
>> >>> > intel_crtc->base.primary->fb = c->primary->fb;
>> >>> > + intel_crtc->base.primary->state->crtc = &intel_crtc->base;
>> >>> > obj->frontbuffer_bits |= INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
>> >>> > break;
>> >>> > }
>> >>>
>> >>> Hm. So I used your patch above. The macbook boots fine and all the
>> >>> oops/WARNS are gone except the audio one that was unrelated and
>> >>> present before all of this.
>> >>>
>> >>> However, the NUC is back to not booting without HDMI plugged in. I
>> >>> did the drm.debug=0xff+blacklist/insmod trick again and put the
>> >>> results up here:
>> >>>
>> >>> https://jwboyer.fedorapeople.org/pub/vetters.txt
>> >>>
>> >>> The frontbuffer splat is back now.
>> >>>
>> >>> I confirmed multiple times that the NUC boots fine with the kernel
>> >>> that doesn't include the above patch but has the other two included
>> >>> (albeit with the drm_atomic WARN still).
>> >>>
>> >>> Not sure what to make of this one.
>> >>
>> >> Yeah that fail looks like we're freeing an fb that's still in use.
>> >> Hilarity happens and since that happens under console_lock at boot-up your
>> >> machine dies.
>> >>
>> >> Does that machine die the same way in drm-intel-nightly/linux-next?
>> >
>> > I'll try that a bit later today. Out of sheer curiosity, I folded
>> > commit5ba76c41e55c (drm/i915: Put update_state_fb() next to the fb
>> > update) into the patch above and kicked off a build. The theory is
>> > that we're picking up a bunch of other changes right in that range of
>> > commits, why not try one more. I'll let you know if that fixes
>> > anything. Otherwise, I'll try building drm-intel-nightly and/or
>> > linux-next after that.
>>
>> The drm-intel-nightly build finished first. It boots without HDMI
>> plugged in, but it has pretty much the same splats as the previous
>> kernel. Confused. Full log here:
>>
>> https://jwboyer.fedorapeople.org/pub/intel-nightly.txt
>>
>> I don't have much hope for my other build.
>
> Yeah that's at least good news for the theory I've been cooking meanwhile.
> Can you try the below diff (on top of next/nightly)? For the current
> cherry-pick pile on top of 4.0-rc you'd need to prepend intel_crtc->base.
> to primary->...
>
> Thanks, Daniel
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index ceb2e61b4c91..cb508542c6ab 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2594,6 +2594,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>
> primary->fb = &plane_config->fb->base;
> primary->state->crtc = &intel_crtc->base;
> + primary->crtc = &intel_crtc->base;
> update_state_fb(primary);
>
> return;
> @@ -2627,6 +2628,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
> drm_framebuffer_reference(c->primary->fb);
> primary->fb = c->primary->fb;
> primary->state->crtc = &intel_crtc->base;
> + primary->crtc = &intel_crtc->base;
> update_state_fb(intel_crtc->base.primary);
> obj->frontbuffer_bits |= INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
> break;
Hey, that seems to do the trick on the NUC machine. Boots without
HDMI connected and there are no backtraces. Nice!
Let me go and munge it around for a backport on top of -rc5 with the
rest of the pile and see if both the macbook and NUC machines work
then. Will be a bit for it to build.
josh
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [Intel-gfx] [git pull] drm fixes
2015-03-25 17:37 ` Josh Boyer
@ 2015-03-25 19:40 ` Josh Boyer
-1 siblings, 0 replies; 71+ messages in thread
From: Josh Boyer @ 2015-03-25 19:40 UTC (permalink / raw)
To: Daniel Vetter
Cc: Dave Airlie, Xi Ruoyao, Linus Torvalds,
Linux-Kernel@Vger. Kernel. Org, DRI mailing list,
Intel Graphics Development
On Wed, Mar 25, 2015 at 01:37:41PM -0400, Josh Boyer wrote:
>>> >> Yeah that fail looks like we're freeing an fb that's still in use.
>>> >> Hilarity happens and since that happens under console_lock at boot-up your
>>> >> machine dies.
>>> >>
>>> >> Does that machine die the same way in drm-intel-nightly/linux-next?
>>> >
>>> > I'll try that a bit later today. Out of sheer curiosity, I folded
>>> > commit5ba76c41e55c (drm/i915: Put update_state_fb() next to the fb
>>> > update) into the patch above and kicked off a build. The theory is
>>> > that we're picking up a bunch of other changes right in that range of
>>> > commits, why not try one more. I'll let you know if that fixes
>>> > anything. Otherwise, I'll try building drm-intel-nightly and/or
>>> > linux-next after that.
>>>
>>> The drm-intel-nightly build finished first. It boots without HDMI
>>> plugged in, but it has pretty much the same splats as the previous
>>> kernel. Confused. Full log here:
>>>
>>> https://jwboyer.fedorapeople.org/pub/intel-nightly.txt
>>>
>>> I don't have much hope for my other build.
>>
>> Yeah that's at least good news for the theory I've been cooking meanwhile.
>> Can you try the below diff (on top of next/nightly)? For the current
>> cherry-pick pile on top of 4.0-rc you'd need to prepend intel_crtc->base.
>> to primary->...
>>
>> Thanks, Daniel
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
>> index ceb2e61b4c91..cb508542c6ab 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -2594,6 +2594,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>>
>> primary->fb = &plane_config->fb->base;
>> primary->state->crtc = &intel_crtc->base;
>> + primary->crtc = &intel_crtc->base;
>> update_state_fb(primary);
>>
>> return;
>> @@ -2627,6 +2628,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>> drm_framebuffer_reference(c->primary->fb);
>> primary->fb = c->primary->fb;
>> primary->state->crtc = &intel_crtc->base;
>> + primary->crtc = &intel_crtc->base;
>> update_state_fb(intel_crtc->base.primary);
>> obj->frontbuffer_bits |= INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
>> break;
>
>Hey, that seems to do the trick on the NUC machine. Boots without
>HDMI connected and there are no backtraces. Nice!
>
>Let me go and munge it around for a backport on top of -rc5 with the
>rest of the pile and see if both the macbook and NUC machines work
>then. Will be a bit for it to build.
OK, that helped on all my machines I have. No backtraces and they all
boot again as I would expect. For the record, here is what I have on
top of -rc5:
drm-Fixup-racy-refcounting-in-plane_force_disable.patch
drm-i915-Don-t-try-to-reference-the-fb-in-get_initia.patch
and this patch:
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 177714a9d778..778e7fa41c17 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2439,6 +2439,8 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
return;
if (intel_alloc_plane_obj(intel_crtc, plane_config)) {
+ intel_crtc->base.primary->state->crtc = &intel_crtc->base;
+ intel_crtc->base.primary->crtc = &intel_crtc->base;
update_state_fb(intel_crtc->base.primary);
return;
}
@@ -2469,6 +2471,8 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
drm_framebuffer_reference(c->primary->fb);
intel_crtc->base.primary->fb = c->primary->fb;
+ intel_crtc->base.primary->state->crtc = &intel_crtc->base;
+ intel_crtc->base.primary->crtc = &intel_crtc->base;
obj->frontbuffer_bits |= INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
break;
}
which is a mash-up of:
"drm/i915: Fix atomic state when reusing the firmware fb"
and
"drm/i915: Fixup legacy plane->crtc link for initial fb config"
which you just sent out.
I think that covers everything.
josh
^ permalink raw reply related [flat|nested] 71+ messages in thread
* Re: [git pull] drm fixes
@ 2015-03-25 19:40 ` Josh Boyer
0 siblings, 0 replies; 71+ messages in thread
From: Josh Boyer @ 2015-03-25 19:40 UTC (permalink / raw)
To: Daniel Vetter
Cc: Dave Airlie, Intel Graphics Development,
Linux-Kernel@Vger. Kernel. Org, DRI mailing list, Xi Ruoyao,
Linus Torvalds
On Wed, Mar 25, 2015 at 01:37:41PM -0400, Josh Boyer wrote:
>>> >> Yeah that fail looks like we're freeing an fb that's still in use.
>>> >> Hilarity happens and since that happens under console_lock at boot-up your
>>> >> machine dies.
>>> >>
>>> >> Does that machine die the same way in drm-intel-nightly/linux-next?
>>> >
>>> > I'll try that a bit later today. Out of sheer curiosity, I folded
>>> > commit5ba76c41e55c (drm/i915: Put update_state_fb() next to the fb
>>> > update) into the patch above and kicked off a build. The theory is
>>> > that we're picking up a bunch of other changes right in that range of
>>> > commits, why not try one more. I'll let you know if that fixes
>>> > anything. Otherwise, I'll try building drm-intel-nightly and/or
>>> > linux-next after that.
>>>
>>> The drm-intel-nightly build finished first. It boots without HDMI
>>> plugged in, but it has pretty much the same splats as the previous
>>> kernel. Confused. Full log here:
>>>
>>> https://jwboyer.fedorapeople.org/pub/intel-nightly.txt
>>>
>>> I don't have much hope for my other build.
>>
>> Yeah that's at least good news for the theory I've been cooking meanwhile.
>> Can you try the below diff (on top of next/nightly)? For the current
>> cherry-pick pile on top of 4.0-rc you'd need to prepend intel_crtc->base.
>> to primary->...
>>
>> Thanks, Daniel
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
>> index ceb2e61b4c91..cb508542c6ab 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -2594,6 +2594,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>>
>> primary->fb = &plane_config->fb->base;
>> primary->state->crtc = &intel_crtc->base;
>> + primary->crtc = &intel_crtc->base;
>> update_state_fb(primary);
>>
>> return;
>> @@ -2627,6 +2628,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>> drm_framebuffer_reference(c->primary->fb);
>> primary->fb = c->primary->fb;
>> primary->state->crtc = &intel_crtc->base;
>> + primary->crtc = &intel_crtc->base;
>> update_state_fb(intel_crtc->base.primary);
>> obj->frontbuffer_bits |= INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
>> break;
>
>Hey, that seems to do the trick on the NUC machine. Boots without
>HDMI connected and there are no backtraces. Nice!
>
>Let me go and munge it around for a backport on top of -rc5 with the
>rest of the pile and see if both the macbook and NUC machines work
>then. Will be a bit for it to build.
OK, that helped on all my machines I have. No backtraces and they all
boot again as I would expect. For the record, here is what I have on
top of -rc5:
drm-Fixup-racy-refcounting-in-plane_force_disable.patch
drm-i915-Don-t-try-to-reference-the-fb-in-get_initia.patch
and this patch:
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 177714a9d778..778e7fa41c17 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2439,6 +2439,8 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
return;
if (intel_alloc_plane_obj(intel_crtc, plane_config)) {
+ intel_crtc->base.primary->state->crtc = &intel_crtc->base;
+ intel_crtc->base.primary->crtc = &intel_crtc->base;
update_state_fb(intel_crtc->base.primary);
return;
}
@@ -2469,6 +2471,8 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
drm_framebuffer_reference(c->primary->fb);
intel_crtc->base.primary->fb = c->primary->fb;
+ intel_crtc->base.primary->state->crtc = &intel_crtc->base;
+ intel_crtc->base.primary->crtc = &intel_crtc->base;
obj->frontbuffer_bits |= INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
break;
}
which is a mash-up of:
"drm/i915: Fix atomic state when reusing the firmware fb"
and
"drm/i915: Fixup legacy plane->crtc link for initial fb config"
which you just sent out.
I think that covers everything.
josh
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 71+ messages in thread
* Re: [Intel-gfx] [git pull] drm fixes
2015-03-25 19:40 ` Josh Boyer
@ 2015-03-25 23:32 ` Xi Ruoyao
-1 siblings, 0 replies; 71+ messages in thread
From: Xi Ruoyao @ 2015-03-25 23:32 UTC (permalink / raw)
To: Josh Boyer, Daniel Vetter
Cc: Dave Airlie, Linus Torvalds, Linux-Kernel@Vger. Kernel. Org,
DRI mailing list, Intel Graphics Development
在 03/26/2015 03:40 AM, Josh Boyer 写道:
> On Wed, Mar 25, 2015 at 01:37:41PM -0400, Josh Boyer wrote:
>>>>>> Yeah that fail looks like we're freeing an fb that's still in use.
>>>>>> Hilarity happens and since that happens under console_lock at boot-up your
>>>>>> machine dies.
>>>>>>
>>>>>> Does that machine die the same way in drm-intel-nightly/linux-next?
>>>>> I'll try that a bit later today. Out of sheer curiosity, I folded
>>>>> commit5ba76c41e55c (drm/i915: Put update_state_fb() next to the fb
>>>>> update) into the patch above and kicked off a build. The theory is
>>>>> that we're picking up a bunch of other changes right in that range of
>>>>> commits, why not try one more. I'll let you know if that fixes
>>>>> anything. Otherwise, I'll try building drm-intel-nightly and/or
>>>>> linux-next after that.
>>>> The drm-intel-nightly build finished first. It boots without HDMI
>>>> plugged in, but it has pretty much the same splats as the previous
>>>> kernel. Confused. Full log here:
>>>>
>>>> https://jwboyer.fedorapeople.org/pub/intel-nightly.txt
>>>>
>>>> I don't have much hope for my other build.
>>> Yeah that's at least good news for the theory I've been cooking meanwhile.
>>> Can you try the below diff (on top of next/nightly)? For the current
>>> cherry-pick pile on top of 4.0-rc you'd need to prepend intel_crtc->base.
>>> to primary->...
>>>
>>> Thanks, Daniel
>>>
>>> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
>>> index ceb2e61b4c91..cb508542c6ab 100644
>>> --- a/drivers/gpu/drm/i915/intel_display.c
>>> +++ b/drivers/gpu/drm/i915/intel_display.c
>>> @@ -2594,6 +2594,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>>>
>>> primary->fb = &plane_config->fb->base;
>>> primary->state->crtc = &intel_crtc->base;
>>> + primary->crtc = &intel_crtc->base;
>>> update_state_fb(primary);
>>>
>>> return;
>>> @@ -2627,6 +2628,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>>> drm_framebuffer_reference(c->primary->fb);
>>> primary->fb = c->primary->fb;
>>> primary->state->crtc = &intel_crtc->base;
>>> + primary->crtc = &intel_crtc->base;
>>> update_state_fb(intel_crtc->base.primary);
>>> obj->frontbuffer_bits |= INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
>>> break;
>> Hey, that seems to do the trick on the NUC machine. Boots without
>> HDMI connected and there are no backtraces. Nice!
>>
>> Let me go and munge it around for a backport on top of -rc5 with the
>> rest of the pile and see if both the macbook and NUC machines work
>> then. Will be a bit for it to build.
> OK, that helped on all my machines I have. No backtraces and they all
> boot again as I would expect. For the record, here is what I have on
> top of -rc5:
>
> drm-Fixup-racy-refcounting-in-plane_force_disable.patch
> drm-i915-Don-t-try-to-reference-the-fb-in-get_initia.patch
>
> and this patch:
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index 177714a9d778..778e7fa41c17 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2439,6 +2439,8 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
> return;
>
> if (intel_alloc_plane_obj(intel_crtc, plane_config)) {
> + intel_crtc->base.primary->state->crtc = &intel_crtc->base;
> + intel_crtc->base.primary->crtc = &intel_crtc->base;
> update_state_fb(intel_crtc->base.primary);
> return;
> }
> @@ -2469,6 +2471,8 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>
> drm_framebuffer_reference(c->primary->fb);
> intel_crtc->base.primary->fb = c->primary->fb;
> + intel_crtc->base.primary->state->crtc = &intel_crtc->base;
> + intel_crtc->base.primary->crtc = &intel_crtc->base;
> obj->frontbuffer_bits |= INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
> break;
> }
>
> which is a mash-up of:
>
> "drm/i915: Fix atomic state when reusing the firmware fb"
>
> and
>
> "drm/i915: Fixup legacy plane->crtc link for initial fb config"
>
> which you just sent out.
>
> I think that covers everything.
>
> josh
I've got an HDMI device from the laboratory. I'll help to test the solution.
--
Xi Ruoyao
School of Aerospace Science and Technology
Xidian University, Xi'an, China
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [git pull] drm fixes
@ 2015-03-25 23:32 ` Xi Ruoyao
0 siblings, 0 replies; 71+ messages in thread
From: Xi Ruoyao @ 2015-03-25 23:32 UTC (permalink / raw)
To: Josh Boyer, Daniel Vetter
Cc: Dave Airlie, Intel Graphics Development, Linus Torvalds,
Linux-Kernel@Vger. Kernel. Org, DRI mailing list
在 03/26/2015 03:40 AM, Josh Boyer 写道:
> On Wed, Mar 25, 2015 at 01:37:41PM -0400, Josh Boyer wrote:
>>>>>> Yeah that fail looks like we're freeing an fb that's still in use.
>>>>>> Hilarity happens and since that happens under console_lock at boot-up your
>>>>>> machine dies.
>>>>>>
>>>>>> Does that machine die the same way in drm-intel-nightly/linux-next?
>>>>> I'll try that a bit later today. Out of sheer curiosity, I folded
>>>>> commit5ba76c41e55c (drm/i915: Put update_state_fb() next to the fb
>>>>> update) into the patch above and kicked off a build. The theory is
>>>>> that we're picking up a bunch of other changes right in that range of
>>>>> commits, why not try one more. I'll let you know if that fixes
>>>>> anything. Otherwise, I'll try building drm-intel-nightly and/or
>>>>> linux-next after that.
>>>> The drm-intel-nightly build finished first. It boots without HDMI
>>>> plugged in, but it has pretty much the same splats as the previous
>>>> kernel. Confused. Full log here:
>>>>
>>>> https://jwboyer.fedorapeople.org/pub/intel-nightly.txt
>>>>
>>>> I don't have much hope for my other build.
>>> Yeah that's at least good news for the theory I've been cooking meanwhile.
>>> Can you try the below diff (on top of next/nightly)? For the current
>>> cherry-pick pile on top of 4.0-rc you'd need to prepend intel_crtc->base.
>>> to primary->...
>>>
>>> Thanks, Daniel
>>>
>>> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
>>> index ceb2e61b4c91..cb508542c6ab 100644
>>> --- a/drivers/gpu/drm/i915/intel_display.c
>>> +++ b/drivers/gpu/drm/i915/intel_display.c
>>> @@ -2594,6 +2594,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>>>
>>> primary->fb = &plane_config->fb->base;
>>> primary->state->crtc = &intel_crtc->base;
>>> + primary->crtc = &intel_crtc->base;
>>> update_state_fb(primary);
>>>
>>> return;
>>> @@ -2627,6 +2628,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>>> drm_framebuffer_reference(c->primary->fb);
>>> primary->fb = c->primary->fb;
>>> primary->state->crtc = &intel_crtc->base;
>>> + primary->crtc = &intel_crtc->base;
>>> update_state_fb(intel_crtc->base.primary);
>>> obj->frontbuffer_bits |= INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
>>> break;
>> Hey, that seems to do the trick on the NUC machine. Boots without
>> HDMI connected and there are no backtraces. Nice!
>>
>> Let me go and munge it around for a backport on top of -rc5 with the
>> rest of the pile and see if both the macbook and NUC machines work
>> then. Will be a bit for it to build.
> OK, that helped on all my machines I have. No backtraces and they all
> boot again as I would expect. For the record, here is what I have on
> top of -rc5:
>
> drm-Fixup-racy-refcounting-in-plane_force_disable.patch
> drm-i915-Don-t-try-to-reference-the-fb-in-get_initia.patch
>
> and this patch:
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index 177714a9d778..778e7fa41c17 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2439,6 +2439,8 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
> return;
>
> if (intel_alloc_plane_obj(intel_crtc, plane_config)) {
> + intel_crtc->base.primary->state->crtc = &intel_crtc->base;
> + intel_crtc->base.primary->crtc = &intel_crtc->base;
> update_state_fb(intel_crtc->base.primary);
> return;
> }
> @@ -2469,6 +2471,8 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>
> drm_framebuffer_reference(c->primary->fb);
> intel_crtc->base.primary->fb = c->primary->fb;
> + intel_crtc->base.primary->state->crtc = &intel_crtc->base;
> + intel_crtc->base.primary->crtc = &intel_crtc->base;
> obj->frontbuffer_bits |= INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
> break;
> }
>
> which is a mash-up of:
>
> "drm/i915: Fix atomic state when reusing the firmware fb"
>
> and
>
> "drm/i915: Fixup legacy plane->crtc link for initial fb config"
>
> which you just sent out.
>
> I think that covers everything.
>
> josh
I've got an HDMI device from the laboratory. I'll help to test the solution.
--
Xi Ruoyao
School of Aerospace Science and Technology
Xidian University, Xi'an, China
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [Intel-gfx] [git pull] drm fixes
2015-03-25 23:32 ` Xi Ruoyao
(?)
@ 2015-03-25 23:45 ` Xi Ruoyao
-1 siblings, 0 replies; 71+ messages in thread
From: Xi Ruoyao @ 2015-03-25 23:45 UTC (permalink / raw)
To: Josh Boyer, Daniel Vetter
Cc: Dave Airlie, Linus Torvalds, Linux-Kernel@Vger. Kernel. Org,
DRI mailing list, Intel Graphics Development, Xi Ruoyao
On 03/26/2015 at 07:32 AM, Xi Ruoyao wrote:
>
>
> 在 03/26/2015 03:40 AM, Josh Boyer 写道:
Sorry for these Chinese charactor. Thunderbird generated them
and I forgot to change.
>> On Wed, Mar 25, 2015 at 01:37:41PM -0400, Josh Boyer wrote:
>>>>>>> Yeah that fail looks like we're freeing an fb that's still in use.
>>>>>>> Hilarity happens and since that happens under console_lock at
>>>>>>> boot-up your
>>>>>>> machine dies.
>>>>>>>
>>>>>>> Does that machine die the same way in drm-intel-nightly/linux-next?
>>>>>> I'll try that a bit later today. Out of sheer curiosity, I folded
>>>>>> commit5ba76c41e55c (drm/i915: Put update_state_fb() next to the fb
>>>>>> update) into the patch above and kicked off a build. The theory is
>>>>>> that we're picking up a bunch of other changes right in that
>>>>>> range of
>>>>>> commits, why not try one more. I'll let you know if that fixes
>>>>>> anything. Otherwise, I'll try building drm-intel-nightly and/or
>>>>>> linux-next after that.
>>>>> The drm-intel-nightly build finished first. It boots without HDMI
>>>>> plugged in, but it has pretty much the same splats as the previous
>>>>> kernel. Confused. Full log here:
>>>>>
>>>>> https://jwboyer.fedorapeople.org/pub/intel-nightly.txt
>>>>>
>>>>> I don't have much hope for my other build.
>>>> Yeah that's at least good news for the theory I've been cooking
>>>> meanwhile.
>>>> Can you try the below diff (on top of next/nightly)? For the current
>>>> cherry-pick pile on top of 4.0-rc you'd need to prepend
>>>> intel_crtc->base.
>>>> to primary->...
>>>>
>>>> Thanks, Daniel
>>>>
>>>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>>>> b/drivers/gpu/drm/i915/intel_display.c
>>>> index ceb2e61b4c91..cb508542c6ab 100644
>>>> --- a/drivers/gpu/drm/i915/intel_display.c
>>>> +++ b/drivers/gpu/drm/i915/intel_display.c
>>>> @@ -2594,6 +2594,7 @@ intel_find_plane_obj(struct intel_crtc
>>>> *intel_crtc,
>>>>
>>>> primary->fb = &plane_config->fb->base;
>>>> primary->state->crtc = &intel_crtc->base;
>>>> + primary->crtc = &intel_crtc->base;
>>>> update_state_fb(primary);
>>>>
>>>> return;
>>>> @@ -2627,6 +2628,7 @@ intel_find_plane_obj(struct intel_crtc
>>>> *intel_crtc,
>>>> drm_framebuffer_reference(c->primary->fb);
>>>> primary->fb = c->primary->fb;
>>>> primary->state->crtc = &intel_crtc->base;
>>>> + primary->crtc = &intel_crtc->base;
>>>> update_state_fb(intel_crtc->base.primary);
>>>> obj->frontbuffer_bits |=
>>>> INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
>>>> break;
>>> Hey, that seems to do the trick on the NUC machine. Boots without
>>> HDMI connected and there are no backtraces. Nice!
>>>
>>> Let me go and munge it around for a backport on top of -rc5 with the
>>> rest of the pile and see if both the macbook and NUC machines work
>>> then. Will be a bit for it to build.
>> OK, that helped on all my machines I have. No backtraces and they all
>> boot again as I would expect. For the record, here is what I have on
>> top of -rc5:
>>
>> drm-Fixup-racy-refcounting-in-plane_force_disable.patch
>> drm-i915-Don-t-try-to-reference-the-fb-in-get_initia.patch
>>
>> and this patch:
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>> b/drivers/gpu/drm/i915/intel_display.c
>> index 177714a9d778..778e7fa41c17 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -2439,6 +2439,8 @@ intel_find_plane_obj(struct intel_crtc
>> *intel_crtc,
>> return;
>> if (intel_alloc_plane_obj(intel_crtc, plane_config)) {
>> + intel_crtc->base.primary->state->crtc = &intel_crtc->base;
>> + intel_crtc->base.primary->crtc = &intel_crtc->base;
>> update_state_fb(intel_crtc->base.primary);
>> return;
>> }
>> @@ -2469,6 +2471,8 @@ intel_find_plane_obj(struct intel_crtc
>> *intel_crtc,
>> drm_framebuffer_reference(c->primary->fb);
>> intel_crtc->base.primary->fb = c->primary->fb;
>> + intel_crtc->base.primary->state->crtc = &intel_crtc->base;
>> + intel_crtc->base.primary->crtc = &intel_crtc->base;
>> obj->frontbuffer_bits |=
>> INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
>> break;
>> }
>>
>> which is a mash-up of:
>>
>> "drm/i915: Fix atomic state when reusing the firmware fb"
>>
>> and
>>
>> "drm/i915: Fixup legacy plane->crtc link for initial fb config"
>>
>> which you just sent out.
>>
>> I think that covers everything.
>>
>> josh
> I've got an HDMI device from the laboratory. I'll help to test the
> solution.
>
At least, my machine boots well and there is no WARNINGs
in kernel log. I will do more tests.
--
Xi Ruoyao
School of Aerospace Science and Technology
Xidian University, Xi'an, China
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [Intel-gfx] [git pull] drm fixes
2015-03-25 23:32 ` Xi Ruoyao
@ 2015-03-26 8:41 ` Xi Ruoyao
-1 siblings, 0 replies; 71+ messages in thread
From: Xi Ruoyao @ 2015-03-26 8:41 UTC (permalink / raw)
To: Josh Boyer, Daniel Vetter
Cc: Dave Airlie, Linus Torvalds, Linux-Kernel@Vger. Kernel. Org,
DRI mailing list, Intel Graphics Development, Xi Ruoyao
On 03/26/2015 at 07:32 AM, Xi Ruoyao wrote:
> On 03/26/2015 at 03:40 AM, Josh Boyer wrote:
>> drm-Fixup-racy-refcounting-in-plane_force_disable.patch
>> drm-i915-Don-t-try-to-reference-the-fb-in-get_initia.patch
>>
>> and this patch:
I hide the patch since it has been managled by Thunderbird.
(BTW, who can tell me how to stop Thunderbird to replace Tabs to spaces?)
>> which is a mash-up of:
>>
>> "drm/i915: Fix atomic state when reusing the firmware fb"
>>
>> and
>>
>> "drm/i915: Fixup legacy plane->crtc link for initial fb config"
>>
>> which you just sent out.
>>
>> I think that covers everything.
>>
>> josh
> I've got an HDMI device from the laboratory. I'll help to test the
> solution.
>
I confirm that after applying those 3 patches, my machine boots fine mutiple
times WITH OR WITHOUT HDMI plugged in and there is no WARNINGs about
drm/i915 in kernel log. So I think these patches have successfully
solved the
problem, although maybe I am the one who makes some mistakes again......
--
Xi Ruoyao
School of Aerospace Science and Technology
Xidian University, Xi'an, China
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [git pull] drm fixes
@ 2015-03-26 8:41 ` Xi Ruoyao
0 siblings, 0 replies; 71+ messages in thread
From: Xi Ruoyao @ 2015-03-26 8:41 UTC (permalink / raw)
To: Josh Boyer, Daniel Vetter
Cc: Dave Airlie, Intel Graphics Development,
Linux-Kernel@Vger. Kernel. Org, DRI mailing list, Xi Ruoyao,
Linus Torvalds
On 03/26/2015 at 07:32 AM, Xi Ruoyao wrote:
> On 03/26/2015 at 03:40 AM, Josh Boyer wrote:
>> drm-Fixup-racy-refcounting-in-plane_force_disable.patch
>> drm-i915-Don-t-try-to-reference-the-fb-in-get_initia.patch
>>
>> and this patch:
I hide the patch since it has been managled by Thunderbird.
(BTW, who can tell me how to stop Thunderbird to replace Tabs to spaces?)
>> which is a mash-up of:
>>
>> "drm/i915: Fix atomic state when reusing the firmware fb"
>>
>> and
>>
>> "drm/i915: Fixup legacy plane->crtc link for initial fb config"
>>
>> which you just sent out.
>>
>> I think that covers everything.
>>
>> josh
> I've got an HDMI device from the laboratory. I'll help to test the
> solution.
>
I confirm that after applying those 3 patches, my machine boots fine mutiple
times WITH OR WITHOUT HDMI plugged in and there is no WARNINGs about
drm/i915 in kernel log. So I think these patches have successfully
solved the
problem, although maybe I am the one who makes some mistakes again......
--
Xi Ruoyao
School of Aerospace Science and Technology
Xidian University, Xi'an, China
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [Intel-gfx] [git pull] drm fixes
2015-03-25 8:54 ` Daniel Vetter
@ 2015-03-26 12:02 ` Jani Nikula
-1 siblings, 0 replies; 71+ messages in thread
From: Jani Nikula @ 2015-03-26 12:02 UTC (permalink / raw)
To: Daniel Vetter, Josh Boyer
Cc: Intel Graphics Development, Linux-Kernel@Vger. Kernel. Org,
DRI mailing list, Xi Ruoyao, Linus Torvalds
On Wed, 25 Mar 2015, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Tue, Mar 24, 2015 at 12:10:28PM -0400, Josh Boyer wrote:
>> OK, with that commit applied I no longer get the kref.h splat and the
>> NUC machine boots headless. I still see the backtrace below on both
>> the NUC and the macbook. I have a copy of it with drm.debug=0xff from
>> the NUC here:
>>
>> https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
>>
>> Getting better at least :).
>
> On top of what you currently have please also cherry-pick
>
> commit fb9981aa675eb7b398849915364916fd98833cfa
> Author: Damien Lespiau <damien.lespiau@intel.com>
> Date: Thu Feb 5 19:24:25 2015 +0000
>
> drm/i915: Fix atomic state when reusing the firmware fb
>
> from -next. Let's hope this terminates eventually ;-)
For posterity, I've picked this up for drm-intel-fixes. Thanks for all
the testing.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [Intel-gfx] [git pull] drm fixes
@ 2015-03-26 12:02 ` Jani Nikula
0 siblings, 0 replies; 71+ messages in thread
From: Jani Nikula @ 2015-03-26 12:02 UTC (permalink / raw)
To: Daniel Vetter, Josh Boyer
Cc: Xi Ruoyao, Intel Graphics Development, Linus Torvalds,
Linux-Kernel@Vger. Kernel. Org, DRI mailing list
On Wed, 25 Mar 2015, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Tue, Mar 24, 2015 at 12:10:28PM -0400, Josh Boyer wrote:
>> OK, with that commit applied I no longer get the kref.h splat and the
>> NUC machine boots headless. I still see the backtrace below on both
>> the NUC and the macbook. I have a copy of it with drm.debug=0xff from
>> the NUC here:
>>
>> https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
>>
>> Getting better at least :).
>
> On top of what you currently have please also cherry-pick
>
> commit fb9981aa675eb7b398849915364916fd98833cfa
> Author: Damien Lespiau <damien.lespiau@intel.com>
> Date: Thu Feb 5 19:24:25 2015 +0000
>
> drm/i915: Fix atomic state when reusing the firmware fb
>
> from -next. Let's hope this terminates eventually ;-)
For posterity, I've picked this up for drm-intel-fixes. Thanks for all
the testing.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [Intel-gfx] [git pull] drm fixes
2015-03-25 17:37 ` Josh Boyer
@ 2015-03-26 12:06 ` Jani Nikula
-1 siblings, 0 replies; 71+ messages in thread
From: Jani Nikula @ 2015-03-26 12:06 UTC (permalink / raw)
To: Josh Boyer, Daniel Vetter, Dave Airlie, Xi Ruoyao,
Linus Torvalds, Linux-Kernel@Vger. Kernel. Org, DRI mailing list,
Intel Graphics Development
On Wed, 25 Mar 2015, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> On Wed, Mar 25, 2015 at 1:17 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> On Wed, Mar 25, 2015 at 12:42:46PM -0400, Josh Boyer wrote:
>>> > I'll try that a bit later today. Out of sheer curiosity, I folded
>>> > commit5ba76c41e55c (drm/i915: Put update_state_fb() next to the fb
>>> > update) into the patch above and kicked off a build. The theory is
>>> > that we're picking up a bunch of other changes right in that range of
>>> > commits, why not try one more. I'll let you know if that fixes
>>> > anything. Otherwise, I'll try building drm-intel-nightly and/or
>>> > linux-next after that.
>>>
>>> The drm-intel-nightly build finished first. It boots without HDMI
>>> plugged in, but it has pretty much the same splats as the previous
>>> kernel. Confused. Full log here:
>>>
>>> https://jwboyer.fedorapeople.org/pub/intel-nightly.txt
>>>
>>> I don't have much hope for my other build.
>>
>> Yeah that's at least good news for the theory I've been cooking meanwhile.
>> Can you try the below diff (on top of next/nightly)? For the current
>> cherry-pick pile on top of 4.0-rc you'd need to prepend intel_crtc->base.
>> to primary->...
>>
>> Thanks, Daniel
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
>> index ceb2e61b4c91..cb508542c6ab 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -2594,6 +2594,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>>
>> primary->fb = &plane_config->fb->base;
>> primary->state->crtc = &intel_crtc->base;
>> + primary->crtc = &intel_crtc->base;
>> update_state_fb(primary);
>>
>> return;
>> @@ -2627,6 +2628,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>> drm_framebuffer_reference(c->primary->fb);
>> primary->fb = c->primary->fb;
>> primary->state->crtc = &intel_crtc->base;
>> + primary->crtc = &intel_crtc->base;
>> update_state_fb(intel_crtc->base.primary);
>> obj->frontbuffer_bits |= INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
>> break;
>
> Hey, that seems to do the trick on the NUC machine. Boots without
> HDMI connected and there are no backtraces. Nice!
I've picked this [1] up for drm-intel-fixes as well. Thanks for the
testing.
BR,
Jani.
[1] http://mid.gmane.org/1427304638-7897-1-git-send-email-daniel.vetter@ffwll.ch
--
Jani Nikula, Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [Intel-gfx] [git pull] drm fixes
@ 2015-03-26 12:06 ` Jani Nikula
0 siblings, 0 replies; 71+ messages in thread
From: Jani Nikula @ 2015-03-26 12:06 UTC (permalink / raw)
To: Josh Boyer, Daniel Vetter, Dave Airlie, Xi Ruoyao,
Linus Torvalds, Linux-Kernel@Vger. Kernel. Org, DRI mailing list,
Intel Graphics Development
On Wed, 25 Mar 2015, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> On Wed, Mar 25, 2015 at 1:17 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> On Wed, Mar 25, 2015 at 12:42:46PM -0400, Josh Boyer wrote:
>>> > I'll try that a bit later today. Out of sheer curiosity, I folded
>>> > commit5ba76c41e55c (drm/i915: Put update_state_fb() next to the fb
>>> > update) into the patch above and kicked off a build. The theory is
>>> > that we're picking up a bunch of other changes right in that range of
>>> > commits, why not try one more. I'll let you know if that fixes
>>> > anything. Otherwise, I'll try building drm-intel-nightly and/or
>>> > linux-next after that.
>>>
>>> The drm-intel-nightly build finished first. It boots without HDMI
>>> plugged in, but it has pretty much the same splats as the previous
>>> kernel. Confused. Full log here:
>>>
>>> https://jwboyer.fedorapeople.org/pub/intel-nightly.txt
>>>
>>> I don't have much hope for my other build.
>>
>> Yeah that's at least good news for the theory I've been cooking meanwhile.
>> Can you try the below diff (on top of next/nightly)? For the current
>> cherry-pick pile on top of 4.0-rc you'd need to prepend intel_crtc->base.
>> to primary->...
>>
>> Thanks, Daniel
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
>> index ceb2e61b4c91..cb508542c6ab 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -2594,6 +2594,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>>
>> primary->fb = &plane_config->fb->base;
>> primary->state->crtc = &intel_crtc->base;
>> + primary->crtc = &intel_crtc->base;
>> update_state_fb(primary);
>>
>> return;
>> @@ -2627,6 +2628,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>> drm_framebuffer_reference(c->primary->fb);
>> primary->fb = c->primary->fb;
>> primary->state->crtc = &intel_crtc->base;
>> + primary->crtc = &intel_crtc->base;
>> update_state_fb(intel_crtc->base.primary);
>> obj->frontbuffer_bits |= INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
>> break;
>
> Hey, that seems to do the trick on the NUC machine. Boots without
> HDMI connected and there are no backtraces. Nice!
I've picked this [1] up for drm-intel-fixes as well. Thanks for the
testing.
BR,
Jani.
[1] http://mid.gmane.org/1427304638-7897-1-git-send-email-daniel.vetter@ffwll.ch
--
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [Intel-gfx] [git pull] drm fixes
2015-03-02 16:53 ` Linus Torvalds
@ 2015-03-02 17:23 ` Daniel Vetter
0 siblings, 0 replies; 71+ messages in thread
From: Daniel Vetter @ 2015-03-02 17:23 UTC (permalink / raw)
To: Linus Torvalds
Cc: Dave Airlie, Daniel Vetter, Jani Nikula, Matt Roper,
Ander Conselvan de Oliveira, intel-gfx,
Linux Kernel Mailing List, DRI mailing list
On Mon, Mar 2, 2015 at 5:53 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Mon, Mar 2, 2015 at 1:04 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> And can you please attach a bactrace of the WARN in your patch, just to
>> double-check you blow up at the same spot?
>
> So the dmesg I attached had a backtrace for the new WARN_ONCE() (in
> addition to an unrelated(?) one from i915_gem_free_object()).
>
> Or did you mean a backtrace of the oops when things go wrong, when my
> patch is *not* applied? My first email had that with the kref.h
> warning from drm_framebuffer_reference, which is otherwise the same
> thing.
I've mixed things up with the other reporter which was full of the
subsequent oopses. But after I've sorted out why drm-intel-next
doesn't blow up the same way I see the bug now. Still baffled that we
underrun the refcount apparently since the same pile of legacy code +
atomic glue is used for the old modeset ioctl. But obviously something
is different, so still digging.
The gem_free_object backtrace is a completely unrelated issue. Fix for
that is in drm-intel-fixes and on the way to you:
commit 62e537f8d568347bbe4e00d7803a838750cdc618
Author: Rodrigo Vivi <rodrigo.vivi@intel.com>
Date: Tue Feb 24 13:37:54 2015 -0800
drm/i915: Fix frontbuffer false positve.
If that one doesn't help please scream ;-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [Intel-gfx] [git pull] drm fixes
@ 2015-03-02 17:23 ` Daniel Vetter
0 siblings, 0 replies; 71+ messages in thread
From: Daniel Vetter @ 2015-03-02 17:23 UTC (permalink / raw)
To: Linus Torvalds
Cc: intel-gfx, Linux Kernel Mailing List, DRI mailing list, Daniel Vetter
On Mon, Mar 2, 2015 at 5:53 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Mon, Mar 2, 2015 at 1:04 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> And can you please attach a bactrace of the WARN in your patch, just to
>> double-check you blow up at the same spot?
>
> So the dmesg I attached had a backtrace for the new WARN_ONCE() (in
> addition to an unrelated(?) one from i915_gem_free_object()).
>
> Or did you mean a backtrace of the oops when things go wrong, when my
> patch is *not* applied? My first email had that with the kref.h
> warning from drm_framebuffer_reference, which is otherwise the same
> thing.
I've mixed things up with the other reporter which was full of the
subsequent oopses. But after I've sorted out why drm-intel-next
doesn't blow up the same way I see the bug now. Still baffled that we
underrun the refcount apparently since the same pile of legacy code +
atomic glue is used for the old modeset ioctl. But obviously something
is different, so still digging.
The gem_free_object backtrace is a completely unrelated issue. Fix for
that is in drm-intel-fixes and on the way to you:
commit 62e537f8d568347bbe4e00d7803a838750cdc618
Author: Rodrigo Vivi <rodrigo.vivi@intel.com>
Date: Tue Feb 24 13:37:54 2015 -0800
drm/i915: Fix frontbuffer false positve.
If that one doesn't help please scream ;-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [Intel-gfx] [git pull] drm fixes
2015-03-02 9:44 ` Paul Bolle
@ 2015-03-02 10:33 ` Daniel Vetter
0 siblings, 0 replies; 71+ messages in thread
From: Daniel Vetter @ 2015-03-02 10:33 UTC (permalink / raw)
To: Paul Bolle
Cc: Linus Torvalds, Dave Airlie, intel-gfx,
Linux Kernel Mailing List, DRI mailing list, Daniel Vetter
On Mon, Mar 02, 2015 at 10:44:16AM +0100, Paul Bolle wrote:
> On Sat, 2015-02-28 at 22:08 -0800, Linus Torvalds wrote:
> > Hmm. 3.19 works fine, even if it ends up spewing
> >
> > WARNING: CPU: 0 PID: 6 at drivers/gpu/drm/drm_irq.c:1121
> > drm_wait_one_vblank+0x125/0x130()
> > vblank not available on crtc 1, ret=-22
> >
> > a lot.
>
> For what it's worth, that stream of WARNINGs was reported for v3.19-rc1
> in http://lkml.kernel.org/r/20150131211609.GA3710@yulia-desktop .
>
> Commit f9b61ff6bce9 ("drm/i915: Push vblank enable/disable past
> encoder->enable/disable") silenced it again in v4.0-rc1. I guess that
> commit will end up in v3.19-stable in due time.
Yeah we've forgotten to tag it as stable (it missed 3.19 by a notch and
we didn't add teh tag when moving it to the 3.20^W4.0 branch) but Jani
just sent out the mail for that.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 71+ messages in thread
end of thread, other threads:[~2015-03-26 12:07 UTC | newest]
Thread overview: 71+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-03-20 21:49 [git pull] drm fixes Dave Airlie
2015-03-20 21:49 ` Dave Airlie
2015-03-21 17:50 ` Linus Torvalds
2015-03-23 15:33 ` Josh Boyer
2015-03-23 15:33 ` Josh Boyer
2015-03-23 18:34 ` Josh Boyer
2015-03-23 18:34 ` Josh Boyer
2015-03-24 7:32 ` [Intel-gfx] " Daniel Vetter
2015-03-24 7:32 ` Daniel Vetter
2015-03-24 13:15 ` [Intel-gfx] " Josh Boyer
2015-03-24 13:15 ` Josh Boyer
2015-03-24 13:40 ` [Intel-gfx] " Daniel Vetter
2015-03-24 13:40 ` Daniel Vetter
2015-03-24 13:57 ` Josh Boyer
2015-03-24 13:57 ` Josh Boyer
2015-03-24 14:22 ` [Intel-gfx] " Josh Boyer
2015-03-24 14:22 ` Josh Boyer
2015-03-24 14:34 ` [Intel-gfx] " Daniel Vetter
2015-03-24 14:34 ` Daniel Vetter
2015-03-24 14:46 ` Josh Boyer
2015-03-24 16:10 ` Josh Boyer
2015-03-24 16:10 ` Josh Boyer
2015-03-24 16:48 ` [Intel-gfx] " Daniel Vetter
2015-03-24 16:48 ` Daniel Vetter
2015-03-24 16:49 ` [Intel-gfx] " Daniel Vetter
2015-03-24 16:54 ` Josh Boyer
2015-03-25 3:49 ` Xi Ruoyao
2015-03-25 3:49 ` Xi Ruoyao
2015-03-25 8:54 ` [Intel-gfx] " Daniel Vetter
2015-03-25 8:54 ` Daniel Vetter
2015-03-25 13:11 ` [Intel-gfx] " Josh Boyer
2015-03-25 14:00 ` Daniel Vetter
2015-03-25 14:00 ` Daniel Vetter
2015-03-25 14:56 ` [Intel-gfx] " Xi Ruoyao
2015-03-25 14:56 ` Xi Ruoyao
2015-03-25 15:12 ` [Intel-gfx] " Xi Ruoyao
2015-03-25 15:12 ` Xi Ruoyao
2015-03-25 15:19 ` [Intel-gfx] " Jani Nikula
2015-03-25 15:19 ` Jani Nikula
2015-03-25 15:26 ` Takashi Iwai
2015-03-25 15:26 ` Takashi Iwai
2015-03-25 15:37 ` Josh Boyer
2015-03-25 15:50 ` Daniel Vetter
2015-03-25 15:50 ` Daniel Vetter
2015-03-25 15:53 ` Josh Boyer
2015-03-25 15:53 ` Josh Boyer
2015-03-25 16:42 ` [Intel-gfx] " Josh Boyer
2015-03-25 16:42 ` Josh Boyer
2015-03-25 17:17 ` [Intel-gfx] " Daniel Vetter
2015-03-25 17:17 ` Daniel Vetter
2015-03-25 17:37 ` [Intel-gfx] " Josh Boyer
2015-03-25 17:37 ` Josh Boyer
2015-03-25 19:40 ` [Intel-gfx] " Josh Boyer
2015-03-25 19:40 ` Josh Boyer
2015-03-25 23:32 ` [Intel-gfx] " Xi Ruoyao
2015-03-25 23:32 ` Xi Ruoyao
2015-03-25 23:45 ` [Intel-gfx] " Xi Ruoyao
2015-03-26 8:41 ` Xi Ruoyao
2015-03-26 8:41 ` Xi Ruoyao
2015-03-26 12:06 ` [Intel-gfx] " Jani Nikula
2015-03-26 12:06 ` Jani Nikula
2015-03-26 12:02 ` Jani Nikula
2015-03-26 12:02 ` Jani Nikula
2015-03-24 1:41 ` Dave Jones
2015-03-25 8:56 ` Daniel Vetter
2015-03-25 8:56 ` Daniel Vetter
2015-03-25 14:34 ` Dave Jones
2015-03-25 14:34 ` Dave Jones
-- strict thread matches above, loose matches on Subject: below --
2015-02-27 4:42 Dave Airlie
2015-03-01 5:40 ` Linus Torvalds
2015-03-01 6:08 ` Linus Torvalds
2015-03-01 7:27 ` Linus Torvalds
2015-03-01 20:35 ` Linus Torvalds
2015-03-01 21:00 ` Linus Torvalds
2015-03-02 1:59 ` Linus Torvalds
2015-03-02 9:04 ` Daniel Vetter
2015-03-02 16:53 ` Linus Torvalds
2015-03-02 17:23 ` [Intel-gfx] " Daniel Vetter
2015-03-02 17:23 ` Daniel Vetter
2015-03-02 9:44 ` Paul Bolle
2015-03-02 10:33 ` [Intel-gfx] " Daniel Vetter
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.