2.6.5 forcedeth sending .. trash? / intel 82540EM dropping packets?

From: Mark Rutherford
Date: Mon Apr 05 2004 - 01:58:22 EST


Hi all,
before I get into this, since I am not on list, I would appreciate any
response be CC'd. thanks!

I started having problems with my onboard intel gigabit controller, and
decided to fire up the nforce ethernet driver in an attempt to isolate the
problem. I was trying to determine if its a kernel setup, or something on the
machine.. who knows.... I am trying to find out.

but, the nforce ethernet driver appears to be inop. ( or the interface is
hosed...)
I tried compiling it in at first, it finds the interface and I can configure
it.
however I cannot use the interface...
according to ifconfig, its transmitting the packets, its just not recieving
any.
now, the real fun is when I happened to look at my switch and note that the
activity light is rapidly flashing.
so, I telnet into the switch to find out that its rather upset about this and
has isolated that port...
when I unload the module it continues to send .. random stuff out, and the
only way to stop this is to shut it down, and start the machine back up.

I try using a different port, and cable and I get the same results.
since I dont have Window$ I cant see if its actually working or not. (at least
in Window$)

however, that leads me to another question. I have this other interface, the
intel gigabit that I used for the last few months just fine until the other
day I noticed something odd start to happen.
basically, what happens is anything that sends data rapidly, tends to 'vanish'
for example, if I were to fire up a game browser and search for a server it
would 'lose' chunks of the queries to other servers.
in one in-game browser it makes the game flat out crash, and so I started
trying to figure out why this all is happening....
what I see a ton of in the strace for the game, before it dies is the
following:
gettimeofday({1081103264, 263945}, NULL) = 0
ioctl(6, FIONREAD, [0]) = 0
read(0, 0xbfff754f, 1) = -1 EAGAIN (Resource temporarily
unavailable)
recvfrom(13, 0x93848c0, 32768, 0, 0xbfff75a0, 0xbfff759c) = -1 EAGAIN
(Resource temporarily unavailable)

now, I googled around about this EAGAIN (Resource temporarily unavailable)
error and came to some conclusion it had to do with the networking.
correct me if im wrong.

so, what im asking, am I having a problem with the card, the kernel, or both?
(with regards to the intel)
whats odd about it, is that im just noticing this problem. but it only occurs
when a lot of connections out are made.
some more interesting things, are:
I ran sniffit on the linux nat box, and these packets never made it there.
and, I run ping -f and ping the hell out of another machine, and it always got
a response. I let it run for 2 hours, and when I ctrl+c'd it, it only lost 1
response, out of like 10 million.
and, the last interesting thing...
I can try rapidly connecting to the machine with the intel nic from another
machine and it seems to lose it then, as well.
an example of how I can reproduce this is as follows:
traceroute google.com, hit ctrl+c, uparrow, and enter rapidly.
but not so fast you cant see the first 2 or 3 hops...
every second or third try it will drop out on you. and its almost ALWAYS the
second or third try.
ex:

traceroute: Warning: google.com has multiple addresses; using 216.239.37.99
traceroute to 216.239.37.99 (216.239.37.99), 30 hops max, 40 byte packets
1 192.168.0.1 (192.168.0.1) 0.239 ms 0.167 ms 0.207 ms
traceroute: Warning: google.com has multiple addresses; using 216.239.39.99
traceroute to 216.239.39.99 (216.239.39.99), 30 hops max, 40 byte packets
1 192.168.0.1 (192.168.0.1) 0.230 ms * 0.241 ms

it lost the second response there....

im lost.

and as far as the forcedeth, I dont know what to do with that one.

someone, please give me some advice here. throw the board out? :)

--
Regards,
mark@xxxxxxxxxxxxx
Server Admin, FreeQuest IRC Network
http://www.freequest.net



-
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/