Re: BUG: IPv4: Attempt to release TCP socket in state 1

[dormando]

> On Mon, 2013-03-04 at 21:44 -0800, dormando wrote:
>
> > No 3rd party modules. There's a tiny patch for controlling initcwnd from
> > userspace and another one for the extra_free_kbytes tunable that I brought
> > up in another thread. We've had the initcwnd patch in for a long time
> > without trouble. The extra_free_kbytes tunable isn't even being used yet,
> > so all that's doing is adding a 0 somewhere.
> >
> > Only two iptables rules loaded: global NOTRACK rules for PREROUTING/OUTPUT
> > in raw.
> >
> > Kernel's as close to pristine as I can make it. We had the 10g patch in
> > but I've dropped it.
> > --
>
> Hmm, I spent time on this bug report but found nothing.
>
> Please post as much information as you can on your setup.
>
> I see you use macvlan, bridge, so maybe there is a configuration issue
> (and a kernel bug of course)

Ok... bridge module is loaded but nothing seems to be using it. No
bond/tunnels/anything enabled. I couldn't quickly figure out what was
causing it to load.

We removed the need for macvlan, started machines with a fresh boot, and
they still crashed without it, after a few hours.

Unfortunately I just saw a machine crash in the same way on 3.6.6 and
3.6.9. I'm working on getting a completely pristine 3.6.6 and 3.6.9
tested. Our patches are minor but there were a few, so I'm backing it all
out just to be sure.

Is there anything in particular which is most interesting? I can post lots
and lots and lots of information. Sadly bridge/macvlan weren't part of the
problem. .config, sysctls are easiest I guess? When this "hang" happens
the machine is still up somewhat, but we lose access to it. Syslog is
still writing entries to disk occasionally, so it's possible we could set
something up to dump more information.

It takes a day or two to cycle this, so it might take a while to get
information and test crashes.

thanks,
-Dormando
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/