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
(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.
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.
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
(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.
(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...