Bug 247210

Summary: Risc-V in QEMU: missing interrupts and cc(1) failure
Product: Base System Reporter: Poul-Henning Kamp <phk>
Component: miscAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed FIXED    
Severity: Affects Only Me CC: kp, mhorne
Priority: ---    
Version: CURRENT   
Hardware: riscv   
OS: Any   

Description Poul-Henning Kamp freebsd_committer freebsd_triage 2020-06-12 15:35:18 UTC
I tried following the wiki to setup a Risc-V system using -CURRENT under Qemu-devel.

As far as things goes it does boot, and big hat tip for that.

Two issues however:

Two phenomena points to some timer interrupts not happening.

1) Ping(1) reports "inf ms":

    root@qemu:/tmp # ping 192.168.60.1
    PING 192.168.60.1 (192.168.60.1): 56 data bytes
    64 bytes from 192.168.60.1: icmp_seq=0 ttl=64 time=inf ms
    64 bytes from 192.168.60.1: icmp_seq=1 ttl=64 time=inf ms
    64 bytes from 192.168.60.1: icmp_seq=2 ttl=64 time=inf ms

2) Things run faster i CTRL-T is repeatedly pressed in the console.

I think this may also be why any attempt to ssh into the instance times out.


The other problem is that the installed compiler does not work, compiling the canonical hello.c fails with:

    ld: error: a.c:(.text+0x0): relocation R_RISCV_ALIGN requires unimplemented linker relaxation; recompile with -mno-relax
    cc: error: linker command failed with exit code 1 (use -v to see invocation)
Comment 1 Kristof Provost freebsd_committer freebsd_triage 2020-06-12 15:42:16 UTC
https://reviews.freebsd.org/D25210 will fix the compiler issue. Unless anyone objects to it I'll commit it early next week.

I have no immediate idea as to what's causing your timer interrupt issues.
I can reproduce it in my own qemu machine, but not in the qemu that emulates a piece of riscv hardware I'm working on now. Those are two different qemu versions, so it's not immediately obvious to me if this is a qemu issue or a FreeBSD issue.
Comment 2 Poul-Henning Kamp freebsd_committer freebsd_triage 2020-06-12 15:57:04 UTC
If I pass '-smp 1' to qemu, the boot sequence is much (4-5x) faster, but shortly after getting to multiuser, it slows to a crawl again.
Comment 3 Poul-Henning Kamp freebsd_committer freebsd_triage 2020-06-12 16:03:26 UTC
(In reply to Poul-Henning Kamp from comment #2)

Seems to be a qemu-devel issue.

With the qemu package the interrupt problem seems gone.
Comment 4 Poul-Henning Kamp freebsd_committer freebsd_triage 2020-06-12 20:24:30 UTC
(In reply to Poul-Henning Kamp from comment #3)

Hmm, it only seems to work with the qemu port with a single CPU.

If I give -smp N for N>1 the symtoms of interrupt-trouble comes back.

(Testing D25210)
Comment 5 Mitchell Horne freebsd_committer freebsd_triage 2020-09-04 00:15:56 UTC
Hi,

There have been a couple of interrupt related commits that have gone in over the last few months. I have encountered the ping(1) issue you reported before, but on a recent HEAD with -smp 2, I no longer see it.

If you have the chance, could you try again with a newer kernel and confirm whether or not the issue is still present?
Comment 6 Mitchell Horne freebsd_committer freebsd_triage 2020-09-04 14:10:58 UTC
(In reply to Mitchell Horne from comment #5)

I should specify that I used devel/qemu50 for my test. This version contains an important bugfix for the interrupt controller implementation.
Comment 7 Mitchell Horne freebsd_committer freebsd_triage 2020-10-16 16:44:38 UTC
Closing this as both issues are believed to be fixed. Please re-open if this is not the case.