From nobody Mon Feb 27 20:02:46 2023 X-Original-To: fs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PQWd33TWBz3vYJM for ; Mon, 27 Feb 2023 20:02:47 +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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PQWd31NTsz4GcZ for ; Mon, 27 Feb 2023 20:02:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1677528167; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=rESW55LG/UPTl6FFvX6/vhh9qpEZnUE1nVomY8PpvlM=; b=yrHr9XCzpSA3sZDIxJuJaNmVLaA0LeVufSJQ0y0W2CFtbOrGPpV8rDGELH/IqeO2r6CNfE pO7Z9/p5QN0JkZiernv5RVOG97v2SY0A5ECXnfT2guzFYO0f46pBuZueWLsgm/plfKBKRY xJpQco1q/rmckbP7Rb7AIOXJUGFn40QvVf00S+oAz6qlP/My97ySnkbPPhiHfudPJlEQgz X5h8Wxc16ze/XpgGPzuq92yX5srIEIHs7FF/3fzxDMWtuS2hJMhsE6o0zZFqMVvcL3/0kG j/3yfAgXktdJ+H1C1qyBe6QMHhfrmP+YfMYVBgTB7lD9vgJKYqZ2Pm4HLmMAvw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1677528167; a=rsa-sha256; cv=none; b=CHroxskw9qs4JwT2Ki8WrVQueh4iyNgCrxX3OrVsJ1odImstJITTxewy6BEPwedO8lAw0l 0Yk9XspIuiV3P0CmnSpadntSUZJv67o2F/ECvFfmsbisgrY9s5D5IQ913cDMj7rWzSQu+1 WnCBKsmOtPrzjIfRDCpNF3Q25B/j30r7Y1kmNl8KYnmXIKbRW4GES4EWCaZcRpaysO+jRC BBFLNFg5kzHmACDln8+oYvsn2FOLDKImMhfyO4uWspOd7Wla+tGT0R2Ulc5NAqCWln9r97 WvuNiCOW3dmrRM9NaYrcxfdJ04Ep5lmBG+EYNo07NSZjkUfbyQNKcuIyicUitQ== 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 4PQWd30RwBzfQg for ; Mon, 27 Feb 2023 20:02:47 +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 31RK2la1003024 for ; Mon, 27 Feb 2023 20:02:47 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 31RK2loP003023 for fs@FreeBSD.org; Mon, 27 Feb 2023 20:02:47 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: fs@FreeBSD.org Subject: [Bug 267028] kernel panics when booting with both (zfs,ko or vboxnetflt,ko or acpi_wmi.ko) and amdgpu.ko Date: Mon, 27 Feb 2023 20:02:46 +0000 X-Bugzilla-Reason: AssignedTo CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 13.1-RELEASE X-Bugzilla-Keywords: crash, needs-qa X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: marklmi26-fbsd@yahoo.com X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: fs@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? maintainer-feedback? 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 List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D267028 --- Comment #86 from Mark Millard --- (In reply to George Mitchell from comment #85) Where does dumpdev point for "test disk"? Someplace also on the "test disk" that a "regular disk" boot would not change? If yes, the first boot of the "test disk" after the crash should have picked up the dump information, even if the "regular disk" was booted between times. But if the dumpdev place is common to both types of boot, then the regular disk boot would have processed the dump. likely using a different /var/crash/ place to store things. Another question would be if there is sufficient room for /var/crash/ to contain the saved vmcore.* and related files. Yet another question is if the test disk has /usr/local/bin/gdb installed vs. not. ( When present, /usr/local/bin/gdb is used to provides one of the forms of backtrace, the one with source file references and line numbers and such. Much nicer to deal with.) If a vmcore.* was saved but some related information was not for some reason, it should be possible to have the related information produced based on the vmcore.* file. Side note: In case it is relevant, I'll note that defining dumpdev in /boot/loader.conf in a form the kernel chan handle, instead of in /etc/rc.conf , can be used to allow the system to produce dumps for earlier crashes. (But I'm guessing the crash was not that earliy to need such.) --=20 You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.=