[PATCH] Making de2104x working with BNC connection on 21040 chipset

[PATCH] Making de2104x working with BNC connection on 21040 chipset

[Michael Mueller]

[-- Attachment #1: Type: text/plain, Size: 891 bytes --]

Hi,

while I recently updated an older machine to the latest Debian
distribution which included updating the kernel from 2.4.x to 3.0 the
tulip driver did stop working for my network card. The replacement
driver de2104x did initialize the network interfaces but no transmission
was possible.

Digging into it I found the de2104x driver just assumes there is no BNC
transceiver on a card using the 21040 chipset. So I extracted the
correct configuration values from the old tulip driver and removed some
sanity checking which denied setting the transceiver to BNC. Now I can
use the driver by just setting the correct transceiver using ethtool.

A patch against 3.0 is appended. It should apply against more recent
versions too since there was not the lot happening for this old driver,
but for the relocation of the files from drivers/net/tulip to
drivers/net/ethernet/dec/tulip.


Michael


[-- Attachment #2: de21040_bnc.patch --]
[-- Type: text/x-patch, Size: 1991 bytes --]

--- drivers/net/tulip/de2104x.c.orig	2012-01-12 23:12:31.000000000 +0100
+++ drivers/net/tulip/de2104x.c	2012-01-12 23:15:52.000000000 +0100
@@ -358,10 +358,10 @@
 };
 
 /* 21040 transceiver register settings:
- * TP AUTO(unused), BNC(unused), AUI, TP, TP FD*/
-static u16 t21040_csr13[] = { 0, 0, 0x8F09, 0x8F01, 0x8F01, };
-static u16 t21040_csr14[] = { 0, 0, 0x0705, 0xFFFF, 0xFFFD, };
-static u16 t21040_csr15[] = { 0, 0, 0x0006, 0x0000, 0x0000, };
+ * TP AUTO(unused), BNC, AUI, TP, TP FD*/
+static u16 t21040_csr13[] = { 0, 0x8F0D, 0x8F09, 0x8F01, 0x8F01, };
+static u16 t21040_csr14[] = { 0, 0x0705, 0x0705, 0xFFFF, 0xFFFD, };
+static u16 t21040_csr15[] = { 0, 0x0006, 0x0006, 0x0000, 0x0000, };
 
 /* 21041 transceiver register settings: TP AUTO, BNC, AUI, TP, TP FD*/
 static u16 t21041_csr13[] = { 0xEF01, 0xEF09, 0xEF09, 0xEF01, 0xEF09, };
@@ -975,7 +975,7 @@
 	carrier = (status & NetCxnErr) ? 0 : 1;
 
 	if (carrier) {
-		if (de->media_type != DE_MEDIA_AUI && (status & LinkFailStatus))
+		if (de->media_type != DE_MEDIA_AUI && de->media_type != DE_MEDIA_BNC && (status & LinkFailStatus))
 			goto no_link_yet;
 
 		de->media_timer.expires = jiffies + DE_TIMER_LINK;
@@ -1536,8 +1536,6 @@
 		return -EINVAL;
 	if (ecmd->port != PORT_TP && ecmd->port != PORT_AUI && ecmd->port != PORT_BNC)
 		return -EINVAL;
-	if (de->de21040 && ecmd->port == PORT_BNC)
-		return -EINVAL;
 	if (ecmd->transceiver != XCVR_INTERNAL)
 		return -EINVAL;
 	if (ecmd->autoneg != AUTONEG_DISABLE && ecmd->autoneg != AUTONEG_ENABLE)
@@ -1731,12 +1729,14 @@
 
 	de->media_type = DE_MEDIA_TP;
 	de->media_supported |= SUPPORTED_TP | SUPPORTED_10baseT_Full |
-			       SUPPORTED_10baseT_Half | SUPPORTED_AUI;
+			       SUPPORTED_10baseT_Half | SUPPORTED_AUI |
+			       SUPPORTED_BNC;
 	de->media_advertise = de->media_supported;
 
 	for (i = 0; i < DE_MAX_MEDIA; i++) {
 		switch (i) {
 		case DE_MEDIA_AUI:
+		case DE_MEDIA_BNC:
 		case DE_MEDIA_TP:
 		case DE_MEDIA_TP_FD:
 			de->media[i].type = i;

Re: [PATCH] Making de2104x working with BNC connection on 21040 chipset

[Paul Gortmaker]

On Thu, Jan 12, 2012 at 5:52 PM, Michael Mueller <malware@t-online.de> wrote:
> Hi,
>
> while I recently updated an older machine to the latest Debian
> distribution which included updating the kernel from 2.4.x to 3.0 the
> tulip driver did stop working for my network card. The replacement
> driver de2104x did initialize the network interfaces but no transmission
> was possible.

Did you try the original de4x5.c driver?   I believe it was all that existed
back in the 2.4 vintage, and I think it was kept around just to keep old
cards that didn't like the "new" tulip driver working.

Paul.

>
> Digging into it I found the de2104x driver just assumes there is no BNC
> transceiver on a card using the 21040 chipset. So I extracted the
> correct configuration values from the old tulip driver and removed some
> sanity checking which denied setting the transceiver to BNC. Now I can
> use the driver by just setting the correct transceiver using ethtool.
>
> A patch against 3.0 is appended. It should apply against more recent
> versions too since there was not the lot happening for this old driver,
> but for the relocation of the files from drivers/net/tulip to
> drivers/net/ethernet/dec/tulip.
>
>
> Michael
>

Re: [PATCH] Making de2104x working with BNC connection on 21040 chipset

[Michael Mueller]

Hi Paul,

you wrote [copy to you]:
>> while I recently updated an older machine to the latest Debian
>> distribution which included updating the kernel from 2.4.x to 3.0 the
>> tulip driver did stop working for my network card. The replacement
>> driver de2104x did initialize the network interfaces but no transmission
>> was possible.
> 
> Did you try the original de4x5.c driver?   I believe it was all that existed
> back in the 2.4 vintage, and I think it was kept around just to keep old
> cards that didn't like the "new" tulip driver working.

In 2.4.x the tulip driver was present and did work for me when selecting
the transceiver by module parameter.

The original de4x5 does not exist in 3.0. The comments at the top of
de2104x.c suggest it had been consolidated into this one. The de2104x
driver is the one autoloaded due to the PCI id of the device, see bottom
for lspci output. So it seems to be the obvious candidate to get
running. Selecting the transceiver using ethtool might to be sufficient
for this corner case. Otherwise the media auto dectection sheme would
have to be changed too which may cause trouble to users of the currently
about exclusively used twisted pair cabling. The way I solved the
problem I see no harm taken.

When trying the de4x5 using 2.6.32 - which is what I can boot into
without too much problems - it did lock the machine while starting the
interface (ifconfig up). Sorry, but I do not feel like digging into this
just now.

A comment in the de4x5 driver source suggest that for the 21040 chipset
it is a choice of the board maker to connect a BNC, an AUI port or both
selectable by jumper. Mine has no AUI, probably because two of them
would not fit onto the slot plate together with 2 TP ports while there
is enough space for 2 TP and 2 BNC.


Michael


00:11.0 0604: 1011:0001 (rev 02) (prog-if 00 [Normal decode])
        Flags: bus master, medium devsel, latency 64
        Bus: primary=00, secondary=02, subordinate=02, sec-latency=64
        I/O behind bridge: 00009000-00009fff
        Memory behind bridge: cfe00000-cfefffff
        Prefetchable memory behind bridge: cdb00000-cdbfffff

[AGP left out]

02:04.0 0200: 1011:0002 (rev 23)
        Flags: bus master, medium devsel, latency 64, IRQ 11
        I/O ports at 9c00 [size=128]
        Memory at cfefff80 (32-bit, non-prefetchable) [size=128]
        Kernel driver in use: de2104x

02:05.0 0200: 1011:0002 (rev 23)
        Flags: bus master, medium devsel, latency 64, IRQ 11
        I/O ports at 9800 [size=128]
        Memory at cfefff00 (32-bit, non-prefetchable) [size=128]
        Kernel driver in use: de2104x

de4x5 (was Re: [PATCH] Making de2104x working with BNC connection on 21040 chipset)

[Michael Mueller]

Hi Paul,

I wrote [copy to you]:
> The original de4x5 does not exist in 3.0. The comments at the top of

My fault, it was not included into the compiled version of 3.1 for debian.

> When trying the de4x5 using 2.6.32 - which is what I can boot into
> without too much problems - it did lock the machine while starting the
> interface (ifconfig up). Sorry, but I do not feel like digging into this
> just now.

I did try this with 3.1 now and it did lock up too but started printing
out the cutting line of an oops. Replacing init by bash I got the
remainder of a trace on the console. I could catch it on a serial
console then:

# insmod ./de4x5.ko
[   47.051976] de4x5 0000:02:04.0: PCI INT A -> Link[LNKB] -> GSI 11
(level, low) -> IRQ 11
[   47.167825] 0000:02:04.0: DE434/5 at 0x9c00, h/w address
00:00:c0:e5:0c:c0
[   47.250320]       and requires IRQ11 (provided by PCI BIOS).
[   47.318094] de4x5.c:V0.546 2001/02/22 davies@maniac.ultranet.com
[   47.391488] de4x5 0000:02:05.0: PCI INT A -> Link[LNKC] -> GSI 11
(level, low) -> IRQ 11
[   47.507273] 0000:02:05.0: DE434/5 at 0x9800, h/w address
00:00:c0:3e:09:c0
[   47.589822]       and requires IRQ11 (provided by PCI BIOS).
[   47.657595] de4x5.c:V0.546 2001/02/22 davies@maniac.ultranet.com
# ifconfig eth2 up
[   52.750984] ------------[ cut here ]------------
[   52.806316] WARNING: at fs/proc/generic.c:323
__xlate_proc_name+0x88/0x92()
[   52.889717] Hardware name: K7S5A
[   52.956449] name 'DE434/5 (0000:02:05.0)'
[   53.004387] Modules linked in: de4x5 ext3 jbd mbcache dm_mod sr_mod
sd_mod cdrom crc_t10dif ata_generic ohci_hcd ehci_hcd pata_sis libata
scsi_mod epic100 usbcore sis900 mii floppy [last unloaded: de2104x]
[   53.225143] Pid: 162, comm: ifconfig Not tainted 3.1.0-1-686-pae #1
[   53.300113] Call Trace:
[   53.329345]  [<c1037684>] ? warn_slowpath_common+0x68/0x79
[   53.395051]  [<c1100231>] ? __xlate_proc_name+0x88/0x92
[   53.457545]  [<c10376fd>] ? warn_slowpath_fmt+0x29/0x2d
[   53.520037]  [<c1100231>] ? __xlate_proc_name+0x88/0x92
[   53.582530]  [<c1100285>] ? __proc_create+0x4a/0xe6
[   53.640866]  [<c1100486>] ? proc_mkdir_mode+0x18/0x3b
[   53.701285]  [<c1077e43>] ? register_handler_proc+0xbf/0xe5
[   53.768039]  [<c10769df>] ? __setup_irq+0x2c5/0x310
[   53.826385]  [<e0810af5>] ? de4x5_queue_pkt+0x290/0x290 [de4x5]
[   53.897288]  [<c1076ac5>] ? request_threaded_irq+0x9b/0xc2
[   53.962903]  [<e081311b>] ? de4x5_open+0x293/0x436 [de4x5]
[   54.028514]  [<c120e46b>] ? __dev_open+0x7a/0xa4
[   54.083728]  [<c120e631>] ? __dev_change_flags+0x8e/0x101
[   54.148298]  [<c120e703>] ? dev_change_flags+0x10/0x3b
[   54.209757]  [<c124e004>] ? devinet_ioctl+0x24d/0x502
[   54.270172]  [<c11ff049>] ? sock_ioctl+0x1b4/0x1db
[   54.327462]  [<c11fee95>] ? might_fault+0x5/0x5
[   54.381645]  [<c10d32fe>] ? do_vfs_ioctl+0x459/0x48f
[   54.441123]  [<c12b1037>] ? do_page_fault+0x2e0/0x2fc
[   54.501633]  [<c12b1024>] ? do_page_fault+0x2cd/0x2fc
[   54.562051]  [<c1078ca3>] ? __call_rcu+0xd6/0xe1
[   54.617262]  [<c10d3378>] ? sys_ioctl+0x44/0x68
[   54.671440]  [<c12b295f>] ? sysenter_do_call+0x12/0x28
[   54.732888] ---[ end trace 63fdd5a99a21a1c6 ]---

I changed the name from 'DE434/5' to 'DE434_5' since the slash seems to
be no good idea within a file/directory name. This does yield a lockup
with no message.


Michael

Re: de4x5

[Michael Mueller]

[-- Attachment #1: Type: text/plain, Size: 806 bytes --]

Hi Paul,

I wrote [copy to you]:
>> When trying the de4x5 using 2.6.32 - which is what I can boot into
>> without too much problems - it did lock the machine while starting the
>> interface (ifconfig up). Sorry, but I do not feel like digging into this
>> just now.
[..]
> I changed the name from 'DE434/5' to 'DE434_5' since the slash seems to
> be no good idea within a file/directory name. This does yield a lockup
> with no message.

It hangs due to the usage of synchronize_irq within the interrupt
handler. It does not look like it was intended usage for this. Removing
this code it does not lock up anymore. But it is not working either.
Looking through the code it uses the same configuration values for BNC
and AUI which de2104x uses for AUI.

Changes done so far are appended as patch.


Michael

[-- Attachment #2: de4x5.patch --]
[-- Type: text/x-patch, Size: 808 bytes --]

--- drivers/net/tulip/de4x5.c.orig	2011-12-09 17:57:05.000000000 +0100
+++ drivers/net/tulip/de4x5.c	2012-01-14 18:54:46.000000000 +0100
@@ -1551,8 +1551,6 @@
     if (test_and_set_bit(MASK_INTERRUPTS, (void*) &lp->interrupt))
 	printk("%s: Re-entering the interrupt handler.\n", dev->name);
 
-    synchronize_irq(dev->irq);
-
     for (limit=0; limit<8; limit++) {
 	sts = inl(DE4X5_STS);            /* Read IRQ status */
 	outl(sts, DE4X5_STS);            /* Reset the board interrupts */
@@ -3909,7 +3907,7 @@
     int i, status = 0, siglen = ARRAY_SIZE(de4x5_signatures);
 
     if (lp->chipset == DC21040) {
-	strcpy(name, "DE434/5");
+	strcpy(name, "DE434_5");
 	return status;
     } else {                           /* Search for a DEC name in the SROM */
 	int tmp = *((char *)&lp->srom + 19) * 3;