Date: Sat, 20 Feb 2016 14:04:01 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: freebsd-current@freebsd.org Subject: Re: new computer, strange usb messages at boot Message-ID: <20160220120401.GA91220@kib.kiev.ua> In-Reply-To: <20160220051951.GA47875@lrosenman-dell.lerctr.org> References: <20160220051951.GA47875@lrosenman-dell.lerctr.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 *
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160220120401.GA91220>