Since I don't understand where such short mbufs can come from, I just
resorted to dropping them and hoping for the better. The code still
hasn't fired as it takes a long time for the buggy condition to come
up. I don't see any regression either.

$ diff -u sys/dev/ic/if_wi.c~ sys/dev/ic/if_wi.c
--- sys/dev/ic/if_wi.c~ Thu May 20 19:02:38 2010
+++ sys/dev/ic/if_wi.c  Thu May 20 19:02:38 2010
@@ -2443,6 +2443,7 @@
                            (m0->m_pkthdr.len -
                             sizeof(struct ether_header)) + 18);
                } else {
+                  if (m0->m_pkthdr.len >= sizeof(struct ether_header)) {
                        m_copydata(m0, sizeof(struct ether_header),
                            m0->m_pkthdr.len - sizeof(struct ether_header),
                            (caddr_t)&sc->wi_txbuf);
@@ -2454,6 +2455,13 @@
                            (caddr_t)&sc->wi_txbuf,
                            (m0->m_pkthdr.len -
                             sizeof(struct ether_header)) + 2);
+                  } else {
+                       static int dropped_packets = 0;
+                       dropped_packets++;
+                       printf("Dropping too short packet: %d bytes %d
times",
+                              m0->m_pkthdr.len,
+                              dropped_packets);
+                  }
                }
        } else {
                tx_frame.wi_dat_len = htole16(m0->m_pkthdr.len);


On Wed, May 19, 2010 at 10:49 PM, Greg Steuck <g...@nest.cx> wrote:
> I've only now caught the full trace of this bug that bit me many times
> over. The bug is non-deterministic, but happens often enough that I
> can be sure it's fixed if I don't see it in a week.
>
> panic: m_copydata: len -7 < 0
> kdb breakpoint at 1442b20
> Stopped at      Debugger+0x4:   nop
> RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC!
> DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!
> ddb> trace
> m_copydata(40006b5e680, e, fffffffffffffff9, 4000069b8c8,
> ffffffffffffff83, e0017b5c) at m_copydata+0xf0
> wi_start(4000069a048, 0, 3b9aca00, 1, 0, 8) at wi_start+0x4b4
> wihap_data_input(0, e0017cf8, 40006b5e680, 40006801810, 9,
> 4000680180e) at wihap_data_input+0x280
> wi_rxeof(4000069a000, 0, e0017ec8, ff0000, 13de520, 1) at wi_rxeof+0x4cc
> wi_intr(4000069a000, 0, e0017ec8, 40006c4e000, 105ef60, 0) at wi_intr+0x3a8
> sparc_interrupt(188adb0, e0018000, 1515550, 1886f88, 400006dda00,
> 182ec70) at sparc_interrupt+0x2a0
> sched_idle(e0018000, 40006c40480, 1515b20, 40006c48000, 40000693020,
> deafbeef) at sched_idle+0x20c
> proc_trampoline(0, 0, 0, 0, 0, 0) at proc_trampoline+0x4
--
nest.cx is Gmail hosted, use PGP for anything private. Key:
http://tinyurl.com/ho8qg
Fingerprint: 5E2B 2D0E 1E03 2046 BEC3  4D50 0B15 42BD 8DF5 A1B0

Reply via email to