help w/panic under heavy load - 5.4

[Giorgos Keramidas]

On 2005-07-22 17:53, Edwin <edwin at verolan.com> wrote:
>
> I also patched ip_fastforward.c w/ your patch - still a crash - still
> same type bogus mtu value - a few lines from kgdb included @ end of
> message.
> (kgdb) f 13
> #13 0xc06933c1 in ip_fastforward (m=0xc12e6c00) at /usr/src/sys/netinet/ip_fastfwd.c:572
> 572                             if (ip_fragment(ip, &m, mtu, ifp->if_hwassist,
> (kgdb) p ro.ro_rt->rt_rmx
> $1 = {rmx_mtu = 1500, rmx_expire = 333905919, rmx_pksent = 3868}

The route entry has mtu = 1500.

> (kgdb) p *ifp
> $3 = {if_softc = 0xc0f91800, if_link = {tqe_next = 0xc0f90000, tqe_prev = 0xc08ebe84},
>   if_xname = "sis0", '\0' <repeats 11 times>, if_dname = 0xc0f2ec2c "sis", if_dunit = 0,
>   if_addrhead = {tqh_first = 0xc0ec0000, tqh_last = 0xc1040460}, if_klist = {
>     kl_lock = 0xc08e5a40, kl_list = {slh_first = 0x0}}, if_pcount = 0, if_carp = 0x0,
>   if_bpf = 0x0, if_index = 1, if_timer = 5, if_nvlans = 0, if_flags = 34883,
>   if_capabilities = 72, if_capenable = 72, if_linkmib = 0x0, if_linkmiblen = 0,
>   if_data = {ifi_type = 6 '\006', ifi_physical = 0 '\0', ifi_addrlen = 6 '\006',
>     ifi_hdrlen = 18 '\022', ifi_link_state = 2 '\002', ifi_recvquota = 0 '\0',
>     ifi_xmitquota = 0 '\0', ifi_datalen = 80 'P', ifi_mtu = 1500, ifi_metric = 0,

The interface also has an mtu of 1500 (ifi_mtu in the last line above).

> #10 0xc0611fef in panic (fmt=0xc0820008 "default")
>     at /usr/src/sys/kern/kern_shutdown.c:550
> #11 0xc0641a2c in m_copym (m=0x0, off0=1500, len=1480, wait=1)
>     at /usr/src/sys/kern/uipc_mbuf.c:385
> #12 0xc069b694 in ip_fragment (ip=0xc12f700e, m_frag=0xc76bfc6c, mtu=-1056788992,
>     if_hwassist_flags=0, sw_csum=1) at /usr/src/sys/netinet/ip_output.c:967
> #13 0xc06933c1 in ip_fastforward (m=0xc12e6c00) at /usr/src/sys/netinet/ip_fastfwd.c:572

This looks rather strange.  ip_fastforward() should pass an mtu of 1500
but somehow the negative strange value gets passed.  It would be
interesting to see the value of ``mtu'' in frame 13 too, if you still
have this crash dump stored somewhere.

You are not running a kernel with optimization and/or architecture-
dependent optimization flags, right?