summaryrefslogtreecommitdiffstats
path: root/results/classifier/gemma3:12b/network/2143
diff options
context:
space:
mode:
authorChristian Krinitsin <mail@krinitsin.com>2025-07-03 07:27:52 +0000
committerChristian Krinitsin <mail@krinitsin.com>2025-07-03 07:27:52 +0000
commitd0c85e36e4de67af628d54e9ab577cc3fad7796a (patch)
treef8f784b0f04343b90516a338d6df81df3a85dfa2 /results/classifier/gemma3:12b/network/2143
parent7f4364274750eb8cb39a3e7493132fca1c01232e (diff)
downloademulator-bug-study-d0c85e36e4de67af628d54e9ab577cc3fad7796a.tar.gz
emulator-bug-study-d0c85e36e4de67af628d54e9ab577cc3fad7796a.zip
add deepseek and gemma results
Diffstat (limited to 'results/classifier/gemma3:12b/network/2143')
-rw-r--r--results/classifier/gemma3:12b/network/214339
1 files changed, 39 insertions, 0 deletions
diff --git a/results/classifier/gemma3:12b/network/2143 b/results/classifier/gemma3:12b/network/2143
new file mode 100644
index 00000000..f33a46a2
--- /dev/null
+++ b/results/classifier/gemma3:12b/network/2143
@@ -0,0 +1,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
+```