Messages in this thread | | | Subject | Re: 2.6.32-rc5-mmotm1101 - kernel BUG at net/ipv4/tcp_input.c:3707! | From | Valdis.Kletnieks@vt ... | Date | Tue, 03 Nov 2009 21:01:33 -0500 |
| |
On Tue, 03 Nov 2009 23:34:19 +0200, Ilpo JÃâ¬rvinen said:
> On Tue, 3 Nov 2009, Gilad Ben-Yossef wrote: > > > Eric Dumazet wrote: > > > > > Valdis.Kletnieks@vt.edu a écrit : > > > > > > > Seen right after I started 'fetchmail'. Reproducible - 3 out of 3. > > > > I'll bisect this tonight if nobody jumps up and yells they know what it > > > > is... > > > > > > Bah... this is most probably my fault. Sorry about that. > > > > Can you please try the patch in the next email?
Tried while at home, machine panic'ed. No netconsole here at the moment, sorry.
> > But also, can you please send me the route table in effect when this happened > > and the fetchmail command line/config (removing any passwords or account > > details of course)? I want to understand better when this happens.
% route -n -A inet Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 128.173.12.0 0.0.0.0 255.255.252.0 U 0 0 0 eth0 0.0.0.0 128.173.12.1 0.0.0.0 UG 0 0 0 eth0 % route -n -A inet6 Kernel IPv6 routing table Destination Next Hop Flags Metric Ref Use Iface ::1/128 :: U 0 687 1 lo 2001:468:c80:2103:215:c5ff:fec8:334e/128 :: U 0 53533 1 lo 2001:468:c80:2103::/64 :: UA 256 316 0 eth0 fe80::215:c5ff:fec8:334e/128 :: U 0 176 1 lo fe80::218:deff:fe9c:24e0/128 :: U 0 0 1 lo fe80::/64 :: U 256 0 0 eth0 fe80::/64 :: U 256 0 0 wlan0 ff02::1/128 ff02::1 UC 0 451 0 eth0 ff00::/8 :: U 256 0 0 eth0 ff00::/8 :: U 256 0 0 wlan0 ::/0 fe80::20f:35ff:fe3e:d41a UGDA 1024 2082 1 eth0
Command line was just 'fetchmail'. Relevant .fetchmailrc:
set postmaster "valdis" set bouncemail set no spambounce set properties "" set daemon 240 poll imap.vt.edu with proto IMAP and options user 'valdis' there with password 'redacted' is 'valdis' here ssl fetchsizelimit 0 smtpaddress turing-police.cc.vt.edu
(imap.vt.edu is 198.82.183.77 - so off the local subnet)
> According to the stacktrace, it came from ipv6 side which doesn't have any > null checking what so ever atm (you only handled ipv4 correctly). ...You > should be a bit more careful next time when adding any BUG_ONs...
Why was this blowing chunks in the IPv6 when I was making an IPv4 connection then? I just noticed that. My fetchmail can't make an IPv6 TCP connection to our IMAP server because the server isn't v6-enabled yet. And although I contact our DNS over IPv6, but that's UDP not TCP.
[unhandled content-type:application/pgp-signature] | |