Date: Sat, 19 Dec 2020 14:17:14 -0400 From: Mitchell Horne <mhorne@freebsd.org> To: Michael Dexter <editor@callfortesting.org> Cc: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: RISC-V root device question -> Panic Message-ID: <CADeAsy07h2s58TxoO48zVMf8mXBm7tSMEbC6Co-2pKmvgs0kNw@mail.gmail.com> In-Reply-To: <e9ff294d-620e-0466-4ccd-4acf1eb340ff@callfortesting.org> References: <4fcf5f35-481b-a321-cb52-7264fc10d1d4@callfortesting.org> <CADeAsy0jyHx10pQ5NRYzuk2gjMGOf4Of5jGOL-0BmoN5PVJd5A@mail.gmail.com> <e9ff294d-620e-0466-4ccd-4acf1eb340ff@callfortesting.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Dec 14, 2020 at 6:03 PM Michael Dexter <editor@callfortesting.org> wrote: > > Mitchell, > > On 12/7/20 1:56 PM, Mitchell Horne wrote: > > You can also override it using the QEMU commandline, which is simpler > > since you won't need to recompile anything. Adding the following > > argument should suffice: > > This works great but riscv 12-STABLE using last week's snapshot revision > throws the panic output included below under QEMU and leaves nothing in > /var/crash > > What expectations should I set for RISC-V STABLE and CURRENT? > Hi Michael, sorry for my delayed reply. Development and testing has been almost entirely focused on CURRENT. I believe riscv64 may have been functional on stable/12 at some point (and we even made an effort to MFC changes there), but it is not used anymore as far as I know. The expectations I would set going forward are that 13.0 will be the first functional release for the architecture (including stable/13 when it is branched), and stable/12 will remain unsupported. Also, to follow up on earlier items in this thread, I have documented how to generate a bootable RISC-V image containing an EFI partition with loader.efi. If you encounter any issues with the instructions, please let me know. https://wiki.freebsd.org/riscv/QEMU#Generate_a_root_filesystem Cheers, Mitchell > All the best, > > Michael > > t[0] == 0xffffffc0006c9d98 > t[1] == 0x0000000040c50000 > t[2] == 0x0000000040c65000 > t[3] == 0x0000000000000001 > t[4] == 0x0000000000000000 > t[5] == 0x0000000000000001 > t[6] == 0x0000000000000001 > s[0] == 0xffffffd0b1600248 > s[1] == 0x0000000040e49000 > s[2] == 0xfffffffffffff000 > s[3] == 0x00000000000000ff > s[4] == 0x0000000041000000 > s[5] == 0x0000000000000001 > s[6] == 0xffffffc000aff988 > s[7] == 0x00000000410a1000 > s[8] == 0x0000000000000280 > s[9] == 0x0000000000000000 > s[10] == 0x0000000000001000 > s[11] == 0xffffffffffffff73 > a[0] == 0x0000000000000000 > a[1] == 0xffffffd00297d560 > a[2] == 0x0000000000000000 > a[3] == 0x0000000000000021 > a[4] == 0x0000000000000000 > a[5] == 0x0000000000000021 > a[6] == 0x000000000000003f > a[7] == 0xffffffc000aff900 > sepc == 0xffffffc0004ce414 > sstatus == 0x0000000000000120 > panic: Fatal page fault at 0xffffffc0004ce414: 0x00000000000065 > cpuid = 1 > time = 1607915275 > KDB: stack backtrace: > #0 0xffffffc00023f2d4 at kdb_backtrace+0x50 > Uptime: 2d1h40m41s > Automatic reboot in 15 seconds - press a key on the console to abort > Rebooting...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CADeAsy07h2s58TxoO48zVMf8mXBm7tSMEbC6Co-2pKmvgs0kNw>