From owner-freebsd-multimedia@freebsd.org Tue Oct 13 20:44:24 2020 Return-Path: Delivered-To: freebsd-multimedia@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4648E44B311 for ; Tue, 13 Oct 2020 20:44:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4C9nbD1DQkz4GW7 for ; Tue, 13 Oct 2020 20:44:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 2A1D344B055; Tue, 13 Oct 2020 20:44:24 +0000 (UTC) Delivered-To: multimedia@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 29E4344B310 for ; Tue, 13 Oct 2020 20:44:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C9nbD0LXsz4GPm for ; Tue, 13 Oct 2020 20:44:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id E37A82368A for ; Tue, 13 Oct 2020 20:44:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 09DKiNdv084759 for ; Tue, 13 Oct 2020 20:44:23 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 09DKiNv5084758 for multimedia@FreeBSD.org; Tue, 13 Oct 2020 20:44:23 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: multimedia@FreeBSD.org Subject: [Bug 250248] 12.2-RC2 kernel reboots with hw.acpi.debug=1 after a warm reboot. Date: Tue, 13 Oct 2020 20:44:24 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: Unspecified X-Bugzilla-Keywords: panic X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: mav@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: multimedia@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2020 20:44:24 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D250248 --- Comment #12 from Alexander Motin --- About the first patch adding shutdown handling I think it is an overkill for workaround and wrong approach in general, since there is no reason to detach the device on shutdown. It is designed to flush some caches and do alike things, and I know only one kind of devices detaching on shutdown -- USB, though I don't know why Hans done it that way. The second patch moving enabling UNSOL looks better to me, since I don't see what good for us could those message be before we even probe the codecs, not mentioning attaching them. Theoretically, if we ever implement codec hot-p= lug (for which I've never had a hardware), it would be required to better handle UNSOL events during the CODEC probe, since it may happen during run time.=20 Meanwhile if this patch works -- great, but generally it looks like a parti= al case to me, since hdac_unsolq_flush() already checks for sc->codecs[cad].de= v to be NULL, that is assigned the last by the probe loop inside hdac_attach2().= So it may just affect some timings, not really fix the issue. --=20 You are receiving this mail because: You are the assignee for the bug.=