Bug 277638
| Summary: | Crash when running devinfo on RPI CM4 | ||
|---|---|---|---|
| Product: | Base System | Reporter: | HP van Braam <hp> |
| Component: | kern | Assignee: | freebsd-arm (Nobody) <freebsd-arm> |
| Status: | Closed FIXED | ||
| Severity: | Affects Many People | Keywords: | crash |
| Priority: | --- | ||
| Version: | 15.0-CURRENT | ||
| Hardware: | arm64 | ||
| OS: | Any | ||
Small update: I added the following to the RPI4 IO board: https://www.waveshare.com/wiki/PCIe_TO_USB_3.2_Gen1_(B) Which should make the RPI CM4 + the IO board basically identical to a 'normal' RPI4. And now devinfo no longer crashes. I'm beginning to suspect that perhaps, somewhere, the existence of the USB controller from the RPI4 is hardcoded as an assumption somewhere? A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=10e0c34bf842885b4bd78adbbdbd7fb00f133cb5 commit 10e0c34bf842885b4bd78adbbdbd7fb00f133cb5 Author: HP van Braam <hp@tmm.cx> AuthorDate: 2024-04-16 23:01:20 +0000 Commit: Ed Maste <emaste@FreeBSD.org> CommitDate: 2024-04-21 22:34:05 +0000 Enable L1SS handling on RPI4 pcib Thanks to @kevans91 for pointing me in the right direction. FreeBSD had the same bug as Linux (see https://bugzilla.kernel.org/show_bug.cgi?id=217276) where the ultimate solution was to honor the brcm,enable-l1ss FDT property. In current versions of the dtb files this property has been added by default. Without this on many, many pcie addin cards the pcib will Serror when trying to assert the clreq# pin on the pcie bus. Many cards do not have these hooked up. PR: 260131, 277638, 277605 Reviewed-by: emaste Signed-off-by: HP van Braam <hp@tmm.cx> Pull-request: https://github.com/freebsd/freebsd-src/pull/1179 sys/arm/broadcom/bcm2835/bcm2838_pci.c | 22 ++++++++++++++++++---- 1 file changed, 18 insertions(+), 4 deletions(-) |
Note: This was also tested on 14.0-RELEASE with the same results. To boot the CM4 it is necessary to set devmatch_enable="NO". This papers over the same crash it seems as gets triggered when running "devinfo" with it enabled. Doing this results in the following backtrace (obtained using kgdb) #0 0xffff00000042b1c8 in doadump (textdump=0, textdump@entry=3234298464) at /usr/src/sys/kern/kern_shutdown.c:403 #1 0xffff0000000efaa4 in db_dump (dummy=<optimized out>, dummy2=<optimized out>, dummy3=<optimized out>, dummy4=<optimized out>) at /usr/src/sys/ddb/db_command.c:590 #2 0xffff0000000ef880 in db_command (last_cmdp=<optimized out>, cmd_table=<optimized out>, dopager=true) at /usr/src/sys/ddb/db_command.c:503 #3 0xffff0000000ef568 in db_command_loop () at /usr/src/sys/ddb/db_command.c:550 #4 0xffff0000000f3050 in db_trap (type=<optimized out>, code=<optimized out>) at /usr/src/sys/ddb/db_main.c:267 #5 0xffff00000047a94c in kdb_trap (type=60, code=0, tf=<optimized out>) at /usr/src/sys/kern/subr_kdb.c:790 #6 <signal handler called> #7 kdb_enter (why=<optimized out>, msg=<optimized out>) at /usr/src/sys/kern/subr_kdb.c:556 #8 0xffff00000042b480 in vpanic (fmt=<optimized out>, ap=...) at /usr/src/sys/kern/kern_shutdown.c:961 #9 0xffff00000042b29c in panic (fmt=0x12 <error: Cannot access memory at address 0x12>) at /usr/src/sys/kern/kern_shutdown.c:889 #10 0xffff00000077e964 in data_abort (td=0xffff0000c3a86c80, frame=0xffff0000c0c783b0, esr=2516582404, far=<optimized out>, lower=0) at /usr/src/sys/arm64/arm64/trap.c:398 #11 <signal handler called> #12 strlcpy (dst=dst@entry=0xffff0000c0c78570 "", src=0xdeadc0dedeadc0de <error: Cannot access memory at address 0xdeadc0dedeadc0de>, dsize=dsize@entry=32) at /usr/src/sys/libkern/strlcpy.c:36 #13 0xffff000000486c4c in sysctl_rman (oidp=<optimized out>, arg1=<optimized out>, arg2=<optimized out>, req=0xffff0000c0c786d0) at /usr/src/sys/kern/subr_rman.c:998 #14 0xffff00000043d3e4 in sysctl_root_handler_locked (oid=oid@entry=0xffff000000a3aa60 <sysctl___hw_bus_rman>, arg1=arg1@entry=0xffff0000c0c787ac, arg2=arg2@entry=3, req=req@entry=0xffff0000c0c786d0, tracker=tracker@entry=0xffff0000c0c78658) at /usr/src/sys/kern/kern_sysctl.c:199 #15 0xffff00000043c754 in sysctl_root (oidp=<optimized out>, arg1=0xffff0000c0c787ac, arg1@entry=0xffff0000c0c787a0, arg2=3, arg2@entry=6, req=req@entry=0xffff0000c0c786d0) at /usr/src/sys/kern/kern_sysctl.c:2407 #16 0xffff00000043cdec in userland_sysctl (td=td@entry=0xffff0000c3a86c80, name=name@entry=0xffff0000c0c787a0, namelen=<optimized out>, old=0x1e0e686d760, oldlenp=<optimized out>, inkernel=<optimized out>, inkernel@entry=-1060665472, new=<optimized out>, newlen=<optimized out>, retval=0xffff0000c0c78798, flags=0) at /usr/src/sys/kern/kern_sysctl.c:2564 #17 0xffff00000043cc68 in sys___sysctl (td=0xffff0000c3a86c80, uap=0xffff0000c3a87080) at /usr/src/sys/kern/kern_sysctl.c:2437 #18 0xffff00000077df4c in syscallenter (td=0xffff0000c3a86c80) at /usr/src/sys/arm64/arm64/../../kern/subr_syscall.c:186 #19 svc_handler (td=0xffff0000c3a86c80, frame=<optimized out>) at /usr/src/sys/arm64/arm64/trap.c:198 #20 do_el0_sync (td=0xffff0000c3a86c80, frame=<optimized out>) at /usr/src/sys/arm64/arm64/trap.c:640 #21 <signal handler called> #22 0x000001e0e9df9944 in ?? () #23 0x000001e0e9d7e888 in ?? () After looking at the code a bit it seems that the "rm" entry is invalid at that point. I don't really know how to continue debugging this.