From nobody Tue Jul 22 17:01:38 2025 X-Original-To: current@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 4bmk800gPtz5ptdt for ; Tue, 22 Jul 2025 17:01:52 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx-01.divo.sbone.de (mx-01.divo.sbone.de [IPv6:2003:a:140a:2200:6:594:fffe:19]) (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 ECDSA (prime256v1) client-digest SHA256) (Client CN "mx-01.divo.sbone.de", Issuer "E5" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4bmk7y6TSKz419h for ; Tue, 22 Jul 2025 17:01:50 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Authentication-Results: mx1.freebsd.org; none Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by mx-01.divo.sbone.de (Postfix) with ESMTPS id 4CC0CA64809; Tue, 22 Jul 2025 17:01:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=zabbadoz.net; s=20240622; t=1753203697; bh=6hSWpqbNFkkTDLtN9Pcs9MIkZnV1u/0/xsRhZjE805s=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=JGg1o62O0kilkyTnzPlkoU/Yn/1Ab/EDuYmcyxZj4d7qH5A1XzIxIRZn26Z/cL3pv Q2Wtit4EuwCA/pQvgzK56qniowcUHPbiuca497eiwam+lvhtIuvcesL/WUcZ81cHB3 F7n0APA+ThFQnvdLluHWApd7vbyQfKEu/qocl7/tleczmTnMfr3a5nkJvm/3TiBuLl GEiehk0GRxx9Shuv6K+JLNG7NOqP8rWKgzKM5KTpxueBkxnqw6QY8EYni0Whc7ph1P QqxgcZYejcyd0fFKKoYSYGU9otQlbDC+7izaR2g75pjklbWBwnyrfxNEkeFeFgkvZp AEyoiUvp5wSTsfspvh9KNlS3KLiytssVY6l/FMMd9Og+gFDmDs4fHZsxyYuaByFHMa NeOqmUt2wIDeamPHDCFPYSJqhPKkHX3AOBnJggsebkxwnhGfZWC9RuzVPhVJ/85nH/ /DgNc4KB6VrMEV7oTe3S5bd7hs6p5piuzsz58N8th//D1tTIKBEy1KC64Kq2AMLQj8 kKUF6Upg7bhWBGJAnRInGPrF0QvcticQeSAIOgFY5eYEYpu5Pnvp66Fcwz2j0ffTmG xkar3nbP75ujbPOYSuF6BSu0fxor0Xw0nEgGRJKOEnBASAryLD7EGzT3LlFMw2CiHw zMFHo9go5fez/C+481JUwVno= Received: from content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (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) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id F23A52D029E1; Tue, 22 Jul 2025 17:01:40 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) by content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (amavisd-new, port 10024) with ESMTP id GnROwp53FGqn; Tue, 22 Jul 2025 17:01:39 +0000 (UTC) Received: from strong-iwl0.sbone.de (strong-iwl0.sbone.de [IPv6:fde9:577b:c1a9:4902:a66b:b6ff:fe40:39a9]) (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) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id A86EC2D029D8; Tue, 22 Jul 2025 17:01:39 +0000 (UTC) Date: Tue, 22 Jul 2025 17:01:38 +0000 (UTC) From: "Bjoern A. Zeeb" To: Warner Losh cc: FreeBSD Current Subject: Re: mmccam -> no more cards/sdio but "mmcprobe" In-Reply-To: Message-ID: References: <602976q7-s2r2-o8n4-8s59-93pqq4ro3433@yvfgf.mnoonqbm.arg> <01r0s597-9ssr-s796-p54r-qs882628p4s7@yvfgf.mnoonqbm.arg> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="1098556516-948891769-1753203699=:4643" X-Rspamd-Queue-Id: 4bmk7y6TSKz419h X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:3320, ipnet:2003::/19, country:DE] This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1098556516-948891769-1753203699=:4643 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Mon, 21 Jul 2025, Warner Losh wrote: Hi Warner, > On Mon, Jul 21, 2025 at 11:38 AM Warner Losh wrote: >> >> So, We're getting through the 'reset' and 'identify' states in the >> state machine and entering the 'power off' state. And then progressing >> no further. So we get into the 'done' routine, but don't progress to >> sending the get ocr command. That's why we still have the probe >> routine. We're not setting the probe into INVALID state, so we should >> be calling xpt_schedule() to do the next single step of this process >> at the end of mmc_done(), but that doesn't trigger a new call to >> mmc_start(). >> >> I did some CAM cleanups that shouldn't have broken this, but might >> have (low probability, but with cam you never know, especially in the >> single step phase we do to do the probing). I'll check those out. >> Maybe it's easy. > > OK. It turned out that I had messed things up, unbeknownst to me. I've > added a KASSERT that should catch problems like this in the future > (and caught a second one that I also fixed). It should be safe to go > back into the MMCCAM water after b4b166b8c46b8. It broke a few days > ago in c6dc5d367681 (I just realised I forgot to add the fixes: tag to > my commit in my rush to get a fix in). > > When we're running the single stepping engine to probe the device, all > those commands are queued. And we'll not run through them if we queue > something at CAM_PRIORITY_NONE. c6dc5d367681 made the ccb that ran for > the xpt_path_inq() at the NONE priority. Normally, this is fine. All > the instances in the tree but two use that the stack to pass in a CCB > for this use. It doesn't matter the priority. But, xpt_start() did > xpt_path_inq on the start_ccb passed in that was allocated in > xpt_schedule which fills in the proper priority and other fields. It > didn't matter for the xpt_path_inq, it completed just fine. However, > for the XPT_MMC_IO commands that followed, the priority was wrong, so > they'd never run. It turns out that we don't need or use the > xpt_path_inq() results at all, so it was just having the side effect > of initializing the CCB (bogusly and redundantly, it turns out. The > other location that doesn't use the stack for xpt_path_inq() doesn't > really reuse the CCB, but saves the results of the path_inq away (it > could allocate less memory if it did a similar thing to the stack > trick in its soft state structure, but doesn't). > > So tl;dr: Thanks for the heads up, this broke only a few days ago, and > should be fixed now. My sdhci system with eMMC in it works with these > changes. And I added a KASSERT to catch this problem in the future. I can confirm that your fixes are working. I had a look through the cam diff but wouldn't have spotted this. I can also confirm that the KASSERT works: panic: xpt_action: queued ccb and CAM_PRIORITY_NONE illegal. Now to fix my own code ;-) Thanks a lot for the investigation and quick fix! Very much appreciated! /bz -- Bjoern A. Zeeb r15:7 --1098556516-948891769-1753203699=:4643--