Last Saturday or so I mentioned an Oops in __find_symbol in 2.5.59
and two people sent me Kai's patch. Thanks!
This evening the next attempt. Under 2.5.58 my ethernet cards
still work, under 2.5.59 eth0, a 3c509, fails.
(1) Started to read the source and come across
3c509.c:
----------
/* Huh ? Can someone explain what is this for ? */
if (dev->mem_end == 0x3c509 /* Magic key */ && ...
----------
An answer to that question is:
See Documentation/networking/3c509.txt
(under "Special Driver Features").
(2) Reading el3_probe() one sees
3c509.c:
----------
static int __init el3_probe(int card_idx) {
struct net_device *dev;
#ifdef CONFIG_MCA
if( MCA_bus ) {
for() {
if(dev && ((dev->irq >= 1 && ...
}
}
#endif
----------
Funny. Since dev has a random value we must conclude that
this code is broken. Also, MCA_NOTFOUND is undefined.
Things improve with
#include <linux/mca-legacy.h>
at the start, and an assignment to dev (or this code involving
dev ripped out). Something like
--- .../linux-2.5.59/linux/drivers/net/3c509.c Sat Jan 18 23:54:39 2003
+++ ./3c509.c Tue Jan 21 20:37:10 2003
@@ -88,6 +88,7 @@
#include <linux/ethtool.h>
#include <linux/device.h>
#include <linux/eisa.h>
+#include <linux/mca-legacy.h>
#include <asm/uaccess.h>
#include <asm/bitops.h>
@@ -398,14 +399,14 @@
ioaddr = ((short)((pos4&0xfc)|0x02)) << 8;
irq = pos5 & 0x0f;
-
+#if 0
/* probing for a card at a particular IO/IRQ */
if(dev && ((dev->irq >= 1 && dev->irq != irq) ||
(dev->base_addr >= 1 && dev->base_addr != ioaddr))) {
slot++; /* probing next slot */
continue;
}
-
+#endif
printk("3c509: found %s at slot %d\n",
el3_mca_adapters[j].name, slot + 1 );
(3) In cases such as these, where ethernet cards get different names
than they had under the previous kernel, it is neccessary to find
out which name belongs to which card. An easy approach is
dmesg | grep eth
For me this yields eth0, eth2 and eth3 but not eth1, a 3c900 Boomerang.
Indeed, the boot message only says about this animal:
<6>PCI: Found IRQ 11 for device 00:0d.0
<6>PCI: Sharing IRQ 11 with 00:07.2
<6>PCI: Sharing IRQ 11 with 00:09.0
<6>PCI: Sharing IRQ 11 with 00:09.1
<4>3c59x: Donald Becker and others. http://www.scyld.com/network/vortex.html
<6>00:0d.0: 3Com PCI 3c900 Boomerang 10Mbps Combo at 0xb400. Vers LK1.1.18
<4> ***WARNING*** No MII transceivers found!
but no MAC address, and no ethN number is given.
I consider this a bug (and submitted a patch a year ago or so).
Should I resubmit the patch?
Andries
Please Don't do this:
#include <linux/ethtool.h>
#include <linux/device.h>
#include <linux/eisa.h>
+#include <linux/mca-legacy.h>
#include <asm/uaccess.h>
If you're getting MCA_NOTFOUND undefined, it's because CONFIG_MCA_LEGACY isn't
set when mca.h is included (either because it's not in your kernel config, or
possibly because config.h isn't included into the right place in the
driver---the latter doesn't look to be the problem for 3c509.c).
James
Please Don't do this:
+#include <linux/mca-legacy.h>
If you're getting MCA_NOTFOUND undefined, it's because
CONFIG_MCA_LEGACY isn't set when mca.h is included
(either because it's not in your kernel config, or
possibly because config.h isn't included into the right place
in the driver---the latter doesn't look to be the problem
for 3c509.c).
Yes, you are right. But.
(I do not have an MCA machine myself, this was just from
source inspection. Let me grep a bit more.)
Suppose CONFIG_MCA_LEGACY is not set, and CONFIG_MCA is set.
Then, as you say, <linux/mca-legacy.h> is not included.
Thus, the only definition of MCA_NOTFOUND is not seen.
Thus, all files that use it (eexpress.c, smctr.c, madgemc.c,
3c509.c, at1700.c, 3c523.c, depca.c, 3c527.c, sk_mca.c,
eicon_mod.c, ibmmca.c, mca_53c9x.c, fd_mcs.c, aha1542.c,
sim710.c, ps2esdi.c, sb_card.c) will not compile, if I am
not mistaken.
If you want to preserve the distinction between CONFIG_MCA and
CONFIG_MCA_LEGACY, then I suppose you want to replace the former
by the latter in all of the drivers mentioned?
Andries
>>>>> "Andries" == Andries Brouwer <[email protected]> writes:
Andries> This evening the next attempt. Under 2.5.58 my ethernet cards
Andries> still work, under 2.5.59 eth0, a 3c509, fails.
I'm the guilty one for (1) and (2). These problems are coming from the
3c509 removal from Space.c.
I'll cook a patch latter today...
Thanks for the report.
M.
--
Places change, faces change. Life is so very strange.
From: Marc Zyngier <[email protected]>
Andries> This evening the next attempt. Under 2.5.58 my ethernet cards
Andries> still work, under 2.5.59 eth0, a 3c509, fails.
I'm the guilty one for (1) and (2). These problems are coming from the
3c509 removal from Space.c.
I'll cook a patch latter today...
I forgot to mention the conclusion of (3): inserting code
in the Boomerang driver to print ethN and MAC address
made immediately clear what happened: eth0 and eth1 had
been interchanged.
Andries
>>>>> "Andries" == Andries Brouwer <[email protected]> writes:
Andries> I forgot to mention the conclusion of (3): inserting code
Andries> in the Boomerang driver to print ethN and MAC address
Andries> made immediately clear what happened: eth0 and eth1 had
Andries> been interchanged.
That's also an effect of the Space.c removal...
This is a lot more tricky to solve, apart from using modules.
M.
--
Places change, faces change. Life is so very strange.
[email protected] said:
> Yes, you are right. But. (I do not have an MCA machine myself, this
> was just from source inspection. Let me grep a bit more.)
> Suppose CONFIG_MCA_LEGACY is not set, and CONFIG_MCA is set. Then, as
> you say, <linux/mca-legacy.h> is not included.
Yes, and unfortunately it does this by default. The idea of CONFIG_MCA_LEGACY
was to have legacy drivers unable to compile like this. However, it seems
that most people who will be trying this don't get the CONFIG_MCA_LEGACY set.
When the option was added, I couldn't come up with a useful scheme to make the
legacy (which is almost all MCA drivers) require CONFIG_MCA_LEGACY (there's a
kernel bug about this too).
However, looking through the source, the 3c509 driver is broken anyway for MCA
(done by the eisa sysfs patches), so I think I can probably just add the extra
pieces to convert it to the new sysfs MCA API.
James
On Wed, Jan 22, 2003 at 11:44:50AM -0500, James Bottomley wrote:
> However, looking through the source, the 3c509 driver is broken anyway for MCA
> (done by the eisa sysfs patches), so I think I can probably just add the extra
> pieces to convert it to the new sysfs MCA API.
Excellent... that's what I was hoping would happen :)