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
Rik van Riel wrote:
>
> 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...
>
It doesn't hold the file and
On Tue, 31 Oct 2000, Rik van Riel wrote:
>
>Ummm, last I looked Linux held the Specweb99 record;
>by a wide margin...
>
... but since then IBM/Zeus appear to have taken the lead:
http://www.zeus.com/news/articles/001004-001/
http://www.spec.org/osg/web99/results/res2000q3/
But they were using
> Check your logs and see if their is a speed setting
> block issued, only if
> you are using patched 2.2x or 2.4.0x kernels will
> this report be
> generated.
I haven't been able to recover anything from the root
fs as of yet. If I do; I will check the logs.
> > Before, on a 40-conductor
> Question - is hardware APM suspend supported in any current available
> kernel/apmd? I ask this because when I press the power button on my
> computer, which is supposed to do a hardware suspend (according to my
> BIOS) and I'm in X, the screen basically turns to garbage and I can't do
>
On Tue, 31 Oct 2000, Reto Baettig wrote:
> Rik van Riel wrote:
> > Ummm, last I looked Linux held the Specweb99 record;
> > by a wide margin...
>
> ...does that remove any memory copies???
> I don't want to make linux bad or stand on anybodys toes.
Good to know, your previous message might
On Tue, 31 Oct 2000 05:59:59 -0600, Peter Samuelson
<[EMAIL PROTECTED]> wrote:
>
>[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
Question - is hardware APM suspend supported in any current available
kernel/apmd? I ask this because when I press the power button on my
computer, which is supposed to do a hardware suspend (according to my
BIOS) and I'm in X, the screen basically turns to garbage and I can't do
anything except
On Tue, 31 Oct 2000, Russell King wrote:
> Linus Torvalds writes:
> > 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
On Tue, 31 Oct 2000, Rik van Riel wrote:
> 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
> Also pay attention to the security aspects of a true "zero copy" TCP stack.
> It means that SOMETIMES a user buffer will recieve data that is destined
> for a different process.
The moment you try and do zero copy like that you end up playing so many MMU
games the copy is faster. We do zero
Linus Torvalds writes:
> 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
>
>
> how much memory you have, is there any patch I can put into a 2.2.x kernel
> or a program to run after bootup to find out the max MEM= setting which is
> appropriate, without having to do blind tests changing the amount until it
> crashes?
There is a patch for E820 memory detection that Orc
> Ok, test10-final is out there now. This has no _known_ bugs that I
> consider show-stoppers, for what it's worth.
The fact power management even handling is completely broken and crashes
on unfortunately timed module unloads doesnt count ?
More importantly has the bug when you can use the
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?
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
- 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
> "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/
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
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
> 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
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?!?!"
--
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
> 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
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
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
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
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
"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!!!
> > >
> > >
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
>
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
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
>
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
"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
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,
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
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
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
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
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
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,
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 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
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
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
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
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
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
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
> 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
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
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
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?
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
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
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 :).
[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
> 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
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__
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
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
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
> >
> >
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
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
> >
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
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; /*
(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
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
>
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
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, 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:
"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
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.
> > 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
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
> 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
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
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() --
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.
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
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
-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
>
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
>
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
[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
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
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
[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
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
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
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
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
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)
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
[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
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]
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:
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
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
101 - 200 of 421 matches
Mail list logo
