From: Roberto Nibali <ratz@tac.ch>
To: Ion Badulescu <ionut@cs.columbia.edu>
Cc: linux-kernel@vger.kernel.org, Andrew Morton <andrewm@uow.edu.au>
Subject: Re: Fix for Donald Becker's DP83815 network driver (v1.07)
Date: Fri, 20 Apr 2001 11:03:18 +0200 [thread overview]
Message-ID: <3ADFFB56.A9C84A2@tac.ch> (raw)
In-Reply-To: <Pine.LNX.4.33.0104192241060.4771-100000@age.cs.columbia.edu>
> 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 NrOatSz@tPacA.cMh | sed 's/[NOSPAM]//g'`
next prev parent reply other threads:[~2001-04-20 9:06 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-04-17 15:58 Fix for Donald Becker's DP83815 network driver (v1.07) Steve Hill
2001-04-17 16:16 ` Roberto Nibali
2001-04-17 16:30 ` Steve Hill
2001-04-17 17:12 ` Roberto Nibali
2001-04-18 10:25 ` Ion Badulescu
2001-04-18 11:32 ` Steve Hill
2001-04-18 15:14 ` Tim Hockin
2001-04-18 20:33 ` Ion Badulescu
2001-04-18 20:40 ` Steve Hill
2001-04-19 10:54 ` Roberto Nibali
2001-04-19 13:06 ` Roberto Nibali
2001-04-20 5:48 ` Ion Badulescu
2001-04-20 6:30 ` Jeff Garzik
2001-04-20 7:09 ` Ion Badulescu
2001-04-20 7:31 ` Jeff Garzik
2001-04-20 9:49 ` Ion Badulescu
2001-04-20 9:57 ` Jeff Garzik
2001-04-20 10:05 ` Ion Badulescu
2001-04-20 16:10 ` Roberto Nibali
2001-04-20 16:19 ` Jeff Garzik
2001-04-20 16:50 ` Roberto Nibali
2001-04-20 19:27 ` Ion Badulescu
2001-04-20 9:03 ` Roberto Nibali [this message]
2001-04-20 9:42 ` Ion Badulescu
2001-04-20 10:12 ` Roberto Nibali
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3ADFFB56.A9C84A2@tac.ch \
--to=ratz@tac.ch \
--cc=andrewm@uow.edu.au \
--cc=ionut@cs.columbia.edu \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox