blob: 80693a2629247582e4eca09402e88102d5b19c0b (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
|
<think>
Okay, I need to classify this bug report for QEMU into one of the given categories. Let me read through the details carefully.
The bug is in hw/mc146818, which relates to an error reading RTC_HOURS_ALARM. The issue is that get_next_alarm() doesn't read the field correctly.
Looking at the points mentioned:
- Bit 7 must be masked before conversion from BCD.
- Need to check don't care conditions properly after masking.
- PM bit should come from RTC_HOURS_ALARM, not RTC_HOURS.
So, the problem is about how certain bits are being handled in the hardware emulation. Specifically, it's related to reading and processing specific fields correctly when dealing with the Real-Time Clock (RTC) alarms.
The commit mentioned seems to be a fix for this issue. Now, looking at the categories:
- Mistranslation: Incorrect semantic mapping from source architecture to IR/target, user-mode assembly.
- Assembly lowering
- Other
- Device
- Graphic
- Socket
- Network
- KVM
- Boot
- VNC
- Debug
- Files
- Permissions
- Performance
- Kernel
- Peripherals
- Hypervisor
The bug is in hw/mc146818, which suggests it's related to hardware devices. The mc146818 is a hardware component (a microcontroller), so the issue falls under device emulation.
Looking at other possible categories: It doesn't seem to be about assembly lowering or user-mode issues. It's more about how QEMU handles specific hardware registers, which points towards 'device'.
</think>
The bug report pertains to incorrect handling of RTC alarm fields in a hardware component (mc146818), making it a device-related issue.
**Answer:** device
|