[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <81bfc67a0911232217n41b9ac02w3b7770b789e5d209@mail.gmail.com>
Date: Tue, 24 Nov 2009 01:17:09 -0500
From: Caleb Cushing <xenoterracide@...il.com>
To: Jarek Poplawski <jarkao2@...il.com>
Cc: Frans Pop <elendil@...net.nl>, Andi Kleen <andi@...stfloor.org>,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: large packet loss take2 2.6.31.x
> Btw, currently I don't consider this dropping means there has to be
> a bug. It could be otherwise - a feature... e.g. when a new kernel
> can transmit faster (then dropping in some other, slower place can
> happen).
um... where would it be dropping that we wouldn't have a bug? I mean
sure faster is great... but if it makes my network not work right...
I've added all (I think) information you've asked for to the bug
http://bugzilla.kernel.org/show_bug.cgi?id=13835 except for ethtool
and netstat on the router side. ethtool complains about not having
driver or capability (maybe because it's a 2.4 kernel?) and the
version of netstat doesn't support -s. I disabled everything that I
can think of that would send/receive packets before doing the test
client side, except dhcp/dns windows box's were probably sending some
broadcasts too. but the traffic should be pretty low. I did remember
to set the txqueuelen didn't seem to make a difference
only error in dmesg I see is
e1000e 0000:00:19.0: pci_enable_pcie_error_reporting failed 0xfffffffb
but it's in working versions too.
--
Caleb Cushing
http://xenoterracide.blogspot.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists