Bug 255289

Summary: panic: mmc: host bridge didn't serialize us
Product: Base System Reporter: Loïc Bartoletti <lbartoletti>
Component: miscAssignee: freebsd-bugs (Nobody) <bugs>
Status: New ---    
Severity: Affects Only Me CC: 9k0yuncu, freebsd, hlh, imp, marius
Priority: --- Keywords: crash, regression
Version: 12.2-RELEASE   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
mmc panic none

Description Loïc Bartoletti freebsd_committer freebsd_triage 2021-04-21 06:20:58 UTC 
Created attachment 224319 [details]
mmc panic

Hello,

I have a Beelink BT3 Pro [1] It worked perfectly under 12.1-RELEASE, but crashes on 12.2-RELEASE and 13.0-RELEASE. Sorry, I haven't a dump core only the screenshot.

The crash occurs after X11 is started (using kde plasma). This computer needs the i915kms driver for display, but I think it is to be excluded [2] because I managed to crash it using the scfb driver.

Thanks.


[1] https://www.amazon.fr/Beelink-Mini-Computer-Windows-Processeur/dp/B07PVG9KQL

[2] similar issue: https://github.com/freebsd/drm-kmod/issues/43
Comment 1 Andriy Gapon freebsd_committer freebsd_triage 2021-04-21 07:34:40 UTC 
(In reply to Loïc Bartoletti from comment #0)
The drm-kmod issue you linked is not similar at all.
The only similarity is the post-panic garbage from the drm driver, but the actual panics are completely unrelated and, as you noted yourself, are not related to drm either.
Comment 2 Gokhan Koyuncu 2021-06-13 23:49:07 UTC 
Hello, I suffer from the same panic - though the stack is different:

panic() at panic+0x43/frame 0xfffffe008e4cc3a0
mmc_acquire_bus() at mmc_acquire_bus+0x439/frame 0xfffffe008e4cc440
mmcsd_flush_cache() at mmcsd_flush_cache+0x68/frame 0xfffffe008e4cc480
mmcsd_close() at mmcsd_close+0x1f/frame 0xfffffe008e4cc4a0
g_disk_access() at g_disk_access+0x238/frame 0xfffffe008e4cc4e0
g_access() at g_access+0x1c0/frame 0xfffffe008e4cc570
g_dev_close() at g_dev_close+0x17a/frame 0xfffffe008e4cc5d0
devfs_close() at devfs_close+0x36f/frame 0xfffffe008e4cc640
VOP_CLOSE_APV() at VOP_CLOSE_APV+0x7a/frame 0xfffffe008e4cc670
vn_close1() at vn_close1+0x138/frame 0xfffffe008e4cc6f0
vn_closefile() at vn_closefile+0x4e/frame 0xfffffe008e4cc770
devfs_close_f() at devfs_close_f+0x2c/frame 0xfffffe008e4cc7a0
_fdrop() at _fdrop+0x29/frame 0xfffffe008e4cc7c0
closef() at closef+0x24a/frame 0xfffffe008e4cc850
closefp() at closefp+0x9e/frame 0xfffffe008e4cc890

I use 10/stable (amd64) (I know it is unsupported now). The platform is Intel Apollo Lake with eMMC 5.0 controller (no other special patch or configuration).

I can reproduce the panic with some networking activity that, I guess, triggers some disk activity which I can't characterize for now).

How can I proceed with this issue? Any pointers are highly appreciated! I can provide further information.
Comment 3 Henri Hennebert 2021-11-08 09:32:41 UTC 
FreeBSD keystone.lab.bel 13.0-STABLE FreeBSD 13.0-STABLE #0 stable/13-n248012-b6b91760300b: Sun Nov  7 20:36:15 CET 2021     root@keystone.lab.bel:/usr/obj/usr/src/arm64.aarch64/sys/ROCKPRO64  arm64

on a rockpro64

While running
/usr/sbin/watchdogd -s 30 -e /sbin/zpool import -w --softtimeout --softtimeout-action printf,log -t 128 -x 256

When `make -s buildworld`, I get:

panic: mmc: host bridge didn't serialize us.
cpuid = 3
time = 1636356673
KDB: stack backtrace:
#0 0xffff0000003f50bc at kdb_backtrace+0x60
#1 0xffff00000039fb8c at vpanic+0x184
#2 0xffff00000039fa04 at panic+0x44
#3 0xffff000000190e3c at mmc_acquire_bus+0x5c4
#4 0xffff0000001997d0 at mmcsd_flush_cache+0x6c
#5 0xffff000000197f34 at mmcsd_close+0x20
#6 0xffff0000002ee354 at g_disk_access+0xd8
#7 0xffff0000002f4c3c at g_access+0x1c8
#8 0xffff0000002ebf7c at g_dev_close+0x284
#9 0xffff00000023d5d8 at devfs_close+0x810
#10 0xffff000000824738 at VOP_CLOSE_APV+0x2c
#11 0xffff0000004aa188 at vn_close1+0x170
#12 0xffff0000004a84c4 at vn_closefile+0x3c
#13 0xffff00000023e1bc at devfs_close_f+0x28
#14 0xffff000000330964 at _fdrop+0x18
#15 0xffff000000334d00 at closef+0x30c
#16 0xffff000000330db0 at closefp+0xa0
#17 0xffff0000007cd7b4 at do_el0_sync+0x6a0
Uptime: 18m51s
(da0:umass-sim0:0:0:0): Synchronize cache failed
Dumping 451 out of 3910 MB:Aborting dump due to I/O error.

If I run without watchdogd, `make -s buildworld` complete without problem... :-O
Comment 4 Henri Hennebert 2021-11-11 08:24:48 UTC 
(In reply to Henri Hennebert from comment #3)
On the same hw configuration under

FreeBSD keystone.lab.bel 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n250557-eb5e0755f749: Tue Nov  9 17:53:07 CET 2021     root@keystone.lab.bel:/usr/obj/usr/src/arm64.aarch64/sys/ROCKPRO64  arm64

I can't reproduce the panic.
Comment 5 Henri Hennebert 2021-11-15 09:22:07 UTC 
(In reply to Henri Hennebert from comment #3)
After a complete power of (unplugged) I *can NOT* reproduce the panic under the same 13/stable version.

After another complete power of, the panic can be reproduce.

So maybe a hardware setup (by u-boot ?) may be the culprit...