On 11/20/20 6:56 PM, Jakub Kicinski wrote:
On Fri, 20 Nov 2020 18:41:03 -0500 Ion Badulescu wrote:
Frankly, no, I don't know of any users, and that unfortunately includes
myself. I still have two cards in my stash, but they're 64-bit PCI-X, so
plugging them in would likely require taking
On 11/20/20 6:17 PM, Jakub Kicinski wrote:
On Fri, 20 Nov 2020 15:50:00 +0800 xiakaixu1...@gmail.com wrote:
From: Kaixu Xia
The body of the if statement can be executed only when the variable
vlan_count equals to 32, so the condition of the while statement can
not be true and the while
On 03/17/2016 10:28 PM, Mike Galbraith wrote:
On Wed, 2016-03-16 at 12:15 -0400, Ion Badulescu wrote:
Just following up to my own email:
It turns out that we can eliminate the RCU stalls by changing from
CONFIG_RCU_NOCB_CPU_ALL to CONFIG_RCU_NOCB_CPU_NONE. Letting each cpu
handle its own RCU
On 03/17/2016 10:28 PM, Mike Galbraith wrote:
On Wed, 2016-03-16 at 12:15 -0400, Ion Badulescu wrote:
Just following up to my own email:
It turns out that we can eliminate the RCU stalls by changing from
CONFIG_RCU_NOCB_CPU_ALL to CONFIG_RCU_NOCB_CPU_NONE. Letting each cpu
handle its own RCU
on RCU grace periods
isn't very interesting, given that its rcuo* threads could be running
anywhere, on any cpu.
Thanks,
-Ion
On 02/04/2016 02:12 PM, Ion Badulescu wrote:
Hello,
We run a compute cluster of about 800 or so machines here, which makes
heavy use of NFS and fscache (on a dedicated
on RCU grace periods
isn't very interesting, given that its rcuo* threads could be running
anywhere, on any cpu.
Thanks,
-Ion
On 02/04/2016 02:12 PM, Ion Badulescu wrote:
Hello,
We run a compute cluster of about 800 or so machines here, which makes
heavy use of NFS and fscache (on a dedicated
Hello,
We run a compute cluster of about 800 or so machines here, which makes
heavy use of NFS and fscache (on a dedicated local drive with an ext4
filesystem) and also exercises the other local drives pretty hard. All
the compute jobs run as unprivileged users with SCHED_OTHER scheduling,
nice
Hello,
We run a compute cluster of about 800 or so machines here, which makes
heavy use of NFS and fscache (on a dedicated local drive with an ext4
filesystem) and also exercises the other local drives pretty hard. All
the compute jobs run as unprivileged users with SCHED_OTHER scheduling,
nice
Hi Alexey,
On Sat, 3 Sep 2005, Alexey Kuznetsov wrote:
Well, take a look at the double acks for 84439343, 84440447 and 84441059,
they seem pretty much identical to me.
It is just a little tcpdump glitch.
19:34:54.532271 < 10.2.20.246.33060 > 65.171.224.182.8700: . 44:44(0) ack 84439343
win
Hi Alexey,
On Fri, 2 Sep 2005, Alexey Kuznetsov wrote:
This is where things start going bad. The window starts shrinking from
15340 all the way down to 2355 over the course of 0.3 seconds. Notice the
many duplicate acks that serve no purpose
These are not duplicate, TCP_NODELAY sender just
On Fri, 2 Sep 2005, John Heffner wrote:
If it is window clamping, then you should be asymptotically approaching a
ratio between receive buffer and window that corresponds (with a fudge
factor) to the ratio between TCP segment data size and allocated packet size.
If you make the receive buffer
On Fri, 2 Sep 2005, Guillaume Autran wrote:
I experienced the very same problem but with window size going all the way
down to just a few bytes (14 bytes). dump files available upon requests :)
Ion, how were you able to reproduce the issue ? Can the same type of traffice
always reproduce the
On Fri, 2 Sep 2005, Noritoshi Demizu wrote:
By the way, if tcpdump does not track the window scale option, the right
edge (ack + real win) does not change between the following two ACKs.
11:34:54.337167 10.2.20.246.33060 > 10.2.224.182.8700: . ack 84402527 win 15340
(DF)
(259 ACKs are
On Fri, 2 Sep 2005, Noritoshi Demizu wrote:
By the way, if tcpdump does not track the window scale option, the right
edge (ack + real win) does not change between the following two ACKs.
11:34:54.337167 10.2.20.246.33060 10.2.224.182.8700: . ack 84402527 win 15340
nop,nop,timestamp
On Fri, 2 Sep 2005, Guillaume Autran wrote:
I experienced the very same problem but with window size going all the way
down to just a few bytes (14 bytes). dump files available upon requests :)
Ion, how were you able to reproduce the issue ? Can the same type of traffice
always reproduce the
Hi Alexey,
On Sat, 3 Sep 2005, Alexey Kuznetsov wrote:
Well, take a look at the double acks for 84439343, 84440447 and 84441059,
they seem pretty much identical to me.
It is just a little tcpdump glitch.
19:34:54.532271 10.2.20.246.33060 65.171.224.182.8700: . 44:44(0) ack 84439343
win
On Fri, 2 Sep 2005, John Heffner wrote:
If it is window clamping, then you should be asymptotically approaching a
ratio between receive buffer and window that corresponds (with a fudge
factor) to the ratio between TCP segment data size and allocated packet size.
If you make the receive buffer
Hi Alexey,
On Fri, 2 Sep 2005, Alexey Kuznetsov wrote:
This is where things start going bad. The window starts shrinking from
15340 all the way down to 2355 over the course of 0.3 seconds. Notice the
many duplicate acks that serve no purpose
These are not duplicate, TCP_NODELAY sender just
Hi David,
On Thu, 1 Sep 2005, David S. Miller wrote:
Thanks for the empty posting. Please provide the content you
intended to post, and furthermore please post it to the network
developer mailing list, netdev@vger.kernel.org
First of all, thanks for the reply (even to an empty posting :).
Hi David,
On Thu, 1 Sep 2005, David S. Miller wrote:
Thanks for the empty posting. Please provide the content you
intended to post, and furthermore please post it to the network
developer mailing list, netdev@vger.kernel.org
First of all, thanks for the reply (even to an empty posting :).
it and remove all doubt.
-
--- linux-2.4/drivers/net/starfire.c.orig Thu Jul 12 10:15:18 2001
+++ linux-2.4/drivers/net/starfire.cThu Jul 12 10:17:30 2001
@@ -87,8 +87,7 @@
LK1.3.3 (Ion Badulescu)
- Initialize the TxMode register properly
it and remove all doubt.
-
--- linux-2.4/drivers/net/starfire.c.orig Thu Jul 12 10:15:18 2001
+++ linux-2.4/drivers/net/starfire.cThu Jul 12 10:17:30 2001
@@ -87,8 +87,7 @@
LK1.3.3 (Ion Badulescu)
- Initialize the TxMode register properly
On Fri, 20 Jul 2001 03:03:58 +0100 (BST), Anton Altaparmakov <[EMAIL PROTECTED]>
wrote:
> I will repost as soon as I manage to convince pine of it's wrong ways...
You can't, so don't bother. Just inline it, ctrl-r should do the trick. However
be careful, newer pine's like to strip trailing
On Fri, 20 Jul 2001 03:03:58 +0100 (BST), Anton Altaparmakov [EMAIL PROTECTED]
wrote:
I will repost as soon as I manage to convince pine of it's wrong ways...
You can't, so don't bother. Just inline it, ctrl-r should do the trick. However
be careful, newer pine's like to strip trailing spaces
On Fri, 8 Jun 2001, Tom Sightler wrote:
> OK, I tried your patch, it did fix the problem where pump wouldn't
> pull an IP address, but I'm still having the problem where my ping
> times go nuts. I've attached an example, it's 100% repeatable on my
> network at work. It was so bad I couldn't
On Fri, 8 Jun 2001, Tom Sightler wrote:
OK, I tried your patch, it did fix the problem where pump wouldn't
pull an IP address, but I'm still having the problem where my ping
times go nuts. I've attached an example, it's 100% repeatable on my
network at work. It was so bad I couldn't get
On Thu, 7 Jun 2001, Tom Sightler wrote:
> Transferring files between the eepro100 machine running 2.4.2-ac11 and my
> laptop produced a result of 2.24MB/s for sending and 2.13MB/s recieving the
> file.
>
> Transfering files between the Alteon Gigabit machine running 2.2.19 and my
> laptop
On Wed, 6 Jun 2001, Tom Sightler wrote:
> At home where I have a 10Mb half-duplex hub connection all of the drivers work
> properly.
All right, that's expected.
> At work where I have a 10/100Mb full-duplex switch connection the drivers work
> exactly as I described before:
>
> 2.4.4-ac11 --
On Wed, 6 Jun 2001, Tom Sightler wrote:
At home where I have a 10Mb half-duplex hub connection all of the drivers work
properly.
All right, that's expected.
At work where I have a 10/100Mb full-duplex switch connection the drivers work
exactly as I described before:
2.4.4-ac11 -- mostly
On Thu, 7 Jun 2001, Tom Sightler wrote:
Transferring files between the eepro100 machine running 2.4.2-ac11 and my
laptop produced a result of 2.24MB/s for sending and 2.13MB/s recieving the
file.
Transfering files between the Alteon Gigabit machine running 2.2.19 and my
laptop resulted
On Wed, 6 Jun 2001 13:20:41 -0400, Tom Sightler <[EMAIL PROTECTED]> wrote:
>> 2.4.5-ac9
>
>> o Fix xircom_cb problems with some cisco kit (Ion Badulescu)
>
> I'm not sure what this is supposed to fix, but it makes my Xircom
> RBEM56G-100 almost useless on my netwo
On Wed, 6 Jun 2001, Keith Owens wrote:
> Nicely spotted. The X3201-3 Software Specification says nothing about
> the segment bits for the filter, instead the information is tucked away
> in the 21143 PCI/CardBus 10/100Mb/s Ethernet LAN Controller Hardware
> Reference Manual. So Xircom have a
On Wed, 6 Jun 2001 13:20:41 -0400, Tom Sightler [EMAIL PROTECTED] wrote:
2.4.5-ac9
o Fix xircom_cb problems with some cisco kit (Ion Badulescu)
I'm not sure what this is supposed to fix, but it makes my Xircom
RBEM56G-100 almost useless on my network at the office. Actually, I can't
On Wed, 6 Jun 2001, Keith Owens wrote:
Nicely spotted. The X3201-3 Software Specification says nothing about
the segment bits for the filter, instead the information is tucked away
in the 21143 PCI/CardBus 10/100Mb/s Ethernet LAN Controller Hardware
Reference Manual. So Xircom have a
+2,10 @@
/*
Written 1998-2000 by Donald Becker.
+ Current maintainer is Ion Badulescu <[EMAIL PROTECTED]>. Please
+ send all bug reports to me, and not to Donald Becker, as this code
+ has been modified quite a bit from Donald's original version.
+
This so
+2,10 @@
/*
Written 1998-2000 by Donald Becker.
+ Current maintainer is Ion Badulescu [EMAIL PROTECTED]. Please
+ send all bug reports to me, and not to Donald Becker, as this code
+ has been modified quite a bit from Donald's original version.
+
This software may
On Tue, 29 May 2001 15:50:22 +0200, [EMAIL PROTECTED] wrote:
> Today I tried to install freeswan1.9. After establishing ipsec tunnel with
> my peer I got the wait_on_bh message.
> (I cannot paste exactly because It is a production machine, and I restarted
> it as fast as I could)
>
> So what to
On Tue, 29 May 2001 15:50:22 +0200, [EMAIL PROTECTED] wrote:
Today I tried to install freeswan1.9. After establishing ipsec tunnel with
my peer I got the wait_on_bh message.
(I cannot paste exactly because It is a production machine, and I restarted
it as fast as I could)
So what to do?
On Tue, 22 May 2001 [EMAIL PROTECTED] wrote:
> This sounds like a bug I have heard before: some switches don't work with
> the xircom card (well, our drivers for it) when doing full duplex.
> Could you try the latest driver from
>
> http://people.redhat.com/arjanv
>
> which forces the card to
On Tue, 22 May 2001 20:10:41 +0100 (BST), Alan Cox <[EMAIL PROTECTED]> wrote:
> Before you give up on the xircom thing, try the -ac kernel and set the box
> up to use xircom_cb not xircom_tulip_cb
>
> That might help a lot
It doesn't, it still performs poorly with any of the three available
On Tue, 22 May 2001 [EMAIL PROTECTED] wrote:
This sounds like a bug I have heard before: some switches don't work with
the xircom card (well, our drivers for it) when doing full duplex.
Could you try the latest driver from
http://people.redhat.com/arjanv
which forces the card to
On Tue, 22 May 2001 20:10:41 +0100 (BST), Alan Cox [EMAIL PROTECTED] wrote:
Before you give up on the xircom thing, try the -ac kernel and set the box
up to use xircom_cb not xircom_tulip_cb
That might help a lot
It doesn't, it still performs poorly with any of the three available
drivers
On Fri, 18 May 2001, James Fidell wrote:
> > Is this a real card, or is it built-in on the motherboard?
>
> It's a real card.
All right, that's good to know. Maybe I'll get one for myself, so I can
test new code on it -- right now I only have rev 9 and earlier cards.
> For various reasons
On Thu, 17 May 2001 16:59:04 +0100, James Fidell <[EMAIL PROTECTED]> wrote:
> I have two eepro100 interfaces in a machine, one rev 8, which works just
> fine, and another rev 12, which appears as a device when the kernel boots
> and can be configured with an IP address etc., but I can't get any
On Thu, 17 May 2001 16:59:04 +0100, James Fidell [EMAIL PROTECTED] wrote:
I have two eepro100 interfaces in a machine, one rev 8, which works just
fine, and another rev 12, which appears as a device when the kernel boots
and can be configured with an IP address etc., but I can't get any data
On Fri, 18 May 2001, James Fidell wrote:
Is this a real card, or is it built-in on the motherboard?
It's a real card.
All right, that's good to know. Maybe I'll get one for myself, so I can
test new code on it -- right now I only have rev 9 and earlier cards.
For various reasons that
On Tue, 1 May 2001, Trond Myklebust wrote:
> > I'll give your patch a spin tomorrow, after I catch some
> > zzz's. :-)
>
> Right you are.
And indeed, the tcp-hang patch fixed the problem! Thanks a lot!
> FYI I've now put up those patches of which I am aware against 2.2.19
> on
>
>
On Tue, 1 May 2001, Trond Myklebust wrote:
> Did you apply the following patch which I put out on the lists a
> couple of weeks ago?
No, I was testing with 2.2.19 and then I started going back into the
2.2.19pre series until I found the culprit.
I'll give your patch a spin tomorrow, after I
On Tue, 1 May 2001, Ion Badulescu wrote:
> I'll do another test, 2.2.18 + the NFS/SunRPC changes, and see how it
> goes. Hopefully they'll apply easily...
As I suspected, 2.2.18 + all the NFS/NFSd/SunRPC changes present in
2.2.19pre10 locks up with wait_on_bh as soon as I run
On Tue, 1 May 2001, Ion Badulescu wrote:
> Right now I'm pretty sure it's the NFS/SunRPC changes, but I'll know for
> sure in about 30 minutes.
As I suspected, 2.2.19pre9 + the NFS/SunRPC changes locked up under load
with the now familiar:
wait_on_bh, CPU 2:
irq: 1 [0 0]
bh:
On Tue, 1 May 2001, Ion Badulescu wrote:
> > aic7xxx
>
> Loaded but not used, no devices attached to it.
Scratch that, I was confusing it with another box. There is no trace of
aic7xxx on this system.
Ion
--
It is better to keep your mouth shut and be thought a fool,
On Tue, 1 May 2001, Alan Cox wrote:
> Ok the main candidates there would be:
>
> The sunrpc/nfs changes
I'm currently testing this one -- just preparing to reboot pre9 + these
changes.
> EEpro100/starfire
eepro100 is in use. But that patch is harmless.
> aic7xxx
Loaded
On Tue, 1 May 2001, Alan Cox wrote:
Ok the main candidates there would be:
The sunrpc/nfs changes
I'm currently testing this one -- just preparing to reboot pre9 + these
changes.
EEpro100/starfire
eepro100 is in use. But that patch is harmless.
aic7xxx
Loaded but
On Tue, 1 May 2001, Ion Badulescu wrote:
aic7xxx
Loaded but not used, no devices attached to it.
Scratch that, I was confusing it with another box. There is no trace of
aic7xxx on this system.
Ion
--
It is better to keep your mouth shut and be thought a fool,
than
On Tue, 1 May 2001, Ion Badulescu wrote:
Right now I'm pretty sure it's the NFS/SunRPC changes, but I'll know for
sure in about 30 minutes.
As I suspected, 2.2.19pre9 + the NFS/SunRPC changes locked up under load
with the now familiar:
wait_on_bh, CPU 2:
irq: 1 [0 0]
bh: 1 [0 1
On Tue, 1 May 2001, Ion Badulescu wrote:
I'll do another test, 2.2.18 + the NFS/SunRPC changes, and see how it
goes. Hopefully they'll apply easily...
As I suspected, 2.2.18 + all the NFS/NFSd/SunRPC changes present in
2.2.19pre10 locks up with wait_on_bh as soon as I run ls -lR on a large
On Tue, 1 May 2001, Trond Myklebust wrote:
Did you apply the following patch which I put out on the lists a
couple of weeks ago?
No, I was testing with 2.2.19 and then I started going back into the
2.2.19pre series until I found the culprit.
I'll give your patch a spin tomorrow, after I
On Tue, 1 May 2001, Trond Myklebust wrote:
I'll give your patch a spin tomorrow, after I catch some
zzz's. :-)
Right you are.
And indeed, the tcp-hang patch fixed the problem! Thanks a lot!
FYI I've now put up those patches of which I am aware against 2.2.19
on
On Mon, 30 Apr 2001, Ion Badulescu wrote:
> Ok, so onto the binary search through the 2.2.19pre series...
I think it started in 2.2.19pre10. I can reproduce the hang on pre10,
quite easily, but I couldn't reproduce it on pre5, pre7 and pre9. I'll try
a few other pre versions, just to m
On Mon, 30 Apr 2001, Mohammad A. Haque wrote:
> Just to give another data point...
>
> 2.2.19 + LVM patches - dual P3 550
> 1 GB RAM
> eepro100
> ncr53c8xx scsi
> mylex accelRAID 1100 RAID controller
>
> We've transferred around 1 GB of stuff over the network and about 200 GB
> between two
On Mon, 30 Apr 2001, Alan Cox wrote:
> > I also have reports but related to the network driver updates. So I
> > suggest to try again with 2.2.19 but with the drivers/net/* of 2.2.18.
>
> Thats probably a better starting point. Its easier to back out than the VM
> changes and it would also
On Sun, 29 Apr 2001 01:16:04 +0200, bert hubert <[EMAIL PROTECTED]> wrote:
> On Sat, Apr 28, 2001 at 02:21:29PM -0700, Ion Badulescu wrote:
>> Hi Alan,
>>
>> Over the last week I've tried to upgrade a 4-CPU Xeon box to 2.2.19, but
>> the it keeps locking up when
On Sun, 29 Apr 2001 01:16:04 +0200, bert hubert [EMAIL PROTECTED] wrote:
On Sat, Apr 28, 2001 at 02:21:29PM -0700, Ion Badulescu wrote:
Hi Alan,
Over the last week I've tried to upgrade a 4-CPU Xeon box to 2.2.19, but
the it keeps locking up whenever the disks are stresses a bit, e.g. when
On Mon, 30 Apr 2001, Alan Cox wrote:
I also have reports but related to the network driver updates. So I
suggest to try again with 2.2.19 but with the drivers/net/* of 2.2.18.
Thats probably a better starting point. Its easier to back out than the VM
changes and it would also explain the
On Mon, 30 Apr 2001, Mohammad A. Haque wrote:
Just to give another data point...
2.2.19 + LVM patches - dual P3 550
1 GB RAM
eepro100
ncr53c8xx scsi
mylex accelRAID 1100 RAID controller
We've transferred around 1 GB of stuff over the network and about 200 GB
between two raids w/o
On Mon, 30 Apr 2001, Ion Badulescu wrote:
Ok, so onto the binary search through the 2.2.19pre series...
I think it started in 2.2.19pre10. I can reproduce the hang on pre10,
quite easily, but I couldn't reproduce it on pre5, pre7 and pre9. I'll try
a few other pre versions, just to make sure
Hi Alan,
Over the last week I've tried to upgrade a 4-CPU Xeon box to 2.2.19, but
the it keeps locking up whenever the disks are stresses a bit, e.g. when
updatedb is running. I get the following messages on the console:
wait_on_bh, CPU 1:
irq: 1 [1 0]
bh: 1 [1 0]
<[8010af71]>
over and
Hi Alan,
Over the last week I've tried to upgrade a 4-CPU Xeon box to 2.2.19, but
the it keeps locking up whenever the disks are stresses a bit, e.g. when
updatedb is running. I get the following messages on the console:
wait_on_bh, CPU 1:
irq: 1 [1 0]
bh: 1 [1 0]
[8010af71]
over and over
On 25 Apr 2001 00:39:43 +0200, Trond Myklebust <[EMAIL PROTECTED]> wrote:
>> " " == apark <[EMAIL PROTECTED]> writes:
>
> > Hi, Recently upgraded to 2.2.19, along with new
> > nfs-utils(0.3.1). But I have a program that requires a
> > exclusive write lock on a NFSed directory.
On 25 Apr 2001 00:39:43 +0200, Trond Myklebust [EMAIL PROTECTED] wrote:
== apark [EMAIL PROTECTED] writes:
Hi, Recently upgraded to 2.2.19, along with new
nfs-utils(0.3.1). But I have a program that requires a
exclusive write lock on a NFSed directory. When I was using
On 23 Apr 2001 12:54:22 -0600, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> I'll include it again. I had it attached as a plain text attachment,
> I don't know if that is a problem or not.
Actually it was attached as text/x-patch, not as text/plain... so
pine certainly refused to display it
On 23 Apr 2001 12:54:22 -0600, Eric W. Biederman [EMAIL PROTECTED] wrote:
I'll include it again. I had it attached as a plain text attachment,
I don't know if that is a problem or not.
Actually it was attached as text/x-patch, not as text/plain... so
pine certainly refused to display it
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
eanups
-
+
LK1.1.4 (jgarzik):
- Merge Becker version 1.03
+
+ LK1.2.1 (Ion Badulescu <[EMAIL PROTECTED]>)
+ - Support hardware Rx/Tx checksumming
+ - Use the GFP firmware taken from Adaptec's Netware driver
+
+ LK1.2.2 (Ion Badulescu)
+ - Backpor
+
+ LK1.2.1 (Ion Badulescu <[EMAIL PROTECTED]>)
+ - Support hardware Rx/Tx checksumming
+ - Use the GFP firmware taken from Adaptec's Netware driver
+
+ LK1.2.2 (Ion Badulescu)
+ - Backported to 2.2.x
+
+ LK1.2.3 (Ion Badulescu)
+ - Fix the flaky mdio int
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
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
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
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.
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.
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
+
+ LK1.2.1 (Ion Badulescu [EMAIL PROTECTED])
+ - Support hardware Rx/Tx checksumming
+ - Use the GFP firmware taken from Adaptec's Netware driver
+
+ LK1.2.2 (Ion Badulescu)
+ - Backported to 2.2.x
+
+ LK1.2.3 (Ion Badulescu)
+ - Fix the flaky mdio interface
-
+
LK1.1.4 (jgarzik):
- Merge Becker version 1.03
+
+ LK1.2.1 (Ion Badulescu [EMAIL PROTECTED])
+ - Support hardware Rx/Tx checksumming
+ - Use the GFP firmware taken from Adaptec's Netware driver
+
+ LK1.2.2 (Ion Badulescu)
+ - Backported to 2.2.x
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
LK1.1.4 (jgarzik):
- Merge Becker version 1.03
+
+ LK1.2.1 (Ion Badulescu <[EMAIL PROTECTED]>)
+ - Support hardware Rx/Tx checksumming
+ - Use the GFP firmware taken from Adaptec's Netware driver
+
+ LK1.2.2 (Ion Badulescu)
+ - Backported to 2.2.x
1.4 (jgarzik):
- Merge Becker version 1.03
+
+ LK1.2.1 (Ion Badulescu <[EMAIL PROTECTED]>)
+ - Support hardware Rx/Tx checksumming
+ - Use the GFP firmware taken from Adaptec's Netware driver
+
+ LK1.2.2 (Ion Badulescu)
+ - Backported to 2.2.x
+
+ LK1.
Becker version 1.03
+
+ LK1.2.1 (Ion Badulescu [EMAIL PROTECTED])
+ - Support hardware Rx/Tx checksumming
+ - Use the GFP firmware taken from Adaptec's Netware driver
+
+ LK1.2.2 (Ion Badulescu)
+ - Backported to 2.2.x
+
+ LK1.2.3 (Ion Badulescu)
+ - Fix
Merge Becker version 1.03
+
+ LK1.2.1 (Ion Badulescu [EMAIL PROTECTED])
+ - Support hardware Rx/Tx checksumming
+ - Use the GFP firmware taken from Adaptec's Netware driver
+
+ LK1.2.2 (Ion Badulescu)
+ - Backported to 2.2.x
+
+ LK1.2.3 (Ion Badulescu)
+
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, 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
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
On Mon, 16 Apr 2001 15:06:44 +0100, [EMAIL PROTECTED] wrote:
>
> Hi,
> I am trying to put virtual mac address at the place of physical mac
> address , for that I have overwrite source hardware address with virtual
> address.Now when I try to ping to this machine with some other
> machine.It says
On Mon, 16 Apr 2001 15:06:44 +0100, [EMAIL PROTECTED] wrote:
Hi,
I am trying to put virtual mac address at the place of physical mac
address , for that I have overwrite source hardware address with virtual
address.Now when I try to ping to this machine with some other
machine.It says
On Fri, 6 Apr 2001, Andre Hedrick wrote:
> > You really ought to rename this parameter to pcibus. Even though it doesn't
> > do justice to the VLB bus, the potential for user error is much smaller.
>
> Until today you had a vaild point!
>
> Promise Ultra100TX2 (20268 chipset).
>
> This is a
On Fri, 06 Apr 2001 21:30:24 -0700, Andre Hedrick <[EMAIL PROTECTED]> wrote:
>
> You killed yourself
>
> You do not have a host that will do idebus=66
You really ought to rename this parameter to pcibus. Even though it doesn't
do justice to the VLB bus, the potential for user error is much
On Fri, 06 Apr 2001 21:30:24 -0700, Andre Hedrick [EMAIL PROTECTED] wrote:
You killed yourself
You do not have a host that will do idebus=66
You really ought to rename this parameter to pcibus. Even though it doesn't
do justice to the VLB bus, the potential for user error is much
1 - 100 of 302 matches
Mail list logo
