Re: MMCCAM - Re: onboard wireless on rpi4
Andriy Gapon <[email protected]>
| Newsgroups | gmane.os.freebsd.devel.arm |
|---|---|
| Message-ID | <[email protected]> |
On 07/09/2020 19:18, Bjoern A. Zeeb wrote: > On 7 Sep 2020, at 15:21, bob prohaska wrote: > >> On Mon, Sep 07, 2020 at 03:14:28PM +0200, Ronald Klop wrote: >>> >>> I've MMCCAM running since 12.1-BETA1 on rpi3B+. No problems so far. >>> Apparently I'm to only one :-) >>> https://dmesgd.nycbug.org/index.cgi?do=index&fts=mmccam >>> >> >> I just gave it a spin on a Pi3B (not +) and was rewarded with a >> panic. The machine boots from a USB mechanical disk. Sources are >> at 365355. Here's the console output: >> >> http://www.zefox.net/~fbsd/rpi3/GENERIC-MMCCAM/console >> >> I'll give the corresponding vanilla GENERIC kernel a try shortly, but 364900 >> boots without trouble. > > This seems to be a FDT/loader thing; others will know more about what it means. Bjoern, I think that you didn't scroll down enough. The real panic is down there. It looks like a page fault or something like that in sddastart. Perhaps a stack overflow? Kernel page fault with the following non-sleepable locks held: ... #2 0xffff00000073d35c at data_abort+0xe4 #3 0xffff00000073cd38 at do_el1h_sync+0x14c #4 0xffff000000724078 at handle_el1h_sync+0x78 #5 0xffff0000000f7d68 at sddastart+0xa8 Bob, I noticed this: (sdda0:sdhci_slot0:0:0:0): Partition 0 -> 8265462 Perhaps r365445 might be of some help. P.S. I found this article about ARMv8 and handle_el1h_sync: https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/semihalf-arm-blog-2-dead-board-and-stack-growth It has some theory but not sure if it help in practice. -- Andriy Gapon _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "[email protected]"