On Tue, Jan 02, 2007 at 03:32:01PM +0000, Sid Boyce wrote:
Jarek Poplawski wrote:
...
quoted
If you could send full ifconfig, route -n (or ip route
if you use additional tables) and tcpdump (all packets)
from both boxes while pinging each other and a few words
how it is connected (other cards, other active boxes in
the network?) maybe something more could be found.
...
Everything is fine with a eepro100 on the 64x2 box that gave the same
problem with a nVidia Corporation MCP51 Ethernet Controller (rev a1)
using the forcedeth module. On the x86_64 laptop the problem is with a
Broadcom NetXtreme BCM5788 using the tg3 module. Switching back to a
2.6.18.2 kernel, there is no problem.
With all configurations of cards on both, route -n is the same on all
kernels and instantly reports back. With >=2.6.19 on the laptop, netstat
-r takes a very long time before returning the information ~30 seconds,
instantly on 2.6.18.2.
This could be a problem with DNS. Could you do all tests
(including pinging) with -n option?
I've read your other message on netdev and see you
have firewall working and addresses from various
networks in logs. I think it would be much easier
to exclude possible network config errors and try
to isolate pinging problems by connecting (with
switch or even crossed cable if possible) only 2
boxes with firewalls and other net devices disabled
and try to repeat this pinging with tcpdumps.
Jarek P.
Jarek Poplawski wrote:
On Tue, Jan 02, 2007 at 03:32:01PM +0000, Sid Boyce wrote:
quoted
Jarek Poplawski wrote:
...
quoted
quoted
If you could send full ifconfig, route -n (or ip route
if you use additional tables) and tcpdump (all packets)
from both boxes while pinging each other and a few words
how it is connected (other cards, other active boxes in
the network?) maybe something more could be found.
...
quoted
Everything is fine with a eepro100 on the 64x2 box that gave the same
problem with a nVidia Corporation MCP51 Ethernet Controller (rev a1)
using the forcedeth module. On the x86_64 laptop the problem is with a
Broadcom NetXtreme BCM5788 using the tg3 module. Switching back to a
2.6.18.2 kernel, there is no problem.
With all configurations of cards on both, route -n is the same on all
kernels and instantly reports back. With >=2.6.19 on the laptop, netstat
-r takes a very long time before returning the information ~30 seconds,
instantly on 2.6.18.2.
This could be a problem with DNS. Could you do all tests
(including pinging) with -n option?
I've read your other message on netdev and see you
have firewall working and addresses from various
networks in logs. I think it would be much easier
to exclude possible network config errors and try
to isolate pinging problems by connecting (with
switch or even crossed cable if possible) only 2
boxes with firewalls and other net devices disabled
and try to repeat this pinging with tcpdumps.
Jarek P.
It seems >=2.6.19 and the SuSEfirewall are incompatible.
Turning off the firewall on the laptop cured the problem using
2.6.20-rc2 and 2.6.20-rc3. I thought it was off. On the 64x2 box, the
firewall is turned off, so I shall have to reconfigure the network to
use the Gigabit ethernet instead of the eepro100 in case I turned it off
after seeing the bug on that box, but didn't stop the firewall.
There is still the problem where the ethernet doesn't get configured
with acpi=off which I shall post to the acpi devel list, but this is not
a showstopper for me. ifconfig eth0 192.168.10.5 returns SIOCSIFFLAGS:
Function not implemented.
Thanks and Regards
Sid.
--
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support
Specialist, Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks
On Wed, Jan 03, 2007 at 04:53:58PM +0000, Sid Boyce wrote:
...
It seems >=2.6.19 and the SuSEfirewall are incompatible.
Actually, many programs could be incomapatible with
newer kernel versions, so sometimes upgrades or at
least recompilations are needed.
...
There is still the problem where the ethernet doesn't get configured
with acpi=off which I shall post to the acpi devel list, but this is not
a showstopper for me. ifconfig eth0 192.168.10.5 returns SIOCSIFFLAGS:
I don't know acpi enough but as far as I know
some mainboards can't work properly with acpi
off, so it's probably not a bug.
Cheers,
Jarek P.