Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Panic with drm-next on Thinkpad T460s (Skylake, Intel HD Graphics 520) when undocking from Lenovo docking station #159

Open
raw-bin opened this issue Jul 15, 2017 · 3 comments

Comments

@raw-bin
Copy link

raw-bin commented Jul 15, 2017

Hi.

I experience this panic frequently when undocking my Thinkpad T460s from it's Lenovo docking station. Prior to the undock I was using xrandr to get video output to an external monitor connected to the dock.

Relevant details are as under.

  1. Links to pics showing the panic and the backtrace:
  • This is a link to a pic showing the panic log.
  • This is a link to a pic showing the backtrace.
  1. Output of uname -a:
    FreeBSD gene 12.0-CURRENT FreeBSD 12.0-CURRENT #2 ff9c7fc1f1a(drm-next)-dirty: Fri Jul 14 21:29:44 BST 2017 robin@gene:/usr/obj/usr/src/sys/GENERIC amd64

  2. The kernel is drm-next as of yesterday built with the bog standard GENERIC configuration. The dirty indication is because I have the following patch in place which was needed in order for suspend-resume to work correctly as reported here:

diff --git a/sys/modules/drm/i915/i915kmsfw/skldmc/Makefile b/sys/modules/drm/i915/i915kmsfw/skldmc/Makefile
index d6c389c24d8..c066a25daae 100644
--- a/sys/modules/drm/i915/i915kmsfw/skldmc/Makefile
+++ b/sys/modules/drm/i915/i915kmsfw/skldmc/Makefile
@@ -1,7 +1,7 @@
 # $FreeBSD$
 
-KMOD   = i915_skl_dmc_ver1_26_bin
-NAME   = i915/skl_dmc_ver1_26.bin
-IMG    = skl_dmc_ver1_26
+KMOD   = i915_skl_dmc_ver1_bin
+NAME   = i915/skl_dmc_ver1.bin
+IMG    = skl_dmc_ver1
 
 .include <bsd.kmod.mk>
diff --git a/sys/modules/drm/i915/i915kmsfw/sklguc/Makefile b/sys/modules/drm/i915/i915kmsfw/sklguc/Makefile
index 509b6e2b795..b787d2d9540 100644
--- a/sys/modules/drm/i915/i915kmsfw/sklguc/Makefile
+++ b/sys/modules/drm/i915/i915kmsfw/sklguc/Makefile
@@ -1,6 +1,6 @@
 # $FreeBSD$
 
-KMOD   = i915_skl_guc_ver6_1_bin
-NAME   = i915/skl_guc_ver6_1.bin
-IMG    = skl_guc_ver6_1
+KMOD   = i915_skl_guc_ver4_bin
+NAME   = i915/skl_guc_ver4.bin
+IMG    = skl_guc_ver4
 .include <bsd.kmod.mk>

  1. rc.conf contents
clear_tmp_enable="YES"
sendmail_enable="NONE"
hostname="gene"
keymap="uk.capsctrl.kbd"
ifconfig_em0="DHCP"
sshd_enable="YES"
ntpd_enable="YES"
powerd_enable="YES"
powerd_flags="-a hiadaptive -b adaptive -i 75 -r 85 -p 500"
performance_cx_lowest="Cmax"
economy_cx_lowest="Cmax"
# Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable
dumpdev="AUTO"
zfs_enable="YES"
kld_list="i915kms"
dbus_enable="YES"
hald_enable="YES"
#slim_enable="YES"
gdm_enable="YES"
gnome_enable="YES"
webcamd_enable="YES"
wlans_iwm0="wlan0"
ifconfig_wlan0="WPA SYNCDHCP"
linux_enable="YES"
  1. loader.conf contents
kern.geom.label.disk_ident.enable="0"
kern.geom.label.gptid.enable="0"
zfs_load="YES"
cuse_load="YES"
if_iwm_load="YES"
iwm8000Cfw_load="YES"
hw.pci.do_power_nodriver=3
drm.i915.enable_rc6=7
hw.snd.latency=7
hint.pcm.0.buffersize=65536
hint.pcm.1.buffersize=65536
hint.pcm.2.buffersize=65536
hw.snd.feeder_buffersize=65536
kern.vty=vt
fusefs_load="YES"

  1. Output of pciconf -lv:
hostb0@pci0:0:0:0:      class=0x060000 card=0x223317aa chip=0x19048086 rev=0x08 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = 'Skylake Host Bridge/DRAM Registers'
    class      = bridge
    subclass   = HOST-PCI
vgapci0@pci0:0:2:0:     class=0x030000 card=0x223317aa chip=0x19168086 rev=0x07 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = 'HD Graphics 520'
    class      = display
    subclass   = VGA
none0@pci0:0:8:0:       class=0x088000 card=0x223317aa chip=0x19118086 rev=0x00 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = 'Skylake Gaussian Mixture Model'
    class      = base peripheral
xhci0@pci0:0:20:0:      class=0x0c0330 card=0x223317aa chip=0x9d2f8086 rev=0x21 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = 'Sunrise Point-LP USB 3.0 xHCI Controller'
    class      = serial bus
    subclass   = USB
none1@pci0:0:20:2:      class=0x118000 card=0x223317aa chip=0x9d318086 rev=0x21 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = 'Sunrise Point-LP Thermal subsystem'
    class      = dasp
none2@pci0:0:22:0:      class=0x078000 card=0x223317aa chip=0x9d3a8086 rev=0x21 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = 'Sunrise Point-LP CSME HECI'
    class      = simple comms
none3@pci0:0:22:3:      class=0x070002 card=0x223317aa chip=0x9d3d8086 rev=0x21 hdr=0x00
    vendor     = 'Intel Corporation'
    class      = simple comms
    subclass   = UART
ahci0@pci0:0:23:0:      class=0x010601 card=0x223317aa chip=0x9d038086 rev=0x21 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = 'Sunrise Point-LP SATA Controller [AHCI mode]'
    class      = mass storage
    subclass   = SATA
pcib1@pci0:0:28:0:      class=0x060400 card=0x223317aa chip=0x9d108086 rev=0xf1 hdr=0x01
    vendor     = 'Intel Corporation'
    class      = bridge
    subclass   = PCI-PCI
pcib2@pci0:0:28:2:      class=0x060400 card=0x223317aa chip=0x9d128086 rev=0xf1 hdr=0x01
    vendor     = 'Intel Corporation'
    class      = bridge
    subclass   = PCI-PCI
isab0@pci0:0:31:0:      class=0x060100 card=0x223317aa chip=0x9d488086 rev=0x21 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = 'Sunrise Point-LP LPC Controller'
    class      = bridge
    subclass   = PCI-ISA
none4@pci0:0:31:2:      class=0x058000 card=0x223317aa chip=0x9d218086 rev=0x21 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = 'Sunrise Point-LP PMC'
    class      = memory
hdac0@pci0:0:31:3:      class=0x040300 card=0x223317aa chip=0x9d708086 rev=0x21 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = 'Sunrise Point-LP HD Audio'
    class      = multimedia
    subclass   = HDA
none5@pci0:0:31:4:      class=0x0c0500 card=0x223317aa chip=0x9d238086 rev=0x21 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = 'Sunrise Point-LP SMBus'
    class      = serial bus
    subclass   = SMBus
em0@pci0:0:31:6:        class=0x020000 card=0x223317aa chip=0x156f8086 rev=0x21 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = 'Ethernet Connection I219-LM'
    class      = network
    subclass   = ethernet
none6@pci0:2:0:0:       class=0xff0000 card=0x223317aa chip=0x522a10ec rev=0x01 hdr=0x00
    vendor     = 'Realtek Semiconductor Co., Ltd.'
    device     = 'RTS522A PCI Express Card Reader'
iwm0@pci0:4:0:0:        class=0x028000 card=0x01308086 chip=0x24f38086 rev=0x3a hdr=0x00
    vendor     = 'Intel Corporation'
    device     = 'Wireless 8260'
    class      = network

Please let me know if any other details would help. Any help/guidance graciously appreciated.

Cheers.

@raw-bin
Copy link
Author

raw-bin commented Jul 15, 2017

There's this code from pfs_add_node() at sys/fs/pseudofs/pseudofs.c:108:

#ifdef INVARIANTS
	/* XXX no locking! */
	if (pn->pn_type == pfstype_procdir)
		for (iter = parent; iter != NULL; iter = iter->pn_parent)
			KASSERT(iter->pn_type != pfstype_procdir,
			    ("%s(): nested process directories", __func__));

I wonder whether that has a bearing on the problem ? The GENERIC conf enables INVARIANTS.

@raw-bin raw-bin changed the title Panic with drm-next on Thinkpad T460s (Intel HD 560) when undocking from Lenovo docking station Panic with drm-next on Thinkpad T460s (Skylake, Intel HD Graphics 520) when undocking from Lenovo docking station Jul 15, 2017
iotamudelta pushed a commit that referenced this issue Jul 17, 2017
This resolves two 'zfs recv' issues. First, when receiving into an
existing filesystem, a snapshot created during the receive process is
not added to the guid->dataset map for the stream, resulting in failed
lookups for deduped streams when a WRITE_BYREF record refers to a
snapshot received earlier in the stream. Second, the newly created
snapshot was also not set properly, referencing the snapshot before the
new receiving dataset rather than the existing filesystem.

Closes #159

Reviewed by: Matthew Ahrens <[email protected]>
Reviewed by: Dan Kimmel <[email protected]>
Author: Chris Williamson <[email protected]>

openzfs/openzfs@b09697c
@valpackett
Copy link

You can try GENERIC-NODEBUG to avoid assertion panics. Of course they should be actually fixed though…

@raw-bin
Copy link
Author

raw-bin commented Jul 23, 2017

@myfreeweb Thanks. I commented out the code block referenced above and haven't had panics any more. Agree that a proper fix is preferable. I'll keep this open for the moment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants