Re: [PATCH -next V17 4/7] riscv: entry: Convert to generic entry

["Heiko Stübner" <heiko@sntech.de>]

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