So, has anyone else had any problems with ethernet on their lombard?
I was having trouble with 2.2.18, so I decided to try upgrading to
2.4.0-* (the 2_3 bk tree, as of this morning). I thought the problem
was fixed, but perhaps I didn't try long enough to break it.
It seems to be easier to kill the network on a 10Mbit connection,
rather than a 100Mbit connection.
I can kill the network easily with ping -f <ip of local host>
There aren't any helpful messages in any logs (actually, nothing
relating to ethernet). No errors are shown in ifconfig eth0.
The only fix seems to be to ifdown/ifup the interface. Anyone else
see this? The ping -f output looks like the following to me:
PING jd.local (192.168.0.1): 56 data bytes
..............................................................................................................................................................................................................................................................................................................
--- jd.local ping statistics ---
31706 packets transmitted, 31244 packets received, 1% packet loss
round-trip min/avg/max = 0.4/19.6/106.8 ms
The packets are returned most of the time, until the dots begin to be
displayed quickly. (assuming eth0 is broken at this point) In a
couple seconds, the dots aren't displayed anymore, so it's unable to
send data.
hmm?
--
Josh Huber
1024D/6B21489A 61F0 6138 BE7B FEBF A223 E9D1 BFE1 2065 6B21 489A
So, has anyone else had any problems with ethernet on their lombard?
I was having trouble with 2.2.18, so I decided to try upgrading to
2.4.0-* (the 2_3 bk tree, as of this morning). I thought the problem
was fixed, but perhaps I didn't try long enough to break it.
It seems to be easier to kill the network on a 10Mbit connection,
rather than a 100Mbit connection.
I've seen problems recently with NFS over 100 Mbit - the server just
'disappears' for my Lombard. I'd say it's only in .18 because that's what
I use most of the time and I don't recall trouble in .17
I can kill the network easily with ping -f <ip of local host>
I'll try that one then. No idea what causes it, and it's not really been
happening too often here.
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On 19 Dec, this message from Josh Huber echoed through cyberspace:
I can kill the network easily with ping -f <ip of local host>
Ping _from_ local _to_ local? I believe that doesn't even go to the
ethernet interface, but is returned right in the IP stack. At least, for
me, I don't get _any_ sort of network activity when ping -f'ing on local
IP address....
Michel
-------------------------------------------------------------------------
Michel Lanners | " Read Philosophy. Study Art.
23, Rue Paul Henkes | Ask Questions. Make Mistakes.
L-1710 Luxembourg |
email mlan@cpu.lu |
http://www.cpu.lu/~mlan | Learn Always. "
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
It seems to be easier to kill the network on a 10Mbit connection,
rather than a 100Mbit connection.
I can kill the network easily with ping -f <ip of local host>
There aren't any helpful messages in any logs (actually, nothing
relating to ethernet). No errors are shown in ifconfig eth0.
One thing I could notice is quite high packet drop rates that start at
packet sizes above about 560 (580 gives a slow increase of the dots, 768
has them running rather fast). It took extended periods of flooding at
560 bytes to bring the interface down (on the order of 600k packets) and
up to that point it logged a large number of TX overruns but no RX errors.
The hangup has the packet counts frozen but shows just a few RX errors
which slowly accumulated. The connection appears to freeze even before the
dots start running wild.
There's one clear pattern I can see: After each freeze and subsequent
restart of the network adapter, both the dropped packet and frame error
count increased by one. Does the BMAC require special treatment after a
frame error?
That's with 2.2.18pre18 on a switched 100 Mibt network (3com 3300) with no
load worth mentioning.
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/