Message ID | cover.1576286757.git.fthain@telegraphics.com.au |
---|---|
Headers | show |
Series | Fixes for DP8393X SONIC device emulation | expand |
Patchew URL: https://patchew.org/QEMU/cover.1576286757.git.fthain@telegraphics.com.au/ Hi, This series seems to have some coding style problems. See output below for more information: Subject: [PATCH 00/10] Fixes for DP8393X SONIC device emulation Type: series Message-id: cover.1576286757.git.fthain@telegraphics.com.au === TEST SCRIPT BEGIN === #!/bin/bash git rev-parse base > /dev/null || exit 0 git config --local diff.renamelimit 0 git config --local diff.renames True git config --local diff.algorithm histogram ./scripts/checkpatch.pl --mailback base.. === TEST SCRIPT END === Switched to a new branch 'test' 702b708 dp8393x: Don't clobber packet checksum a6efce5 dp8393x: Don't stop reception upon RBE interrupt assertion 8f04361 dp8393x: Implement packet size limit and RBAE interrupt 19bdaec dp8393x: Implement TBWC0 and TBWC1 registers to restore buffer state d4634fd dp8393x: Clear RRRA command register bit only when appropriate 39e35db dp8393x: Update LLFA register 240cef4 dp8393x: Don't advance RX descriptor twice ba2922d dp8393x: Have dp8393x_receive() return the packet size 8e1c5a6 dp8393x: Clean up endianness hacks 9c9ffc3 dp8393x: Mask EOL bit from descriptor addresses === OUTPUT BEGIN === 1/10 Checking commit 9c9ffc38e9b9 (dp8393x: Mask EOL bit from descriptor addresses) ERROR: return is not a function, parentheses are not required #24: FILE: hw/net/dp8393x.c:200: + return (s->regs[SONIC_URDA] << 16) | (s->regs[SONIC_CRDA] & 0xfffe); ERROR: return is not a function, parentheses are not required #33: FILE: hw/net/dp8393x.c:220: + return (s->regs[SONIC_UTDA] << 16) | (s->regs[SONIC_TTDA] & 0xfffe); total: 2 errors, 0 warnings, 26 lines checked Patch 1/10 has style problems, please review. If any of these errors are false positives report them to the maintainer, see CHECKPATCH in MAINTAINERS. 2/10 Checking commit 8e1c5a688838 (dp8393x: Clean up endianness hacks) 3/10 Checking commit ba2922dc3e93 (dp8393x: Have dp8393x_receive() return the packet size) 4/10 Checking commit 240cef4caaee (dp8393x: Don't advance RX descriptor twice) 5/10 Checking commit 39e35db107bd (dp8393x: Update LLFA register) 6/10 Checking commit d4634fdd244c (dp8393x: Clear RRRA command register bit only when appropriate) 7/10 Checking commit 19bdaec299f1 (dp8393x: Implement TBWC0 and TBWC1 registers to restore buffer state) 8/10 Checking commit 8f04361b6bc8 (dp8393x: Implement packet size limit and RBAE interrupt) 9/10 Checking commit a6efce5b17d0 (dp8393x: Don't stop reception upon RBE interrupt assertion) 10/10 Checking commit 702b708cf099 (dp8393x: Don't clobber packet checksum) === OUTPUT END === Test command exited with code: 1 The full log is available at http://patchew.org/logs/cover.1576286757.git.fthain@telegraphics.com.au/testing.checkpatch/?type=message. --- Email generated automatically by Patchew [https://patchew.org/]. Please send your feedback to patchew-devel@redhat.com
On Fri, 13 Dec 2019, no-reply@patchew.org wrote: > === OUTPUT BEGIN === > 1/10 Checking commit 9c9ffc38e9b9 (dp8393x: Mask EOL bit from descriptor addresses) > ERROR: return is not a function, parentheses are not required > #24: FILE: hw/net/dp8393x.c:200: > + return (s->regs[SONIC_URDA] << 16) | (s->regs[SONIC_CRDA] & 0xfffe); > > ERROR: return is not a function, parentheses are not required > #33: FILE: hw/net/dp8393x.c:220: > + return (s->regs[SONIC_UTDA] << 16) | (s->regs[SONIC_TTDA] & 0xfffe); > I expect that checkpatch.pl has no idea about operator precedence, but these parentheses could actually be omitted. I kept them because I don't want readers to have to remember that bit shift operator has higher precedence than bitwise OR operator, or look it up if they don't. The existing code also has those unnecessary parentheses. Please let me know if this patch should include a code style change.
On 12/14/19 3:52 AM, Finn Thain wrote: > On Fri, 13 Dec 2019, no-reply@patchew.org wrote: > >> === OUTPUT BEGIN === >> 1/10 Checking commit 9c9ffc38e9b9 (dp8393x: Mask EOL bit from descriptor addresses) >> ERROR: return is not a function, parentheses are not required >> #24: FILE: hw/net/dp8393x.c:200: >> + return (s->regs[SONIC_URDA] << 16) | (s->regs[SONIC_CRDA] & 0xfffe); >> >> ERROR: return is not a function, parentheses are not required >> #33: FILE: hw/net/dp8393x.c:220: >> + return (s->regs[SONIC_UTDA] << 16) | (s->regs[SONIC_TTDA] & 0xfffe); >> > > I expect that checkpatch.pl has no idea about operator precedence, but > these parentheses could actually be omitted. > > I kept them because I don't want readers to have to remember that bit > shift operator has higher precedence than bitwise OR operator, or look it > up if they don't. > > The existing code also has those unnecessary parentheses. > > Please let me know if this patch should include a code style change. This is a bug in checkpatch. Since this script doesn't have dedicated maintainer, I Cc'ed the recent contributors: $ ./scripts/get_maintainer.pl -f scripts/checkpatch.pl get_maintainer.pl: No maintainers found, printing recent contributors.
On 12/14/19 7:38 AM, Philippe Mathieu-Daudé wrote: > On 12/14/19 3:52 AM, Finn Thain wrote: >> On Fri, 13 Dec 2019, no-reply@patchew.org wrote: >> >>> === OUTPUT BEGIN === >>> 1/10 Checking commit 9c9ffc38e9b9 (dp8393x: Mask EOL bit from >>> descriptor addresses) >>> ERROR: return is not a function, parentheses are not required >>> #24: FILE: hw/net/dp8393x.c:200: >>> + return (s->regs[SONIC_URDA] << 16) | (s->regs[SONIC_CRDA] & >>> 0xfffe); >>> >>> ERROR: return is not a function, parentheses are not required >>> #33: FILE: hw/net/dp8393x.c:220: >>> + return (s->regs[SONIC_UTDA] << 16) | (s->regs[SONIC_TTDA] & >>> 0xfffe); >>> >> >> I expect that checkpatch.pl has no idea about operator precedence, but >> these parentheses could actually be omitted. You are correct: It's a false positive; you can safely ignore it. >> >> I kept them because I don't want readers to have to remember that bit >> shift operator has higher precedence than bitwise OR operator, or look it >> up if they don't. >> >> The existing code also has those unnecessary parentheses. >> >> Please let me know if this patch should include a code style change. > > This is a bug in checkpatch. Since this script doesn't have dedicated > maintainer, I Cc'ed the recent contributors: However, it's complex enough, and the false positive occurs infrequently enough, that just ignoring it (instead of trying to patch checkpatch) is also fine, and probably what will happen.
On Saturday, December 14, 2019, Finn Thain <fthain@telegraphics.com.au> wrote: > Hi All, > > There is a bug in the DP8393X emulation that can stop packet reception. > > Can you provide the details of your test scenario? Thanks, Aleksandar > Whilst debugging that issue I found that the receiver algorithm differs > from the one described in the National Semiconductor datasheet. > > These issues and others are addressed by this patch series. > > This series has only been tested with Linux/m68k guests. It needs further > testing with MIPS Jazz guests such as NetBSD or Windows NT. > > Thanks. > > > Finn Thain (10): > dp8393x: Mask EOL bit from descriptor addresses > dp8393x: Clean up endianness hacks > dp8393x: Have dp8393x_receive() return the packet size > dp8393x: Don't advance RX descriptor twice > dp8393x: Update LLFA register > dp8393x: Clear RRRA command register bit only when appropriate > dp8393x: Implement TBWC0 and TBWC1 registers to restore buffer state > dp8393x: Implement packet size limit and RBAE interrupt > dp8393x: Don't stop reception upon RBE interrupt assertion > dp8393x: Don't clobber packet checksum > > hw/net/dp8393x.c | 80 +++++++++++++++++++++++++++++++----------------- > 1 file changed, 52 insertions(+), 28 deletions(-) > > -- > 2.23.0 > > >
On Sat, 14 Dec 2019, Aleksandar Markovic wrote: > On Saturday, December 14, 2019, Finn Thain <fthain@telegraphics.com.au> > wrote: > > > Hi All, > > > > There is a bug in the DP8393X emulation that can stop packet reception. > > > > > Can you provide the details of your test scenario? > > Thanks, > Aleksandar > 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.) I normally use a disk image with Debian/m68k SID rootfs but in this example I've used the initrd that you can find on the Debian/m68k installer ISO. Once the guest starts, switch to a different virtual console and bring up the SONIC: <ctrl>-<a> <ctrl>-<a> <2> # ip addr add dev eth0 192.168.65.2/24 # ip link set dev eth0 up On the host, send a ping flood (with preload) to the guest: # ifconfig br0 192.168.65.1/24 # ping 192.168.65.2 -f -l 20 The packet reception ("deaf sonic") issue is reproduced immediately. This has been observed in both qemu-m68k and mainline qemu. See also, https://github.com/vivier/qemu-m68k/commit/0a45280c9fa40da8d5f30b1bb3d0513db91c3909
On Sunday, December 15, 2019, Finn Thain <fthain@telegraphics.com.au> wrote: > On Sat, 14 Dec 2019, Aleksandar Markovic wrote: > > > On Saturday, December 14, 2019, Finn Thain <fthain@telegraphics.com.au> > > wrote: > > > > > Hi All, > > > > > > There is a bug in the DP8393X emulation that can stop packet reception. > > > > > > > > Can you provide the details of your test scenario? > > > > Thanks, > > Aleksandar > > > > 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.) > > I normally use a disk image with Debian/m68k SID rootfs but in this > example I've used the initrd that you can find on the Debian/m68k > installer ISO. > > Once the guest starts, switch to a different virtual console and bring up > the SONIC: > > <ctrl>-<a> <ctrl>-<a> <2> > # ip addr add dev eth0 192.168.65.2/24 > # ip link set dev eth0 up > > On the host, send a ping flood (with preload) to the guest: > > # ifconfig br0 192.168.65.1/24 > # ping 192.168.65.2 -f -l 20 > > The packet reception ("deaf sonic") issue is reproduced immediately. > > This has been observed in both qemu-m68k and mainline qemu. See also, > https://github.com/vivier/qemu-m68k/commit/0a45280c9fa40da8d5f30b1bb3d051 > 3db91c3909 > > Finn, I appreciate your detailed response! Aleksandar
On Sunday, December 15, 2019, Aleksandar Markovic < aleksandar.m.mail@gmail.com> wrote: > > > On Sunday, December 15, 2019, Finn Thain <fthain@telegraphics.com.au> > wrote: > >> On Sat, 14 Dec 2019, Aleksandar Markovic wrote: >> >> > On Saturday, December 14, 2019, Finn Thain <fthain@telegraphics.com.au> >> > wrote: >> > >> > > Hi All, >> > > >> > > There is a bug in the DP8393X emulation that can stop packet >> reception. >> > > >> > > >> > Can you provide the details of your test scenario? >> > >> > Thanks, >> > Aleksandar >> > >> >> 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.) >> >> I normally use a disk image with Debian/m68k SID rootfs but in this >> example I've used the initrd that you can find on the Debian/m68k >> installer ISO. >> >> Once the guest starts, switch to a different virtual console and bring up >> the SONIC: >> >> <ctrl>-<a> <ctrl>-<a> <2> >> # ip addr add dev eth0 192.168.65.2/24 >> # ip link set dev eth0 up >> >> On the host, send a ping flood (with preload) to the guest: >> >> # ifconfig br0 192.168.65.1/24 >> # ping 192.168.65.2 -f -l 20 >> >> The packet reception ("deaf sonic") issue is reproduced immediately. >> >> This has been observed in both qemu-m68k and mainline qemu. See also, >> https://github.com/vivier/qemu-m68k/commit/0a45280c9fa40da8d >> 5f30b1bb3d0513db91c3909 >> >> > Finn, > > I appreciate your detailed response! > > Aleksandar > > Herve, Is there any way for us to come up with an equivalent or at least approximate scenario for Jazz machines? Regards, Aleksandar
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 (?)
On Mon, 16 Dec 2019, Finn Thain wrote: > 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 ... > > 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. I've fixed some bugs and I don't see these problems any more. I'll send v2.
On Sun, 15 Dec 2019, Aleksandar Markovic wrote: > > Herve, > > Is there any way for us to come up with an equivalent or at least > approximate scenario for Jazz machines? > > Regards, > Aleksandar > That would be useful in general, but in this case I think it might be better to test NetBSD, since I have already tested Linux. (I had to fix some bugs in the Linux sonic driver.) I tried to boot NetBSD/arc but failed. I got a blue screen when I typed "cd:boot" at the "Run A Program" prompt in the ARC menu. $ ln -s NTPROM.RAW mipsel_bios.bin $ mips64el-softmmu/qemu-system-mips64el -M magnum -L . -drive if=scsi,unit=2,media=cdrom,format=raw,file=NetBSD-8.1-arc.iso -global ds1225y.filename=nvram -global ds1225y.size=8200 qemu-system-mips64el: g364: invalid read at [0000000000102000] $ Any help would be appreciated.
On Sat, Dec 14, 2019 at 2:29 AM Finn Thain <fthain@telegraphics.com.au> wrote: > > Hi All, > > There is a bug in the DP8393X emulation that can stop packet reception. > > Whilst debugging that issue I found that the receiver algorithm differs > from the one described in the National Semiconductor datasheet. > Finn, could you please provide the link to the exact datasheet that you used for reference, so that we are on the same page while looking at your code? Best regards, Aleksandar > These issues and others are addressed by this patch series. > > This series has only been tested with Linux/m68k guests. It needs further > testing with MIPS Jazz guests such as NetBSD or Windows NT. > > Thanks. > > > Finn Thain (10): > dp8393x: Mask EOL bit from descriptor addresses > dp8393x: Clean up endianness hacks > dp8393x: Have dp8393x_receive() return the packet size > dp8393x: Don't advance RX descriptor twice > dp8393x: Update LLFA register > dp8393x: Clear RRRA command register bit only when appropriate > dp8393x: Implement TBWC0 and TBWC1 registers to restore buffer state > dp8393x: Implement packet size limit and RBAE interrupt > dp8393x: Don't stop reception upon RBE interrupt assertion > dp8393x: Don't clobber packet checksum > > hw/net/dp8393x.c | 80 +++++++++++++++++++++++++++++++----------------- > 1 file changed, 52 insertions(+), 28 deletions(-) > > -- > 2.23.0 > >
On Fri, Dec 20, 2019 at 12:38 PM Aleksandar Markovic <aleksandar.m.mail@gmail.com> wrote: > > On Sat, Dec 14, 2019 at 2:29 AM Finn Thain <fthain@telegraphics.com.au> wrote: > > > > Hi All, > > > > There is a bug in the DP8393X emulation that can stop packet reception. > > > > Whilst debugging that issue I found that the receiver algorithm differs > > from the one described in the National Semiconductor datasheet. > > > > Finn, could you please provide the link to the exact datasheet that or, several datasheets... > you used for reference, so that we are on the same page while looking > at your code? > > Best regards, > Aleksandar > > > These issues and others are addressed by this patch series. > > > > This series has only been tested with Linux/m68k guests. It needs further > > testing with MIPS Jazz guests such as NetBSD or Windows NT. > > > > Thanks. > > > > > > Finn Thain (10): > > dp8393x: Mask EOL bit from descriptor addresses > > dp8393x: Clean up endianness hacks > > dp8393x: Have dp8393x_receive() return the packet size > > dp8393x: Don't advance RX descriptor twice > > dp8393x: Update LLFA register > > dp8393x: Clear RRRA command register bit only when appropriate > > dp8393x: Implement TBWC0 and TBWC1 registers to restore buffer state > > dp8393x: Implement packet size limit and RBAE interrupt > > dp8393x: Don't stop reception upon RBE interrupt assertion > > dp8393x: Don't clobber packet checksum > > > > hw/net/dp8393x.c | 80 +++++++++++++++++++++++++++++++----------------- > > 1 file changed, 52 insertions(+), 28 deletions(-) > > > > -- > > 2.23.0 > > > >
Le 20/12/2019 à 12:38, Aleksandar Markovic a écrit : > On Sat, Dec 14, 2019 at 2:29 AM Finn Thain <fthain@telegraphics.com.au> wrote: >> >> Hi All, >> >> There is a bug in the DP8393X emulation that can stop packet reception. >> >> Whilst debugging that issue I found that the receiver algorithm differs >> from the one described in the National Semiconductor datasheet. >> > > Finn, could you please provide the link to the exact datasheet that > you used for reference, so that we are on the same page while looking > at your code? According to his comments ,"National Semiconductor DP83932C" and sections seem to be the same, I think the datasheet is: https://www.eit.lth.se/fileadmin/eit/courses/datablad/Periphery/Communication/DP83932C.pdf Thanks, Laurent
On Fri, 20 Dec 2019, Laurent Vivier wrote: > Le 20/12/2019 ? 12:38, Aleksandar Markovic a ?crit?: > > On Sat, Dec 14, 2019 at 2:29 AM Finn Thain <fthain@telegraphics.com.au> wrote: > >> > >> Hi All, > >> > >> There is a bug in the DP8393X emulation that can stop packet reception. > >> > >> Whilst debugging that issue I found that the receiver algorithm differs > >> from the one described in the National Semiconductor datasheet. > >> > > > > Finn, could you please provide the link to the exact datasheet that > > you used for reference, so that we are on the same page while looking > > at your code? > > According to his comments ,"National Semiconductor DP83932C" and > sections seem to be the same, I think the datasheet is: > > https://www.eit.lth.se/fileadmin/eit/courses/datablad/Periphery/Communication/DP83932C.pdf > Yes. I know of 3 datasheets from National Semiconductor, 11719 DP83934CVUL-20/25 MHz SONIC-T Systems-Oriented Network Interface Controller with Twisted Pair Interface 10492 DP83932C-20/25/33 MHz SONIC Systems-Oriented Network Interface Controller 11722 DP83916 SONIC-16 Systems-Oriented Network Interface Controller The publication numbered 10492 is the one that Laurent linked to. It and 11722 both have the same table of contents. The references I gave in the patch descriptions are applicable to these. (Having said that, I see now that I did mess up one reference. I'll fix it.) The "1995 National Ethernet Databook" on bitsavers has more information. https://mirrorservice.org/sites/www.bitsavers.org/components/national/_dataBooks/1995_National_Ethernet_Databook.pdf
On Saturday, December 21, 2019, Finn Thain <fthain@telegraphics.com.au> wrote: > On Fri, 20 Dec 2019, Laurent Vivier wrote: > > > Le 20/12/2019 ? 12:38, Aleksandar Markovic a ?crit?: > > > On Sat, Dec 14, 2019 at 2:29 AM Finn Thain <fthain@telegraphics.com.au> > wrote: > > >> > > >> Hi All, > > >> > > >> There is a bug in the DP8393X emulation that can stop packet > reception. > > >> > > >> Whilst debugging that issue I found that the receiver algorithm > differs > > >> from the one described in the National Semiconductor datasheet. > > >> > > > > > > Finn, could you please provide the link to the exact datasheet that > > > you used for reference, so that we are on the same page while looking > > > at your code? > > > > According to his comments ,"National Semiconductor DP83932C" and > > sections seem to be the same, I think the datasheet is: > > > > https://www.eit.lth.se/fileadmin/eit/courses/datablad/Periphery/ > Communication/DP83932C.pdf > > > > Yes. I know of 3 datasheets from National Semiconductor, > > 11719 DP83934CVUL-20/25 MHz SONIC-T Systems-Oriented Network Interface > Controller with Twisted Pair Interface > 10492 DP83932C-20/25/33 MHz SONIC Systems-Oriented Network Interface > Controller > 11722 DP83916 SONIC-16 Systems-Oriented Network Interface Controller > > The publication numbered 10492 is the one that Laurent linked to. It and > 11722 both have the same table of contents. The references I gave in the > patch descriptions are applicable to these. (Having said that, I see now > that I did mess up one reference. I'll fix it.) > > The "1995 National Ethernet Databook" on bitsavers has more information. > https://mirrorservice.org/sites/www.bitsavers.org/components/national/_ > dataBooks/1995_National_Ethernet_Databook.pdf > > -- Finn, I truly appreciate your detailed response. Aleksandar > > Thanks, > > Laurent > > >
Hi Finn, On 12/20/19 5:24 AM, Finn Thain wrote: > On Sun, 15 Dec 2019, Aleksandar Markovic wrote: > >> >> Herve, >> >> Is there any way for us to come up with an equivalent or at least >> approximate scenario for Jazz machines? >> >> Regards, >> Aleksandar >> > > That would be useful in general, but in this case I think it might be > better to test NetBSD, since I have already tested Linux. (I had to fix > some bugs in the Linux sonic driver.) > > I tried to boot NetBSD/arc but failed. I got a blue screen when I typed > "cd:boot" at the "Run A Program" prompt in the ARC menu. > > $ ln -s NTPROM.RAW mipsel_bios.bin > $ mips64el-softmmu/qemu-system-mips64el -M magnum -L . > -drive if=scsi,unit=2,media=cdrom,format=raw,file=NetBSD-8.1-arc.iso > -global ds1225y.filename=nvram -global ds1225y.size=8200 > qemu-system-mips64el: g364: invalid read at [0000000000102000] > $ > > Any help would be appreciated. Please open a new bug entry with this information at https://bugs.launchpad.net/qemu/+filebug Thanks, Phil.
On Mon, 23 Dec 2019, Philippe Mathieu-Daud? wrote: > Hi Finn, > > On 12/20/19 5:24 AM, Finn Thain wrote: > > On Sun, 15 Dec 2019, Aleksandar Markovic wrote: > > > > > > > > Herve, > > > > > > Is there any way for us to come up with an equivalent or at least > > > approximate scenario for Jazz machines? > > > > > > Regards, > > > Aleksandar > > > > > > > That would be useful in general, but in this case I think it might be > > better to test NetBSD, since I have already tested Linux. (I had to fix > > some bugs in the Linux sonic driver.) > > > > I tried to boot NetBSD/arc but failed. I got a blue screen when I typed > > "cd:boot" at the "Run A Program" prompt in the ARC menu. > > > > $ ln -s NTPROM.RAW mipsel_bios.bin > > $ mips64el-softmmu/qemu-system-mips64el -M magnum -L . > > -drive if=scsi,unit=2,media=cdrom,format=raw,file=NetBSD-8.1-arc.iso > > -global ds1225y.filename=nvram -global ds1225y.size=8200 > > qemu-system-mips64el: g364: invalid read at [0000000000102000] > > $ > > > > Any help would be appreciated. > > Please open a new bug entry with this information at > https://bugs.launchpad.net/qemu/+filebug > I know precious little about NetBSD installation and MIPS Magnum. What I wrote above was guesswork. Hence this could be a NetBSD bug or user error. Does there exist a known-good combination of NetBSD/arc and qemu-system-mips64el releases? If so, I could use that to check for user error or possible NetBSD issue. > Thanks, > > Phil. > >
On Tue, 24 Dec 2019, Finn Thain wrote: > > I know precious little about NetBSD installation and MIPS Magnum. What I > wrote above was guesswork. Hence this could be a NetBSD bug or user > error. > It was bugs and user error. The user error was not using the serial console. The NetBSD/arc installation guide says that only serial console is supported for MIPS Magnum. The bugs include regressions in NetBSD. (See below.) The other issue is that the ARC firmware didn't work properly until I defined one or more 'boot selections', even though none of these will ever be selected. > Does there exist a known-good combination of NetBSD/arc and > qemu-system-mips64el releases? > The commit log says that Herv? Poussineau used NetBSD 5.1 with dp8393x in the past, so I tried that. Here are the steps I used: ./mips64el-softmmu/qemu-system-mips64el -M magnum -L . -drive if=scsi,unit=2,media=cdrom,format=raw,file=arccd-5.1.iso -global ds1225y.filename=nvram -global ds1225y.size=8200 -serial stdio -serial null -nic bridge,model=dp83932,mac=00:00:00:02:03:04 -> Run setup -> Initialize system -> Set default configurations 800x688 3.5 1.44 M No 7 -> Set default environment CD-ROM 2 -> Set environment variables CONSOLEIN multi()serial(0)term() CONSOLEOUT multi()serial(0)term() -> Exit Now restart QEMU. The ARC menu should appear on the tty. -> Run a program scsi(0)cdrom(2)fdisk(0)boot scsi(0)cdrom(2)fdisk(0)netbsd That doesn't work. Add a boot selection. -> Run setup -> Manage startup -> Add a boot selection -> Scsi CD-ROM 0 \os\nt\osloader.exe Yes \winnt Windows NT No Somehow, that seems to help. Now restart QEMU. -> Run a program scsi(0)cdrom(2)fdisk(0)boot scsi(0)cdrom(2)fdisk(0)netbsd NetBSD/arc Bootstrap, Revision 1.1 (builds@b7.netbsd.org, Sat Nov 6 14:06:36 UTC 2010) devopen: scsi(0)cdrom(2)fdisk(0) type disk file netbsd 5502064+289092=0x5860e0 Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010 The NetBSD Foundation, Inc. All rights reserved. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. NetBSD 5.1 (RAMDISK) #0: Sat Nov 6 14:17:36 UTC 2010 builds@b7.netbsd.org:/home/builds/ab/netbsd-5-1-RELEASE/arc/201011061943Z-obj/home/builds/ab/netbsd-5-1-RELEASE/src/sys/arch/arc/compile/RAMDISK MIPS Magnum total memory = 128 MB avail memory = 117 MB mainbus0 (root) cpu0 at mainbus0: MIPS R4000 CPU (0x400) Rev. 0.0 with MIPS R4010 FPC Rev. 0.0 cpu0: 8KB/16B direct-mapped L1 Instruction cache, 48 TLB entries cpu0: 8KB/16B direct-mapped write-back L1 Data cache jazzio0 at mainbus0 timer0 at jazzio0 addr 0xe0000228 mcclock0 at jazzio0 addr 0xe0004000: mc146818 compatible time-of-day clock LPT1 at jazzio0 addr 0xe0008000 intr 0 not configured fdc0 at jazzio0 addr 0xe0003000 intr 1 fd0 at fdc0 drive 1: 1.44MB, 80 cyl, 2 head, 18 sec MAGNUM at jazzio0 addr 0xe000c000 intr 2 not configured VXL at jazzio0 addr 0xe0800000 intr 3 not configured sn0 at jazzio0 addr 0xe0001000 intr 4: SONIC Ethernet sonic: write 0x0015 to reg CR sonic: write 0x0080 to reg CR sonic: write 0x0000 to reg IMR sonic: write 0x7fff to reg ISR sonic: write 0x0000 to reg CR sn0: Ethernet address 00:00:00:00:00:00 asc0 at jazzio0 addr 0xe0002000 intr 5: NCR53C94, 25MHz, SCSI ID 7 scsibus0 at asc0: 8 targets, 8 luns per target pckbc0 at jazzio0 addr 0xe0005000 intr 6 pckbd0 at pckbc0 (kbd slot) wskbd0 at pckbd0 (mux ignored) pms at jazzio0 addr 0xe0005000 intr 7 not configured com0 at jazzio0 addr 0xe0006000 intr 8: ns16550a, working fifo com0: txfifo disabled com0: console com1 at jazzio0 addr 0xe0007000 intr 9: ns16550a, working fifo com1: txfifo disabled jazzisabr0 at mainbus0 isa0 at jazzisabr0 isapnp0 at isa0 port 0x279: ISA Plug 'n Play device support scsibus0: waiting 2 seconds for devices to settle... cd0 at scsibus0 target 2 lun 0: <QEMU, QEMU CD-ROM, 2.5+> cdrom removable cd1 at scsibus0 target 4 lun 0: <QEMU, QEMU CD-ROM, 2.5+> cdrom removable boot device: <unknown> root on md0a dumps on md0b root file system type: ffs WARNING: preposterous TOD clock time WARNING: using filesystem time WARNING: CHECK AND RESET THE DATE! erase ^H, werase ^W, kill ^U, intr ^C, status ^T Terminal type? [vt100] Erase is backspace. (I)nstall, (S)hell or (H)alt ? s # ifconfig sn0 10.2.3.4/24 # ping usage: ping [-adDfLnoPqQrRv] [-c count] [-g gateway] [-h host] [-i interval] [-I addr] [-l preload] [-p pattern] [-s size] [-t tos] [-T ttl] [-w maxwait] host My initial testing shows that NetBSD 5.1 doesn't like my v2 patch series. I'll debug that before I send v3. BTW, there seem to be regressions in NetBSD 8.1 compared to NetBSD 5.1. The 'boot' program on the 8.1 ISO just hangs. If I use the 'boot' program from the 5.1 ISO to load the 'netbsd' binary from the 8.1 ISO, I get a crash: -> Run a program scsi(0)cdrom(2)fdisk(0)boot scsi(0)cdrom(4)fdisk(0)netbsd NetBSD/arc Bootstrap, Revision 1.1 (builds@b7.netbsd.org, Sat Nov 6 14:06:36 UTC 2010) devopen: scsi(0)cdrom(4)fdisk(0) type disk file netbsd 7902064| Jazz Monitor. Version 174 Press H for help, Q to quit. AdEL exception occurred. at=149f4800 v0=00000000 v1=8003d698 a0=807f3d40 a1=80eff158 a2=00000800 a3=80eff188 t0=00000001 t1=00000001 t2=80045400 t3=800232d8 t4=000a4fa4 t5=00000000 t6=00746669 t7=00746685 s0=80f0cab8 s1=00000800 s2=80eff1d0 s3=80f10000 s4=80f0ee18 s5=80f0ee18 s6=00028eef s7=00000000 t8=00746685 t9=c0000000 k0=80041f50 k1=80000194 gp=80f0c540 sp=80eff128 s8=80f0ca30 ra=80023310 psr=20000803 epc=8002331c cause=00004010 errorepc=00000000 badvaddr=00746689 > I haven't tried the latest iso (9.0-rc1).
Le 24/12/2019 à 05:33, Finn Thain a écrit : > On Tue, 24 Dec 2019, Finn Thain wrote: > >> >> I know precious little about NetBSD installation and MIPS Magnum. What I >> wrote above was guesswork. Hence this could be a NetBSD bug or user >> error. >> > > It was bugs and user error. > > The user error was not using the serial console. The NetBSD/arc > installation guide says that only serial console is supported for MIPS > Magnum. > > The bugs include regressions in NetBSD. (See below.) > > The other issue is that the ARC firmware didn't work properly until I > defined one or more 'boot selections', even though none of these will ever > be selected. > >> Does there exist a known-good combination of NetBSD/arc and >> qemu-system-mips64el releases? >> > > The commit log says that Herv? Poussineau used NetBSD 5.1 with dp8393x in > the past, so I tried that. > > Here are the steps I used: > > ./mips64el-softmmu/qemu-system-mips64el -M magnum -L . > -drive if=scsi,unit=2,media=cdrom,format=raw,file=arccd-5.1.iso > -global ds1225y.filename=nvram -global ds1225y.size=8200 > -serial stdio -serial null > -nic bridge,model=dp83932,mac=00:00:00:02:03:04 > > -> Run setup -> Initialize system -> Set default configurations > 800x688 > 3.5 1.44 M > No > 7 > > -> Set default environment > CD-ROM > 2 > > -> Set environment variables > CONSOLEIN > multi()serial(0)term() > CONSOLEOUT > multi()serial(0)term() > > -> Exit > > Now restart QEMU. The ARC menu should appear on the tty. > > -> Run a program > > scsi(0)cdrom(2)fdisk(0)boot scsi(0)cdrom(2)fdisk(0)netbsd > > That doesn't work. Add a boot selection. > > -> Run setup -> Manage startup -> Add a boot selection -> Scsi CD-ROM 0 > \os\nt\osloader.exe > Yes > \winnt > Windows NT > No > > Somehow, that seems to help. Now restart QEMU. > > -> Run a program > > scsi(0)cdrom(2)fdisk(0)boot scsi(0)cdrom(2)fdisk(0)netbsd > > NetBSD/arc Bootstrap, Revision 1.1 > (builds@b7.netbsd.org, Sat Nov 6 14:06:36 UTC 2010) > devopen: scsi(0)cdrom(2)fdisk(0) type disk file netbsd > 5502064+289092=0x5860e0 > Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, > 2006, 2007, 2008, 2009, 2010 > The NetBSD Foundation, Inc. All rights reserved. > Copyright (c) 1982, 1986, 1989, 1991, 1993 > The Regents of the University of California. All rights reserved. > > NetBSD 5.1 (RAMDISK) #0: Sat Nov 6 14:17:36 UTC 2010 > builds@b7.netbsd.org:/home/builds/ab/netbsd-5-1-RELEASE/arc/201011061943Z-obj/home/builds/ab/netbsd-5-1-RELEASE/src/sys/arch/arc/compile/RAMDISK > MIPS Magnum > total memory = 128 MB > avail memory = 117 MB > mainbus0 (root) > cpu0 at mainbus0: MIPS R4000 CPU (0x400) Rev. 0.0 with MIPS R4010 FPC Rev. 0.0 > cpu0: 8KB/16B direct-mapped L1 Instruction cache, 48 TLB entries > cpu0: 8KB/16B direct-mapped write-back L1 Data cache > jazzio0 at mainbus0 > timer0 at jazzio0 addr 0xe0000228 > mcclock0 at jazzio0 addr 0xe0004000: mc146818 compatible time-of-day clock > LPT1 at jazzio0 addr 0xe0008000 intr 0 not configured > fdc0 at jazzio0 addr 0xe0003000 intr 1 > fd0 at fdc0 drive 1: 1.44MB, 80 cyl, 2 head, 18 sec > MAGNUM at jazzio0 addr 0xe000c000 intr 2 not configured > VXL at jazzio0 addr 0xe0800000 intr 3 not configured > sn0 at jazzio0 addr 0xe0001000 intr 4: SONIC Ethernet > sonic: write 0x0015 to reg CR > sonic: write 0x0080 to reg CR > sonic: write 0x0000 to reg IMR > sonic: write 0x7fff to reg ISR > sonic: write 0x0000 to reg CR > sn0: Ethernet address 00:00:00:00:00:00 > asc0 at jazzio0 addr 0xe0002000 intr 5: NCR53C94, 25MHz, SCSI ID 7 > scsibus0 at asc0: 8 targets, 8 luns per target > pckbc0 at jazzio0 addr 0xe0005000 intr 6 > pckbd0 at pckbc0 (kbd slot) > wskbd0 at pckbd0 (mux ignored) > pms at jazzio0 addr 0xe0005000 intr 7 not configured > com0 at jazzio0 addr 0xe0006000 intr 8: ns16550a, working fifo > com0: txfifo disabled > com0: console > com1 at jazzio0 addr 0xe0007000 intr 9: ns16550a, working fifo > com1: txfifo disabled > jazzisabr0 at mainbus0 > isa0 at jazzisabr0 > isapnp0 at isa0 port 0x279: ISA Plug 'n Play device support > scsibus0: waiting 2 seconds for devices to settle... > cd0 at scsibus0 target 2 lun 0: <QEMU, QEMU CD-ROM, 2.5+> cdrom removable > cd1 at scsibus0 target 4 lun 0: <QEMU, QEMU CD-ROM, 2.5+> cdrom removable > boot device: <unknown> > root on md0a dumps on md0b > root file system type: ffs > WARNING: preposterous TOD clock time > WARNING: using filesystem time > WARNING: CHECK AND RESET THE DATE! > erase ^H, werase ^W, kill ^U, intr ^C, status ^T > Terminal type? [vt100] > Erase is backspace. > (I)nstall, (S)hell or (H)alt ? s > # ifconfig sn0 10.2.3.4/24 > # ping > usage: > ping [-adDfLnoPqQrRv] [-c count] [-g gateway] [-h host] [-i interval] [-I addr] > [-l preload] [-p pattern] [-s size] [-t tos] [-T ttl] [-w maxwait] host > > > My initial testing shows that NetBSD 5.1 doesn't like my v2 patch series. > I'll debug that before I send v3. > > BTW, there seem to be regressions in NetBSD 8.1 compared to NetBSD 5.1. > > The 'boot' program on the 8.1 ISO just hangs. > > If I use the 'boot' program from the 5.1 ISO to load the 'netbsd' > binary from the 8.1 ISO, I get a crash: > > -> Run a program > > scsi(0)cdrom(2)fdisk(0)boot scsi(0)cdrom(4)fdisk(0)netbsd > > NetBSD/arc Bootstrap, Revision 1.1 > (builds@b7.netbsd.org, Sat Nov 6 14:06:36 UTC 2010) > devopen: scsi(0)cdrom(4)fdisk(0) type disk file netbsd > 7902064| > Jazz Monitor. Version 174 > Press H for help, Q to quit. > AdEL exception occurred. > at=149f4800 v0=00000000 v1=8003d698 a0=807f3d40 a1=80eff158 a2=00000800 > a3=80eff188 t0=00000001 t1=00000001 t2=80045400 t3=800232d8 t4=000a4fa4 > t5=00000000 t6=00746669 t7=00746685 s0=80f0cab8 s1=00000800 s2=80eff1d0 > s3=80f10000 s4=80f0ee18 s5=80f0ee18 s6=00028eef s7=00000000 t8=00746685 > t9=c0000000 k0=80041f50 k1=80000194 gp=80f0c540 sp=80eff128 s8=80f0ca30 > ra=80023310 psr=20000803 epc=8002331c cause=00004010 errorepc=00000000 > badvaddr=00746689 >> > > I haven't tried the latest iso (9.0-rc1). > Hello Finn, Thanks for finding the required steps to boot NetBSD on MIPS Magnum. I was trying to find how to let it work on non-configured machine since some days! You indeed need my patch at https://lists.gnu.org/archive/html/qemu-devel/2019-12/msg05037.html My test for networking is: - Terminal type = "vt100" - (S)hell - ifconfig sn0 10.0.2.15 netmask 255.255.255.0 - route add default 10.0.2.2 - connect to ftp.intel.com: ftp 192.198.164.82 Regards, Hervé
On Tue, 24 Dec 2019, hpoussin@reactos.org wrote: > > > > I haven't tried the latest iso (9.0-rc1). > > I found that NetBSD 9.0-rc1 has the same regressions. > > Hello Finn, > > Thanks for finding the required steps to boot NetBSD on MIPS Magnum. I > was trying to find how to let it work on non-configured machine since > some days! > You indeed need my patch at > https://lists.gnu.org/archive/html/qemu-devel/2019-12/msg05037.html > Thanks. As it turned out, I didn't need that patch in order to get NetBSD/arc 5.1 working. But I applied the patch anyway after I found that a Linux/mips kernel produced DMA errors. But the errors remain (see below). With a few minor Linux patches and a mipsel busybox build, I was able to boot to a prompt. ESP SCSI works, but not SONIC ethernet. My dp8393x patch series was not sufficient to make ethernet work (no regression though). NetBSD/arc Bootstrap, Revision 1.1 (builds@b7.netbsd.org, Sat Nov 6 14:06:36 UTC 2010) devopen: scsi(0)cdrom(4)fdisk(0) type disk file vmlinux 5991052+141348 [656192+872841]=0x74eb98 Linux version 5.4.0-00003-g34add35b08c0 (fthain@nippy) (gcc version 4.6.4 (btc)) #24 Mon Jan 6 20:10:57 AEDT 2020 ARCH: Microsoft-Jazz PROMLIB: ARC firmware Version 1 Revision 2 CPU0 revision is: 00000400 (R4000PC) FPU revision is: 00000500 printk: debug: ignoring loglevel setting. Primary instruction cache 8kB, VIPT, direct mapped, linesize 16 bytes. Primary data cache 8kB, direct mapped, VIPT, cache aliases, linesize 16 bytes Zone ranges: DMA [mem 0x0000000000000000-0x0000000000ffffff] Normal [mem 0x0000000001000000-0x0000000007ffffff] Movable zone start for each node Early memory node ranges node 0: [mem 0x0000000000000000-0x0000000007ffffff] Initmem setup node 0 [mem 0x0000000000000000-0x0000000007ffffff] On node 0 totalpages: 32768 DMA zone: 32 pages used for memmap DMA zone: 0 pages reserved DMA zone: 4096 pages, LIFO batch:0 Normal zone: 224 pages used for memmap Normal zone: 28672 pages, LIFO batch:7 pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 pcpu-alloc: [0] 0 Built 1 zonelists, mobility grouping on. Total pages: 32512 Kernel command line: scsi(0)cdrom(4)fdisk(0)vmlinux root=/dev/sda rw ignore_loglevel ip=192.168.66.11 init=/bin/sh Dentry cache hash table entries: 16384 (order: 4, 65536 bytes, linear) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes, linear) mem auto-init: stack:off, heap alloc:off, heap free:off Memory: 123396K/131072K available (4716K kernel code, 168K rwdata, 812K rodata, 184K init, 100K bss, 7676K reserved, 0K cma-reserved) NR_IRQS: 128 random: get_random_bytes called from start_kernel+0x32c/0x4e0 with crng_init=0 Console: colour dummy device 80x25 sched_clock: 32 bits at 100 Hz, resolution 10000000ns, wraps every 21474836475000000ns Calibrating delay loop... 990.41 BogoMIPS (lpj=4952064) pid_max: default: 32768 minimum: 301 Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear) Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear) devtmpfs: initialized clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns futex hash table entries: 256 (order: -1, 3072 bytes, linear) NET: Registered protocol family 16 VDMA: R4030 DMA pagetables initialized. SCSI subsystem initialized NET: Registered protocol family 2 tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 4096 bytes, linear) TCP established hash table entries: 1024 (order: 0, 4096 bytes, linear) TCP bind hash table entries: 1024 (order: 0, 4096 bytes, linear) TCP: Hash tables configured (established 1024 bind 1024) UDP hash table entries: 256 (order: 0, 4096 bytes, linear) UDP-Lite hash table entries: 256 (order: 0, 4096 bytes, linear) NET: Registered protocol family 1 workingset: timestamp_bits=30 max_order=15 bucket_order=0 Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254) io scheduler mq-deadline registered io scheduler kyber registered Console: switching to colour frame buffer device 100x37 Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled printk: console [ttyS0] disabled serial8250.0: ttyS0 at MMIO 0xe0006000 (irq = 32, base_baud = 115200) is a 16550A printk: console [ttyS0] enabled serial8250.0: ttyS1 at MMIO 0xe0007000 (irq = 33, base_baud = 115200) is a 16550A loop: module loaded jazz_esp jazz_esp.0: esp0: regs[(ptrval):(ptrval)] irq[29] jazz_esp jazz_esp.0: esp0: is a FAS100A, 40 MHz (ccf=0), SCSI ID 7 random: fast init done scsi host0: esp scsi 0:0:0:0: Direct-Access QEMU QEMU HARDDISK 2.5+ PQ: 0 ANSI: 5 scsi target0:0:0: Beginning Domain Validation scsi target0:0:0: Domain Validation skipping write tests scsi target0:0:0: Ending Domain Validation scsi 0:0:2:0: CD-ROM QEMU QEMU CD-ROM 2.5+ PQ: 0 ANSI: 5 scsi target0:0:2: Beginning Domain Validation scsi target0:0:2: Domain Validation skipping write tests scsi target0:0:2: Ending Domain Validation scsi 0:0:4:0: CD-ROM QEMU QEMU CD-ROM 2.5+ PQ: 0 ANSI: 5 scsi target0:0:4: Beginning Domain Validation scsi target0:0:4: Domain Validation skipping write tests scsi target0:0:4: Ending Domain Validation sd 0:0:0:0: [sda] 120000 512-byte logical blocks: (61.4 MB/58.6 MiB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 63 00 00 08 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA SONIC ethernet @e0001000, MAC 01:00:1c:00:01:00, IRQ 28 serio: i8042 KBD port at 0xe0005000,0xe0005001 irq 30 serio: i8042 AUX port at 0xe0005000,0xe0005001 irq 31 NET: Registered protocol family 10 Segment Routing with IPv6 sd 0:0:0:0: [sda] Attached SCSI disk sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver input: AT Raw Set 2 keyboard as /devices/platform/i8042/serio0/input/input0 input: ImExPS/2 Generic Explorer Mouse as /devices/platform/i8042/serio1/input/input2 EXT4-fs (sda): warning: mounting unchecked fs, running e2fsck is recommended EXT4-fs (sda): mounted filesystem without journal. Opts: (null) VFS: Mounted root (ext4 filesystem) on device 8:0. Freeing prom memory: 376k freed Freeing prom memory: 60k freed Freeing prom memory: 4k freed Freeing unused kernel memory: 184K This architecture does not have kernel memory protection. Run /bin/sh as init process VDMA: Channel 0: Address error! VDMA: Channel 0: Memory error! The patches may be found at, https://github.com/fthain/linux/commits/magnum https://github.com/fthain/linux/commits/mac68k https://github.com/fthain/qemu/commits/sonic I'll post them when I've finished testing.