On Sun, 15 Dec 2019, Finn Thain wrote:
> I test the qemu build like this,
>
> qemu-system-m68k -M q800 -m 512M -serial none -serial mon:stdio -g 800x600x4
> -net nic,model=dp83932,addr=00:00:00:01:02:03
> -net bridge,helper=/opt/qemu/libexec/qemu-bridge-helper,br=br0
> -append "fbcon=font:ProFont6x11 console=tty0 console=ttyS0 ignore_loglevel"
> -kernel vmlinux-4.14.157-mac-backport+
> -initrd /mnt/loop/install/cdrom/initrd.gz
>
> You can obtain this kernel binary from the linux-mac68k project on
> sourceforge. (I usually use a mainline Linux build but it makes no
> difference.)
>
One difficulty with testing these patches with Linux guests is some old
bugs in drivers/net/ethernet/natsemi/sonic.c that can cause tx watchdog
timeouts on real hardware.
I have some patches for that driver which may be useful when testing
QEMU's hw/net/dp8393x.c device. (I've pushed those patches to my github
repo.)
The second obstacle I have involves testing the dp8393x device with a
bridge device on a Linux/i686 host.
Running tcpdump in the Linux/m68k guest showed these two ping packets from
the host,
00:15:28.480164 IP 192.168.66.1 > 192.168.66.111: ICMP echo request, id 23957,
seq 11, length 64
0x0000: 0800 0702 0304 fe16 d9ae 6943 0800 4500 ..........iC..E.
0x0010: 0054 ff4d 4000 4001 359a c0a8 4201 c0a8 .T.M@.@.5...B...
0x0020: 426f 0800 4243 5d95 000b a0cc f65d cfee Bo..BC]......]..
0x0030: 0600 0809 0a0b 0c0d 0e0f 1011 1213 1415 ................
0x0040: 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 ...........!"#$%
0x0050: 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 &'()*+,-./012345
0x0060: 3637 33e0 14c7 673...
00:15:29.341601 IP truncated-ip - 52 bytes missing! 192.168.66.1 >
192.168.66.111: ICMP echo request, id 23957, seq 12, length 64
0x0000: 0800 0702 0304 fe16 d9ae 6943 0800 4500 ..........iC..E.
0x0010: 0054 ff4e 4000 4001 3599 c0a8 4201 c0a8 .T.N@.@.5...B...
0x0020: 426f 0800 d61a 5d95 000c a0cc f65d Bo....]......]
Sniffing br0 on the host shows no sign of the truncated packet at all
which leaves a gap in the packet sequence numbers captured on the host.
Weird.
When I log the calls to,
static ssize_t dp8393x_receive(NetClientState *nc, const uint8_t * buf,
size_t pkt_size)
the corresponding pkt_size values look like this,
pkt_size 98
pkt_size 42
So this seems to show that the bug is not in dp8393x. Possibly not in
QEMU?
I don't see any options in 'man brctl' that might explain why the host and
guest see different packets. I guess I'll have to find a way to avoid
using bridge interfaces (?)
