Latest working kernel version: 2.6.24.4 Earliest failing kernel version: 2.6.25, 2.6.24 (the last was fixed in 2.6.24.3) Distribution: Debian Sid Hardware Environment: 2xPentiumIII 800 on a Supermicro board, dl2k nic in PCI-X 66MHz slot, lspci result 00:00.0 Host bridge: Broadcom CNB20LE Host Bridge (rev 05) 00:00.1 Host bridge: Broadcom CNB20LE Host Bridge (rev 05) 00:03.0 Ethernet controller: D-Link System Inc DL2000-based Gigabit Ethernet (rev 0c) 00:06.0 Ethernet controller: Intel Corporation 82557/8/9/0/1 Ethernet Pro 100 (rev 08) 00:0f.0 ISA bridge: Broadcom OSB4 South Bridge (rev 4f) 00:0f.1 IDE interface: Broadcom OSB4 IDE Controller 00:0f.2 USB Controller: Broadcom OSB4/CSB5 OHCI USB Controller (rev 04) 01:01.0 RAID bus controller: Silicon Image, Inc. SiI 3114 [SATALink/SATARaid] Serial ATA Controller (rev 02) 01:02.0 VGA compatible controller: nVidia Corporation NV11 [GeForce2 MX/MX 400] (rev b2) 01:03.0 SCSI storage controller: Adaptec AIC-7892P U160/m (rev 02) Software Environment: any Problem Description: The first 2.6.24 linux kernel introduced the bug with this dl2k based nic. After bringing the interface up no packet gets into the wire without any error messages. There are some difference in kernel initialization messages: from 2.6.24.4 dmesg: DL2000/TC902x-based linux driver v1.19 2007/08/12 ACPI: PCI Interrupt 0000:00:03.0[A] -> GSI 20 (level, low) -> IRQ 16 eth0: D-Link DGE-550T Gigabit Ethernet Adapter, 00:11:95:f4:b7:df, IRQ 16 tx_coalesce:^I16 packets rx_coalesce:^I10 packets rx_timeout: ^I128000 ns from 2.6.26 dmesg: [ 10.747031] ACPI: PCI Interrupt 0000:00:03.0[A] -> GSI 20 (level, low) -> IRQ 20 [ 10.747031] 0000:00:03.0: D-Link NIC [ 10.791499] Ethernet device registered as: eth1 The 2.6.24.3 kernel fixed the problem with this log in ChangeLog: - Fix dl2k constants But since then in all 2.6.25 and 2.6.26 series of linux kernel the problem persist. Steps to reproduce: Just get dl2k based nic, bring the interface up and try to ping something. Thank you in advance, D.I. Kulagin
Confused. 2.6.26's dl2k,x also has the "Fix dl2k constants" patch applied.
May be these patches are not the same or it was broken elsewhere? Once again working kernels: till 2.6.23.17 and from 2.6.24.3 till 2.6.24.4 definitly but I suspect it's till 2.6.24.7 in real.
Do you need a full dmesg?
I have a same problem. D-link DGE-550T + Fedora 9 kernel 2.6.25 and 2.6.26.3-29.fc9.i686. On load after a few seconds network is down. Help only restart server.
Install kernel 2.6.27-rc6 - same problem.
Could you try IP1000 driver instead? Actually, DL2K and IP1000 are the driver for same devices...
Komuro, big thanks for idea! I try IP1000 (IPG) driver. But it is not work too. A read some documentation and found that IPG driver was added in kernel versinon 2.6.24.4. And dl2k on gigabit did not work since 2.6.24.4... I add to modprobe IPG module in blacklist and D-Link Dl200 NIC start working!!! Why? I don't know... I use only dl2k module, but there was conflict with IPG module. Try it! Gust add ipg module to blacklist.
static const char *ipg_brand_name[] = { "IC PLUS IP1000 1000/100/10 based NIC", "Sundance Technology ST2021 based NIC", "Tamarack Microelectronics TC9020/9021 based NIC", "Tamarack Microelectronics TC9020/9021 based NIC", "D-Link NIC", "D-Link NIC IP1000A"}; static struct pci_device_id ipg_pci_tbl[] __devinitdata = { { PCI_VDEVICE(SUNDANCE, 0x1023), 0 }, { PCI_VDEVICE(SUNDANCE, 0x2021), 1 }, { PCI_VDEVICE(SUNDANCE, 0x1021), 2 }, { PCI_VDEVICE(DLINK, 0x9021), 3 }, { PCI_VDEVICE(DLINK, 0x4000), 4 }, { PCI_VDEVICE(DLINK, 0x4020), 5 }, { 0, } };
One solution is to remove D-Link PCI ID from ipg.c static const char *ipg_brand_name[] = { "IC PLUS IP1000 1000/100/10 based NIC", "Sundance Technology ST2021 based NIC", "Tamarack Microelectronics TC9020/9021 based NIC", "Tamarack Microelectronics TC9020/9021 based NIC", - "D-Link NIC", "D-Link NIC IP1000A"}; static struct pci_device_id ipg_pci_tbl[] __devinitdata = { { PCI_VDEVICE(SUNDANCE, 0x1023), 0 }, { PCI_VDEVICE(SUNDANCE, 0x2021), 1 }, { PCI_VDEVICE(SUNDANCE, 0x1021), 2 }, { PCI_VDEVICE(DLINK, 0x9021), 3 }, - { PCI_VDEVICE(DLINK, 0x4000), 4 }, { PCI_VDEVICE(DLINK, 0x4020), 5 }, { 0, } };
Is it possible that D-Link has screwed up and used the same device id for products with two different controllers? In that case the probe routines for these drivers may need to be made more robust so that they reject devices that the other driver should handle.
Actually, D-Link DL2000 is a vendor-id-changed-version of Tamarack TC902x. and the IP1000(ipg.c) is the driver for IP1000 and TC902x. so the solution is (1) fix the IP1000(ipg.c) to fully support TC902x(DL2000). or (2)remove the DL2000 id from the ipg.c driver.
Thanks. For reference, the fix presumably is commit 25cca5352712561fba97bd37c495593d641c1d39 Author: Jeff Mahoney <jeffm@suse.com> Date: Thu Feb 11 10:26:38 2010 +0000 ipg: Remove device claimed by dl2k from pci id table This patch removes D-Link DGE-550T PCI ID (1186:4000) from the ipg driver. The ipg driver is for IP2000-based cards and the DGE-550T is a DL2000-based card. The driver loads and works for a few moments, but once a real workload is applied it stops operating. The ipg driver claimed this ID since it was introduced in 2.6.24 and it's forced many users to blacklist it. The correct driver for this hardware is the dl2k driver, which has been claiming this PCI ID since the 2.4 days.