Most recent kernel where this bug did not occur: 2.6.21 Distribution: Debian Hardware Environment: Various hardware with a Davicom Semiconductor 21x4x ethernet card. lspci output: 02:0c.0 Ethernet controller: Davicom Semiconductor, Inc. 21x4x DEC-Tulip compatible 10/100 Ethernet (rev 40) Subsystem: Unknown device 3030:5032 Flags: bus master, medium devsel, latency 64, IRQ 225 I/O ports at d800 [size=256] Memory at feafbc00 (32-bit, non-prefetchable) [size=256] Expansion ROM at bfe00000 [disabled] [size=256K] Capabilities: [50] Power Management version 2 Software Environment: Plain Debian with linux-image-2.6.22-2-686 Problem Description: When booting kernel 2.6.22 network goes up but the server is unable to make it work correctly: even the ping does not respond. ARP cache table is correctly populated tough. Steps to reproduce: Boot with kernel 2.6.22 and simply ping a host on the local network. The ping does not work.
I looked at the diff of drivers/net/tulip (2.6.21.7 vs 2.6.22.9) and dmfe.c has had substantial changes to support wake-on-lan and suspend/resume. I can't explain why 2.6.21 works and 2.6.22 doesn't offhand. In fact, I can't explain why/how either version works. However, like nearly every other variant of the tulip driver, this one doesn't follow the 802.3 MII spec with respect to how the Phy/MII is reset. See bug 2776 and try this patch please: http://iou.parisc-linux.org/~grundler/diff/diff-2.6.23-rc3-dmfe_phy-01 If that helps, I can close both bugs. :)
I'm in no position to test a custom built kernel, sorry. More over I do not have the hardware any more: I made swap the net cards with realtek ones and I solved my problems that way. I reported the problem so it could be documented and solved for others.
Alessandro, no problem! I could have built a kernel for you...but I don't have the HW either. And it was a good idea to just use a different card. These problems aren't always that easy to fix. I'd like to leave this bug open until someone can test the dmfe patch. I _might_ close it as a duplicate of bug 2776 but will decide that later. thanks again! grant
On parisc, I get the same behavior on parisc using tulip driver (ARP works but can not send TCP packets) when the kernel is built with gcc 4.3 but not when it's built with gcc 4.1 or 4.2. Something changed in the higher networking stack layers that are tickling this bug.
Kyle tracked down the parisc/tulip issue to a compiler bug getting tickled by something in the net/ipv4 core code. Bug was fixed and that went away. I just checked and it looks like diff-2.6.23-rc3-dmfe_phy-01 never got submitted. I'll work on that and then close this bug once it's upstream.
I might need to submit this as a new bug? - I'm trying to use the dmfe module on a Sun Fire V100 (SPARC architecture), running Gentoo Linux. the dmfe module doesn't pick up the Hardware/MAC address and even if I specify the address with "ifconfig eth0 hw ether <mac>" it still doesn't come up. I did try applying the above patch to a 2.6.26 kernel, and get the same problem. I've just tried a fresh 2.6.28 kernel as I could see that some changes had been listed for dmfe in the Changelog, but I still have the same problem. I've tried rolling back to a 2.6.16 kernel, but I can't get that to successfully boot. The hardware is listed as "Davicom Semiconductor, Inc. 21x4x DEC-Tulip compatible 10/100 Ethernet (rev 31)"
(In reply to comment #5) > Kyle tracked down the parisc/tulip issue to a compiler bug getting tickled by > something in the net/ipv4 core code. Bug was fixed and that went away. > > I just checked and it looks like diff-2.6.23-rc3-dmfe_phy-01 never got > submitted. I'll work on that and then close this bug once it's upstream. The Debian kernel package was built using gcc-4.1, according to the build log at <https://buildd.debian.org/fetch.cgi?&pkg=linux-2.6&ver=2.6.22-4&arch=i386&stamp=1188532633&file=log>, so this is a separate bug.