Re: Fix for Donald Becker's DP83815 network driver (v1.07)
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.cFri 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
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'` - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
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) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
> 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'` - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
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'` - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
> 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'` - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
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'` - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
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'` - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
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'` - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
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) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
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'` - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
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.cFri 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
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 00-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 0x9051, 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, _dev, ethif_probe }; static struct device eth5_dev = { "eth5", 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, _dev, ethif_probe }; static struct device eth4_dev = { "eth4", 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, _dev, ethif_probe }; static struct device eth3_dev = { "eth3", 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, _dev, ethif_probe }; static struct device eth2_dev = { "eth2", 0,0,0,0,ETH_NOPROBE_ADDR /* I/O
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
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'` - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
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'` - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
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 00-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 0x9051, 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, eth7_dev, ethif_probe }; static struct device eth5_dev = { "eth5", 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, eth6_dev, ethif_probe }; static struct device eth4_dev = { "eth4", 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, eth5_dev, ethif_probe }; static struct device eth3_dev = { "eth3", 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, eth4_dev, ethif_probe }; static struct device eth2_dev = { "eth2", 0,0,0,0,ETH_NOPROBE_ADDR /* I/O
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
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... -- - 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! ... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
> > 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
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! ... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
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! ... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
> 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(_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'` - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
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! ... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
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(_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(_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'` - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
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'` - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
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! ... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
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'` - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/