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
|
ladr_match can cause bus error due to unaligned fetch
Description of problem:
On a SPARC host system, which does not support unaligned fetches, QEMU sometimes takes a bus error in ladr_match.
Steps to reproduce:
1. (see QEMU command line above)
2. let the system boot
3.
Additional information:
Problem is a hack in ladr_match - hw/net/pcnet.c:635 (present since 2006!):
```
Core was generated by `./qemu-system-sparc -rtc base=utc,clock=host -vga cg3 -g 1024x768x8 -machine SS'.
Program terminated with signal SIGKILL, Killed.
#0 0xffffffff7ec3b178 in ladr_match (size=110, buf=0xffffffff7ffee972 "33", s=0x808f2a20) at ../hw/net/pcnet.c:634
634 if ((*(hdr->ether_dhost)&0x01) &&
[Current thread is 632 (LWP 1 )]
(gdb) list
629 }
630
631 static inline int ladr_match(PCNetState *s, const uint8_t *buf, int size)
632 {
633 struct qemu_ether_header *hdr = (void *)buf;
634 if ((*(hdr->ether_dhost)&0x01) &&
635 ((uint64_t *)&s->csr[8])[0] != 0LL) {
636 uint8_t ladr[8] = {
637 s->csr[8] & 0xff, s->csr[8] >> 8,
638 s->csr[9] & 0xff, s->csr[9] >> 8,
(gdb) print &s->csr[8]
$1 = (uint16_t *) 0x808f4a7c
```
The address of s->csr[8], in this case, is on a 4-byte boundary not an 8-byte boundary, so the hack to test for 8 bytes (4 x 16-bit words) being 0 by casting the address up to a pointer to uint64_t and dereferencing it fails.
The data does not seem to be allocated with a deterministic alignment, this failure does not always occur.
A solution to avoid alignment errors could be to test
```
(s->csr[8] | s->csr[9] | s->csr[10] | s->csr[11]) != 0
```
|