blob: 93f0b4f60794c51e7fc128b229ac5c78e4572940 (
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
42
43
|
peripherals: 0.993
device: 0.907
mistranslation: 0.852
architecture: 0.833
vnc: 0.794
network: 0.792
kernel: 0.775
socket: 0.758
ppc: 0.750
performance: 0.750
register: 0.748
semantic: 0.700
risc-v: 0.682
x86: 0.654
arm: 0.631
PID: 0.609
VMM: 0.607
graphic: 0.575
permissions: 0.564
i386: 0.552
boot: 0.538
files: 0.524
TCG: 0.504
debug: 0.490
KVM: 0.425
user-level: 0.369
hypervisor: 0.363
virtual: 0.281
assembly: 0.248
Exynos4210 UART peripheral data loss
Currently the Exynos4210 UART (hw/char/exynos4210_uart.c) incorrectly reports however many empty bytes are available in the FIFO when queried for receive capacity. However this peripheral supports a polled mode where only a single byte can be submitted at a time and the FIFO is unused, meaning that in polled mode data is lost since it's written into the FIFO and the polling code in FIFO disabled mode only returns the value in the RX data register.
Even worse, potentially enabling the FIFO without a FIFO reset will create a weird situation where data is already in the FIFO whenever data came in faster than the polling could pick it up (which is basically always).
This change obscured the issue in https://bugs.launchpad.net/qemu/+bug/1913341, which instead presented as strange data loss until I locally resolved this issue.
I have a patch ready for the bug and will submit it later today, I'm just filing for clarity.
commit 40b4c2ae90e4f864a1015ff748a4af00518ff0c0
|