Hi, i was trying to use the debian etch installer on an Sun Netra X1 and discovered that the netinstall would not work. Cause of this was the dmfe driver claiming an tulip based network and failing to read the mac address and most likely not beeing able to drive the card. I tried an 2.6.18 and 2.6.22 based installer.
Cause of this problem is an identical PCI ID for 2 different cards.
Whatsoever it seems the DMFE does do much to identify a potential
wrong card and just ignore it and leave of for the tulip driver.
A quick hack i thought of was to let the DMFE driver ignore cards
which read an all 0 mac address. As the DMFE fails to read the
SROM for the tulip based card this would be a quick hack. I guess there
are more elegant ways to differentiate the 2 cards and let the right
driver take control but this would be something somebody more intimate with
dmfe and tulip based cards needs to do ...
This was my idea although i know that sometimes producers fail to
program a correct mac address and this would prevent those cards from
beeing usable.
Other ideas ?
Flo
diff --git a/drivers/net/tulip/dmfe.c b/drivers/net/tulip/dmfe.c
index b4891ca..c023ec0 100644
--- a/drivers/net/tulip/dmfe.c
+++ b/drivers/net/tulip/dmfe.c
@@ -362,6 +362,7 @@ static int __devinit dmfe_init_one (struct pci_dev *pdev,
struct net_device *dev;
u32 pci_pmr;
int i, err;
+ u8 macor=0;
DECLARE_MAC_BUF(mac);
DMFE_DBUG(0, "dmfe_init_one()", 0);
@@ -464,8 +465,15 @@ static int __devinit dmfe_init_one (struct pci_dev *pdev,
cpu_to_le16(read_srom_word(db->ioaddr, i));
/* Set Node address */
- for (i = 0; i < 6; i++)
+ for (i = 0; i < 6; i++) {
dev->dev_addr[i] = db->srom[20 + i];
+ macor |= db->srom[20 + i];
+ }
+
+ if (!macor) {
+ err = -ENODEV;
+ goto err_out_res;
+ }
err = register_netdev (dev);
if (err)
Flo
--
Florian Lohoff [EMAIL PROTECTED] +49-171-2280134
Those who would give up a little freedom to get a little
security shall soon have neither - Benjamin Franklin
signature.asc
Description: Digital signature
