From: tim@fungible.com > My NE2000 compatible card is configured at port 0x220 by default. > It's an SMC somethingorother. Port 0x220 wasn't included in the list > of I/O addresses to probe at boot time in the 2.4.10 and 2.4.11 > kernels, so it only found the nework card after I did the following > patch. From: "Jamie Harris" <jamie@jharris.homeip.net> >I've never seen an NE2000 compatible SMC card. You sure you are >using the right module? All my SMC cards have always been driven by >the smcultra module I found out the driver disk and opened my computer case to see what it is. It's an SMC 1660T. I just now tried both the ne and smc-ultra drivers, and ne works and smc-ultra doesn't. I vaguely remember that some Linux networking FAQ lead me to expect this at some point, but I can't find the reference now. The card comes in Plug-and-play mode. I initially left it in that mode. When Linux booted, the IO port was 0x220. In this morning's experiment, I used the DOS-based driver diskette to put the card into jumperless mode, then I configured the IO port to be 0x300. Apparently jumperless mode means it acts like a card with jumpers, except you change the jumpers with their software. I compiled a Linux kernel without my patch that includes 0x220 in the port list, and it found the card. Conclusion: if the goal is to support as many cards out-of-the-box as possible, then adding 0x220 to the port list for the ne.c driver would move towards the goal as long as probing that port doesn't break something else. If it's acceptable to require the user to boot DOS to configure the card, then it's safer to keep the current code and expect people to configure the card use some port on the list, except the list of ports is only available if you read the source. Hmm. Maybe the story is that they should load the module and specify the port number to the module; that saves them from reading the list of ports in the source code. -- Tim Freeman tim@fungible.com; formerly tim@infoscreen.com - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
