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