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
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
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
> 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
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
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
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
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
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
> 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
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
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
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
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
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.
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
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
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
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.
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
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
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
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
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
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
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
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
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.
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
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,
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
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
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
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
> > 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,
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
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
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
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
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
> 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
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
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
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
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
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
46 matches
Mail list logo
