From nobody Tue Jul 22 04:17:20 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 4bmPBC6QZwz62PSS for ; Tue, 22 Jul 2025 04:17:39 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) (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 4bmPBB1stpz3vgX for ; Tue, 22 Jul 2025 04:17:38 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20230601.gappssmtp.com header.s=20230601 header.b=pMf4Bn0P; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::1032) smtp.mailfrom=wlosh@bsdimp.com; dmarc=none Received: by mail-pj1-x1032.google.com with SMTP id 98e67ed59e1d1-311c95ddfb5so3712108a91.2 for ; Mon, 21 Jul 2025 21:17:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1753157851; x=1753762651; 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=nMWb3KjEr6HZAd/Vjp2HTUrbQPe9+qz3oaqHRhI/XqE=; b=pMf4Bn0PUKd3GfndxT3zMHwCKA1QHOWDXbz5/C37OCy3nz6I+/vZ4audHoqKTWE1WR rTXvUr7WflYJUB/iWTRv261YDLLkADbATMeXMH0GY/vMmmj985eSooFtIKaMocUxReh8 vJLkDB2xZ2pTFUXn2Laq4P/faEQDFFBZdnJF9Z1S2It5suQTVw6iYznr5Ay7i1fHV0uA z0/shsYxK99NzWsPEz+PbMIKX15aZWHhZ1Qvs5oP34u1UK2gZzMeaZ28QbofbLF1f9U8 1KBZB7iBXl43dcE3HqfECVSpO9LOUI48flqMZ0qavfzJg82oDm5S2ZUC6UZ1d4okaWH3 IuJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1753157851; x=1753762651; 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=nMWb3KjEr6HZAd/Vjp2HTUrbQPe9+qz3oaqHRhI/XqE=; b=nUG0OMBLV8bgc8tmSiMc05GE/bjKUuBvZl7YBNigBINBCjKAlxMjXXSyu+wp7qn4wu TbUvRWfRCMYy0PSH2v8PYU+M6FQJM9kxWg2vT1S5ZYZTEdksGg1vA1Eukt5XRuJwXksF /ZqcT5oi6yfehpoHBM/6Gs6aS+vsH/nwDcft0vOx+q1Eqb6xnY+Y6P7PlDWSimGM9cv6 Cj0vvwvTs7kd03MID2O6xt0aprHc/IBsmZ0TALElVEyhxXcnLwYCAYxdH0XabyiDdyi2 rp4fagLsWvaotMbhaRO8jVXwKyQDH4uDoG/kzAOt9+UTyq63OavWcjQi3eSuOo4FfBAb ueKw== X-Gm-Message-State: AOJu0YxWAxzqZinuLZz+OBxrIDOK7kykG9+NEJgYGT9sYkJTreh5KLjO 9QoRzzrcvDNI82tHgcD/y9YXGbyQiaCGLZCjABWt759ivo1pkYrUcxEk8F01op7EYZhtezcR6fe 35AD5INQ7cXOr0SImtjh2YqQp2dId31xXOvHtJ04ZzQEnptvStednTn5qwg== X-Gm-Gg: ASbGncsTAigaoVb2weg8BF2XJKK51No45HvHn2KoiBPJFOhygGS27m4m7jWb9oOKvuW upNHOUIHAdT/nU9NCcclDsEKqroU1+3JSG+4/jGWXd8V/Jo37uDWeuabKWhyBLYUeLQ0BW/r5gp 800Ve8sI37AEmxslgmG1WXQJQJbHJE/ca0j9cHjZk7N0+Bu69c3frv/aJd5fZGMh15CEdRwGM5c Su9chc6MuJ5YyphGA== X-Google-Smtp-Source: AGHT+IFbNQS0tPA0zoIspChy0w85JkmIiCn8VmCdAfORq7tKMIS4EvzAQxGLzvhmtoK5ORkrOUL+yR8KKhJiXos4U5o= X-Received: by 2002:a17:90b:1c04:b0:312:e9bd:5d37 with SMTP id 98e67ed59e1d1-31cc2515a29mr21554404a91.6.1753157851088; Mon, 21 Jul 2025 21:17:31 -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: Mon, 21 Jul 2025 22:17:20 -0600 X-Gm-Features: Ac12FXwiJ-8h-IqJX8DtEOFmaGZ8BKsfByQgTNMD3HZNpTzMu804808_HfmhB94 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-Spamd-Result: default: False [-1.81 / 15.00]; NEURAL_HAM_SHORT(-1.00)[-0.997]; NEURAL_HAM_LONG(-0.94)[-0.936]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20230601.gappssmtp.com:s=20230601]; NEURAL_SPAM_MEDIUM(0.13)[0.127]; MIME_GOOD(-0.10)[text/plain]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; MISSING_XM_UA(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; RCPT_COUNT_TWO(0.00)[2]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1032:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; TO_DN_ALL(0.00)[]; MLMMJ_DEST(0.00)[current@freebsd.org]; DKIM_TRACE(0.00)[bsdimp-com.20230601.gappssmtp.com:+] X-Rspamd-Queue-Id: 4bmPBB1stpz3vgX X-Spamd-Bar: - On Mon, Jul 21, 2025 at 11:38=E2=80=AFAM 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. Warner > Warner > > On Mon, Jul 21, 2025 at 7:15=E2=80=AFAM Bjoern A. Zeeb > wrote: > > > > On Sun, 20 Jul 2025, Warner Losh wrote: > > > > > On Sun, Jul 20, 2025, 7:20=E2=80=AFPM Warner Losh wr= ote: > > > > > >> > > >> > > >> On Sun, Jul 20, 2025, 5:24=E2=80=AFPM Warner Losh w= rote: > > >> > > >>> > > >>> > > >>> On Sun, Jul 20, 2025, 5:19=E2=80=AFPM Bjoern A. Zeeb < > > >>> bzeeb-lists@lists.zabbadoz.net> wrote: > > >>> > > >>>> Hi, > > >>>> > > >>>> I've updated one of my trees to main after a longer while and I am > > >>>> confused that I no longer see and SD card or SDIO (this is netboot= ed): > > >>>> > > >>>> # sysctl kern.features.mmccam > > >>>> kern.features.mmccam: 1 > > >>>> > > >>>> # camcontrol devlist -v > > >>>> scbus0 on dw_mmc_sim0 bus 0: > > >>>> <> at scbus0 target 0 lun 0 (mmcpr= obe0) > > >>>> scbus1 on dw_mmc_sim1 bus 0: > > >>>> <> at scbus1 target 0 lun 0 (mmcpr= obe1) > > >>>> scbus-1 on xpt0 bus 0: > > >>>> <> at scbus-1 target -1 lun ffffff= ff > > >>>> (xpt0) > > >>>> > > >>>> Where to start looking? > > >>>> > > >>> > > >>> So those probes are put there to evaluate devices that were found. = If > > >>> they remain, then that never finished. Most likely never started. > > >>> > > >>> What hardware is this on? > > >>> > > >> > > >> Thanks for the debug... > > >> > > >> As luck would have it, I just installed on emmc system (x86). I'm bu= ilding > > >> mmccam kernel now. > > >> > > > > > > I can confirm this result. When was your last update? There was also > > > sleeping on a non-sleepable lock witness warning... > > > > The locking issue I think I posted a while a ago. > > > > I cannot say which kernel last worked there; that was likely from 2024. > > > > I found an arm64 MMCCAM kernel from around 2025-03-18/26 which works o= n > > the LS1088. Seems the last commit from main on that branch was > > 12bff22669cf . > > > > # camcontrol devlist -v > > scbus0 on sdhci_slot0 bus 0: > > at scbus0 target 0 lun 0 (pa= ss0,sdda0) > > ... > > > > In either case the nvme does work by the way. It's just mmccam it seem= s > > which does not. > > > > -- > > Bjoern A. Zeeb r15:= 7