Hi Guo, Am Samstag, 1. April 2023, 04:15:32 CEST schrieb Guo Ren: > On Fri, Mar 31, 2023 at 2:47 PM Heiko Stübner <heiko@xxxxxxxxx> wrote: > > Am Freitag, 31. März 2023, 20:41:35 CEST schrieb Conor Dooley: > > > On Fri, Mar 31, 2023 at 07:34:38PM +0100, Conor Dooley wrote: > > > > On Tue, Feb 21, 2023 at 10:30:18PM -0500, guoren@xxxxxxxxxx wrote: > > > > > From: Guo Ren <guoren@xxxxxxxxxxxxxxxxx> > > > > > > > > > > This patch converts riscv to use the generic entry infrastructure from > > > > > kernel/entry/*. The generic entry makes maintainers' work easier and > > > > > codes more elegant. Here are the changes: > > > > > > > > > > - More clear entry.S with handle_exception and ret_from_exception > > > > > - Get rid of complex custom signal implementation > > > > > - Move syscall procedure from assembly to C, which is much more > > > > > readable. > > > > > - Connect ret_from_fork & ret_from_kernel_thread to generic entry. > > > > > - Wrap with irqentry_enter/exit and syscall_enter/exit_from_user_mode > > > > > - Use the standard preemption code instead of custom > > > > > > > > This has unfortunately broken booting my usual NFS rootfs on both my D1 > > > > and Icicle. It's one of the Fedora images from David, I think this one: > > > > http://fedora.riscv.rocks/kojifiles/work/tasks/3933/1313933/ > > > > > > > > It gets pretty far into things, it's once systemd is operational that > > > > things go pear shaped: > > > > > > Shoulda said, can share the full logs if required of course, but they're > > > quite verbose cos systemd etc. > > > > I was just investigating the same thing just now. So that saves me some > > tracking down the culprit :-) . > > > > My main qemu is living as a "board" in my boardfarm (also doing nfsroot) > > as well as my d1 nezha with nfsroot was affected. > Can you reproduce it with qemu? Could give me some tips and let me > reproduce it on qemu? As written the issue both happens on qemu-virt and also the d1-nezha board. Below I've summarized my setup a bit: (1) Qemu-commandline: --------------------- /usr/local/bin/qemu-system-riscv64 -M virt -smp 2 -m 1G -display none \ -cpu rv64,zbb=true,zbc=true,svpbmt=true,Zicbom=true,Zawrs=true,sscofpmf=true,v=true \ -serial telnet:localhost:5500,server,nowait -kernel /home/devel/nfs/kernel/riscv64/Image \ -append "earlycon=sbi root=/dev/nfs nfsroot=10.0.2.2:/home/devel/nfs/rootfs-riscv64virt ip=dhcp rw" \ -netdev user,id=n1 -device virtio-net-pci,netdev=n1 Which does the start using a nfs-root coming from an nfs-server running on the same host as qemu. Though the issue does not seem to be related to the nfs. I also tried starting with a local disk image like [0] and the issue with the journald still persists. (2) the rootfs-contents: ------------------------ Conor seems to be using Fedora, while my distribution of choice is Debian. My rootfs was created following the instructions on the Debian wiki for the debports with debootstrap [1]. This morning I also re-created a completely new and pristine rootfs using those instructions and the issue appeared immediately on first-boot. Hope this helps a bit Heiko [0] same result with a disk-image ... journald failing /usr/local/bin/qemu-system-riscv64 -M virt -smp 2 -m 1G -display none \ -cpu rv64,zbb=true,zbc=true,svpbmt=true,Zicbom=true,Zawrs=true,sscofpmf=true,v=true \ -serial telnet:localhost:5500,server,nowait -kernel /home/devel/nfs/kernel/riscv64/Image \ -append 'root=/dev/vda console=ttyS0' \ -drive file=/home/devel/nfs/rootfs-riscv64virt.ext4,format=raw,id=hd0 \ -device virtio-blk-pci,drive=hd0 [1] https://wiki.debian.org/RISC-V#debootstrap
