Hello,

I'm working on a new network driver under NetBSD/powerpc 2.0_RC3,
and discovered that the hardware goes off into an unexpected state
when it gets a DMA entry with length zero.  It's easily reproduced
with ping requests (see below), and goes away with a 2-line
workaround in _bus_dmamap_load_mbuf.  Does anybody have an opinion
as to the severity of this: can it be silently ignored as expected
mbuf behaviour, print a warning, or panic?

Note that there's a small chance our local changes to ether_output
are causing this particular instance, although I'm told that they
are not configured and therefore inactive.

*** driver output on the target:
Bogus dmamap:
  seg[0] addr=0x29e002 len=1514
  seg[1] addr=0x29e824 len=0
mbuf chain: pkthdr.len=1514
   EXT=1 m_data=0x29e002 m_len=1514
   EXT=1 m_data=0x29e824 m_len=0
rest of packet from ip_output():
-mbuf: 0x296500
   EXT=0 m_data=0x296544 m_len=20
   EXT=1 m_data=0x29e824 m_len=533


*** tcpdump on the host:
18:42:22.300596 192.168.1.1 > 192.168.1.100: icmp: echo request (frag 
22438:1480@0+)
18:42:22.300669 192.168.1.1 > 192.168.1.100: (frag 22438:532@1480)
18:42:22.304049 192.168.1.100 > 192.168.1.1: icmp: echo reply (frag 
777:1480@0+)
18:42:22.304509 192.168.1.100 > 192.168.1.1: (frag 777:532@1480)
18:42:25.711144 192.168.1.1 > 192.168.1.100: icmp: echo request (frag 
22440:1480@0+)
18:42:25.711216 192.168.1.1 > 192.168.1.100: (frag 22440:533@1480)


*** ping commands on the host:
## 56 nb:~/ >> ping -c 1 -s 2004 -P 192.168.1.100
PING 192.168.1.100 (192.168.1.100): 2004 data bytes
2012 bytes from 192.168.1.100: icmp_seq=0 ttl=255 time=3.999 ms

----192.168.1.100 PING Statistics----
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 3.999/3.999/3.999/0.000 ms
## 57 nb:~/ >> ping -c 1 -s 2005 -P 192.168.1.100
PING 192.168.1.100 (192.168.1.100): 2005 data bytes

----192.168.1.100 PING Statistics----
1 packets transmitted, 0 packets received, 100.0% packet loss


-Neil