Bug 128941

Summary:	No network connectivity with Davicom/tulip nic
Product:	[openSUSE] SUSE LINUX 10.0	Reporter:	Uwe Schmeling <u.schmeling>
Component:	Kernel	Assignee:	Karsten Keil <karsten.keil>
Status:	RESOLVED WORKSFORME	QA Contact:	E-mail List <qa-bugs>
Severity:	Minor
Priority:	P5 - None	CC:	forgotten_xOiK_JGQNy
Version:	Final
Target Milestone:	---
Hardware:	i386
OS:	SuSE Linux 10.0
Whiteboard:
Found By:	Other	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Uwe Schmeling 2005-10-18 07:39:00 UTC

After startup the nic fetches its DHCP info an is setup correctly. About 15
packets are transfered in summary. After that I only get RX errors. The hardware
is properly working with a Knoppix 2.6.12 (Knoppix 4) kernel. The logmessages
are permanently showing: tulip_stop_rxtx() failed

Comment 1 Hubert Mantel 2005-10-18 13:36:05 UTC

What happens when you disable ACPI ("acpi=off" or at least "pci=noacpi")? Did you try a failsafe boot?

Comment 2 Uwe Schmeling 2005-10-19 06:41:22 UTC

Forcing the usage of module dmfe instead of the installation automatical selected  tulip module solves the problems. Controller is a Davicom laptop onboard device. Should be fixed!

Comment 3 Hubert Mantel 2005-10-19 15:13:04 UTC

Ok, so I will close this one for now.

Comment 4 Hubert Mantel 2005-10-19 15:14:25 UTC

*** Bug 121853 has been marked as a duplicate of this bug. ***

Comment 5 John Schwartzman 2005-10-19 15:57:33 UTC

Why is this bug closed when you must override Yast's default nic choice.  The Tulip driver is defective and should be patched or other users will be forced to call installation support or search bugzilla.

Comment 6 John Schwartzman 2005-10-19 16:03:04 UTC

Why has this bug been closed when you must override Yast's default nic choice.  If the Tulip driver is defective in 10.0 final, it should be patched or other users will be forced to call installation support or search bugzilla.

Comment 7 Hubert Mantel 2005-10-19 16:09:15 UTC

Reporter said "should be fixed". Btw, I don't think the driver is broken per se, as it seems to work quite well on lots of cards. It seems it's just those cheap Davicom cards that make problems. And btw, why is this bug CRITICAL when there is an easy workaround? Anyway, I think we should just remove the PCI ID from the tulip driver so the dmfe driver is automatically used. Please provide the needed info for that. The hardware description in this bug report is next to non-existant.

Comment 8 Forgotten User xOiK_JGQNy 2005-10-20 19:50:41 UTC

What is the needed hardware description?

Comment 9 Uwe Schmeling 2005-10-24 06:12:48 UTC

2 comments:
I have classified this bug as critical, as I didn't know about the dmfe workaround at this time.
The hardware is like that (lspci):
00:08.0 Ethernet controller: Davicom Semiconductor, Inc. 21x4x DEC-Tulip compatible 10/100 Ethernet (rev 20)
resp.:
00:08.0 Class 0200: 1282:9102 (rev 20)

Hope we are completed now.

Comment 11 Karsten Keil 2006-06-19 17:12:10 UTC

we always have some duplicate drivers, sometimes one of it isn't working.