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

See Also:


Attachments

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