From nobody Tue Jul 22 17:06:55 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 4bmkGB0Kyxz5ptnm for ; Tue, 22 Jul 2025 17:07:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4bmkG94w5kz44C0 for ; Tue, 22 Jul 2025 17:07:13 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pg1-x533.google.com with SMTP id 41be03b00d2f7-b31d578e774so75389a12.1 for ; Tue, 22 Jul 2025 10:07:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1753204027; x=1753808827; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ST4LEiZme5AH/0lgW2Hhmx8bRV7Fyhjgl2NP65S5M7E=; b=VWiE5skT9IRncqAyj9LYViQMnv9ac8RE4HnjxcIIeXmwtPvGSA6H1+LMhP9i0gC4Cv gHJGhm7twQ70zbF5U2k9hM5rifXAMRTqgFLz+4VFkwe/IRkA3UYnsLc0rG3sxJEMf4nU tLmpZcFxrlGnwhqBsX+h1T/zlRYnA+XFg171T5BmbDDLLpojz7WSX40QuDZRa2iF+Q9e Hbyiz+30R+tEiTTvda359hNck7mcy6UV8X6nmQqUkgyjM8/nZl4LZi7DJHwFJrNPc0na Y/l5uBJrUFlhg+361gicLbEmD8LiZxvsNv3hk9XHO3/Kixy2ipGt4XZ1hmZce3t3f8P3 EI8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1753204027; x=1753808827; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ST4LEiZme5AH/0lgW2Hhmx8bRV7Fyhjgl2NP65S5M7E=; b=b2rNHYKwbdKLW+FP5yZDTz65/5+TT5fGaLXkRypgndL8BKVXmFCnKSOvyYa2inSqIX uDGwq2EriK9rX/fUBNHsdXq9nSoPAXfnwl4vZIOLX0MMfYI0TKVy5MDoRoYEz3DZl7N4 5dNiZ2zg++eXOX7GBYL6/MPzFGOSSYfyTz343g1BjSb0SbsgDUmrfCaMZxJrB5jinA8t nuE+raCq8Whb2U0HJhvXg6suIPRGTQn0X/EytwTq5P0bcE5Y5xKnNtZZb5SVdK6MMlFO k2nmmwa3HRtLZ0IB16woO9Q53Whk42HAOTwOsr4QH5BuKQA4TuXKLQPb4oaatF84EAFr K52Q== X-Gm-Message-State: AOJu0YzCKflDm8jzLygoZXRamwdQ0uRlgEwCkYtrThWYxvJvv+GMdUsR 07fWv0dC78btSMEelv1+kUIXA0CINMcR2nUV4S2eN8RYzC2MaBYHGJXrVxFPM+xDX8NTXJRHFrk Pae0pIneY2UTkD/3dxY991UA5p6VoGwjIJjaoy3y9VG7t6a38o/b2MmE= X-Gm-Gg: ASbGncvvdZxXkZItm/P8a1XrIYAALPhOw4BrODAQvMY1aeoLCmyc9kkkuvZvAmdJvcS +L2N9N57eqWQkyM7bawuKz04EKAgGQbAg43Bs6qk6EHZm7ymzdKolMbCN/EY7wal/dzqcFs/3ez fANxYih+w4efJKWC3fdVOaf/dVssZiXB2/rpc4lj39MzFgFuCrtfe29PRK6R88s3K2cyPx/85/o dLaVi8= X-Google-Smtp-Source: AGHT+IGQyQymg1s+m6aJc1onv8vFatRG6FFwsVvM4p7rYeVNw4odLJh+sU1P6x39Fgxsi2zseoUIdDbz3j9KcLW9vI4= X-Received: by 2002:a17:90b:4aca:b0:30e:9b31:9495 with SMTP id 98e67ed59e1d1-31e3e1cf3a9mr5232734a91.9.1753204026879; Tue, 22 Jul 2025 10:07:06 -0700 (PDT) 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 References: <602976q7-s2r2-o8n4-8s59-93pqq4ro3433@yvfgf.mnoonqbm.arg> <01r0s597-9ssr-s796-p54r-qs882628p4s7@yvfgf.mnoonqbm.arg> In-Reply-To: From: Warner Losh Date: Tue, 22 Jul 2025 11:06:55 -0600 X-Gm-Features: Ac12FXxngdqa1gxbD3IiRg_E9QM8shW8B7s9_UpXaeeinf8E1onNKkF-8UxQ0Ms Message-ID: Subject: Re: mmccam -> no more cards/sdio but "mmcprobe" To: "Bjoern A. Zeeb" Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4bmkG94w5kz44C0 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:15169, ipnet:2607:f8b0::/32, country:US] On Tue, Jul 22, 2025 at 11:01=E2=80=AFAM Bjoern A. Zeeb wrote: > > On Mon, 21 Jul 2025, Warner Losh wrote: > > Hi Warner, > > > On Mon, Jul 21, 2025 at 11:38=E2=80=AFAM Warner Losh w= rote: > >> > >> 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. I need to add which CCB function was queued to this, I think... > Now to fix my own code ;-) It should be easy... > Thanks a lot for the investigation and quick fix! Very much appreciated! You bet. I was worried that I'd broken something with my CAM fixes, despite testing it a lot locally. Then nobody said anything for a couple of weeks and I thought I was in the clear... Then you popped up just at the same time I had installed FreeBSD on an eMMC system I got and noticed it wasn't using MMCCAM as I was about to update it, so the timing was good... Warner