blob: 2dcd00c04cf8e3017fa89b0e3747ecd38086d9de (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
<think>
Alright, let's tackle this bug report classification. The user is reporting a hard lockup in qemu-system-riscv64 when using non-stdio serial output with u-boot firmware.
First, I need to understand what each category means. "mistranslation" relates to incorrect mappings from the source architecture to IR or target, usually happening in user-mode assembly. That doesn't seem to fit here.
The bug is about a lockup, which sounds like a system crash or hang. The mention of serial output suggests it's related to how QEMU handles I/O, possibly through device emulation. Since it's using u-boot firmware, the issue might be with how the serial device is emulated in QEMU.
Looking at the categories, "device" seems appropriate because it likely involves a problem with a specific hardware device's emulation, such as the serial port. Other possibilities like "graphic" or "network" don't fit since the issue isn't graphical or network-related.
I should also consider if it's related to KVM, which is a hypervisor, but the report doesn't mention virtualization specifics, just the QEMU system itself. Therefore, "device" seems the most accurate category for this bug.
</think>
The bug involves a hard lockup in QEMU when using non-stdio serial output with u-boot firmware. Since the issue relates to a device (serial port) emulation problem, the appropriate category is:
**device**
|