On 2017/05/11 17:33, Masanobu SAITOH wrote:
On 2017/05/11 17:20, J. Hannken-Illjes wrote:
The following reply was made to PR kern/52211; it has been noted by GNATS.
From: "J. Hannken-Illjes" <hannken%eis.cs.tu-bs.de@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc:
Subject: Re: kern/52211: vioif stops on dmamap load error
Date: Thu, 11 May 2017 10:18:09 +0200
> On 11. May 2017, at 10:10, Masanobu SAITOH <msaitoh%execsw.org@localhost> wrote:
>
> Coudl you show me the output of ifconfig vioif0?
vioif0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
address: XX:XX:XX:XX:XX:XX
inet XXX.XXX.XXX.XXX netmask 0xffffff00 broadcast XXX.XXX.XXX.255
inet6 fe80::XXXX:XXXX:XXXX:XXXX%vioif0 prefixlen 64 scopeid 0x1
inet6 XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX prefixlen 64
Yes, it has neither TSO nor JUMBO_MTU.
If a lof of mbuf chain is a normal case for vioif(4) it would
worth to try m_defrag(), but I suspect it's not a normal case
and it's caused by a bug in vioif or the upper layer.
--
J. Hannken-Illjes - hannken%eis.cs.tu-bs.de@localhost - TU Braunschweig (Germany)
Could you test with the following diff?
Index: if_vioif.c
===================================================================
RCS file: /cvsroot/src/sys/dev/pci/if_vioif.c,v
retrieving revision 1.34
diff -u -p -r1.34 if_vioif.c
--- if_vioif.c 28 Mar 2017 04:10:33 -0000 1.34
+++ if_vioif.c 11 May 2017 09:10:36 -0000
@@ -833,7 +833,21 @@ retry:
r = bus_dmamap_load_mbuf(virtio_dmat(vsc),
sc->sc_tx_dmamaps[slot],
m, BUS_DMA_WRITE|BUS_DMA_NOWAIT);
- if (r != 0) {
+ switch (r) {
+ case 0:
+ break;
+ case EFBIG:
+ printf("%s: loadup_mbuf() returned EFBIG (%d segs)\n",
+ device_xname(sc->sc_dev),
+ sc->sc_tx_dmamaps[slot]->dm_nsegs);
+ if ((m_defrag(m, M_NOWAIT) == 0) &&
+ (bus_dmamap_load_mbuf(virtio_dmat(vsc),
+ sc->sc_tx_dmamaps[slot],
+ m, BUS_DMA_WRITE|BUS_DMA_NOWAIT) == 0))
+ break;
+
+ /* FALLTHROUGH */
+ default:
virtio_enqueue_abort(vsc, vq, slot);
aprint_error_dev(sc->sc_dev,
"tx dmamap load failed, error code %d\n", r);