and when will the following patch go into tulip.c:
----->
--- tulip.c.orig Sun Jun 9 20:15:22 1996
+++ tulip.c Mon Jun 10 00:26:27 1996
@@ -394,6 +394,8 @@
0x0000c000, PCI_DEVICE_ID_DEC_TULIP, "old smc8432", 0},
{auto21140_select, generic21140_fail,
0x0000f400, PCI_DEVICE_ID_DEC_TULIP_FAST, "LA100PCI", 0},
+ {generic21040_select, generic21040_fail,
+ 0x00009200, PCI_DEVICE_ID_DEC_TULIP, "Cogent EM96x", 1},
{cogent21140_select, generic21140_fail,
0x00009200, PCI_DEVICE_ID_DEC_TULIP_FAST, "cogent_em110", 0},
{generic21140_select, generic21140_fail,
@@ -1177,6 +1179,7 @@
{
/* See note below on the Znyx 315 etherarray. */
static unsigned char last_phys_addr[6] = {0x00, 'L', 'i', 'n', 'u',
'x'};
+ static int last_irq = 0;
char detect_mesg[80], *mesgp=detect_mesg;
struct tulip_private *tp = (struct tulip_private *)dev->priv;
int i;
@@ -1246,6 +1251,7 @@
for (i = 0; i < ETH_ALEN - 1; i++)
dev->dev_addr[i] = last_phys_addr[i];
dev->dev_addr[i] = last_phys_addr[i] + 1;
+ irq = last_irq;
}
for (i = 0; i < ETH_ALEN - 1; i++)
mesgp += sprintf(mesgp, "%2.2x:", dev->dev_addr[i]);
@@ -1255,8 +1261,10 @@
/* copy ethernet address */
if (card_type(tp, device_id,
htonl((*(int*)dev->dev_addr) & 0xFFFFFF)))
- for (i = 0; i < ETH_ALEN - 1; i++)
+ for (i = 0; i < ETH_ALEN - 1; i++) {
last_phys_addr[i] = dev->dev_addr[i];
+ last_irq = irq;
+ }
/* We do a request_region() only to register /proc/ioports info. */
request_region(ioaddr, TULIP_TOTAL_SIZE, tp->signature);
------<
This makes tulip.c handle multiport cards (like the Cogent 964) work
correctly with most BIOSes. I think I've seen a more sophisticated patch
for this problem already on linux-kernel, but that one also didn't made it
into the kernel, so I give it another try.
I think I've also found an important bug in tulip_probe(). It will only
work correctly if there's only one kind of chips in your system (21040 or
21041 or 21140 or ...). This is due a wrong arrangement of the pci_index++
and cno++ loops. They should be exchanged.
Can anyone confirm this behaviour?
Linus, should I prepare a patch for you?
Ciao,
Franz Sirl.
At 18:06 Uhr +0100 03.11.1996, Ion Badulescu wrote:
>Hi,
>
>On Sun, 3 Nov 1996, Linux support wrote:
>
>> I was not able to get my smc8432 (DEC 21041 Tulip) card working with
>> 2.0.24.
>>
>> After restoring tulip.c to the 2.0.23 version, it works fine again.
>>
>> I got the message "eth0: enabling BNC port" repeating after some seconds,
>> but the interface does never come up.
>
>I've got the same problem with a 21041-based card: stock 2.0.24 does not
>work at all and instead cycles the port type; 2.0.23 works just fine as
>does 2.0.24 with tulip.c from 2.0.23; finally, 2.1.7 (which includes
>_almost_ the same changes to tulip.c as 2.0.24) again works fine.
>
>Now, there is a catch here: the difference between tulip.c in 2.1.7 and
>2.0.24 is a constant. 2.1.7 has the correct value (as Linus pointed out in
>a previous message). This is the patch for 2.0.24 (apply it with -p1):
>
>--- linux/drivers/net/tulip.c.orig Sun Nov 3 12:02:47 1996
>+++ linux/drivers/net/tulip.c Fri Nov 1 06:58:44 1996
>@@ -1145,7 +1145,7 @@
> tp->tx_skbuff[entry] = 0;
> /* Put the setup frame on the Tx list. */
> tp->tx_ring[entry].length = 192 |
>- (entry == TX_RING_SIZE-1 ? 0x0a000000 : 0x08000);
>+ (entry == TX_RING_SIZE-1 ? 0x0a000000 :
>0x08000000);
> tp->tx_ring[entry].buffer1 = virt_to_bus((char
>*)tp->setup_frame);
> tp->tx_ring[entry].buffer2 = 0;
> tp->tx_ring[entry].status = TRING_OWN;
>
>
>Ionut
>
>--
>Ionut Badulescu - Columbia College '98 E-mail:ib42@columbia.edu
>Phone: (212)853-7875 Snail mail: 4A4 Wallach Hall
>Fax: (212)695-5560 1116 Amsterdam Ave
>PGP key available on request New York, NY 10027
> It is better to keep your mouth shut and be thought a fool,
> than to open it and remove all doubt.
-- -------------------------------------------------------------------------- phone ++49 8104 8943-0 mail Lauterbach Datentechnik GmbH fax ++49 8104 8943-49 c/o Franz Sirl email franz.sirl@lauterbach.com Fichtenstr. 27 web http://www.lauterbach.com D-85649 Hofolding ftp://ftp.lauterbach.com Germany --------------------------------------------------------------------------