From nobody Mon Mar 25 08:57:14 2024 X-Original-To: freebsd-stable@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 4V36JR0gt1z5Fh0B for ; Mon, 25 Mar 2024 08:57:27 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mx.blih.net [212.83.155.74]) (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 mx1.freebsd.org (Postfix) with ESMTPS id 4V36JP6Lwlz4hRZ for ; Mon, 25 Mar 2024 08:57:25 +0000 (UTC) (envelope-from manu@bidouilliste.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bidouilliste.com header.s=mx header.b=gk2l+hMU; dmarc=pass (policy=none) header.from=bidouilliste.com; spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.155.74 as permitted sender) smtp.mailfrom=manu@bidouilliste.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1711357037; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=MnW+nyrf1BtIybnHJ/SX9xdOd0FMRviVQd4JBEoSkm4=; b=gk2l+hMUitVmRaONa+7SgOafrBMn6i8xsMnPzOQAlNNTMM9Ffy3MdRowjf8+lsxIRHaLhe tHh5Z2QFjoG2pPYLvQwqThQVVk53BPcn1s2FYLxg0UKMfloTk275A92Ko0V2K7BgCLjXz7 IBhBkNVeZVC3qm0EZxDdNVRDz6Zu5QM= Received: from skull.home.blih.net (lfbn-lyo-1-2174-135.w90-66.abo.wanadoo.fr [90.66.97.135]) by mx.blih.net (OpenSMTPD) with ESMTPSA id d7ce174b (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Mon, 25 Mar 2024 08:57:17 +0000 (UTC) Date: Mon, 25 Mar 2024 09:57:14 +0100 From: Emmanuel Vadot To: Chris Torek Cc: freebsd-stable@freebsd.org Subject: Re: 14-stable on AMD7950X: Good and bad news Message-Id: <20240325095714.77aa9945eb5baed415b4bb5b@bidouilliste.com> In-Reply-To: References: X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd15.0) List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.40 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[bidouilliste.com,none]; R_SPF_ALLOW(-0.20)[+ip4:212.83.155.74/32]; R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx]; MIME_GOOD(-0.10)[text/plain]; ONCE_RECEIVED(0.10)[]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[bidouilliste.com:+]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_TLS_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR]; FREEFALL_USER(0.00)[manu]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TAGGED_RCPT(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[] X-Rspamd-Queue-Id: 4V36JP6Lwlz4hRZ On Sun, 24 Mar 2024 19:11:01 -0700 Chris Torek wrote: > I built and booted up the latest 14-stable tree on my > AMD7950X machine: > > Good news: the mysterious AHCI adapter problem is gone, presumably > because of the new PCI range allocation code. So now both sets of SATA > ports work (at least, the drive I've left plugged in to the previously-failing > port now shows up). > > Bad news: building drm-61-kmod, then loading amdgpu.ko, > causes a crash. > > The immediate problem is that vm_phys_fictitious_unreg_range() > does this: > > rw_wlock(&vm_phys_fictitious_reg_lock); > seg = RB_FIND(fict_tree, &vm_phys_fictitious_tree, &tmp); > if (seg->start != start || seg->end != end) { > > At line 1115, `seg` is NULL, so we die with a kernel segfault. It's probably > a good idea to add a NULL test here since RB_FIND can return NULL. > (Presumably just stick `sig == NULL ||` in front of the start/end tests.) > > It's not clear why the unregister is failing though, as the drm code > seems correct at first glance. > > It *is* clear why it's unregistering, though, as the console printed: > > drmn0: could not load firmware image 'amdgpu/psp_13_0_5_toc.bin' amdgpu is known to be bad at unloading and also unregistering when firmware isn't present, please test again after installing the firmware (using fwget(8) should work, if you still missed firmware after that please install all amdgpu firmware packages and report which one are needed for you pciid so we can fix fwget(8)). > and the expected subsequent cleanup messages (and now I've run > out of Stuff I Just Know Off-Hand at this point so I'll have to dig > into this more). > > Chris > Cheers, -- Emmanuel Vadot