I downloaded and installed et131x-1.2.3.tar.gz yesterday on a Gentoo x86_64 system running 2.6.20.3. The module compiled and installed (modprobe) successfully. This system has 3 network cards using the et131x driver (eth1/2/3). Yesterday all 3 worked before I went to bed, but this morning my /var/log/messages is full of this over and over and over... ('inferno' is the hostname):
Mar 22 07:19:46 inferno NETDEV WATCHDOG: eth1: transmit timed out
Mar 22 07:19:46 inferno et131x.ko:WARNING:et131x_tx_timeout TX TIMEOUT
Mar 22 07:19:46 inferno et131x.ko:WARNING:et131x_tx_timeout Send stuck - reset. pMpTcb->WrIndex 1e0, Flags 0x00000000
Mar 22 07:19:46 inferno et131x.ko:WARNING:et131x_tx_timeout pDesc 0x00000000, 0x3a0f8886, 0x0000004a, 0x00000007
Mar 22 07:19:46 inferno et131x.ko:WARNING:et131x_tx_timeout WbStatus 0x00000020
You can see it's complaining specifically about eth1. The only thing different about that interface is that while eth2 and eth3 have IPs assigned (and still work fine), eth1 isn't configured with anything as it's wrapped by ppp0 when my DSL line connects itself using pppoe.
...and in Gentoo /etc/conf.d/net it's configured as 'config_eth1=( "null" )' ... meaning the PC does nothing at all with it when I boot up.
These messages are happening all the time, about every second. I also occasionally see something like this in the output:
Mar 22 07:26:42 inferno et131x.ko:WARNING:et131x_ioctl Unhandled IOCTL Code: 0x8946
Mar 22 07:26:42 inferno et131x.ko:WARNING:et131x_ioctl Unhandled IOCTL Code: 0x8946
Mar 22 07:26:42 inferno et131x.ko:WARNING:et131x_ioctl Unhandled IOCTL Code: 0x8946
'/etc/init.d/net.eth1 restart' doesn't fix the problem, and I am unable to restart ppp0 (my DSL connection) succesfully since it needs to wrap eth1 to talk to my DSL modem. At this time I'm unable to reboot to see if things clear up, but I will try after work today.
Thank you very much for providing these drivers! When I bought these network cards I was rolling the dice on if they would work in Linux or not, and I was very releived to find tyou project. If there's anything you can suggest to debug this problem I'd be more than happy to help.
Thanks!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
modified 2 funcs in et131x_netdev.c and et131x_initpci.c. Let me if it fixes at least fixes the config_eth1=( "null" ) problem and the warning from et131x.ko:WARNING:et131x_ioctl Unhandled IOCTL Code: 0x8946.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I ran "svn co https://et131x.svn.sourceforge.net/svnroot/et131x et131x" to get what I think is the latest code (though the README says it's 1.2.2, and the latest tarball on sourceforge is 1.2.3), then ran "make" and got this:
cd et131x/et131x/trunk
inferno trunk # make
#@make -C /lib/modules/2.6.20.3/build M=/usr/src/et131x-subversion/et131x/et131x/trunk modules
make[1]: Entering directory `/usr/src/linux-2.6.20.3'
CC [M] /usr/src/et131x-subversion/et131x/et131x/trunk/et131x_main.o
In file included from /usr/src/et131x-subversion/et131x/et131x/trunk/et131x_adapter.h:85,
from /usr/src/et131x-subversion/et131x/et131x/trunk/et131x_main.c:116:
/usr/src/et131x-subversion/et131x/et131x/trunk/ET1310_rx.h:441: warning: 'kmem_cache_t' is deprecated
CC [M] /usr/src/et131x-subversion/et131x/et131x/trunk/et131x_initpci.o
In file included from /usr/src/et131x-subversion/et131x/et131x/trunk/et131x_adapter.h:85,
from /usr/src/et131x-subversion/et131x/et131x/trunk/et131x_initpci.c:124:
/usr/src/et131x-subversion/et131x/et131x/trunk/ET1310_rx.h:441: warning: 'kmem_cache_t' is deprecated
/usr/src/et131x-subversion/et131x/et131x/trunk/et131x_initpci.c:1675:59: error: macro "INIT_WORK" passed 3 arguments, but takes just 2
/usr/src/et131x-subversion/et131x/et131x/trunk/et131x_initpci.c: In function 'et131x_pci_setup':
/usr/src/et131x-subversion/et131x/et131x/trunk/et131x_initpci.c:1675: error: 'INIT_WORK' undeclared (first use in this function)
/usr/src/et131x-subversion/et131x/et131x/trunk/et131x_initpci.c:1675: error: (Each undeclared identifier is reported only once
/usr/src/et131x-subversion/et131x/et131x/trunk/et131x_initpci.c:1675: error: for each function it appears in.)
make[2]: *** [/usr/src/et131x-subversion/et131x/et131x/trunk/et131x_initpci.o] Error 1
make[1]: *** [_module_/usr/src/et131x-subversion/et131x/et131x/trunk] Error 2
make[1]: Leaving directory `/usr/src/linux-2.6.20.3'
make: *** [modules] Error 2
...so it did automagically find my kernel source properly in /usr/src/linux-2.6.20.3, but something in et131x_initpci.c is making it unhappy (sorry I don't know C).
Regards,
Mike
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
try svn again, looks like INIT_WORK fuction in et131x_initpci takes different parameters for kernel 2.6.20. You'll have to bear with me as I am on kernel 2.6.17.11. Let me know how the latest svn revision treats you.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I grabbed a fresh copy from svn, compiled it, and it modprobe'd fine. I rebooted and all the "<7>0x00000000"-type messages are gone from /var/log/messages... but I'm still getting these 3 lines written every 15 seconds:
Mar 23 23:30:01 inferno et131x.ko:WARNING:et131x_ioctl Unhandled IOCTL Code: 0x8946
Mar 23 23:30:01 inferno et131x.ko:WARNING:et131x_ioctl Unhandled IOCTL Code: 0x8946
Mar 23 23:30:01 inferno et131x.ko:WARNING:et131x_ioctl Unhandled IOCTL Code: 0x8946
(remember I'm using this driver for 3 interfaces (eth1/2/3) on the same system... maybe it's really just one message repeated once-per-interface?)
So far eth1 (used by ppp0 for DSL PPPoE access) is also working properly... though it worked properly at first last time too... so I'll have to see if it's still happy tomorrow morning.
Thanks!
Mike
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Also, after running a few days it starts with the "<7>0x00000000"-type messages:
Mar 27 07:56:46 inferno NETDEV WATCHDOG: eth3: transmit timed out
Mar 27 07:56:46 inferno et131x.ko:WARNING:et131x_tx_timeout TX TIMEOUT
Mar 27 07:56:46 inferno et131x.ko:WARNING:et131x_tx_timeout Send stuck - reset. pMpTcb->WrIndex 82, Flags 0x00000000
Mar 27 07:56:46 inferno et131x.ko:WARNING:et131x_tx_timeout pDesc 0x00000000, 0x1354b08e, 0x00000042, 0x00000007
Mar 27 07:56:46 inferno et131x.ko:WARNING:et131x_tx_timeout WbStatus 0x00000483
Mar 27 07:56:46 inferno Global block
Mar 27 07:56:46 inferno <snipped <7>0x00000000-type messages>
Mar 27 07:56:46 inferno Tx DMA block
Mar 27 07:56:46 inferno <snipped <7>0x00000000-type messages>
Mar 27 07:56:46 inferno Tx MAC block
Mar 27 07:56:46 inferno <snipped <7>0x00000000-type messages>
Mar 27 07:56:46 inferno MAC block
Mar 27 07:56:46 inferno <snipped <7>0x00000000-type messages>
Once these type of messages start, they happen every second from then on until I reboot. Maybe there's some sort of counter in the driver that is wrapping, or something that runs out of room?
If there's anything I can do to help debug where these messages from, please let me know.
Thanks again for writing this driver for Linux!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I rebooted April 1st... and when I checked on the 1st and 2nd I only saw the three "Unhandled IOCTL Code: 0x8946" messages over and over. Checking this morning I see the 0x00000000 messages have started again every second: at about 8:30 this morning things made the switch:
...then that entire slab of 0x00000000 errors start repeating every second. If the same thing happens as last week, I should lose all networking in a day or so.
If anybody can suggest something I can attempt to get rid of these errors, I'm very happy to try. I still have a week old version of the module on 2.6.20.3. Should I try a the latest code on 2.6.20.4?
Thanks!
Mike
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The TX packet number isn't changing any more, but the "RX packets" count is now zero (which is strange, as this interface has received about 23GB of data) and the "RX errors" number is climbing constantly. Do those numbers come from the et131x driver? Is the RX number maybe overflowing some internal counter when it gets too large? This is a 64bit AMD system: does the driver need to do anything special for 64bit-ness?
Regards,
Mike
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I had to revert the code back when i tried to add code to handle IOCTL Code 0x8946, this is just a warning message indicating that the driver does not process this IOCTL message, it requires some rewrite of the driver though in order to remove the warning. This warning isn't a problem. I get warnings from the IOCTL subsystem as well due to my 2nd wireless ethernet card on my box, as the et131x driver doesn't process wireless IOCTL messages. As far as the timeout messages go, since you have this card wrapped with your pppoe driver, I would try different settings for the timeout default in the pppd driver. I have a suspicion that this is what is causing your problem. The pppd driver can shut down your connection, resulting in timeout error messages. Have you been able to ifdown eth1, ifup eth1 successfully at all? This should reset the connection. If that doesnt do it, I'd google around for pppoe timeouts. I run this on a AMD64 kernel as well, and have not had issues with it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for your help! The DSL/ppp0 connection had been using an onboard Nvidia GigE interface with no problems (exact same pppd/ppp0 setup)... maybe I can switch it back and the 0x00000000 messages will go away. I was concerned because eth1 is also the et131x card that moves the most traffic. i.e. hopefully when the other 2 cards reach similar amounts of traffic over time they don't also start showing errors (and they are straight GigE: no ppp wrapper).
Actually, I could probably leave something like iPerf running until those other connections show similar MB numbers in ifconfig. That would set my mind at ease, and show that it's probably a pppd interaction error...
The next time I see the errors I'll try in order:
1) restart the ppp0/PPPoE wrapper, and if that fails...
2) restart eth1, and if that fails...
3) rmmod/modprobe the module (which would bring down all 3 cards), and if that fails...
4) reboot
....and see what happens!
Thanks again!
Mike
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Restarting ppp0/PPPoE made no difference (ppp0 couldn't connect, since eth1 was locked uan
- stoping/restarting eth1 didn't make any changes either (even ifconfig down/up didn't reset the counters)
- I was unable to rmmod the module - said it was in use - ended up rebooting to get eth1 reset
- upgraded to 2.6.20.4 and today's svn, and enabled CONFIG_MODULE_FORCE_UNLOAD in my kernel so I cna try a "rmmod -f" in the future
- will let you know how it goes....
Thanks!
Mike
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I switched the ppp0/eth1 (most used et131x) interface to use eth0 instead (which uses the Nvidia forcedeth driver). The system runs for about the same amount of time before logging 0x00000000-type errors for eth3 instead ... and eth3 is the second-most active et131x interface (2nd Internet connection)... and it has nothing to do with the ppp0/DSL connection.
I don't know what to test next. As soon as I boot I get 0x8946 errors every 15 seconds... after a day or so the most active et131x drive starts kicking out 0x00000000 errors after moving many GB of traffic... not too long after that the system essentially locks up (although I can see activity on the screen still the mouse/keyboard/network are unresponsive.
I just updated the motherboard BIOS to the latest version and left all settings on default/auto. I'll let it run again and see what happens. I'm also going to start logging ifconfig output to see if it's around the same total tranfer number each time a et131x interface switches to the 0x00000000 errors and starts showing 0 received packets.
I'll let you know what I find: I'm hoping to at least get something reproducible.
Thanks!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I promise this is my last update on this thread. When I wrap ppp0 around my Nvidia/forcedeth-driver card it works (i.e it worked fine before, and I had it switched back over the last 3 days and there wasn't a single problem. When I switch ppp0 and the cables to use eth1 (et131x card) after about 24 hours the 0x00000000 messages start again.
So, for now I'll use my DSL connection over the Nvidia interface... since I don't really have a choice... but it's not an ideal solution.
I'll keep an eye on my lower traffic (eth2 and eth3) et131x cards and see if they complain over time. They handle wireless connections so they don't see a lot of activity... so I'm hoping they'll be OK.
Thanks!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Any updates on this issue? I am having the same issue on a RHEL4 box running 2.6.9-55.0.6.ELsmp and this driver. One thing to note, that it seems twangthunk might also notice, I am running this card at 100mbit, not gig-e. It sounds like twangthunk may be dong the same if it's connected to a cable modem. wondering if this may have something to do with this issue. It is definitely related to data rate (not uptime) because if i push 2 8mbit/sec streams on a 100mbit/sec switch, it will hang eventually.
Thanks,
Karl
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
I downloaded and installed et131x-1.2.3.tar.gz yesterday on a Gentoo x86_64 system running 2.6.20.3. The module compiled and installed (modprobe) successfully. This system has 3 network cards using the et131x driver (eth1/2/3). Yesterday all 3 worked before I went to bed, but this morning my /var/log/messages is full of this over and over and over... ('inferno' is the hostname):
Mar 22 07:19:46 inferno NETDEV WATCHDOG: eth1: transmit timed out
Mar 22 07:19:46 inferno et131x.ko:WARNING:et131x_tx_timeout TX TIMEOUT
Mar 22 07:19:46 inferno et131x.ko:WARNING:et131x_tx_timeout Send stuck - reset. pMpTcb->WrIndex 1e0, Flags 0x00000000
Mar 22 07:19:46 inferno et131x.ko:WARNING:et131x_tx_timeout pDesc 0x00000000, 0x3a0f8886, 0x0000004a, 0x00000007
Mar 22 07:19:46 inferno et131x.ko:WARNING:et131x_tx_timeout WbStatus 0x00000020
Mar 22 07:19:46 inferno Global block
Mar 22 07:19:46 inferno 0x000002bd, <7>0x000003ff, <7>0x00000000, <7>0x000002bc, <7>0x00000038, <7>0x00000000, <7> ISR , <7>0x001ebfd7, <7>
Mar 22 07:19:46 inferno 0x00000000, <7>0x000101e8, <7>0x00000000, <7>0x0003d090, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>
Mar 22 07:19:46 inferno 0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>
Mar 22 07:19:46 inferno 0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>
Mar 22 07:19:46 inferno 0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>
Mar 22 07:19:46 inferno 0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>
Mar 22 07:19:46 inferno 0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>
Mar 22 07:19:46 inferno 0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>
Mar 22 07:19:46 inferno
Mar 22 07:19:46 inferno Tx DMA block
Mar 22 07:19:46 inferno 0x00000100, <7>0x00000000, <7>0x7e060000, <7>0x000001ff, <7>0x00000308, <7>0x00000708, <7>0x00000708, <7>0x00000000, <7>
Mar 22 07:19:46 inferno 0x7c17b000, <7>0x00000020, <7>0x00000020, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>
Mar 22 07:19:46 inferno 0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>
Mar 22 07:19:46 inferno 0x00000020, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>
Mar 22 07:19:46 inferno 0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>
Mar 22 07:19:46 inferno 0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>
Mar 22 07:19:46 inferno 0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>
Mar 22 07:19:46 inferno 0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>
Mar 22 07:19:46 inferno
Mar 22 07:19:46 inferno Tx MAC block
Mar 22 07:19:46 inferno 0x00000009, <7>0x07080708, <7>0x00000000, <7>0x00000139, <7>0x00000040, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>
Mar 22 07:19:46 inferno 0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>
Mar 22 07:19:46 inferno 0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>
Mar 22 07:19:46 inferno 0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>
Mar 22 07:19:46 inferno 0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>
Mar 22 07:19:46 inferno 0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>
Mar 22 07:19:46 inferno 0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>
Mar 22 07:19:46 inferno 0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>
Mar 22 07:19:46 inferno
Mar 22 07:19:46 inferno MAC block
Mar 22 07:19:46 inferno 0x0000001f, <7>0x00007117, <7>0x38585060, <7>0x00a1f037, <7>0x000005ee, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>
Mar 22 07:19:46 inferno 0x00000007, <7>0x00000000, <7>0x00000000, <7>0x00001240, <7>0x00002001, <7>0x00000000, <7>0x01000000, <7>0x00000000, <7>
Mar 22 07:19:46 inferno 0xa1b412cd, <7>0x0a000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>
Mar 22 07:19:46 inferno 0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>
Mar 22 07:19:46 inferno 0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>
Mar 22 07:19:46 inferno 0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>
Mar 22 07:19:46 inferno 0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>
Mar 22 07:19:46 inferno 0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>
You can see it's complaining specifically about eth1. The only thing different about that interface is that while eth2 and eth3 have IPs assigned (and still work fine), eth1 isn't configured with anything as it's wrapped by ppp0 when my DSL line connects itself using pppoe.
'ifconfig eth1' looks like this:
eth1 Link encap:Ethernet HWaddr 00:0A:CD:12:B4:A1
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:6786 dropped:0 overruns:0 frame:6786
TX packets:2336736 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2060848401 (1965.3 Mb) TX bytes:882755787 (841.8 Mb)
Interrupt:11
...and in Gentoo /etc/conf.d/net it's configured as 'config_eth1=( "null" )' ... meaning the PC does nothing at all with it when I boot up.
These messages are happening all the time, about every second. I also occasionally see something like this in the output:
Mar 22 07:26:42 inferno et131x.ko:WARNING:et131x_ioctl Unhandled IOCTL Code: 0x8946
Mar 22 07:26:42 inferno et131x.ko:WARNING:et131x_ioctl Unhandled IOCTL Code: 0x8946
Mar 22 07:26:42 inferno et131x.ko:WARNING:et131x_ioctl Unhandled IOCTL Code: 0x8946
'/etc/init.d/net.eth1 restart' doesn't fix the problem, and I am unable to restart ppp0 (my DSL connection) succesfully since it needs to wrap eth1 to talk to my DSL modem. At this time I'm unable to reboot to see if things clear up, but I will try after work today.
Thank you very much for providing these drivers! When I bought these network cards I was rolling the dice on if they would work in Linux or not, and I was very releived to find tyou project. If there's anything you can suggest to debug this problem I'd be more than happy to help.
Thanks!
modified 2 funcs in et131x_netdev.c and et131x_initpci.c. Let me if it fixes at least fixes the config_eth1=( "null" ) problem and the warning from et131x.ko:WARNING:et131x_ioctl Unhandled IOCTL Code: 0x8946.
oops checkout using subversion and let me know how it goes
Hi, thanks for helping me!
I ran "svn co https://et131x.svn.sourceforge.net/svnroot/et131x et131x" to get what I think is the latest code (though the README says it's 1.2.2, and the latest tarball on sourceforge is 1.2.3), then ran "make" and got this:
cd et131x/et131x/trunk
inferno trunk # make
#@make -C /lib/modules/2.6.20.3/build M=/usr/src/et131x-subversion/et131x/et131x/trunk modules
make[1]: Entering directory `/usr/src/linux-2.6.20.3'
CC [M] /usr/src/et131x-subversion/et131x/et131x/trunk/et131x_main.o
In file included from /usr/src/et131x-subversion/et131x/et131x/trunk/et131x_adapter.h:85,
from /usr/src/et131x-subversion/et131x/et131x/trunk/et131x_main.c:116:
/usr/src/et131x-subversion/et131x/et131x/trunk/ET1310_rx.h:441: warning: 'kmem_cache_t' is deprecated
CC [M] /usr/src/et131x-subversion/et131x/et131x/trunk/et131x_initpci.o
In file included from /usr/src/et131x-subversion/et131x/et131x/trunk/et131x_adapter.h:85,
from /usr/src/et131x-subversion/et131x/et131x/trunk/et131x_initpci.c:124:
/usr/src/et131x-subversion/et131x/et131x/trunk/ET1310_rx.h:441: warning: 'kmem_cache_t' is deprecated
/usr/src/et131x-subversion/et131x/et131x/trunk/et131x_initpci.c:1675:59: error: macro "INIT_WORK" passed 3 arguments, but takes just 2
/usr/src/et131x-subversion/et131x/et131x/trunk/et131x_initpci.c: In function 'et131x_pci_setup':
/usr/src/et131x-subversion/et131x/et131x/trunk/et131x_initpci.c:1675: error: 'INIT_WORK' undeclared (first use in this function)
/usr/src/et131x-subversion/et131x/et131x/trunk/et131x_initpci.c:1675: error: (Each undeclared identifier is reported only once
/usr/src/et131x-subversion/et131x/et131x/trunk/et131x_initpci.c:1675: error: for each function it appears in.)
make[2]: *** [/usr/src/et131x-subversion/et131x/et131x/trunk/et131x_initpci.o] Error 1
make[1]: *** [_module_/usr/src/et131x-subversion/et131x/et131x/trunk] Error 2
make[1]: Leaving directory `/usr/src/linux-2.6.20.3'
make: *** [modules] Error 2
...so it did automagically find my kernel source properly in /usr/src/linux-2.6.20.3, but something in et131x_initpci.c is making it unhappy (sorry I don't know C).
Regards,
Mike
try svn again, looks like INIT_WORK fuction in et131x_initpci takes different parameters for kernel 2.6.20. You'll have to bear with me as I am on kernel 2.6.17.11. Let me know how the latest svn revision treats you.
Hi again,
I grabbed a fresh copy from svn, compiled it, and it modprobe'd fine. I rebooted and all the "<7>0x00000000"-type messages are gone from /var/log/messages... but I'm still getting these 3 lines written every 15 seconds:
Mar 23 23:30:01 inferno et131x.ko:WARNING:et131x_ioctl Unhandled IOCTL Code: 0x8946
Mar 23 23:30:01 inferno et131x.ko:WARNING:et131x_ioctl Unhandled IOCTL Code: 0x8946
Mar 23 23:30:01 inferno et131x.ko:WARNING:et131x_ioctl Unhandled IOCTL Code: 0x8946
(remember I'm using this driver for 3 interfaces (eth1/2/3) on the same system... maybe it's really just one message repeated once-per-interface?)
So far eth1 (used by ppp0 for DSL PPPoE access) is also working properly... though it worked properly at first last time too... so I'll have to see if it's still happy tomorrow morning.
Thanks!
Mike
I'm back from a week out of town, and I still see this line 3x every 15 seconds :
Apr 1 21:05:00 inferno et131x.ko:WARNING:et131x_ioctl Unhandled IOCTL Code: 0x8946
Also, after running a few days it starts with the "<7>0x00000000"-type messages:
Mar 27 07:56:46 inferno NETDEV WATCHDOG: eth3: transmit timed out
Mar 27 07:56:46 inferno et131x.ko:WARNING:et131x_tx_timeout TX TIMEOUT
Mar 27 07:56:46 inferno et131x.ko:WARNING:et131x_tx_timeout Send stuck - reset. pMpTcb->WrIndex 82, Flags 0x00000000
Mar 27 07:56:46 inferno et131x.ko:WARNING:et131x_tx_timeout pDesc 0x00000000, 0x1354b08e, 0x00000042, 0x00000007
Mar 27 07:56:46 inferno et131x.ko:WARNING:et131x_tx_timeout WbStatus 0x00000483
Mar 27 07:56:46 inferno Global block
Mar 27 07:56:46 inferno <snipped <7>0x00000000-type messages>
Mar 27 07:56:46 inferno Tx DMA block
Mar 27 07:56:46 inferno <snipped <7>0x00000000-type messages>
Mar 27 07:56:46 inferno Tx MAC block
Mar 27 07:56:46 inferno <snipped <7>0x00000000-type messages>
Mar 27 07:56:46 inferno MAC block
Mar 27 07:56:46 inferno <snipped <7>0x00000000-type messages>
Once these type of messages start, they happen every second from then on until I reboot. Maybe there's some sort of counter in the driver that is wrapping, or something that runs out of room?
If there's anything I can do to help debug where these messages from, please let me know.
Thanks again for writing this driver for Linux!
At least things are consistent :)
I rebooted April 1st... and when I checked on the 1st and 2nd I only saw the three "Unhandled IOCTL Code: 0x8946" messages over and over. Checking this morning I see the 0x00000000 messages have started again every second: at about 8:30 this morning things made the switch:
Apr 3 08:26:04 inferno et131x.ko:WARNING:et131x_ioctl Unhandled IOCTL Code: 0x8946
Apr 3 08:26:04 inferno et131x.ko:WARNING:et131x_ioctl Unhandled IOCTL Code: 0x8946
Apr 3 08:26:04 inferno et131x.ko:WARNING:et131x_ioctl Unhandled IOCTL Code: 0x8946
Apr 3 08:26:19 inferno et131x.ko:WARNING:et131x_ioctl Unhandled IOCTL Code: 0x8946
Apr 3 08:26:19 inferno et131x.ko:WARNING:et131x_ioctl Unhandled IOCTL Code: 0x8946
Apr 3 08:26:19 inferno et131x.ko:WARNING:et131x_ioctl Unhandled IOCTL Code: 0x8946
Apr 3 08:26:34 inferno et131x.ko:WARNING:et131x_ioctl Unhandled IOCTL Code: 0x8946
Apr 3 08:26:34 inferno et131x.ko:WARNING:et131x_ioctl Unhandled IOCTL Code: 0x8946
Apr 3 08:26:34 inferno et131x.ko:WARNING:et131x_ioctl Unhandled IOCTL Code: 0x8946
Apr 3 08:26:46 inferno NETDEV WATCHDOG: eth1: transmit timed out
Apr 3 08:26:46 inferno et131x.ko:WARNING:et131x_tx_timeout TX TIMEOUT
Apr 3 08:26:46 inferno et131x.ko:WARNING:et131x_tx_timeout Send stuck - reset. pMpTcb->WrIndex f7, Flags 0x00000000
Apr 3 08:26:46 inferno et131x.ko:WARNING:et131x_tx_timeout pDesc 0x00000000, 0x6b3b3c92, 0x0000003e, 0x00000007
Apr 3 08:26:46 inferno et131x.ko:WARNING:et131x_tx_timeout WbStatus 0x00000137
Apr 3 08:26:46 inferno Global block
Apr 3 08:26:46 inferno 0x000002bd, <7>0x000003ff, <7>0x00000000, <7>0x000002bc, <7>0x00000038, <7>0x00000000, <7> ISR , <7>0x001ebfd7, <7>
Apr 3 08:26:46 inferno 0x00000000, <7>0x000101e8, <7>0x00000000, <7>0x0003d090, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>
Apr 3 08:26:46 inferno 0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>
Apr 3 08:26:46 inferno 0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>
Apr 3 08:26:46 inferno 0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>
Apr 3 08:26:46 inferno 0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>
Apr 3 08:26:46 inferno 0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>
Apr 3 08:26:46 inferno 0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>
Apr 3 08:26:46 inferno
Apr 3 08:26:46 inferno Tx DMA block
Apr 3 08:26:46 inferno 0x00000100, <7>0x00000000, <7>0x78078000, <7>0x000001ff, <7>0x00000322, <7>0x00000322, <7>0x00000322, <7>0x00000000, <7>
Apr 3 08:26:46 inferno 0x7a28a000, <7>0x00000137, <7>0x00000137, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>
Apr 3 08:26:46 inferno 0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>
Apr 3 08:26:46 inferno 0x00000137, <7>0x0000ffff, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>
Apr 3 08:26:46 inferno 0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>
Apr 3 08:26:46 inferno 0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>
Apr 3 08:26:46 inferno 0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>
Apr 3 08:26:46 inferno 0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>
Apr 3 08:26:46 inferno
Apr 3 08:26:46 inferno Tx MAC block
Apr 3 08:26:46 inferno 0x00000009, <7>0x03220322, <7>0x00000000, <7>0x0000013f, <7>0x00000040, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>
Apr 3 08:26:46 inferno 0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>
Apr 3 08:26:46 inferno 0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>
Apr 3 08:26:46 inferno 0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>
Apr 3 08:26:46 inferno 0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>
Apr 3 08:26:46 inferno 0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>
Apr 3 08:26:46 inferno 0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>
Apr 3 08:26:46 inferno 0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>
Apr 3 08:26:46 inferno MAC block
Apr 3 08:26:46 inferno 0x0000001f, <7>0x00007117, <7>0x38585060, <7>0x00a1f037, <7>0x000005ee, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>
Apr 3 08:26:46 inferno 0x00000007, <7>0x00000000, <7>0x00000000, <7>0x00001240, <7>0x00002001, <7>0x00000000, <7>0x01000000, <7>0x00000000, <7>
Apr 3 08:26:46 inferno 0xa1b412cd, <7>0x0a000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>
Apr 3 08:26:46 inferno 0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>
Apr 3 08:26:46 inferno 0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>
Apr 3 08:26:46 inferno 0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>
Apr 3 08:26:46 inferno 0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>
Apr 3 08:26:46 inferno 0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>0x00000000, <7>
Apr 3 08:26:46 inferno
...then that entire slab of 0x00000000 errors start repeating every second. If the same thing happens as last week, I should lose all networking in a day or so.
If anybody can suggest something I can attempt to get rid of these errors, I'm very happy to try. I still have a week old version of the module on 2.6.20.3. Should I try a the latest code on 2.6.20.4?
Thanks!
Mike
Oh also, the "Unhandled IOCTL" haven't stopped.. they're still happening.
Also, the eth1 interface that has the 0x00000000 error seems to have stopped sending/receiving traffic:
eth1 Link encap:Ethernet HWaddr 00:0A:CD:12:B4:A1
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:39290 dropped:0 overruns:0 frame:39290
TX packets:29265143 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:24447390148 (23314.8 Mb) TX bytes:14084539547 (13432.0 Mb)
Interrupt:11
The TX packet number isn't changing any more, but the "RX packets" count is now zero (which is strange, as this interface has received about 23GB of data) and the "RX errors" number is climbing constantly. Do those numbers come from the et131x driver? Is the RX number maybe overflowing some internal counter when it gets too large? This is a 64bit AMD system: does the driver need to do anything special for 64bit-ness?
Regards,
Mike
I had to revert the code back when i tried to add code to handle IOCTL Code 0x8946, this is just a warning message indicating that the driver does not process this IOCTL message, it requires some rewrite of the driver though in order to remove the warning. This warning isn't a problem. I get warnings from the IOCTL subsystem as well due to my 2nd wireless ethernet card on my box, as the et131x driver doesn't process wireless IOCTL messages. As far as the timeout messages go, since you have this card wrapped with your pppoe driver, I would try different settings for the timeout default in the pppd driver. I have a suspicion that this is what is causing your problem. The pppd driver can shut down your connection, resulting in timeout error messages. Have you been able to ifdown eth1, ifup eth1 successfully at all? This should reset the connection. If that doesnt do it, I'd google around for pppoe timeouts. I run this on a AMD64 kernel as well, and have not had issues with it.
Hi rla3rd,
Thanks for your help! The DSL/ppp0 connection had been using an onboard Nvidia GigE interface with no problems (exact same pppd/ppp0 setup)... maybe I can switch it back and the 0x00000000 messages will go away. I was concerned because eth1 is also the et131x card that moves the most traffic. i.e. hopefully when the other 2 cards reach similar amounts of traffic over time they don't also start showing errors (and they are straight GigE: no ppp wrapper).
Actually, I could probably leave something like iPerf running until those other connections show similar MB numbers in ifconfig. That would set my mind at ease, and show that it's probably a pppd interaction error...
The next time I see the errors I'll try in order:
1) restart the ppp0/PPPoE wrapper, and if that fails...
2) restart eth1, and if that fails...
3) rmmod/modprobe the module (which would bring down all 3 cards), and if that fails...
4) reboot
....and see what happens!
Thanks again!
Mike
- Restarting ppp0/PPPoE made no difference (ppp0 couldn't connect, since eth1 was locked uan
- stoping/restarting eth1 didn't make any changes either (even ifconfig down/up didn't reset the counters)
- I was unable to rmmod the module - said it was in use - ended up rebooting to get eth1 reset
- upgraded to 2.6.20.4 and today's svn, and enabled CONFIG_MODULE_FORCE_UNLOAD in my kernel so I cna try a "rmmod -f" in the future
- will let you know how it goes....
Thanks!
Mike
Update:
I switched the ppp0/eth1 (most used et131x) interface to use eth0 instead (which uses the Nvidia forcedeth driver). The system runs for about the same amount of time before logging 0x00000000-type errors for eth3 instead ... and eth3 is the second-most active et131x interface (2nd Internet connection)... and it has nothing to do with the ppp0/DSL connection.
I don't know what to test next. As soon as I boot I get 0x8946 errors every 15 seconds... after a day or so the most active et131x drive starts kicking out 0x00000000 errors after moving many GB of traffic... not too long after that the system essentially locks up (although I can see activity on the screen still the mouse/keyboard/network are unresponsive.
I just updated the motherboard BIOS to the latest version and left all settings on default/auto. I'll let it run again and see what happens. I'm also going to start logging ifconfig output to see if it's around the same total tranfer number each time a et131x interface switches to the 0x00000000 errors and starts showing 0 received packets.
I'll let you know what I find: I'm hoping to at least get something reproducible.
Thanks!
Hmmm... I'm copying lots of files through the system now, and I saw a /var/log/messages entry I hadn't seen before:
Apr 8 22:10:25 inferno et131x.ko:WARNING:et131x_isr_handler RXDMA_FB_RING0_LOW or RXDMA_FB_RING1_LOW interrupt
Apr 8 22:10:25 inferno et131x.ko:WARNING:et131x_isr_handler RXDMA_FB_RING0_LOW or RXDMA_FB_RING1_LOW interrupt
...not sure if it's a clue: it's just labelled as a warning.
Hi all,
I promise this is my last update on this thread. When I wrap ppp0 around my Nvidia/forcedeth-driver card it works (i.e it worked fine before, and I had it switched back over the last 3 days and there wasn't a single problem. When I switch ppp0 and the cables to use eth1 (et131x card) after about 24 hours the 0x00000000 messages start again.
So, for now I'll use my DSL connection over the Nvidia interface... since I don't really have a choice... but it's not an ideal solution.
I'll keep an eye on my lower traffic (eth2 and eth3) et131x cards and see if they complain over time. They handle wireless connections so they don't see a lot of activity... so I'm hoping they'll be OK.
Thanks!
Any updates on this issue? I am having the same issue on a RHEL4 box running 2.6.9-55.0.6.ELsmp and this driver. One thing to note, that it seems twangthunk might also notice, I am running this card at 100mbit, not gig-e. It sounds like twangthunk may be dong the same if it's connected to a cable modem. wondering if this may have something to do with this issue. It is definitely related to data rate (not uptime) because if i push 2 8mbit/sec streams on a 100mbit/sec switch, it will hang eventually.
Thanks,
Karl
I wrote a simple brutefore fix.
see the patch tracker: http://sourceforge.net/tracker/index.php?func=detail&aid=1809006&group_id=179406&atid=889025