From owner-freebsd-current@freebsd.org Sat Feb 20 12:04:07 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7AE0FAAFD76 for ; Sat, 20 Feb 2016 12:04:07 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 253E21111 for ; Sat, 20 Feb 2016 12:04:06 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u1KC41rU042020 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sat, 20 Feb 2016 14:04:02 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u1KC41rU042020 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u1KC4129042019 for freebsd-current@freebsd.org; Sat, 20 Feb 2016 14:04:01 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 20 Feb 2016 14:04:01 +0200 From: Konstantin Belousov To: freebsd-current@freebsd.org Subject: Re: new computer, strange usb messages at boot Message-ID: <20160220120401.GA91220@kib.kiev.ua> References: <20160220051951.GA47875@lrosenman-dell.lerctr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160220051951.GA47875@lrosenman-dell.lerctr.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2016 12:04:07 -0000 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 *