Messages in this thread | | | From | Heiko Stübner <> | Subject | Re: [PATCH -next V17 4/7] riscv: entry: Convert to generic entry | Date | Sat, 01 Apr 2023 14:10:25 +0200 |
| |
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@sntech.de> 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@kernel.org wrote: > > > > > From: Guo Ren <guoren@linux.alibaba.com> > > > > > > > > > > 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
| |