Linus Torvalds wrote:
>
>
> On Mon, 30 Oct 2000, Jeff Garzik wrote:
> >
> > Ya know, sorting those lists causes this problem, too... usb.o is
> > listed first in the various lists, as is usbcore.o. Is it possible to
> > avoid sorting? Doing so will fix this, and also any other link order
> >
> > files in the kernel will all be happy in Linuxland. Can any external
>
> Why do you need to touch any existing kernel .c source file ? If you make
> that patch, this breaks "situation 1" above.
It doesn't break situation 1 as the minor changes I've made to those 2 C
files should not have
- Original Message -
From: "Alan Cox" <[EMAIL PROTECTED]>
To: "Linux Kernel Developer" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, October 30, 2000 8:04 AM
Subject: Re: Need info on the use of certain datastructures and the first
C++ keyword patch for 2.2.17
> > js_dev::new
On Tue, Oct 31, 2000 at 01:11:29AM -0500, Brian Gerst wrote:
> This was just changed in 2.4 so that vmalloced pages are faulted in on
> demand.
Could you explain how it handles the vmalloc() -- vfree() -- vmalloc() of same
virtual space but different physical race ?
-Andi
-
To unsubscribe from
On Tue, 31 Oct 2000, Brian Gerst wrote:
> "H. Peter Anvin" wrote:
> >
> > Followup to: <[EMAIL PROTECTED]>
> > By author:"Richard B. Johnson" <[EMAIL PROTECTED]>
> > In newsgroup: linux.dev.kernel
> > >
> > > > 64K probably less. kmalloc allocates physically linear spaces. vmalloc will
> >
On Tue, Oct 31, 2000 at 08:49:02AM +, Tigran Aivazian wrote:
>
> what do you mean?! That is, of course, impossible because it would break
> all existing software, so I won't even bother checking the code, safely
> assuming that you perhaps meant something else, ok?
He refers to faulting int
On Tue, 31 Oct 2000, Andi Kleen wrote:
> On Tue, Oct 31, 2000 at 08:49:02AM +, Tigran Aivazian wrote:
> >
> > what do you mean?! That is, of course, impossible because it would break
> > all existing software, so I won't even bother checking the code, safely
> > assuming that you perhaps me
On Mon Oct 30, 2000 at 06:34:55PM +, Alan Cox wrote:
>
> See www.uclinux.org; the uclinux guys started a 2.4 port recently. Basically
> the idea is to have a mm-nommu/ directory which implements a mostly compatible
> replacement for the mm layer (obviously stuff like mmap dont work without an
On Tue, Oct 31, 2000 at 09:07:29AM +, Tigran Aivazian wrote:
> On Tue, 31 Oct 2000, Andi Kleen wrote:
>
> > On Tue, Oct 31, 2000 at 08:49:02AM +, Tigran Aivazian wrote:
> > >
> > > what do you mean?! That is, of course, impossible because it would break
> > > all existing software, so I
Is an 2.2.16 system that suddenly out of the blue (always! like; every time
the system is started) uses all memory and all swap-space and then crashes
of any intrest?
Or should I just ignore it and install 2.2.17?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bod
I have been told that this is the right mailing list to report this
to.
I have been attempting to use my SNTP client (msntp) under Linux,
and discover that adjtime is more-or-less completely broken, so I
have to use gettimeofday+increment+settimeofday. It is possible
that I have misconfigured, b
Horst von Brand wrote:
>
> Martin Dalecki <[EMAIL PROTECTED]> said:
> > Peter Samuelson wrote:
>
> [...]
>
> > > * Red Hat "2.96" or CVS 2.97 will probably break any known kernel.
>
> > Works fine for me and 2.4.0-test10-pre5... however there are tons of
> > preprocessor warnings in some drive
I looked around for a driver for the Apaptec F940 fibre channel
card... found nothing so far. It looks like the card works with I2O. I2O
requires a I2O motherboard, yes? If there is a web/ftp site that I
missed... please point me in the correct direction.
On Mon, Oct 30, 2000 at 03:34:44PM -0500, Alexander Viro wrote:
> Unfortunately, it doesn't fix the thing. ->sync_page() is called ...
> Minimal patch (against -pre7) follows. It still leaves sync_page() problem
> open - any suggestions on that one are very welcome. ...
I needed to patch your p
Keith Owens writes:
> kbuild 2.5 splits link order into three categories. Those that must
> come first, in the order they are specified - LINK_FIRST. Those that
> must come last, in the order they are specified - LINK_LAST.
Keith, this sounds like a K-ludge.
Take the instance where we need to
On Mon, Oct 30, 2000 at 02:40:16PM -0200, Rik van Riel wrote:
> > There are 256 megabytes of SDRAM available. I don't think it's
> > reasonable that a 1/2 megabyte allocation would fail, especially
> > since it's the first module being installed.
> If you write the defragmentation code for the VM,
Here's a little patch I've been using for a while, and which some
people may find useful. It's mainly good for helping with that feeling
that you might miss something when you simply make oldconfig. Any
self-respecting control freak will understand why this is
important ;-)
What this patch does:
Hallo Linus,
The following patch separates the CPU detection and BIOS interface stuff
in arch/i386/kernel/setup.c from the actual CPU init. This makes it a bit
easier to share code with the x86-64 port [we want to share all the CPU
detection and e820 code, but the cpu init has to be separated]
[Linus]
> In short, we should _remove_ all traces of stuff like
>
> O_OBJS = $(filter-out $(export-objs), $(obj-y))
>
> It's wrong.
>
> We should just have
>
> O_OBJS = $(obj-y)
>
> which is always right.
This part I agree with..
> And it should make all this FIRST/LAST object
Several oops come up when using a lot of memory (using
imagemagick on PIA1.tif from photojournal.jpl.nasa.gov/tiff,
on a 64MB machine, for example)
The weird thing is the oops happen *after* I've finished with
imagemagick (or the gimp, or ...). In this particular situation
netscape suddenly d
Boot after a power cycle works. A ctrl-alt-del reboot always hangs during
startup (caps lock dead, ctrl-alt-del dead):
Oct 31 13:36:22 area51 kernel: (scsi0)
found at PCI 0/4/0
Oct 31 13:36:22 area51 kernel: (scsi0) Narrow Channel, SCSI ID=7, 3/255 SCBs
Oct 31 13:36:22 area51 kernel: (scsi0)
Andi Kleen wrote:
>
> On Tue, Oct 31, 2000 at 01:11:29AM -0500, Brian Gerst wrote:
> > This was just changed in 2.4 so that vmalloced pages are faulted in on
> > demand.
>
> Could you explain how it handles the vmalloc() -- vfree() -- vmalloc() of same
> virtual space but different physical race
On Tue, 31 Oct 2000, Ingo Oeser wrote:
> On Mon, Oct 30, 2000 at 02:40:16PM -0200, Rik van Riel wrote:
> > If you write the defragmentation code for the VM, I'll
> > be happy to bump up the limit a bit ...
>
> Should become easier once we start doing physical page scannings.
>
> We could record
Hi Horst.
>> Before I go any further with this, I would like to ask a few
>> questions relating to it:
>> 1. Is there any likelihood of this making it into the official
>>kernel, or am I just wasting my time?
> Depends, I'd say... perhaps after a long shakeout and much use.
Fair enoug
Hi there,
I noticed that when i changed to binutils 2.10.91 (Debian,woody)
i start to see messages like:
"Warning: Ignoring changed section attributes for .modinfo"
Chasing down the problem appeared that section modinfo is
declared for the first time as ".section .modinfo" without any
a
[kaos]
> > It still does not document the only real link order constraint in
> > USB. The almost complete lack of documentation on which link
> > orders are required and which are historical is extremely annoying
> > and _must_ be fixed, instead we just propagate the problem.
[Linus]
> We can
On Tue, 31 Oct 2000, Rik van Riel wrote:
> On Tue, 31 Oct 2000, Ingo Oeser wrote:
> > On Mon, Oct 30, 2000 at 02:40:16PM -0200, Rik van Riel wrote:
>
> > > If you write the defragmentation code for the VM, I'll
> > > be happy to bump up the limit a bit ...
> >
> > Should become easier once we s
On Tue, 31 Oct 2000 09:37:09 + (GMT),
Russell King <[EMAIL PROTECTED]> wrote:
>Keith Owens writes:
>> kbuild 2.5 splits link order into three categories. Those that must
>> come first, in the order they are specified - LINK_FIRST. Those that
>> must come last, in the order they are specifie
On Tue, 31 Oct 2000 15:54:05 +0200,
Petko Manolov <[EMAIL PROTECTED]> wrote:
>"Warning: Ignoring changed section attributes for .modinfo"
>
>Changing the declaration in linux/module.h to ".modinfo,"a""
>fixed the problem, but i noticed that the author said that
>"we want .modinfo to not be alloca
[rmk]
> > Take the instance where we need to link a.o first, z.o second, f.o
> > third and p.o fourth. How does LINK_FIRST / LINK_LAST guarantee
> > this?
It does. Read the patch. LINK_FIRST *itself* is not sorted.
> > LINK_FIRST = a.o z.o
> > LINK_LAST = f.o p.o
> >
> > But then what guar
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
John R Lenton wrote:
> Several oops come up when using a lot of memory (using
> imagemagick on PIA1.tif from photojournal.jpl.nasa.gov/tiff,
> on a 64MB machine, for example)
>
> The weird thing is the oops happen *after* I've finished with
> im
Keith Owens wrote:
>
> >Changing the declaration in linux/module.h to ".modinfo,"a""
> >fixed the problem, but i noticed that the author said that
> >"we want .modinfo to not be allocated"
>
> Historically that was the only way of preventing the .modinfo section
> from being included in modules
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
John R Lenton wrote:
> Several oops come up when using a lot of memory (using
> imagemagick on PIA1.tif from photojournal.jpl.nasa.gov/tiff,
> on a 64MB machine, for example)
>
> The weird thing is the oops happen *after* I've finished with
> im
On Tue, 31 Oct 2000 16:29:16 +0200,
Petko Manolov <[EMAIL PROTECTED]> wrote:
>I wonder why the compiler decides to add ".section
>.modinfo,"a",@progbits"
>May be this is the thing which should be fixed.
That is just gcc speak for section .modinfo is marked as allocated,
type progbits. Read the
Keith Owens wrote:
>
> On Tue, 31 Oct 2000 16:29:16 +0200,
> Petko Manolov <[EMAIL PROTECTED]> wrote:
> >I wonder why the compiler decides to add ".section
> >.modinfo,"a",@progbits"
> >May be this is the thing which should be fixed.
>
> That is just gcc speak for section .modinfo is marked as a
On Tue, 31 Oct 2000, Ingo Oeser wrote:
> On Mon, Oct 30, 2000 at 02:40:16PM -0200, Rik van Riel wrote:
> > > There are 256 megabytes of SDRAM available. I don't think it's
> > > reasonable that a 1/2 megabyte allocation would fail, especially
> > > since it's the first module being installed.
>
On Tue, 31 Oct 2000, Brian Gerst wrote:
> Andi Kleen wrote:
> >
> > On Tue, Oct 31, 2000 at 01:11:29AM -0500, Brian Gerst wrote:
> > > This was just changed in 2.4 so that vmalloced pages are faulted in on
> > > demand.
> >
> > Could you explain how it handles the vmalloc() -- vfree() -- vmallo
Hi
Searching through the archives I found this post on Tue, Sep 12, 2000 at
09:41:13PM +0200 from Octave Klaba
> Hello,
> On a high load server, kernel has some errors:
>
> VM: do_try_to_free_pages failed for httpd...
> VM: do_try_to_free_pages failed for httpd...
> eth0: Too much work at interr
> The code for vmalloc allocates the pages at vmalloc time, not after. The
> TLB is populated lazily, but most definately not the page tables.
Is the lazy tlb population interrupt safe or do I need to change any driver
using vmalloced memory from an IRQ ?
-
To unsubscribe from this list: send t
On Tue, Oct 31, 2000 at 11:35:46AM -0200, Rik van Riel wrote:
> > Rik: What do you think about this (physical cont. area cache) for 2.5?
^ == PCAC
>
> http://www.surriel.com/zone-alloc.html
Read it when you published it first, but di
> > VM: do_try_to_free_pages failed for httpd...
> > VM: do_try_to_free_pages failed for httpd...
These if they are odd ones and the box continues are fine, if you get masses
of them then probably not
> (our quiet periods) the syslog is nearly empty. In extremis it has been
> necessary to reboot
On Tue, 31 Oct 2000, Heusden, Folkert van wrote:
> Is an 2.2.16 system that suddenly out of the blue (always! like; every time
> the system is started) uses all memory and all swap-space and then crashes
> of any intrest?
> Or should I just ignore it and install 2.2.17?
Ignore and use 2.2.17.
"Alan Cox" <[EMAIL PROTECTED]> writes:
[about what I wrote]
> > > VM: do_try_to_free_pages failed for httpd...
> > > VM: do_try_to_free_pages failed for httpd...
>
> These if they are odd ones and the box continues are fine, if you get
masses
> of them then probably not
What's it actually doing w
On Tue, 31 Oct 2000, Geoff Winkless wrote:
> Hi
>
> Searching through the archives I found this post on Tue, Sep 12, 2000 at
> 09:41:13PM +0200 from Octave Klaba
>
> > Hello,
> > On a high load server, kernel has some errors:
> >
> > VM: do_try_to_free_pages failed for httpd...
> > VM: do_try_
On Tue, 31 Oct 2000 around 08:59:53 -0500, Richard B. Johnson wrote:
[snip]
> Since Linux is starting to be used in many 'strange' non-desktop
> environments, maybe it's time to provide a hook to reserve the
> top N kilobytes of RAM for strange buffers. Like:
>
> append="..,reserve=2M".
>
On Tue, 31 Oct 2000, Alan Cox wrote:
> > The code for vmalloc allocates the pages at vmalloc time, not after. The
> > TLB is populated lazily, but most definately not the page tables.
>
> Is the lazy tlb population interrupt safe or do I need to change any driver
> using vmalloced memory from a
On Tue, 31 Oct 2000, Geoff Winkless wrote:
> "Alan Cox" <[EMAIL PROTECTED]> writes:
> [about what I wrote]
> > > > VM: do_try_to_free_pages failed for httpd...
> > > > VM: do_try_to_free_pages failed for httpd...
> >
> > These if they are odd ones and the box continues are fine, if you get
> ma
(repost, apologies if youve seen this before)
There appeared to be a bug/feature in kernel series 2.0.x and 2.2.x
which caused perodic delays in the sending of very small TCP packets
even when the TCP_NODELAY option was set. In other words, the Linux
kernel was still trying to use delayed acknow
In fs/proc/array.c:proc_pid_statm() there is this test block:
if (vma->vm_flags & VM_EXECUTABLE)
trs += pages; /* text */
else if (vma->vm_flags & VM_GROWSDOWN)
drs += pages; /* stack */
else if (vma->vm_end > 0x6000)
lrs += pages; /* lib
I get a similar message with my 2.2.16 kernel:
Oct 23 15:02:12 cartman kernel: VM: do_try_to_free_pages failed for
kswapd...
Oct 23 15:02:12 cartman kernel: VM: do_try_to_free_pages failed for
klogd...
Oct 23 15:02:13 cartman kernel: VM: do_try_to_free_pages failed for
nmbd...
Oct 23 15:02:13
Hi,
> > By using serial console, I get messages for you ;-)
>
> Thanks, now you're just one step short of being really
> helpful :-). Pass it through ksymoops please, so the
> addresses will map to function names + offsets.
I atacched files. Is it OK?
> > hdc: timeout waiting for DMA
> > ide_d
On Tue, 31 Oct 2000, Ingo Oeser wrote:
> On Tue, Oct 31, 2000 at 11:35:46AM -0200, Rik van Riel wrote:
> > > Rik: What do you think about this (physical cont. area cache) for 2.5?
>^ == PCAC
> >
> > http://www.surriel.com/zone-alloc.
Oops, the second example module I posted did bad things on
SMP based machines, so here is a respin of it:
#include
#include
#include
/*
* This is a example of some of the more complex things that
* the SysRQ registration patch makes possible
*/
void dumpfake_handler (int key, struct pt_
fs/locks.c
- Drop semaphore when we call fl_notify hooks. This is to allow the
notification routines to call posix_unblock_lock().
- In locks_wake_up_blocks(), drop semaphore when we're asking the
waiter waiter to unblock, and reorder loop to protect against the
waiter disappeari
Hi, Peter,
You can easily remove duplicates in object files without sorting. You
can just use a shell written function.
This is an example of such function (bash written).
It removes the duplicates from the argument and prints the result to
stdout.
No sorting used.
# This function removes duplica
Andrea Arcangeli wrote:
>
> On Mon, Oct 30, 2000 at 03:31:22PM -0600, Steve Pratt/Austin/IBM wrote:
> > [..] no patch ever
> > appeared. [..]
>
> You didn't followed l-k closely enough as the strict fix was submitted two
> times but it got not merged. (maybe because it had an #ifdef __s390__ tha
> Oct 31 12:12:25 mail-client kernel: VM: do_try_to_free_pages failed for
> sendmail
> ...
> Oct 31 12:12:26 mail-client last message repeated 60 times
> Oct 31 12:12:26 mail-client kernel: VM: do_try_to_free_pages failed for
> kupdate.
>
> To agree with Octave, this only appears to happen under l
[Vladislav Malyshkin <[EMAIL PROTECTED]>]
> You can easily remove duplicates in object files without sorting.
> You can just use a shell written function.
This is true. That was something I forgot to mention. I have looked
at that as well, and it strikes me as even more of a hack than the
solu
On Tue, Oct 31, 2000 at 10:23:12AM -0600, Steven Pratt wrote:
> I stand corrected, I missed this is my searching. [..]
Never mind, it's nearly impossible to track every single message to l-k.
It was only informational.
> [..] Hopefully this will
> get in this time.
I hope too indeed :).
Andrea
I believe that this is a precursor to the emerald chipset that Adaptec sold
off to JNI. I've asked JNI whether their drivers would drive it but they did
not deign to answer.
> I looked around for a driver for the Apaptec F940 fibre channel
> card... found nothing so far. It looks like th
On Tue, 31 Oct 2000, Peter Samuelson wrote:
>
> The thing that Keith's patch does is flush these things out into the
> open. By using LINK_FIRST/LINK_LAST, we declare that "these are the
> known issues" -- and then the rest of the objects are reordered, and if
> something breaks, we track it d
On Wed, 1 Nov 2000, Keith Owens wrote:
>
> LINK_FIRST is processed in the order it is specified, so a.o will be
> linked before z.o when both are present. See the patch.
So why don't you do the same thing for obj-y, then?
Why can't you do
LINK_FIRST=$(obj-y)
and be done with it?
Followup to: <[EMAIL PROTECTED]>
By author:Linus Torvalds <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> On Tue, 31 Oct 2000, Peter Samuelson wrote:
> >
> > The thing that Keith's patch does is flush these things out into the
> > open. By using LINK_FIRST/LINK_LAST, we declare that
Personally, I think this fix is less ugly than any of the alternatives I've
seen so far.
It removes the dependency on init order completely, by statically putting
the hub driver into the usb_driver_list at compile time.
Leave the link ordering stuff for 2.5.
Index: drivers/usb//hub.c
> Personally, I think this fix is less ugly than any of the
> alternatives I've seen so far.
>
> It removes the dependency on init order completely, by
> statically putting
> the hub driver into the usb_driver_list at compile time.
>
> Leave the link ordering stuff for 2.5.
David is entitled
Also, the function remove_duplicates can be written using make rules and
functions.
Using functions "foreach" "if" from make and comparison you can easily
build
a function remove_duplicates in make, no shell involved.
so instead of $(sort) your will have $(remove_duplicates)
written entirely in ma
On Tue, Oct 31, 2000 at 02:11:24PM -0200, Rik van Riel wrote:
[PCAC]
> It's a nice idea, but you still want to be sure you won't
> allocate eg. page tables randomly in the middle of the
> PCACs ;)
Yes. That's why we check later, whether our hint is still true.
If we cannot free or move all pages
On Mon, Oct 30, 2000 at 02:23:56PM +0800, Andrey Savochkin wrote:
> > > > Oct 26 16:38:01 ns29 kernel: eth0: card reports no resources.
> > > >
> > > let me guess: intel eepro100 or similar??
> > > Well known problem with that one. dont know if its fully fixed ... With
> >
> > Happens here too,
Ok, how about this approach? It only works for the case where we do not
have the kind of multiple stuff that drivers/net has, but hey, we don't
actually need to handle all the cases right now.
We can leave that for the future, as the configuration process is likely
to change anyway during 2.5.x
Andrea Arcangeli wrote:
>>On Mon, Oct 30, 2000 at 03:31:22PM -0600, Steve Pratt/Austin/IBM wrote:
>> [..] no patch ever
>> appeared. [..]
>
>You didn't followed l-k closely enough as the strict fix was submitted two
>times but it got not merged. (maybe because it had an #ifdef __s390__ that
wa
At line 1073 of ../drivers/char/i2lib.c (2.4.0-test9) we find:
WRITE_LOCK_IRQSAVE(...
this is followed by:
COPY_FROM_USER(...
It seems to me that this could result in a page fault with interrupts
off. Is this ok?
George
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel
> At line 1073 of ../drivers/char/i2lib.c (2.4.0-test9) we find:
>
> WRITE_LOCK_IRQSAVE(...
>
> this is followed by:
>
> COPY_FROM_USER(...
>
> It seems to me that this could result in a page fault with interrupts
> off. Is this ok?
It wont do what you want - it'll re-enable irqs and may the
On Tue, Oct 31, 2000 at 07:42:21PM +0100, [EMAIL PROTECTED] wrote:
> IMO you should apply Steve's patch (without any #ifdef __s390__) now.
Agreed.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at
Followup to: <[EMAIL PROTECTED]>
By author:Linus Torvalds <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> Does anybody see any problems with it? Basically, we're sidestepping the
> sorting, because neither SCSI nor USB need it. Making the problem simpler
> is always good.
>
> Now, th
I have a abit BP6 (I know this board has a bad wrap), but it has always
worked well in the past. I installed a fresh copy of redhat 7. I
tried the redhat 2.4test kernel and complied several of my own
(2.4test9,10preX).
Now I realize, that these are beta kernels, but my PC was always rock
sol
Hello!
> Does kernel 2.4.0-testX(latest) still have this behavior?
Why not to test and to report yet? 8)
It is not supposed to have this behaviour.
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ
I've not been paying attention to this eepro100 issue but
a coworker mentions that she saw a driver (or patch) posted
here back around 6 Sep 2000 by [EMAIL PROTECTED] with
Subject: "Re: eepro100 trouble" that might be of interest.
Also, here's a possibly useless personal note WRT the
eepro100
Dominik Kubla <[EMAIL PROTECTED]> said:
> On Tue, Oct 31, 2000 at 01:38:56PM +, Riley Williams wrote:
> ...
> > Also, part of my plan was to check that the disk is already in this
> > non-standard format, and refuse to dump if not. This would ensure that
> > doing so didn't overwrite somebody'
Alan Cox wrote:
>
> > At line 1073 of ../drivers/char/i2lib.c (2.4.0-test9) we find:
> >
> > WRITE_LOCK_IRQSAVE(...
> >
> > this is followed by:
> >
> > COPY_FROM_USER(...
> >
> > It seems to me that this could result in a page fault with interrupts
> > off. Is this ok?
>
> It wont do what you
Hi:
I reported this to David Hinds, and he said that the PCI messages are
probably important, and I should send this to the lkml.
Details: I am trying to use a Lucent WaveLAN Silver card in a Sony Vaio
PCG-Z505SX. First, I tried 3.1.21 (with kernel pcmcia turned off).
When the machine boots,
"H. Peter Anvin" <[EMAIL PROTECTED]> said:
[...]
> Sounds like what you actually need is LINK_BEFORE() LINK_AFTER() and a
> topological sort.
Was suggested before, and shot down by Linus himself...
tsort(1) et al come handy.
--
Dr. Horst H. von Brand mailto:[EMAIL PROTE
Hi!
> > > This is putrid. NetWare does 353,00,000/second on a Xenon, pumping out
> > > gobs of packets in between them. MANOS does 857,000,000/second. This
> > > is terrible. No wonder it's so f_cking slow!!!
>
> And please check your numbers, 857 million
> > context switches per second means th
Hi!
> > TUX modules are kernel modules (I mean you have to write kernel space code for
> > doing TUX ftp). Don't you agree that zero-copy sendfile like ftp serving would
> > be able to perform equally well too?
>
> For this to bw useful for ftp we need a sendfile() that can write from a
> socket
Ingo Molnar wrote:
>
> On Mon, 30 Oct 2000, Jeff V. Merkey wrote:
>
>
> All i did was to inform you that the next release of TUX is imminent and
> that you might want to take a look at the new code. You interpreted that
> in a very interesting way.
I seem to remember a "don't post this emai
Pavel Machek wrote:
>
> Hi!
>
> > > > This is putrid. NetWare does 353,00,000/second on a Xenon, pumping out
> > > > gobs of packets in between them. MANOS does 857,000,000/second. This
> > > > is terrible. No wonder it's so f_cking slow!!!
> >
> > And please check your numbers, 857 million
>
When I'm following this thread, you guys seem to forget the _basics_:
The Linux networking stack sucks!
Everybody tries to work around the networking stack. We just recently
developped a rpc protocol which makes 180MBytes/second (over a Quadrics
Network) because the linux network layer was way to
On Tue, 31 Oct 2000, Jeff V. Merkey wrote:
> It relies on an anomoly in the design of Intel's cache controllers,
> and with memory based applications, I can get 120% scaling per
> procesoor by jugling the working set of executable code cached accros
> each processor. There's sample code with th
"Jeff V. Merkey" wrote:
>
> Pavel Machek wrote:
> >
> > Hi!
> >
> > > > > This is putrid. NetWare does 353,00,000/second on a Xenon, pumping out
> > > > > gobs of packets in between them. MANOS does 857,000,000/second. This
> > > > > is terrible. No wonder it's so f_cking slow!!!
> > >
> > > An
Dr. Horst H. von Brand writes:
> Dominik Kubla <[EMAIL PROTECTED]> said:
> > On Tue, Oct 31, 2000 at 01:38:56PM +, Riley Williams wrote:
> > ...
> > > Also, part of my plan was to check that the disk is already in this
> > > non-standard format, and refuse to dump if not. This would ensure tha
On Tue, 31 Oct 2000, Pavel Machek wrote:
> > Excuse me, 857,000,000 instructions executed and 460,000,000
> > context switches a second -- on a PII system at 350 Mhz. [...]
> That's more than one context switch per clock. I do not think so.
> Really go and check those numbers.
yep, you cannot
> Why not solve the problem at the source and completely redesign the
> network stack? Get rid of the old sk_buff & co! Rip the whole network
> layer out! Redesign it and give the user a possibility of Zero-Copy
> networking!
For one because you don't need to do that to get zero copy networking f
Alan Cox wrote:
>
> > Why not solve the problem at the source and completely redesign the
> > network stack? Get rid of the old sk_buff & co! Rip the whole network
> > layer out! Redesign it and give the user a possibility of Zero-Copy
> > networking!
>
> For one because you don't need to do tha
On Tue, 31 Oct 2000, Reto Baettig wrote:
> When I'm following this thread, you guys seem to forget the
> _basics_: The Linux networking stack sucks!
Ummm, last I looked Linux held the Specweb99 record;
by a wide margin...
Rik
--
"What you're running that piece of shit Gnome?!?!"
-- Migue
> And what if I'd like to use the network for something different than
> html?
Read the tux source. Then come back and ask sensible questions
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www
After talking with two members of the list, here is the latest situation.
I was having major problems upgrading to .17, having it crash immediately
on boot. Yesterday due to frustration I wound up setting MEM=900 (as per
Alan Cox's suggestion) and keeping .15 running.. this seemed to be working
Ok, test10-final is out there now. This has no _known_ bugs that I
consider show-stoppers, for what it's worth.
And when I don't know of a bug, it doesn't exist. Let us rejoice. In
traditional kernel naming tradition, this kernel hereby gets anointed as
one of the "greased weasel" kernel series,
> "sublinear scaling",
^-- extralinear. whatever.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
On Tue, 31 Oct 2000, Linus Torvalds wrote:
> Ok, test10-final is out there now. This has no _known_ bugs that
> I consider show-stoppers, for what it's worth.
>
> And when I don't know of a bug, it doesn't exist. Let us
> rejoice. In traditional kernel naming tradition, this kernel
> hereby gets
- Received message begins Here -
>
> > And what if I'd like to use the network for something different than
> > html?
>
> Read the tux source. Then come back and ask sensible questions
Also pay attention to the security aspects of a true "zero copy" TCP stack.
It means that S
Rik van Riel wrote:
> Ummm, last I looked Linux held the Specweb99 record;
> by a wide margin...
...does that remove any memory copies???
To be best does not mean that there's no place for improvment.
Can anybody please help me and tell me where to start understanding what
tux does?
www.tux.or
1 - 100 of 218 matches
Mail list logo
