The attached patch fixes the following problems with the DP83815 driver
(natsemi.c):
1. When compiled into the kernel, the cards would be registered multiple
times.
2. Autonegotiation code was buggy, causing the card to stop working after
autonegotiation.
--
- Steve Hill
System Administrator Email: [email protected]
Navaho Technologies Ltd. Tel: +44-870-7034015
... Alcohol and calculus don't mix - Don't drink and derive! ...
Steve Hill wrote:
>
> The attached patch fixes the following problems with the DP83815 driver
> (natsemi.c):
>
> 1. When compiled into the kernel, the cards would be registered multiple
> times.
I assume this code fragment fixes this:
+ static int done = 0;
+
+ if (done) return -ENODEV;
if (pci_drv_register(&natsemi_drv_id, dev) < 0)
return -ENODEV;
+ done = 1;
My 2 questions are:
Is this an acceptable fix for Donald? Because if so, I'd like to submit it
for the starfire quardboard driver.
--- starfire.c-old Tue Apr 17 18:11:07 2001
+++ starfire.c Tue Apr 17 18:12:37 2001
@@ -378,8 +378,12 @@
#ifndef MODULE
int starfire_probe(struct net_device *dev)
{
+ static int done = 0;
+
+ if (done) return -ENODEV;
if (pci_drv_register(&starfire_drv_id, dev) < 0)
return -ENODEV;
+ done = 1;
printk(KERN_INFO "%s" KERN_INFO "%s", version1, version2);
return 0;
}
Is there no implication with PCI latencies if multiple such cards
are loaded? I'm still having problems initializing more then 4
Quadboards.
Regards,
Roberto Nibali, ratz
--
mailto: `echo [email protected] | sed 's/[NOSPAM]//g'`
On Tue, 17 Apr 2001, RobertoNibali wrote:
> My 2 questions are:
> Is this an acceptable fix for Donald? Because if so, I'd like to submit it
> for the starfire quardboard driver.
I have no idea - I haven't been able to get in touch with him :(
(The fix was urgently required, and this did the job).
> Is there no implication with PCI latencies if multiple such cards
> are loaded? I'm still having problems initializing more then 4
> Quadboards.
Not sure - I've never tried initing more than 3 of the DP83815 cards in a
single machine. (I am using Cobalt Qube 3's, which have 2 DP83815's on
the motherboard, and a single PCI slot which I have installed a DP38315 in
for testing purposes).
--
- Steve Hill
System Administrator Email: [email protected]
Navaho Technologies Ltd. Tel: +44-870-7034015
... Alcohol and calculus don't mix - Don't drink and derive! ...
> I have no idea - I haven't been able to get in touch with him :(
> (The fix was urgently required, and this did the job).
I just realized I had this old patch for 2.2.17 and that in 2.2.19
series this problem is addressed correctly by Donald. Apologies to
him and sorry about the confusion. His or Ion's code from the starfire.c:
int __init starfire_probe(struct net_device *dev)
{
static int __initdata probed = 0;
if (probed)
return -ENODEV;
probed++;
return pci_module_init(&starfire_driver);
}
> Not sure - I've never tried initing more than 3 of the DP83815 cards in a
> single machine. (I am using Cobalt Qube 3's, which have 2 DP83815's on
> the motherboard, and a single PCI slot which I have installed a DP38315 in
> for testing purposes).
I think this is not the problem of the driver specifically but more of the
limitation of Space.c. I haven't yet found a clean way around it. I always
get "early initialization of device eth14 is deferred" messages.
Regards,
Roberto Nibali, ratz
--
mailto: `echo [email protected] | sed 's/[NOSPAM]//g'`
On Tue, 17 Apr 2001 17:30:46 +0100 (BST), Steve Hill <[email protected]> wrote:
> Not sure - I've never tried initing more than 3 of the DP83815 cards in a
> single machine. (I am using Cobalt Qube 3's, which have 2 DP83815's on
> the motherboard, and a single PCI slot which I have installed a DP38315 in
> for testing purposes).
Have you tried the starfire driver in 2.2.19 or 2.4.x-ac? Or, if you want to
use vanilla 2.4.x, you can simply copy drivers/net/starfire.c from the -ac
tree.
Ion
Starfire driver maintainer
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
On Wed, 18 Apr 2001, IonBadulescu wrote:
> use vanilla 2.4.x, you can simply copy drivers/net/starfire.c from the -ac
> tree.
I can't use 2.4 kernels ATM because they don't boot (at all) on Cobalt
hardware for some reason - when I've got chance I'll look into it and try
and fix the 2.4 kernels so they work on Cobalt kit, but ATM it's fairly
low on my todo list ...
Anyway, it wasn't me who wanted to use the starfire driver :)
--
- Steve Hill
System Administrator Email: [email protected]
Navaho Technologies Ltd. Tel: +44-870-7034015
... Alcohol and calculus don't mix - Don't drink and derive! ...
> > use vanilla 2.4.x, you can simply copy drivers/net/starfire.c from the -ac
> > tree.
>
> I can't use 2.4 kernels ATM because they don't boot (at all) on Cobalt
> hardware for some reason - when I've got chance I'll look into it and try
> and fix the 2.4 kernels so they work on Cobalt kit, but ATM it's fairly
> low on my todo list ...
ftp://ftp.cobaltnet.com/pub/users/thockin/2.4
On Wed, 18 Apr 2001, Steve Hill wrote:
> Anyway, it wasn't me who wanted to use the starfire driver :)
True, I plead guilty to the "replying at 3:30am" sin. :-) I meant to reply
to Roberto's mail, and accidentally replied to yours..
Anyway, Roberto, if you could give the starfire driver in 2.2.19 a try,
I'd appreciate it. You mentioned looking at the code, did you actually
test it?
Thanks,
Ion
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
On Wed, 18 Apr 2001, IonBadulescu wrote:
> True, I plead guilty to the "replying at 3:30am" sin. :-) I meant to reply
> to Roberto's mail, and accidentally replied to yours..
:)
I know the feeling... <still stuck at work at 9:40 pm>
--
- Steve Hill
System Administrator Email: [email protected]
Navaho Technologies Ltd. Tel: +44-870-7034015
... Alcohol and calculus don't mix - Don't drink and derive! ...
Hello,
> True, I plead guilty to the "replying at 3:30am" sin. :-) I meant to reply
> to Roberto's mail, and accidentally replied to yours..
That's what I thought ...
> Anyway, Roberto, if you could give the starfire driver in 2.2.19 a try,
> I'd appreciate it. You mentioned looking at the code, did you actually
> test it?
Today I started testing it and indeed, as the code shows, I works now. The
main problem was that if you compiled the driver into the kernel and only
had one Quadboard, it would get initialized twice. It worked but was nasty
to configure ;).
Now I started my tests with the new driver from plain vanilla 2.2.19 kernel
and it worked for my problem above. I've you're interested I could send you
some dmesg and proc-fs outputs. I'm working on a Intel L440GX+ SMP board
but with one processor, a stopper card and SMP disabled. Unfortunately a
guy back here destroyed the board by trying to hotplug the Quadboard and
touching the motherboard's voltage regulator. I have to get a new one to
continue my tests with 3 or 4 Quadboards. Will be back in a few hours with
the remaining results.
Best regards,
Roberto Nibali, ratz
--
mailto: `echo [email protected] | sed 's/[NOSPAM]//g'`
Hello,
> Anyway, Roberto, if you could give the starfire driver in 2.2.19 a try,
> I'd appreciate it. You mentioned looking at the code, did you actually
> test it?
Ok, I replaced the motherboard and did the remaining tests. Everything
looks fine up to 3 quadboards, 2 3c905C and one eepro100. The excerpt:
3c59x.c 18Feb01 Donald Becker and others
http://www.scyld.com/network/vortex.html
eth0: 3Com 3c905C Tornado at 0x3000, 00:01:03:1f:50:11, IRQ 11
8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface.
MII transceiver found at address 24, status 7809.
Enabling bus-master transmits and whole-frame receives.
eth1: 3Com 3c905C Tornado at 0x3080, 00:01:03:1f:50:14, IRQ 11
8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface.
MII transceiver found at address 24, status 7809.
Enabling bus-master transmits and whole-frame receives.
eepro100.c:v1.09j-t 9/29/99 Donald Becker
http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html
eepro100.c: $Revision: 1.20.2.10 $ 2000/05/31 Modified by Andrey V. Savochkin
<[email protected]> and others
eepro100.c: VA Linux custom, Dragan Stancevic <[email protected]> 2000/11/15
eth2: Intel PCI EtherExpress Pro100 82557, 00:D0:B7:A7:DD:78, IRQ 11.
Board assembly 000000-000, Physical connectors present: RJ45
Primary interface chip i82555 PHY #1.
General self-test: passed.
Serial sub-system self-test: passed.
Internal registers self-test: passed.
ROM checksum self-test: passed (0x04f4518b).
eepro100.c:v1.09j-t 9/29/99 Donald Becker
http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html
eepro100.c: $Revision: 1.20.2.10 $ 2000/05/31 Modified by Andrey V. Savochkin
<[email protected]> and others
eepro100.c: VA Linux custom, Dragan Stancevic <[email protected]> 2000/11/15
starfire.c:v1.03 7/26/2000 Written by Donald Becker <[email protected]>
Updates and info at http://www.scyld.com/network/starfire.html
(unofficial 2.2.x kernel port, version 1.2.8, March 7, 2001)
eth3: Adaptec Starfire 6915 at 0x90006000, 00:00:d1:ed:eb:e9, IRQ 10.
eth3: MII PHY found at address 1, status 0x7809 advertising 01e1.
eth4: Adaptec Starfire 6915 at 0x90087000, 00:00:d1:ed:eb:ea, IRQ 11.
eth4: MII PHY found at address 1, status 0x7809 advertising 01e1.
eth5: Adaptec Starfire 6915 at 0x90108000, 00:00:d1:ed:eb:eb, IRQ 11.
eth5: MII PHY found at address 1, status 0x7809 advertising 01e1.
eth6: Adaptec Starfire 6915 at 0x90189000, 00:00:d1:ed:eb:ec, IRQ 11.
eth6: MII PHY found at address 1, status 0x7809 advertising 01e1.
eth7: Adaptec Starfire 6915 at 0x9020a000, 00:00:d1:ed:e5:01, IRQ 5.
eth7: MII PHY found at address 1, status 0x7809 advertising 01e1.
early initialization of device eth8 is deferred
eth8: Adaptec Starfire 6915 at 0x9028b000, 00:00:d1:ed:e5:02, IRQ 11.
eth8: MII PHY found at address 1, status 0x7809 advertising 01e1.
early initialization of device eth9 is deferred
eth9: Adaptec Starfire 6915 at 0x9030c000, 00:00:d1:ed:e5:03, IRQ 11.
eth9: MII PHY found at address 1, status 0x7809 advertising 01e1.
early initialization of device eth10 is deferred
eth10: Adaptec Starfire 6915 at 0x9038d000, 00:00:d1:ed:e5:04, IRQ 11.
eth10: MII PHY found at address 1, status 0x7809 advertising 01e1.
early initialization of device eth11 is deferred
eth11: Adaptec Starfire 6915 at 0x9040e000, 00:00:d1:ed:e8:c5, IRQ 11.
eth11: MII PHY found at address 1, status 0x7809 advertising 01e1.
early initialization of device eth12 is deferred
eth12: Adaptec Starfire 6915 at 0x9048f000, 00:00:d1:ed:e8:c6, IRQ 11.
eth12: MII PHY found at address 1, status 0x7809 advertising 01e1.
early initialization of device eth13 is deferred
eth13: Adaptec Starfire 6915 at 0x90510000, 00:00:d1:ed:e8:c7, IRQ 11.
eth13: MII PHY found at address 1, status 0x7809 advertising 01e1.
early initialization of device eth14 is deferred
eth14: Adaptec Starfire 6915 at 0x90591000, 00:00:d1:ed:e8:c8, IRQ 11.
eth14: MII PHY found at address 1, status 0x7809 advertising 01e1.
A 2.2.x UP-APIC patch would maybe improve things here while under
heavy load. I'm using such boxes as packetfilters. All quadboards
get IRQ 11 which is rather nasty considering a possible throughput
of 40Mbit/s per NIC.
Would be nice if I could fix the "early initialization ..." problem
too. I'm still checking the Space.c code:
#define ETH_NOPROBE_ADDR 0xffe0
static struct device eth7_dev = {
"eth7", 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, NEXT_DEV,
ethif_probe };
static struct device eth6_dev = {
"eth6", 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, ð7_dev,
ethif_probe };
static struct device eth5_dev = {
"eth5", 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, ð6_dev,
ethif_probe };
static struct device eth4_dev = {
"eth4", 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, ð5_dev,
ethif_probe };
static struct device eth3_dev = {
"eth3", 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, ð4_dev,
ethif_probe };
static struct device eth2_dev = {
"eth2", 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, ð3_dev,
ethif_probe };
static struct device eth1_dev = {
"eth1", 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, ð2_dev,
ethif_probe };
static struct device eth0_dev = {
"eth0", 0, 0, 0, 0, ETH0_ADDR, ETH0_IRQ, 0, 0, 0, ð1_dev, ethif_probe };
# undef NEXT_DEV
# define NEXT_DEV (ð0_dev)
Would it make sense to extend this structure? Andrew Morgan made such a
suggestion
but why is that eth7 limitation? And why can't I use more then 16 ethernet
interfaces?
eth15: Adaptec Starfire 6915 at 0x90612000, 00:00:d1:ed:e8:c5, IRQ 7.
eth15: MII PHY found at address 1, status 0x7809 advertising 01e1.
early initialization of device is deferred
: Adaptec Starfire 6915 at 0x90693000, 00:00:d1:ed:e8:c6, IRQ 11.
: MII PHY found at address 1, status 0x7809 advertising 01e1.
early initialization of device is deferred
: Adaptec Starfire 6915 at 0x90714000, 00:00:d1:ed:e8:c7, IRQ 11.
: MII PHY found at address 1, status 0x7809 advertising 01e1.
early initialization of device is deferred
: Adaptec Starfire 6915 at 0x90795000, 00:00:d1:ed:e8:c8, IRQ 11.
: MII PHY found at address 1, status 0x7809 advertising 01e1.
Why isn't it possible to put the "probed" counter into the Space.c for all
network drivers? So people would not need to care about and the driver
code would yet be more generic (at least a little bit). I refer to the code:
int __init starfire_probe(struct net_device *dev)
{
static int __initdata probed = 0;
if (probed)
return -ENODEV;
probed++;
return pci_module_init(&starfire_driver);
}
Any pointers, sources are welcome and in hope for some further wisdom,
Roberto Nibali, ratz
--
mailto: `echo [email protected] | sed 's/[NOSPAM]//g'`
On Thu, 19 Apr 2001, Roberto Nibali wrote:
> A 2.2.x UP-APIC patch would maybe improve things here while under
> heavy load. I'm using such boxes as packetfilters. All quadboards
> get IRQ 11 which is rather nasty considering a possible throughput
> of 40Mbit/s per NIC.
The UP-APIC wouldn't help much since there really aren't other processors
available to share the load.
On the other hand, this is not as bad as it looks. In fact, it will
function rather well and with relatively little overhead if all configured
interfaces are seeing traffic on a regular basis. The IRQ dispatcher will
simply call all registered interrupt routines, and most of them will end
up doing something useful.
> Would be nice if I could fix the "early initialization ..." problem
> too. I'm still checking the Space.c code:
[snip]
Well.. Space.c is a dinozaur. However, this is the 2.2 series and no more
surgery will happen on this kernel, at least normally.
Have you tried loading the drivers as modules? You might have more luck
with that approach. Space.c was designed at a time when having 4 NIC's in
a PC was "pushing the limits"...
> Why isn't it possible to put the "probed" counter into the Space.c for all
> network drivers? So people would not need to care about and the driver
> code would yet be more generic (at least a little bit).
Because, again, this is legacy code. It works, it does the job, that's it.
All this crap is gone in 2.4.
> Any pointers, sources are welcome and in hope for some further wisdom,
Like I said, try the modules approach. If that doesn't work, I'll take a
closer look (and maybe borrow a few quads from work so I can actually test
the code...)
Ion
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
On Fri, 20 Apr 2001, Jeff Garzik wrote:
> > Have you tried loading the drivers as modules? You might have more luck
> > with that approach. Space.c was designed at a time when having 4 NIC's in
> > a PC was "pushing the limits"...
>
> 2.2.recent has module_init/exit, so you don't even need Space.c.
Check again. drivers/net builds a .a, not a .o. Trust me, I've tried.
Ion
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
Ion Badulescu wrote:
> Well.. Space.c is a dinozaur. However, this is the 2.2 series and no more
> surgery will happen on this kernel, at least normally.
>
> Have you tried loading the drivers as modules? You might have more luck
> with that approach. Space.c was designed at a time when having 4 NIC's in
> a PC was "pushing the limits"...
2.2.recent has module_init/exit, so you don't even need Space.c.
--
Jeff Garzik | "The universe is like a safe to which there is a
Building 1024 | combination -- but the combination is locked up
MandrakeSoft | in the safe." -- Peter DeVries
Ion Badulescu wrote:
>
> On Fri, 20 Apr 2001, Jeff Garzik wrote:
>
> > > Have you tried loading the drivers as modules? You might have more luck
> > > with that approach. Space.c was designed at a time when having 4 NIC's in
> > > a PC was "pushing the limits"...
> >
> > 2.2.recent has module_init/exit, so you don't even need Space.c.
>
> Check again. drivers/net builds a .a, not a .o. Trust me, I've tried.
Sure, but if you are patching anyway, it much better to fix that than
hack space.c :)
--
Jeff Garzik | "The universe is like a safe to which there is a
Building 1024 | combination -- but the combination is locked up
MandrakeSoft | in the safe." -- Peter DeVries
> The UP-APIC wouldn't help much since there really aren't other processors
> available to share the load.
Hmm, but doesn't the code in 2.4.x improve the hard IRQ signal delivery
even for UP systems with a local APIC table? I have an APIC aware board
but I have only got 1 CPU on it and I currently need to run 2.2 kernel.
But if you tell me that there is not much help, I'm ok with that, as
long as it wouldn't be better with APIC support :)
> On the other hand, this is not as bad as it looks. In fact, it will
> function rather well and with relatively little overhead if all configured
> interfaces are seeing traffic on a regular basis. The IRQ dispatcher will
> simply call all registered interrupt routines, and most of them will end
> up doing something useful.
Aha, thanks for the information. Indeed you're right because I'm running
boxes with such a configuration which have already 100+ days uptime under
heavy network load.
> Well.. Space.c is a dinozaur. However, this is the 2.2 series and no more
> surgery will happen on this kernel, at least normally.
So, what is your suggestion: Does this limitation do any harm or can I
live with that and still run 16 eth devices and safely disregard the
"early initialization ..." ?
> Have you tried loading the drivers as modules? You might have more luck
> with that approach. Space.c was designed at a time when having 4 NIC's in
> a PC was "pushing the limits"...
Yes, I've tried it but the problem is, that I've hundreds of nodes and about
a dozen of different node setups, some with 1 NIC, some with 1 NIC and 1 quad
board, up to some with 3 NICs and 3 quadboards. I've developed an own distro
which has one kernel. Since I can't make the correct modules get loaded without
mucking around with the /etc/modules.conf, I need to compile-in the drivers.
I'd be happy if the ethif_probe() could call the request_module() and load the
correct module and initialize the ethX. As of now I would need to adjust the
/etc/modules.conf according to the amount of quadboards I have put into my
node. Or did I miss the concept of /etc/modules.conf?
> Because, again, this is legacy code. It works, it does the job, that's it.
> All this crap is gone in 2.4.
I'll be porting my distribution to 2.4.x soon I think :)
> Like I said, try the modules approach. If that doesn't work, I'll take a
> closer look (and maybe borrow a few quads from work so I can actually test
> the code...)
Your driver works now and for me now need to mark it experimental. It also
works statically built into the kernel up to 4 quadboards. I hacked Space.c
and enhanced the ``static struct device ethX_dev = { };'' stuff.
Roberto Nibali, ratz
--
mailto: `echo [email protected] | sed 's/[NOSPAM]//g'`
On Fri, 20 Apr 2001, Roberto Nibali wrote:
> Hmm, but doesn't the code in 2.4.x improve the hard IRQ signal delivery
> even for UP systems with a local APIC table? I have an APIC aware board
> but I have only got 1 CPU on it and I currently need to run 2.2 kernel.
> But if you tell me that there is not much help, I'm ok with that, as
> long as it wouldn't be better with APIC support :)
I think the UP-APIC support was added primarily to support the NMI oopser
on UP systems. I might be wrong, though.
> > Well.. Space.c is a dinozaur. However, this is the 2.2 series and no more
> > surgery will happen on this kernel, at least normally.
>
> So, what is your suggestion: Does this limitation do any harm or can I
> live with that and still run 16 eth devices and safely disregard the
> "early initialization ..." ?
You can safely disregard the "early initialization deferred" messages.
They are essentially harmless.
As for the 16 eth ports limit, if you want to increase it, simply edit
drivers/net/net_init.c and change the value of MAX_ETH_CARDS. This limit
appears to also affect modules, so my earlier suggestion of using modules
wouldn't have helped.
> > Because, again, this is legacy code. It works, it does the job, that's it.
> > All this crap is gone in 2.4.
>
> I'll be porting my distribution to 2.4.x soon I think :)
If the only thing you need from your boxes is networking-related, than
it's probably ok. Otherwise I'd wait a bit longer before putting 2.4 on
production servers...
> Your driver works now and for me now need to mark it experimental.
Yeah, I guess I'll submit a patch to remove the experimental bit, after
the current code changes are accepted..
> It also works statically built into the kernel up to 4 quadboards. I
> hacked Space.c and enhanced the ``static struct device ethX_dev = { };''
> stuff.
You shouldn't need to do that, it's just wasted memory. The ethX_dev was
used mostly to avoid probing for ISA cards, which is completely irrelevant
when using PCI cards. As for the 4 quadboards limit, see above -- all you
need to change is MAX_ETH_CARDS.
Ion
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
On Fri, 20 Apr 2001, Jeff Garzik wrote:
> > Check again. drivers/net builds a .a, not a .o. Trust me, I've tried.
>
> Sure, but if you are patching anyway, it much better to fix that than
> hack space.c :)
Well, I remember asking Alan if he'd prefer it done that way, and not
getting a reply back. So I didn't press further.
The change to support __init/__exit in drivers/net is a no-brainer, and I
did test it at the time -- it worked as expected. But it's really up to
Alan to decide, I couldn't care less to be quite honest.
In a way I think I understand why he's reluctant: it's very easy to end up
changing the initialization order by mistake and messing up people's
network setups.
Ion
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
Ion Badulescu wrote:
> On Fri, 20 Apr 2001, Jeff Garzik wrote:
> > > Check again. drivers/net builds a .a, not a .o. Trust me, I've tried.
> > Sure, but if you are patching anyway, it much better to fix that than
> > hack space.c :)
>
> Well, I remember asking Alan if he'd prefer it done that way, and not
> getting a reply back. So I didn't press further.
>
> The change to support __init/__exit in drivers/net is a no-brainer, and I
> did test it at the time -- it worked as expected. But it's really up to
> Alan to decide, I couldn't care less to be quite honest.
>
> In a way I think I understand why he's reluctant: it's very easy to end up
> changing the initialization order by mistake and messing up people's
> network setups.
Sorry, I was talking about a local patch not a global patch. If a user
must patch their 2.2 kernel to get the starfire driver working anyway,
then adding a change to do s/.a/.o/ on Makefiles would be simple.
That said, a 2.2.20 patch to s/.a/.o/ should not break anything at all.
All old drivers work as before through the static call chain. All newer
drivers using module_init/exit simply wind up being initialized after
all static initialization has occurred. With some subsystems this does
create a chicken-and-egg situation, but not for drivers/net...
--
Jeff Garzik | "The universe is like a safe to which there is a
Building 1024 | combination -- but the combination is locked up
MandrakeSoft | in the safe." -- Peter DeVries
On Fri, 20 Apr 2001, Jeff Garzik wrote:
> Sorry, I was talking about a local patch not a global patch. If a user
> must patch their 2.2 kernel to get the starfire driver working anyway,
> then adding a change to do s/.a/.o/ on Makefiles would be simple.
People don't need to patch *anything* to get the starfire driver working --
it's included in 2.2.19 and working rather well I might add. :-)
This was a special case, which btw had nothing to do with the starfire
driver itself. The user needed to support more than 8 eth ports, which
2.2 complains about, and more than 16 eth ports, which 2.2 simply doesn't
allow without further changes.
Ion
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
Hi Ion,
> I think the UP-APIC support was added primarily to support the NMI oopser
> on UP systems. I might be wrong, though.
You're right, at least from the perspective of this patch:
http://www.csd.uu.se/~mikpe/linux/upapic/upapic-2.4.1
> You can safely disregard the "early initialization deferred" messages.
> They are essentially harmless.
Thanks for the info. I can sleep now :)
> As for the 16 eth ports limit, if you want to increase it, simply edit
> drivers/net/net_init.c and change the value of MAX_ETH_CARDS. This limit
> appears to also affect modules, so my earlier suggestion of using modules
> wouldn't have helped.
Thanks a lot. And sorry I don't know the kernel sources and documentations
good enough yet.
> If the only thing you need from your boxes is networking-related, than
> it's probably ok. Otherwise I'd wait a bit longer before putting 2.4 on
> production servers...
It is only network related (packetfiltering and load balancing with QoS)
and I like the improved mm. I've been testing 2.4 since its early days
and f.e. on the Intel L440GX+ boards it runs like hell, also with SMP.
Only the CPU numbering is incorrect if the kernel is SMP and you only
put in one processor. But I read somewhere that also this feature is
normal since it seems to be impossible to give the CPUs the correct
numbers because there is no defined order of initialization.
> Yeah, I guess I'll submit a patch to remove the experimental bit, after
> the current code changes are accepted..
Good. Yes, I saw the patches. I might try it out back here with a 2.4.x
kernel and 4 quadboards.
> You shouldn't need to do that, it's just wasted memory. The ethX_dev was
> used mostly to avoid probing for ISA cards, which is completely irrelevant
> when using PCI cards. As for the 4 quadboards limit, see above -- all you
> need to change is MAX_ETH_CARDS.
Will certainly do that. And thank you again for this information.
Best regards,
Roberto Nibali, ratz
--
mailto: `echo [email protected] | sed 's/[NOSPAM]//g'`
> This was a special case, which btw had nothing to do with the starfire
> driver itself. The user needed to support more than 8 eth ports, which
> 2.2 complains about, and more than 16 eth ports, which 2.2 simply doesn't
> allow without further changes.
I made the changes and I was able to load 4 quadboards, 2 3com cards and
1 eepro100 (onboard) and I did some tests and it works fine. However the
starfire driver seems not to initialize more then 4 quadboards. I put in
5 and he doesn't initialize it and the others don't work although they
get initialized. Is there a trivial way to get more then 4 NIC's of the
same manufacturer running in one box. I also start believing that this
is a motherboard problem since when I put in more the 4 3Com cards, the
boot freezes after the SCSI BIOS init and before the lilo. Does anybody
have the same problem?
Roberto Nibali, ratz
--
mailto: `echo [email protected] | sed 's/[NOSPAM]//g'`
Roberto Nibali wrote:
>
> > This was a special case, which btw had nothing to do with the starfire
> > driver itself. The user needed to support more than 8 eth ports, which
> > 2.2 complains about, and more than 16 eth ports, which 2.2 simply doesn't
> > allow without further changes.
>
> I made the changes and I was able to load 4 quadboards, 2 3com cards and
> 1 eepro100 (onboard) and I did some tests and it works fine. However the
> starfire driver seems not to initialize more then 4 quadboards. I put in
> 5 and he doesn't initialize it and the others don't work although they
> get initialized.
If all five show up in 'lspci', then starfire driver should be able to
register all five. [if it doesn't, it is probably a starfire bug]
If only four show up in lspci, that sounds more like a PCI core problem
--
Jeff Garzik | The difference between America and England is that
Building 1024 | the English think 100 miles is a long distance and
MandrakeSoft | the Americans think 100 years is a long time.
| (random fortune)
Jeff Garzik wrote:
>
> Roberto Nibali wrote:
> >
> > > This was a special case, which btw had nothing to do with the starfire
> > > driver itself. The user needed to support more than 8 eth ports, which
> > > 2.2 complains about, and more than 16 eth ports, which 2.2 simply doesn't
> > > allow without further changes.
> >
> > I made the changes and I was able to load 4 quadboards, 2 3com cards and
> > 1 eepro100 (onboard) and I did some tests and it works fine. However the
> > starfire driver seems not to initialize more then 4 quadboards. I put in
> > 5 and he doesn't initialize it and the others don't work although they
> > get initialized.
>
> If all five show up in 'lspci', then starfire driver should be able to
> register all five. [if it doesn't, it is probably a starfire bug]
No, it's not a bug but thank you for this tip. It's just a put-on limitation
in the driver itself:
--- starfire.c~ Fri Apr 20 18:48:05 2001
+++ starfire.c Fri Apr 20 18:27:20 2001
@@ -308,7 +308,7 @@
void (*resume)(struct pci_dev *dev); /* Device woken up */
};
-#define PCI_MAX_MAPPINGS 16
+#define PCI_MAX_MAPPINGS 32
static struct pci_driver_mapping drvmap [PCI_MAX_MAPPINGS] = { { NULL, } , };
#define __devinit __init
This cures my problem. I've checked this and it seems as if Ion copied
this from the sound/emu10k1/emu_wrapper.c code, where I understand that
nobody will have more then 16 times the same soundcard. Ion, do I break
something with this? If not, could you please adjust your driver?
Thanks to all of you for your help. I learned a lot today.
Roberto Nibali, ratz
--
mailto: `echo [email protected] | sed 's/[NOSPAM]//g'`
On Fri, 20 Apr 2001, Roberto Nibali wrote:
> No, it's not a bug but thank you for this tip. It's just a put-on limitation
> in the driver itself:
>
> --- starfire.c~ Fri Apr 20 18:48:05 2001
> +++ starfire.c Fri Apr 20 18:27:20 2001
> @@ -308,7 +308,7 @@
> void (*resume)(struct pci_dev *dev); /* Device woken up */
> };
>
> -#define PCI_MAX_MAPPINGS 16
> +#define PCI_MAX_MAPPINGS 32
Ehh.. yes, I forgot about this. It's a limitation in the 2.2 compatibility
code, 2.4 is not affected.
> This cures my problem. I've checked this and it seems as if Ion copied
> this from the sound/emu10k1/emu_wrapper.c code, where I understand that
> nobody will have more then 16 times the same soundcard. Ion, do I break
> something with this? If not, could you please adjust your driver?
Well, normally nobody will have more than 16 eth ports, either, because
net_init.c won't let them. So I'm not sure this is something *I* should fix.
I guess I'll send a patch to Alan that changes both the driver and
net_init.c, once 2.2.20pre is started. If he takes it, great, otherwise
you'll have to continue making this change for yourself.
> Thanks to all of you for your help. I learned a lot today.
You're welcome. :-)
Ion
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.