On 2/28/06, Per Jessen wrote:

What you need to do is make sure the system loads the right driver. The kernel has a whole section called "Tulip family network drivers", of which one option is "Davicom DM910x/DM980x support". The module is called "dmfe". I think that's what you're after - if you want to be sure, send us the PCI-ids (hex-numbers printed out by lspci -n) of the Davicom device.

I'll do that -- tonight is the earliest

You didn't say anything about which kernel version you've got, so you may or may not have this module. Try "modprobe dmfe" and let us know what it says - optionally post the last few lines of "dmesg".

suse 10 boxed (whatever kernel version it installs) -- but I will get the modprobe data also and post it. I may also use the "reintstall cd" to put everything back as from the factory, just to see the nic info P (sorry about the double post, Per ...)

Peter Van Lone wrote:

Below is the last bit of lspci -v (only the Davicom portion) and then the lspci -n where the last entry is, I think, the one that matches the Davicom portion of lspci -v

02:02.0 Ethernet controller: Davicom Semiconductor, Inc. 21x4x DEC-Tulip compati ble [snip] 02:02.0 Class 0200: 1282:9102 (rev 31)

OK, the '1282' identifies the manufacturer to be Davicom Semiconductor, Inc., and the '9102' means "21x4x DEC-Tulip compatible 10/100 Ethernet", which is of course what lspci/YaST tells us. (You can look up PCI ids in /usr/share/pci.ids). I checked the source for the dmfe module, and it is definitely the right driver for that chip.

0000:02:02.0: tulip_stop_rxtx() failed 0000:02:02.0: tulip_stop_rxtx() failed 0000:02:02.0: tulip_stop_rxtx() failed

So -- what next? This nic works in windows, so the issue is not failed hardware.

You need to look a bit further back in the dmesg output. I don't know what the tulip_stop_rxtx() failed means, but at the very least we should see the module being loaded and recognising the chip. If you don't know where to look, just send the entire dmesg output to me (off-line) and I'll have a look. Also, once you've loaded the "dmfe" module, check if you've got a new ethernet device - cat /proc/net/dev/. /Per Jessen, Zürich

Peter Van Lone wrote:

ok, will do tonight ... but what I sent you was the begginging of the output I could grab from the terminal window -- it was clear that there was earlier material, but I could not scroll up to get to it. I suppose I should do something like dmesg > /root/dmesout.txt or some such, to capture everything?

Yep, you do "dmesg >dmesg.txt" - that'll write all the output to a file called "dmesg.txt".

...

Also, once you've loaded the "dmfe" module, check if you've got a new ethernet device - cat /proc/net/dev/.

how will I attempt to do that? I would think that since it is defined as being the module for this device, the system has already loaded it?

That is a good assumption - "lsmod" will tell you if its alreayd loaded.

Would I do a network restart, or some such thing? (sorry be dense, but it's all still pretty new ..)

Don't worry - it's a learning exercise. Boot your system as normal, then do the "modprobe dmfe". That is a load of the module plus any other required modules. Then you do "cat /proc/net/dev/" Per

On Wednesday 01 March 2006 19:18, Peter Nikolic wrote:

you could use "dmseg|o" as suse is setup to use o as analias for either more or less can never remember which one but it works a treat use the up/down arrow keys to navigate then ..

Why not just "dmesg | less" ? Up and down arrows and PgUp and PgDn keys for scrolling and a 'q' to quit. Easy and no alias involved. Carl

On 3/1/06, Per Jessen wrote:

You need to look a bit further back in the dmesg output. I don't know what the tulip_stop_rxtx() failed means, but at the very least we should see the module being loaded and recognising the chip. If you don't know where to look, just send the entire dmesg output to me (off-line) and I'll have a look. Also, once you've loaded the "dmfe" module, check if you've got a new ethernet device - cat /proc/net/dev/.

I've attached a file in a seperate message offline to you, that contains the entire dmesg output after a reboot. I can't tell exactly why it is failing from this, perhaps you will be able to. It appears as though it identified the ip address of the dhcp server ... Also, here is the output of cat /proc/net/dev and also lsmod and modprobe dmfe linux:~ # cat /proc/net/dev Inter-| Receive | Transmit face |bytes packets errs drop fifo frame compressed multicast|bytes packe ts errs drop fifo colls carrier compressed lo: 3756 50 0 0 0 0 0 0 3756 50 0 0 0 0 0 0 sit0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 eth0: 2977 24 241 0 0 0 0 0 745 7 13 0 0 0 13 0 linux:~ # linux:~ # modprobe dmfe linux:~ # linux:~ # lsmod Module Size Used by nls_utf8 2048 0 hfsplus 75140 0 ipt_pkttype 1664 1 ipt_LOG 6912 7 vfat 12800 0 fat 49692 1 vfat ipt_limit 2304 7 subfs 7552 2 speedstep_lib 4228 0 freq_table 4612 0 snd_pcm_oss 59168 0 snd_mixer_oss 18944 1 snd_pcm_oss snd_seq 51984 0 snd_seq_device 8588 1 snd_seq button 7056 0 battery 10244 0 ac 5252 0 af_packet 21384 0 edd 9824 0 tulip 51360 0 snd_intel8x0 33408 1 snd_ac97_codec 90876 1 snd_intel8x0 ehci_hcd 32136 0 snd_ac97_bus 2432 1 snd_ac97_codec snd_pcm 93064 3 snd_pcm_oss,snd_intel8x0,snd_ac97_codec snd_timer 24452 2 snd_seq,snd_pcm snd 60420 10 snd_pcm_oss,snd_mixer_oss,snd_seq,snd_seq_device,snd_intel8x0,snd_ac97_codec,snd_pcm,snd_timer soundcore 9184 1 snd snd_page_alloc 10632 2 snd_intel8x0,snd_pcm i2c_i801 8844 0 i2c_core 20368 1 i2c_i801 hw_random 5268 0 intel_agp 22044 1 agpgart 33096 1 intel_agp uhci_hcd 32016 0 generic 4484 0 [permanent] usbcore 112640 3 ehci_hcd,uhci_hcd shpchp 88676 0 pci_hotplug 26164 1 shpchp ip6t_REJECT 5504 3 ipt_REJECT 5632 3 ipt_state 1920 12 iptable_mangle 2688 0 iptable_nat 22228 0 iptable_filter 2816 1 ip6table_mangle 2304 0 ip_conntrack 42168 2 ipt_state,iptable_nat ip_tables 19456 8 ipt_pkttype,ipt_LOG,ipt_limit,ipt_REJECT,ipt_state,iptable_mangle,iptable_nat,iptable_filter ip6table_filter 2688 1 ip6_tables 18176 3 ip6t_REJECT,ip6table_mangle,ip6table_filter ipv6 242752 13 ip6t_REJECT parport_pc 38980 1 lp 11460 0 parport 33864 2 parport_pc,lp dm_mod 54972 0 reiserfs 250480 1 ide_cd 39684 0 cdrom 36896 1 ide_cd fan 4996 0 thermal 14472 0 processor 24252 1 thermal piix 9988 0 [permanent] ide_disk 17152 3 ide_core 122380 4 generic,ide_cd,piix,ide_disk linux:~ #

On 3/2/06, Per Jessen wrote:

To summarise - your card is being recognised by YaST and the right driver is loaded etc. So what sort of problem are you seeing now?

the same that I have had all along ... no ip address, no communication on the lan. It should be picking up an IP from the dhcp server .. I suppose I could try manuala ssignement, I'll do that. Not sure why it would not work with linux when it does with windows. And, what are all the error messages in dmesg? P

On 3/2/06, Per Jessen wrote:

What does "ifconfig eth0" say?

I have not checked that since before sending the original post ... it reported the ip 127.0.0.1

The "tulip_stop_rxtx() failed" message? I'm not sure, but I would ignore it for the time being.

ok

On 3/2/06, Per Jessen wrote:

What does "ifconfig eth0" say?

cvl:~ # ifconfig eth0 Link encap:Ethernet HWaddr 00:08:A1:23:26:6E inet addr:192.168.2.198 Bcast:192.168.2.255 Mask:255.255.255.0 inet6 addr: fe80::208:a1ff:fe23:266e/64 Scope:Link UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:399 errors:2406 dropped:0 overruns:0 frame:0 TX packets:7 errors:12 dropped:0 overruns:0 carrier:12 collisions:0 txqueuelen:1000 RX bytes:44957 (43.9 Kb) TX bytes:735 (735.0 b) Interrupt:9 Base address:0xd800 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:96 errors:0 dropped:0 overruns:0 frame:0 TX packets:96 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:7537 (7.3 Kb) TX bytes:7537 (7.3 Kb) cvl:~ #

I noticed some SUSE Firewall messages in the dmesg output - 192.168.2.101 was mentioned. Might that be your card?

no that would be the ip address it had at the time. And then I looked later, and no ip address showed up ... so I did an ipconfig eth0 down, and then ifconfig eth0 up --- to no avail. Still showing no IP addr for eth0. So, I manually added the IP address you see above .. and the gateway and dns servers and subnet addr ... and I can now ping loopback, but cannot ping the df gateway or anything beyond. And another device on the network cannot ping this machine. I disabled the SUSe firewall via YAST ... same thing. dmesg is filled to the brim with the tulip_stop_rxtx( ) failed messages grrr ... now what? Peter

On 3/4/06, Per Jessen wrote:

Looks good except for the many errors.

lol! yes -- now if this were windows, I would guess that either: 1)the OS has an outdated driver for the device it had correctly detected, or 2)the OS has incorrectly detected the device, and therefore the driver being used is wrong I'm not sure how to do these things in linux -- if I find a newer version of the tulip driver, do I install it simply by copying the files to the correct location? If I wanted to try, say, the DMFE driver instead of tulip (is this even an option???) how would I do that? <snip>

That seems to be the problem after all. Try googling for tulip_stop_rxtx - you'll get quite a few hits. I can't quite see if a problem has been fixed, but it might be worth updating your kernel to the most recent kernel-of-the-day (YOU).

well how does one do that without an internet connection? Is it possible to download specific patch/update files to another device and then burn them to cd? (I have not seen that option ... ) Depending on what you say to the questions above, it appears as though I may have 2 choices: 1)dig up an intel pro 10/100 nic from somewhere (I assume these are easily/correctly detected?), or 2)put windows back on, so my son can use his PC -- he's become impatient! sigh ... Peter

On 3/4/06, Daniel Bauer wrote:

"In Yast I deleted the network card and finished Yast. Then opened Yast again and "installed" the network card again, leaving the name, that yast gave her untouched, just overwriting "tulip" by "dmfe" (in hardware details).

After this eth0 was not on the list given by "infconfig" (only lo appeared). I rebooted the PC - and now the network card works as it should. I've rebooted twice, to see, if was only an accident - but it seems that first deleting and then adding the card again works better than just changing the settings."

Since then my card works perfect...

Daniel, that appears to have done it! Thank you so much .. I also saw the following items from a google of the tulip error: "One person found that the follwoing procedure worked: ifdown eth0 rmmod tulip rmmod dmfe modprobe dmfe ifup eth0" and the debian bug list reported this in a bug about tulip not working with the davicom chipset:: "The problem with this is, that after another bugreport (see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=284730) the kernel module for this device was changed from dmfe to tulip. It seems that some devices work with the dmfe module while others work with tulip, but yet they both use the same PCI ID. I really don't know what to do in this case." So -- I followed your suggestions and replaced "tulip" with "dmfe" in the hardware details after removing and then re-adding the nic. I did not do a restart, but ratther rmmod tulip rmmod dmfe modprobe dmfe ifup eth0 after serveral reboots to check ... all now appears good. Thank you much! Peter

On 3/4/06, Per Jessen wrote:

Peter Van Lone wrote:

...

1)the OS has an outdated driver for the device it had correctly detected, or 2)the OS has incorrectly detected the device, and therefore the driver being used is wrong

1) is a possibility, but given that the PCI ids are a match, I doubt it. And certainly not 2).

if you look at my last post on this, from the debian buglist entry makes it clear that some davicom devices work with tulip and not dmfe, and some the other way around. And they share a PCI device ID.

...

If I wanted to try, say, the DMFE driver instead of tulip (is this even an option???) how would I do that?

To be honest, I'm not sure. It used to be a simple edit of /etc/module.conf, now /etc/modprobe.conf, but I haven't really worked enough with 2.6 to know my way around. I'm sure someone can tell you how to specify you want to use dmfe instead of tulip. In the meantime, you could just unload the tulip module (rmmod tulip) and load the dmfe instead (modprobe dmfe).

simply changing the module name in yast/network devices/<your nic>/hardware details seems to have done it Thank you so much Per for sticking with me on this thread! The support and good will generated by folks like you and Daniel is quite amazing! Peter