Bug 247210 - Risc-V in QEMU: missing interrupts and cc(1) failure
Summary: Risc-V in QEMU: missing interrupts and cc(1) failure
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: misc (show other bugs)
Version: CURRENT
Hardware: riscv Any
: --- Affects Only Me
Assignee: freebsd-bugs (Nobody)
Depends on:
Reported: 2020-06-12 15:35 UTC by Poul-Henning Kamp
Modified: 2020-10-16 16:44 UTC (History)
2 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Poul-Henning Kamp freebsd_committer 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
    PING ( 56 data bytes
    64 bytes from icmp_seq=0 ttl=64 time=inf ms
    64 bytes from icmp_seq=1 ttl=64 time=inf ms
    64 bytes from 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 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 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 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 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 2020-09-04 00:15:56 UTC

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 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 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.