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 requir
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 stateme
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
behind 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
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 l
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 st
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 is
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 omi
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 :).
T
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 spac
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 res
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 -- m
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
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 so
-2,6 +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.
+
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, 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
dri
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 tha
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 da
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 ca
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
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:
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 bu
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,
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 raid
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 expla
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
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 ove
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 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 i
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)(struc
er cleanups
-
+
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)
+
rsion 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 the
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 ba
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 Space
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
r cleanups
-
+
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)
er cleanups
-
+
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)
+
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.
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 D
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 66
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 Thu, 5 Apr 2001, Andreas Dilger wrote:
> Why do it from user space? Simply add a printk() to sys_init_module() or
> similar.
Agreed, but at that point the solution has absolutely nothing to do with
insmod anymore. :-)
Besides, as you said, I don't really see the point. It certainly doesn
On Thu, 5 Apr 2001 17:57:48 -0700 (PDT), Andrew Daviel <[EMAIL PROTECTED]> wrote:
> Is there a good reason why insmod should not call syslog() to log
> any module that gets installed ?
Simple: you'll have quite a bit of a problem if you are trying to insmod
the module with support for AF_UNIX s
On Thu, 5 Apr 2001 12:52:28 -0400 (EDT), Richard B. Johnson <[EMAIL PROTECTED]>
wrote:
> Only an observation:
>
>
> main()
> {
>nice(19);
>for(;;)
>sched_yield();
> }
>
> does...
>
[...]
>
> It consumes 99.1 percent CPU, just spinning.
And, umm, what *exactly* would you ex
On Wed, 4 Apr 2001 20:00:29 +0100 (BST), Alan Cox <[EMAIL PROTECTED]> wrote:
>> Been running this configuration over more than 2 years now without such
>> major problems.
>> Could this be the cause?
>
> Quite possibly. There are reasons we ignore bug reports from overclockers
Perhaps. But,
ide
On Wed, 4 Apr 2001 16:43:14 -0700 (PDT), Andre Hedrick <[EMAIL PROTECTED]> wrote:
> The subject says it all
Use the latest snapshot of am-utils (6.0.6s1), which fixes the problem.
Ion
am-utils co-maintainer
--
It is better to keep your mouth shut and be thought a fool,
than to o
On Tue, 3 Apr 2001 16:56:57 -0500, Matthew Fredrickson <[EMAIL PROTECTED]> wrote:
>
> I have decided to leave lkml because everybody else is doing it too.
I have decided to switch to Windows because everybody else is doing it too.
Oh, wait.. wrong mailing list. It's not hosted on aol.com. :-)
On Fri, 23 Mar 2001 09:34:36 -0800, Jun Sun <[EMAIL PROTECTED]> wrote:
> BTW, does the eepro100 patch for 2.2.19pre apply to 2.4.2? Or it is already
> in it?
It was backported from 2.4.1, so yes, it's already in.
Ion
--
It is better to keep your mouth shut and be thought a fool,
On Fri, 23 Mar 2001 23:59:09 +0100, J . A . Magallon <[EMAIL PROTECTED]> wrote:
>
>
> On 03.23 Linus Torvalds wrote:
>>
>> I agree. I'd much prefer that syntax also.
>>
>> Or just remove the "default:" altogether, when it doesn't make any
>> difference.
>>
>
> Well, at last some sense. The s
On Thu, 22 Mar 2001 11:30:46 -0800 (PST), Alan Olsen <[EMAIL PROTECTED]> wrote:
> He found out what happens when you mix Penguin bars and Penguin Mints and
> he has been in detox since. ];>
Wouldn't that be de-tux, though? :-)
Ion
--
It is better to keep your mouth shut and be thought a foo
On Tue, 20 Mar 2001 15:19:37 -0500, Doug Ledford <[EMAIL PROTECTED]> wrote:
> Why would esd get a short write() unless it is opening the file in non
> blocking mode (which I didn't see when I was working on the i810 sound
> driver)? If esd is writing to a file in blocking mode and that write is
On Mon, 12 Mar 2001 22:02:12 -0500, Jeff Garzik <[EMAIL PROTECTED]> wrote:
> It is highly recommended to always compile with CONFIG_ISAPNP=y due to
> these differences. If you grep around for CONFIG_ISAPNP versus
> CONFIG_ISAPNP_MODULE, you'll see that many drivers are woefully
> unprepared for
On Sat, 10 Mar 2001 01:21:25 +1100, Andrew Morton <[EMAIL PROTECTED]> wrote:
> +/**
> + * enable_nmi_watchdog - enables/disables NMI watchdog checking.
> + * @yes: If zero, disable
Ugh. I have a feeling that your chances to get Linus to accept this are
extremely slim.
Just have two functions, e
On Wed, 28 Feb 2001, Alexander Viro wrote:
> > And disadvantages: you can't have broken symlinks.
> >
> > This actually turns out to be quite a bit of a problem when one tries
> > to use bind mounts with autofs. For one thing, it's perfectly legal
> > to have /autofs/foo as a symlink to /autofs/
On Wed, 28 Feb 2001 13:07:29 -0500 (EST), Alexander Viro <[EMAIL PROTECTED]> wrote:
> On Wed, 28 Feb 2001, David L. Parsley wrote:
>> Yeah, mount --bind is cool, I've been using it on one of my projects
>> today. But - maybe I'm just not thinking creatively enough - what are
>> the advantages o
ght a fool,
than to open it and remove all doubt.
---
--- /mnt/3/linux-2.2.19pre/drivers/net/starfire.c Mon Feb 26 21:56:30 2001
+++ linux-2.2.18/drivers/net/starfire.c Mon Feb 26 21:51:06 2001
@@ -49,6 +49,16 @@
LK1.2.4 (Ion Badu
On Mon, 26 Feb 2001 23:18:37 + (GMT), Alan Cox <[EMAIL PROTECTED]> wrote:
> 2.2.19pre15
[...]
> o EEpro100 posted writes fix (Ion Badulescu)
All the credit goes to Andrey Savochkin and Don Becker -- I only applied
their 2.4.1 patch to 2.2.x..
.
--
--- /mnt/3/linux-2.4-ac/drivers/net/starfire.c Mon Feb 19 14:35:01 2001
+++ linux-2.4/drivers/net/starfire.cThu Feb 22 14:19:33 2001
@@ -52,6 +52,9 @@
LK1.2.5 (Ion Badulescu)
- Several fixes from Manfred Spraul
+ LK1.2.6 (Ion Badulescu
On Tue, 20 Feb 2001, CaT wrote:
> > patched, old removed, new installed, waiting for fubar. :)
>
> Ok. this is what I got in my kern.log. this is on a fresh reboot.
>
> Feb 20 18:31:49 theirongiant kernel: eepro100: cmd_wait for(0x70) timedout
>with(0x70)!
> Feb 20 18:31:49 theirongiant kernel
On Mon, 19 Feb 2001 14:49:35 -0800, Andrey Savochkin <[EMAIL PROTECTED]> wrote:
> On Tue, Feb 20, 2001 at 09:21:06AM +1100, CaT wrote:
>>
>> It happened again. Same deal. Once was after a reboot and this time
>> was after a resume. :/
>
> In my experiments wait_for_cmd timeouts almost always we
http://www.stallion.com
S: Supported
+STARFIRE/DURALAN NETWORK DRIVER
+P: Ion Badulescu
+M: [EMAIL PROTECTED]
+S: Maintained
+
STARMODE RADIO IP (STRIP) PROTOCOL DRIVER
W: http://mosquitonet.Stanford.EDU/strip.html
S: Unsupported ?
--- /mnt/3/linux-2.4-ac/Document
On Thu, 15 Feb 2001 15:57:09 -0500 (EST), Richard A Nelson <[EMAIL PROTECTED]> wrote:
> The machine boots and runs for some time without problems, but then
> something makes the clock *very* jittery:
>
> * xscreensaver kicks in after almost no time (even betwixt quick
>keystrokes and in the
On Wed, 14 Feb 2001, Alan Cox wrote:
> > The way I understand it, IA64 and Alpha cope with it, but at the expense
> > of taking an exception for each packet -- so it's not worth it.
>
> You want to copy_checksum the frame on these platforms,
That's what we're doing...
> or better yet use
> a
On Wed, 14 Feb 2001, Jeff Garzik wrote:
> On Wed, 14 Feb 2001, Alan Cox wrote:
> > It does. It does so on IA64 now as well. The only architecture which has troubles
> > with alignment on IP frames now is ARM2
>
> So the IA64-specific PKT_CAN_COPY code in starfire can go away
> completely? Jes,
On Tue, 13 Feb 2001 12:29:16 -0800, Ion Badulescu <[EMAIL PROTECTED]> wrote:
> On Tue, 13 Feb 2001 07:06:44 -0600 (CST), Jeff Garzik
><[EMAIL PROTECTED]> wrote:
>
>> On 12 Feb 2001, Jes Sorensen wrote:
>>> In fact one has to look out for this and disable t
On 12 Feb 2001, Jes Sorensen wrote:
> Ion> Yes, but I'd rather let people turn off the always-copy behavior
> Ion> by simply changing rx_copybreak. The unused code is not really
> Ion> that much of a deal, it's only a few lines.
>
> However, it is in the hot path code where it hurts the most.
I
On Tue, 13 Feb 2001 12:09:32 + (GMT), Michèl Alexandre Salim
<[EMAIL PROTECTED]> wrote:
> Currently running the XFree 4.0.2 from RH 7.0.90 (7.1
> beta, Fisher) on top of my RH 7 + Ximian system and
> when using aviplay it doesn't use any acceleration
> features at all, consequently choppy di
On Tue, 13 Feb 2001 07:06:44 -0600 (CST), Jeff Garzik
<[EMAIL PROTECTED]> wrote:
> On 12 Feb 2001, Jes Sorensen wrote:
>> In fact one has to look out for this and disable the feature in some
>> cases. On the acenic not disabling Memory Write and Invalidate costs
>> ~20% on performance on some sy
On Mon, 12 Feb 2001, Ion Badulescu wrote:
> Here is an incremental patch from the version in 2.2.19pre10 to the latest
> version of starfire.c. Please apply, the 2219pre10 version doesn't work if
> compiled-in (because drivers/net builds net.a not net.o). It also fixes
>
MOD_xxx races
@@ -31,7 +31,7 @@
LK1.1.3 (Andrew Morton)
- Timer cleanups
-
+
LK1.1.4 (jgarzik):
- Merge Becker version 1.03
@@ -41,6 +41,17 @@
LK1.2.2 (Ion Badulescu)
- Backported to 2.2.x
+
+ LK1.2.3 (Ion Badulescu)
+ - Fix the flaky m
On Mon, 12 Feb 2001, Alan Cox wrote:
> No resolution to firmware fiasco, no driver in kernel
But the driver _does_ work without the firmware, it only loses the
hardware TCP checksum on Rx capability. That's what we have in 2.4.x right
now, why should 2.2.x be pickier and *demand* to have the fi
On Sat, 10 Feb 2001, Ion Badulescu wrote:
> Hi Alan,
>
> This is basically the same driver I sent to Jeff Garzik and you yesterday,
> for 2.4.1. Only one byte is different, in the version string. :-) The
> patch was generated against 2.2.18, it applies cleanly to 2.2.19pre9.
On Mon, 12 Feb 2001, Andrey Savochkin wrote:
> I've just checked: "Sending a multicast list set command" is printed only on
> high debug levels, so Augustin might not see them.
I could have sworn that I saw the message being printed unconditionally.
But you're right, so we're back to square one
On Sun, 11 Feb 2001 16:20:47 -0200, Rogerio Brito <[EMAIL PROTECTED]> wrote:
>> >ioctl(cd_fd, CDROM_SELECT_SPEED, speed);
Yes: pass 0 as the speed, in the ioctl() above.
Ion
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
On Sat, 10 Feb 2001 16:46:01 -0600, Nathan Neulinger <[EMAIL PROTECTED]> wrote:
> Any ideas on how I can correct this symptom?
This seems to be Donald Becker's driver, right? Please try with the
starfire driver for 2.2.x I posted a few hours ago to the list. If you
don't have it, contact me priv
):
+ - 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 (Io
On Fri, 9 Feb 2001, Alan Cox wrote:
> > It's amusing that a full receive copy is added without any concern, in
> > the same discussion where zero-copy transmit is treated as a holy grail!
>
> For non routing paths its virtually free because the DMA forced the lines
> from cache anyway.
Are you
On 9 Feb 2001, Jes Sorensen wrote:
> Manfred> What about changing the default for rx_copybreak instead?
> Manfred> Set it to 1536 on ia64 and Alpha, 0 for the rest. tulip and
> Manfred> eepro100 use that aproach.
>
> Inefficient, my patch will make the unused code path disappear during
> compil
On Fri, 9 Feb 2001, Jeff Garzik wrote:
> For 2.2, define SET_MODULE_OWNER to null.
>
> Define STAR_MOD_INC_USE_COUNT and STAR_MOD_DEC_USE_COUNT. For 2.4,
> these are null. For 2.2, these point to MOD_{INC,DEC}_USE_COUNT.
... and use both SET_MODULE_OWNER and STAR_MOD_*_USE_COUNT. It's along t
On Fri, 9 Feb 2001, Jeff Garzik wrote:
> I would prefer that zerocopy code remain out of all official kernels
> until zerocopy itself is in said kernels. It's experimental code that
> simply cannot work in its present form, due to lack of infrastructure in
> the general kernel. And being based
On Thu, 8 Feb 2001, Donald Becker wrote:
> > Or we can just tell people, "hey, don't use this 64-bit PCI card on a real
> > 64-bit system, it's broken by design"? I don't think that's a good
> > solution either.
>
> This is not a 64 bit PCI issue.
I know. It was just an ironic comment: we h
On Thu, 8 Feb 2001, Ion Badulescu wrote:
> >The MII read code is no longer reliable. I spent twenty minutes at
> >the show, but couldn't figure out the problem. I haven't been able
> >reproduce the problem locally with my 2.2 code and someone older
>
On Thu, 8 Feb 2001, Donald Becker wrote:
> > > The align-copy should *never* be required because the alignment differs
> > > between DIX and E-II encapsulated packets. The machine shouldn't crash
> > > because someone sends you a different encapsulation type!
>
> This is true for a number of dr
On Thu, 8 Feb 2001, Jeff Garzik wrote:
> Well at least let's do it the Linux Kernel Way(tm): separate out the
> zerocopy stuff such that there are minimal ifdefs in the code... For
> example:
>
> /* add these functions... */
> #ifdef ZEROCOPY
> static inline setup_txrx_rings(
On Thu, 8 Feb 2001, Manfred Spraul wrote:
> What about changing the default for rx_copybreak instead?
> Set it to 1536 on ia64 and Alpha, 0 for the rest.
> tulip and eepro100 use that aproach.
That makes a lot of sense, thanks for the suggestion. I'll do so in the
next version.
Ion
--
It i
On Thu, 8 Feb 2001, Jeff Garzik wrote:
> I would prefer that the zerocopy changes stay in DaveM's external patch
> until they are ready to be merged.
I would actually prefer to have a single source for all the driver
versions. The 2.2.x version I sent to Alan later on actually compiles on
2.
On Thu, 8 Feb 2001, Augustin Vidovic wrote:
> This suppression of thousands of lines was described as a DOS-protection
> in the docs I read.
Still, there should be something before these suppressed messages started.
> With my patch, the test becomes (eeprom[3] & 0x03), which is not null
> for e
On Thu, 8 Feb 2001 20:15:39 +0900, Augustin Vidovic <[EMAIL PROTECTED]> wrote:
>> So what _were_ those messages? Can you post them?
>
> No I can't because they were suppressed by the syslogd (DOS protection), only
> their number being reported (several thousands every few seconds).
syslogd does
On Thu, 8 Feb 2001 19:41:56 +0900, Augustin Vidovic <[EMAIL PROTECTED]> wrote:
> You can see a kind of sudden blackout which lasts about 3 hours, and then the
> situation resumes to normality.
>
> At the same time, the /var/log/messages receives thousands of messages from the
> NET: subsystem.
1 - 100 of 160 matches
Mail list logo
