new computer, strange usb messages at boot

[Konstantin Belousov]

On Fri, Feb 19, 2016 at 11:19:51PM -0600, Larry Rosenman wrote:
> Does any of this look weird?  What can I provide to help?

> Sleeping on "acmtx" with the following non-sleepable locks held:
> exclusive sleep mutex intr sources (intr sources) r = 0 (0xffffffff81c7f630) locked @ /usr/src/sys/x86/x86/intr_machdep.c:549
> stack backtrace:
> #0 0xffffffff80a7f790 at witness_debugger+0x70
> #1 0xffffffff80a80aa7 at witness_warn+0x3d7
> #2 0xffffffff80a2e26d at _sleep+0x6d
> #3 0xffffffff80399ff8 at AcpiOsAcquireMutex+0xc8
> #4 0xffffffff8036891a at AcpiUtAcquireMutex+0x3a
> #5 0xffffffff80355f2b at AcpiExEnterInterpreter+0xb
> #6 0xffffffff8035a2fb at AcpiNsEvaluate+0x1cb
> #7 0xffffffff8035d7b4 at AcpiEvaluateObject+0x174
> #8 0xffffffff8039ac0d at acpi_GetInteger+0x3d
> #9 0xffffffff80f94c01 at dmar_find_hpet+0x81
> #10 0xffffffff80f9d54d at iommu_map_msi_intr+0x2d
> #11 0xffffffff80fb2f91 at msi_map+0x171
> #12 0xffffffff80e73035 at hpet_remap_intr+0xb5
> #13 0xffffffff80fb2627 at msi_assign_cpu+0x1c7
> #14 0xffffffff80fa9733 at intr_shuffle_irqs+0x73
> #15 0xffffffff809c3a38 at mi_startup+0x108
> #16 0xffffffff802fb02c at btext+0x2c
> lock order reversal: (Giant after non-sleepable)
>  1st 0xffffffff81c7f630 intr sources (intr sources) @ /usr/src/sys/x86/x86/intr_machdep.c:549
>  2nd 0xffffffff81cd4d60 Giant (Giant) @ /usr/src/sys/kern/kern_synch.c:244
> stack backtrace:
> #0 0xffffffff80a7f790 at witness_debugger+0x70
> #1 0xffffffff80a7f691 at witness_checkorder+0xTrying to mount root from zfs:zroot/ROOT/default []...
> e71
> #2 0xffffffff80a06f94 at __mtx_lock_flags+0xa4
> #3 0xffffffff80a2e5ba at _sleep+0x3ba
> #4 0xffffffff80399ff8 at AcpiOsAcquireMutex+0xc8
> #5 0xffffffff8036891a at AcpiUtAcquireMutex+0x3a
> #6 0xffffffff80355f2b at AcpiExEnterInterpreter+0xb
> #7 0xffffffff8035a2fb at AcpiNsEvaluate+0x1cb
> #8 0xffffffff8035d7b4 at AcpiEvaluateObject+0x174
> #9 0xffffffff8039ac0d at acpi_GetInteger+0x3d
> #10 0xffffffff80f94c01 at dmar_find_hpet+0x81
> #11 0xffffffff80f9d54d at iommu_map_msi_intr+0x2d
> #12 0xffffffff80fb2f91 at msi_map+0x171
> #13 0xffffffff80e73035 at hpet_remap_intr+0xb5
> #14 0xffffffff80fb2627 at msi_assign_cpu+0x1c7
> #15 0xffffffff80fa9733 at intr_shuffle_irqs+0x73
> #16 0xffffffff809c3a38 at mi_startup+0x108
> #17 0xffffffff802fb02c at btext+0x2c

For these two LORs, please try the following patch. Apparently
acpi_GetInteger() might get acpi lock.  Patch also modernizes /dev/hpet
creation.

Just patch and boot, the LOR messages should go away as the only change
in behaviour.

diff --git a/sys/dev/acpica/acpi_hpet.c b/sys/dev/acpica/acpi_hpet.c
index 1b5a161..76fbd5a 100644
--- a/sys/dev/acpica/acpi_hpet.c
+++ b/sys/dev/acpica/acpi_hpet.c
@@ -85,6 +85,7 @@ struct hpet_softc {
 	struct resource		*intr_res;
 	void			*intr_handle;
 	ACPI_HANDLE		handle;
+	uint32_t		acpi_uid;
 	uint64_t		freq;
 	uint32_t		caps;
 	struct timecounter	tc;
@@ -295,6 +296,15 @@ hpet_intr(void *arg)
 	return (FILTER_STRAY);
 }
 
+uint32_t
+hpet_get_uid(device_t dev)
+{
+	struct hpet_softc *sc;
+
+	sc = device_get_softc(dev);
+	return (sc->acpi_uid);
+}
+
 static ACPI_STATUS
 hpet_find(ACPI_HANDLE handle, UINT32 level, void *context,
     void **status)
@@ -422,8 +432,9 @@ hpet_attach(device_t dev)
 {
 	struct hpet_softc *sc;
 	struct hpet_timer *t;
+	struct make_dev_args mda;
 	int i, j, num_msi, num_timers, num_percpu_et, num_percpu_t, cur_cpu;
-	int pcpu_master;
+	int pcpu_master, error;
 	static int maxhpetet = 0;
 	uint32_t val, val2, cvectors, dvectors;
 	uint16_t vendor, rev;
@@ -745,11 +756,16 @@ hpet_attach(device_t dev)
 			maxhpetet++;
 		}
 	}
-
-	sc->pdev = make_dev(&hpet_cdevsw, 0, UID_ROOT, GID_WHEEL,
-	    0600, "hpet%d", device_get_unit(dev));
-	if (sc->pdev) {
-		sc->pdev->si_drv1 = sc;
+	acpi_GetInteger(sc->handle, "_UID", &sc->acpi_uid);
+
+	make_dev_args_init(&mda);
+	mda.mda_devsw = &hpet_cdevsw;
+	mda.mda_uid = UID_ROOT;
+	mda.mda_gid = GID_WHEEL;
+	mda.mda_mode = 0600;
+	mda.mda_si_drv1 = sc;
+	error = make_dev_s(&mda, &sc->pdev, "hpet%d", device_get_unit(dev));
+	if (error == 0) {
 		sc->mmap_allow = 1;
 		TUNABLE_INT_FETCH("hw.acpi.hpet.mmap_allow",
 		    &sc->mmap_allow);
@@ -766,9 +782,10 @@ hpet_attach(device_t dev)
 		    OID_AUTO, "mmap_allow_write",
 		    CTLFLAG_RW, &sc->mmap_allow_write, 0,
 		    "Allow userland write to the HPET register space");
-	} else
-		device_printf(dev, "could not create /dev/hpet%d\n",
-		    device_get_unit(dev));
+	} else {
+		device_printf(dev, "could not create /dev/hpet%d, error %d\n",
+		    device_get_unit(dev), error);
+	}
 
 	return (0);
 }
diff --git a/sys/dev/acpica/acpivar.h b/sys/dev/acpica/acpivar.h
index 4f601c9..4df83d5 100644
--- a/sys/dev/acpica/acpivar.h
+++ b/sys/dev/acpica/acpivar.h
@@ -441,6 +441,8 @@ int		acpi_wakeup_machdep(struct acpi_softc *sc, int state,
 int		acpi_table_quirks(int *quirks);
 int		acpi_machdep_quirks(int *quirks);
 
+uint32_t	hpet_get_uid(device_t dev);
+
 /* Battery Abstraction. */
 struct acpi_battinfo;
 
diff --git a/sys/x86/iommu/intel_drv.c b/sys/x86/iommu/intel_drv.c
index 47588af..d2197ff 100644
--- a/sys/x86/iommu/intel_drv.c
+++ b/sys/x86/iommu/intel_drv.c
@@ -826,13 +826,9 @@ dmar_find_nonpci(u_int id, u_int entry_type, uint16_t *rid)
 struct dmar_unit *
 dmar_find_hpet(device_t dev, uint16_t *rid)
 {
-	ACPI_HANDLE handle;
-	uint32_t hpet_id;
 
-	handle = acpi_get_handle(dev);
-	if (ACPI_FAILURE(acpi_GetInteger(handle, "_UID", &hpet_id)))
-		return (NULL);
-	return (dmar_find_nonpci(hpet_id, ACPI_DMAR_SCOPE_TYPE_HPET, rid));
+	return (dmar_find_nonpci(hpet_get_uid(dev), ACPI_DMAR_SCOPE_TYPE_HPET,
+	    rid));
 }
 
 struct dmar_unit *