Hi all,
this patch fixes bug in pnpbios_rawdata_2_pci_dev() - miscalculated length of
ioport range. This function uses word at offset 6 in I/O Port Descriptor,
but according to ISA PnP specification ioport range length is a byte at offset 7
and byte 6 is base alignment.
BTW will it usefull to
I get this oops while booting 2.4.7-pre9:
Jul 20 08:01:52 hafnium kernel: Unable to handle kernel NULL pointer dereference at
virtual address 007c
Jul 20 08:01:52 hafnium kernel: c01467e3
Jul 20 08:01:52 hafnium kernel: *pde =
Jul 20 08:01:52 hafnium kernel: Oops:
Jul 20
> This patch fixes a failure in the scc.c driver to properly allocate the
I/O
> region for the interrupt vector latch, which is present on some ham radio
> SCC cards, such as the PA0HZP card.
>
> Rob Turk - PE1KOX
>
After receiving a few hints that uu-encoded messages are 'not done', here's
the
Problem solved.
This is one top output:
5:47pm up 21 min, 2 users, load average: 0.99, 0.70, 0.48
110 processes: 109 sleeping, 1 running, 0 zombie, 0 stopped
CPU0 states: 0.1% user, 2.4% system, 0.0% nice, 96.4% idle
CPU1 states: 0.1% user, 5.4% system, 0.0% nice, 93.5% idle
Mem:
I'm getting ready to do a 2.4.7, but one of the fixes in 2.4.7 is a nasty
SMP race that was found and made it clear that using an old trick of
having a semaphore on the stack and doing "down()" on it to wait for some
event (that would do the "up()") was a really bad idea.
This kind of trick was
gcc -D__KERNEL__ -I/usr/src/linux-2.4.6/include -Wall -Wstrict-prototypes
-Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common
-pipe -mpreferred-stack-boundary=2 -march=i686 -DMODULE -c -o apm.o apm.c
{standard input}: Assembler messages:
{standard input}:188: Warning:
Followup to: <[EMAIL PROTECTED]>
By author:David Woodhouse <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> It has been stated many times that kernel headers should not be used in
> apps. Renaming or moving them should not be necessary - and people would
> probably only start to use
> /usr/src/linux-2.4.6/include/linux/mtd/cfi.h: In function `cfi_spin_unlock':
> /usr/src/linux-2.4.6/include/linux/mtd/cfi.h:387: `do_softirq' undeclared
> (first use in this function)
> /usr/src/linux-2.4.6/include/linux/mtd/cfi.h:387: (Each undeclared identifier
> is reported only once
>
nfsroot uses bogus protocol version when it asks portmapper on
server for mountd port. Fix is obvious:
--- linux/fs/nfs/nfsroot.cFri Feb 16 18:56:03 2001
+++ linux/fs/nfs/nfsroot.c.new Thu Jul 19 23:55:09 2001
@@ -418,7 +418,7 @@
"as nfsd port\n", port);
gcc -D__KERNEL__ -I/usr/src/linux-2.4.6/include -Wall -Wstrict-prototypes
-Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common
-pipe -mpreferred-stack-boundary=2 -march=i686 -DMODULE -c -o cfi_probe.o
cfi_probe.c
In file included from cfi_probe.c:17:
Jens,
Remember several weeks ago when I mentioned a problem w/ ridicyulous
mod-use counts w/ loop.o???
Well, it's back again 2.4.5-ac19 (IIRC) worked fine.
Basically, the result of attempting sudo losetup -d /dev/loop0 is the
following
ioctl LOOP_CLR_FD Device or resource busy
strace shows
At 03:58 20/07/2001, Anton Altaparmakov wrote:
>This is clearly not my day for sending emails...
>
>Sorry. The attachment was fine on last email but a little misunderstanding
>between elm and myself resulted in the invention of two non-existent email
>addresses and put them in the To: field.
This is clearly not my day for sending emails...
Sorry. The attachment was fine on last email but a little misunderstanding
between elm and myself resulted in the invention of two non-existent email
addresses and put them in the To: field. )-: Just remove them before
replying... They are
>Groan< The "unregister_netdevice" bug is back.
I haven't been able to do extensive testing, but I have
just encountered the message
unregister_netdevice: waiting for eth0 to become free. Usage count = 2
again. Once it starts, it repeats ad infinitum, once per second.
The message starts
Sorry for confusion. Here goes again, sent with elm, and tested for being
clear text inline and that white space is not mangled.
-
Linus,
Please consider attached patch. It does three things:
- Adds docbook style comments to a very few functions relating to the page
cache
At 3:03 AM +0100 2001-07-20, Anton Altaparmakov wrote:
>I do appologize. I didn't realize pine would do this. In pine I can just
>read the attachment as text and in Eudora it just appears as inlined
>text without any indication of it being a separate attachment, so I just
>assumed that it was
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 Thu, 19 Jul 2001, Pete Zaitcev wrote:
> > This message is in MIME format. The first part should be readable text,
> > while the remaining parts are likely unreadable without MIME-aware tools.
>
> Quite so. Linus told you many times not to send patches
> in MIME and I happen to agree.
>
[EMAIL PROTECTED] said:
> works fine thanks! Of course I agree with rmk it would be better not
> to disable -fno-common but this is ok for now ;)
Yeah, it's temporary. rmk's idea was to use the link script to toss errno.o
out of the final binary.
> (after all we would
> catch any potential
On Thu, Jul 19, 2001 at 06:45:38PM -0400, Jeff Dike wrote:
> > Only in 2.4.7pre6aa1: 51_uml-ac-to-aa-2.bz2
> > Only in 2.4.7pre8aa1/: 51_uml-ac-to-aa-3.bz2
> > Moved part of it in the tux directory so it can compile
> > without tux (in reality I got errno compilation error
> >
> This message is in MIME format. The first part should be readable text,
> while the remaining parts are likely unreadable without MIME-aware tools.
Quite so. Linus told you many times not to send patches
in MIME and I happen to agree.
> Content-Type: TEXT/PLAIN; charset=US-ASCII;
Linus,
Please consider attached patch. It does three things:
- Adds docbook style comments to a very few functions relating to the page
cache (mm/filemap.c) and does very minor clean up on those to keep within
80 character wide lines (only look affected).
- Minor cleanup making the
On Sunday 15 July 2001 20:22, Albert D. Cahalan wrote:
> An extra 4 bits buys us 6 years maybe. Nice, except that we
> already have people complaining. Maybe somebody remembers when
> the complaining started.
I blame Charles Babbage, myself...
As for the scalable block numbers, assuming
On Thu, 19 Jul 2001 15:54:00 -0600,
"Peter J. Braam" <[EMAIL PROTECTED]> wrote:
>I'm trying to export a symbol (journal_begin/end) from
>fs/reiserfs/journal.c. To export the symbols I added to the Makefile:
>export-objs := journal.o
>
>There is also a file fs/jbd/journal.c which exports symbols.
hi,
On Jul 19, 5:04pm, Poul Petersen wrote:
> Subject: Oops (NULL pointer dereference) with 2.4.5+xfs-1.0.1
> I'm running RedHat 7.1 with the manually patched 2.4.5 kernel and
> xfs-1.0.1 on a dual PII (400) with 1 Gig of RAM. The XFS filesystems are
> located on a SAN RAID device
On Thu, Jul 19, 2001 at 07:38:15PM -0500, Tad Dolphay wrote:
> I know there was a fix for a "Busy inodes after unmount" problem in
> 2.4.6-pre3. Here's an excerpt from a posting to the NFS mailing list
> from Neil Brown:
Thanks. I'll try that and see if that solves the problem (also the XFS
UUID
In file included from cfi_probe.c:17:
/usr/src/linux-2.4.6/include/linux/mtd/cfi.h: In function `cfi_spin_unlock':
/usr/src/linux-2.4.6/include/linux/mtd/cfi.h:387: `do_softirq' undeclared
(first use in this function)
/usr/src/linux-2.4.6/include/linux/mtd/cfi.h:387: (Each undeclared identifier
I know there was a fix for a "Busy inodes after unmount" problem in
2.4.6-pre3. Here's an excerpt from a posting to the NFS mailing list
from Neil Brown:
-Included message---
Previously anonymous dentries were hashed (though with no name, the
hash was pretty
I'm running RedHat 7.1 with the manually patched 2.4.5 kernel and
xfs-1.0.1 on a dual PII (400) with 1 Gig of RAM. The XFS filesystems are
located on a SAN RAID device accessed through a qlogic 2100 Fibre Channel
card (using the qla2x00 module provided by Qlogic, ver 4.25). This system
I reported this a couple of months back. It's reassuring to know that it's a
consistent problem.
On Fri, 20 Jul 2001, [iso-8859-1] Ragnar Kjørstad wrote:
> On Thu, Jul 19, 2001 at 04:22:07PM -0400, Christian, Chip wrote:
> > I found the same thing happening. Tracked it down in our case to
On Thu, Jul 19, 2001 at 04:22:07PM -0400, Christian, Chip wrote:
> I found the same thing happening. Tracked it down in our case to using fdisk to
>re-read disk size before mounting. Replaced it with "blockdev --readpt" and the
>problem seems to have gone away. YMMV.
I've now been able to
> Only in 2.4.7pre6aa1: 51_uml-ac-to-aa-2.bz2
> Only in 2.4.7pre8aa1/: 51_uml-ac-to-aa-3.bz2
> Moved part of it in the tux directory so it can compile
> without tux (in reality I got errno compilation error
> but it's low prio and I'll sort it out later, Jeff Dike any
>
Hey, I'm having trouble applying your first patch to kernel 2.4.6. I have a
list of 18 failed hunks.
The command I used is: cd /usr/src/linux && patch -Np0 -i
/home/arch/pppoe-davidmiller.patch Is the patch for a different kernel? I
had the same problem applying it to 2.4.7-pre8.
Andrew
On Fri, 20 Jul 2001, Julian Anastasov wrote:
>
> My understanding was that eax, ... edx are declared as
> local vars and so their values can't be used out of the current
> function scope, even when they are defined in inline func.
Yes, but notice how we return a value.
And the only way
Julian Anastasov wrote:
>
> Hello,
>
> On Thu, 19 Jul 2001, Linus Torvalds wrote:
>
> > No. It's correct, because cpuid doesn't have any side effects (*), so we
> > don't need to mark it volatile. gcc is free to remove it if nothing uses
> > the outputs, for example. But gcc cannot
Hello,
On Thu, 19 Jul 2001, Linus Torvalds wrote:
> No. It's correct, because cpuid doesn't have any side effects (*), so we
> don't need to mark it volatile. gcc is free to remove it if nothing uses
> the outputs, for example. But gcc cannot (and generally does not) ignore
> outputs
Michal Ostrowski writes:
> Alexey replied to my last post with some valuable comments and in
> response I have a new patch (that goes on top of David Miller's patch
> from yesterday).
Applied to my tree, thanks.
Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send
Julian Anastasov wrote:
>
> Hello,
>
> On Thu, 19 Jul 2001, H. Peter Anvin wrote:
>
> > Julian Anastasov wrote:
> > >
> > > What I want to say (I could be wrong and that can't surprise me) is
> > > that the original cpuid_eax is in fact incorrect. All cpuid_XXX funcs
> > > use only
Hello,
this patch was inspired by the Stanford checker (the report was sent out a
while ago, but I'm just getting around to submitting the patch).
They pointed out two instances of dereferencing potentially NULL pointers
in the UFS code, one of which was valid, and the other was incorrect (so
Hello,
On Thu, 19 Jul 2001, H. Peter Anvin wrote:
> Julian Anastasov wrote:
> >
> > What I want to say (I could be wrong and that can't surprise me) is
> > that the original cpuid_eax is in fact incorrect. All cpuid_XXX funcs
> > use only dummy output operands...
> >
>
> Bullsh*t. One
On Fri, 20 Jul 2001, Julian Anastasov wrote:
>
> In my distro (now with gcc 2.96) I have a gcc info with name "Extended
> Asm", "Assembler Instructions with C Expression Operands" with the
> following text:
[ yes ]
> What I want to say (I could be wrong and that can't surprise me) is
> that
Julian Anastasov wrote:
>
> What I want to say (I could be wrong and that can't surprise me) is
> that the original cpuid_eax is in fact incorrect. All cpuid_XXX funcs
> use only dummy output operands...
>
Bullsh*t. One of the output operands is always a non-dummy (in
cpuid_edx() edx is not a
Hello,
> > kernel files that volatile solves gcc bugs. The question is whether
> > the volatile is needed only as a work-around or it is needed in this
> > case particulary, i.e. where the output registers are not used and are
> > optimized.
> >
>
> It certainly shouldn't; obviously,
> It looks like the 2.4.6-ac5 fixed the deadlock feature with ASUS A7V133
> mobo. It's been running stable for over 24 hours now. VIA and Promise IDE
> controllers are in use.
Excellent. I hope soon to push the official via fix to Linus. The other good
news is that I now have some official VIA
> Any ideas when this thing will be fixed in the kernel?
The buz driver is obsolete. Use a -ac kernel or 2.4.7pre if you need buz
support
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
I'm trying to export a symbol (journal_begin/end) from
fs/reiserfs/journal.c. To export the symbols I added to the Makefile:
export-objs := journal.o
There is also a file fs/jbd/journal.c which exports symbols.
It seems that the two journal.ver files in include/modules/*.ver get
clobbered.
[EMAIL PROTECTED] said:
> If you do not want kernel headers to be used in apps, just move them
> from asm and linux into msa and xunil. Then you can simple remove all
> #ifdef __KERNEL__ from them...
It has been stated many times that kernel headers should not be used in
apps. Renaming or
Hi.
The following patch makes drivers/net/tokenring/ibmtr.c
call iounmap before it returns on error paths, makes it
not use check_region(), makes it check the return
of request_region and init_trdev and adds a few comment
strings on #endifs.
It applies against 246ac5 and my writing this patch
This patch fixes a failure in the scc.c driver to properly allocate the I/O
region for the interrupt vector latch, which is present on some ham radio
SCC cards, such as the PA0HZP card.
Rob Turk - PE1KOX
begin 666 scc_vec.patch
just fyi, 2.4.7-pre8 did not cure the problem.
i was able to reproduce the problem like before.
this time, i switched to the log console before locking the machine
up, and the oops is in fact identical to the one christian was
seeing.
the last line says "In interrupt handler - not syncing." which
Hi!
> > I did NOT verified other callers of acpi_walk_namespace... And there
> > is still some problem left, as although now S5 is listed as available,
> > poweroff still does nothing instead of poweroff.
>
> Replying to myself, after following change in additon to acpi_ex_...
> poweroff on
Hi!
> There are still a lot of help texts missing from Configure.help,
> CONFIG_AIC7_BUILD_FIRMWARE to name just one example.
>
> I'm pretty annoyed by RELEASE versions that don't have all options
> documented. If a module doesn't come with proper documentation for all
> its options, drop
On Thu, Jul 19, 2001 at 03:24:09PM -0400, Ryan C. Bonham wrote:
> I get the following messages, I will paste dmesg.log at the bottom if you
> want to see it..
> mtrr: your CPUs had inconsistent fixed MTRR settings
> mtrr: probably your BIOS does not setup all CPUs
>
>From what i gather that
Ok,
I am fairly inept when it comes to kernel and what the messages mean, I was
wondering if someone would explain a few messages to me.. I just compiled
the 2.4.6 kernel on a new computer with the Tyan Thunder K7 and 2 1.2Ghz AMD
Athlon MP CPUs, I have 1 GB of DDRAM in this computer.. I also am
Alexey replied to my last post with some valuable comments and in
response I have a new patch (that goes on top of David Miller's patch
from yesterday).
The approach here is that in case we don't have room in the skb for
PPPoE headers, we create a new one (skb2) and copy the entire thing.
If we
Diff between 2.4.7pre6aa1 and 2.4.7pre8aa1 (besides moving on top
of 2.4.7pre8).
Only in 2.4.7pre8aa1/: 00_do_swap_page-fix-1
Account major faults for swapins. (from -ac)
Only in 2.4.7pre6aa1: 00_drop_async-io-get_bh-1
Only in 2.4.7pre8aa1/: 00_drop_async-io-get_bh-2
Rediffed
Followup to:
By author:Julian Anastasov <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> This patch works for me too (I checked all cpuid_XXX calls).
> After some thinking I produced another patch. The interesting part is
> that __volatile__ solves the problem. Patch appended.
On Thu, Jul 19, 2001 at 07:21:48PM +, Petr Vandrovec wrote:
> Maybe because of I do not know ARM assembler? If you do not want
> kernel headers to be used in apps, just move them from asm and linux
> into msa and xunil. Then you can simple remove all #ifdef __KERNEL__
> from them...
Why
Hello!
> However, could we not have dev_queue_xmit behave as such (not free
> frame on failure)?
If you need to hold original skb, you may hold its refcnt.
However, this feature inevitably results in big troubles: dev_queue_xmit()
is allowed to change skb and you cannot assume anything about
Trond Myklebust wrote:
>
> > " " == Chris Mason <[EMAIL PROTECTED]> writes:
>
> > Well, returning the last filename won't do much for filesystems
> > that don't have any directory indexes, but that's besides the
> > point. Could nfsv4 be better than it is? probably. Can we
[EMAIL PROTECTED] writes:
> Hello!
>
> SOme short comment on the patch:
>
>
> > - dev_queue_xmit(skb);
> > + /* The skb we are to transmit may be a copy (see above). If
> > +* this fails, then the caller is responsible for the original
> > +* skb, otherwise we must free it. Also
On Thu, Jul 19, 2001 at 07:33:02PM +0200, Andi Kleen wrote:
> Cornel Ciocirlan <[EMAIL PROTECTED]> writes:
>
> > Hi,
> >
> > I was thinking of starting a project to implement a Cisco-like
> > "NetFlow" architecture for Linux. This would be relevant for edge routers
> > and/or network
Linus Torvalds writes:
>
> On Thu, 19 Jul 2001, Richard Gooch wrote:
> > Linus Torvalds writes:
> > > Note that the unfair aging (apart from just being a natural
> > > requirement of higher allocation pressure) actually has some other
> > > advantages too: it ends up being aload balancing thing.
Cornel Ciocirlan <[EMAIL PROTECTED]> writes:
> Hi,
>
> I was thinking of starting a project to implement a Cisco-like
> "NetFlow" architecture for Linux. This would be relevant for edge routers
> and/or network monitoring devices.
Linux 2.1+ already has such a cache in form of the rtcache
On Thu, 19 Jul 2001, Linus Torvalds wrote:
> Note that the unfair aging (apart from just being a natural requirement of
> higher allocation pressure) actually has some other advantages too: it
> ends up being aload balancing thing. Sure, it might throw out some things
> that get "unfairly"
On Thu, Jul 19, 2001 at 06:44:52PM +0300, Cornel Ciocirlan wrote:
> What this would do is keep a "cache" of all the "flows" that are passing
> through the system; a flow is defined as the set of packets that have the
> same headers - or header fields. For example we could choose "ip source,
> ip
Hello!
SOme short comment on the patch:
> - dev_queue_xmit(skb);
> + /* The skb we are to transmit may be a copy (see above). If
> + * this fails, then the caller is responsible for the original
> + * skb, otherwise we must free it. Also if this fails we must
> + *
Cornel Ciocirlan <[EMAIL PROTECTED]> ecrit :
[heavy linux networking rewrite in sight]
> Is it useful at all ? Point b) above could be implemented in userspace
> (Actually I've done a basic skeleton a while ago). Are the others worth
> the trouble ?
>
> What do you gurus think ?
* Are you sure
On Thu, 19 Jul 2001, Richard Gooch wrote:
> Linus Torvalds writes:
> > Note that the unfair aging (apart from just being a natural
> > requirement of higher allocation pressure) actually has some other
> > advantages too: it ends up being aload balancing thing. Sure, it
> > might throw out some
On 19 Jul 01 at 12:48, Russell King wrote:
>
> I totally disagree here. We already say "user space should not include
> kernel headers". Why should bitops.h be any different? Why should atomic.h
> be any different? They contain architecture specific code, yes, which
> may not work in user
On Thu, 19 Jul 2001, Marcelo Tosatti wrote:
>
> Well, here is a patch on top of -ac5 (which already includes the first
> zoned based approach patch).
Looks ok.
I'd like to see what the patch looks on top of a virgin tree, as it should
now be noticeably smaller (no need to pas extra parameters
Linus Torvalds writes:
> Note that the unfair aging (apart from just being a natural
> requirement of higher allocation pressure) actually has some other
> advantages too: it ends up being aload balancing thing. Sure, it
> might throw out some things that get "unfairly" treated, but once we
>
On 17-Jul-2001 Hubertus Franke wrote:
>
>
> This only applies only to the idle thread and it says that the idle
> thread actively monitors its need_resched flag and hence will
> instantly call schedule() at that point. Hence there won't be any
> delay either for IPI or for waiting to return
Wilfried Weissmann wrote:
>
> Just for curiosity, do you have those messages in our logfiles:
>
> eth0: Transmit error, Tx status register 82.
That's a 3com message, not natsemi.
And it's such a common error that it is now specially detected in the
driver:
if (tx_status == 0x82)
On Thu, 19 Jul 2001, Rik van Riel wrote:
>
> On Wed, 18 Jul 2001, Marcelo Tosatti wrote:
>
> > Still able to trigger the problem with the GFP_HIGHUSER patch applied.
>
> Hrrm, maybe the fact that the free target in the DMA zone is
> four times higher than in the other zones has something to do
>
"Kevin P. Fleming" wrote:
>
> I upgraded two machines here from 2.4.7-pre6 to 2.4.7-pre7 yesterday
> afternoon.
>
> The first machine I upgraded, my workstation, is a 1GHz Athlon on a VIA
> KT133 (not A) motherboard using a NetGear FA312TX network card. This machine
> has always run Linux just
[christian, i'm quoting a message of yours below. maybe this is of
interest to you, so i'm cc:ing]
Thomas wrote:
>
> Jörn Nettingsmeier wrote:
>
> > hello brad, hello netfilter people !
> > Brad Chapman wrote:
> >
> >>Were you able to rescue any console output from the hard
> >> lockup;
>
++ 19/07/01 18:44 +0300 - Cornel Ciocirlan:
> a) more efficient packet filtering. After a cache entry is created for a
> flow, we apply the ACLs for the packet and associate the action with the
> flow. All subsequent packets belonging to the same flow will be
> dropped/accepted without
On Thursday 19 July 2001 01:42, Daniel Phillips wrote:
> Yes. The inactive shortage needs to be a function of the length of
> the inactive_dirty queue rather than just the amount that free pages
> is less than some fixed minimum.
Oops, it already is, good :-]
> The target length of the
>
> On Thursday 19 July 2001 06:26 am, Wakko Warner wrote:
> > I'm using a kernel that is dd'd to a floppy to net boot linux on random
> > machines. I noticed that 2.4.6 won't get it's IP from the server (it won't
> > even attempt it). 2.4.4 works
> >
> > If any more info is needed, just ask.
>
> > I'm using a kernel that is dd'd to a floppy to net boot linux on random
> > machines. I noticed that 2.4.6 won't get it's IP from the server (it won't
> > even attempt it). 2.4.4 works
> >
> > If any more info is needed, just ask.
>
> It sounds as though you left out CONFIG_IP_PNP in the
I upgraded two machines here from 2.4.7-pre6 to 2.4.7-pre7 yesterday
afternoon.
The first machine I upgraded, my workstation, is a 1GHz Athlon on a VIA
KT133 (not A) motherboard using a NetGear FA312TX network card. This machine
has always run Linux just fine. After this upgrade, telnetting to
On Thursday 19 July 2001 06:26 am, Wakko Warner wrote:
> I'm using a kernel that is dd'd to a floppy to net boot linux on random
> machines. I noticed that 2.4.6 won't get it's IP from the server (it won't
> even attempt it). 2.4.4 works
>
> If any more info is needed, just ask.
Sine 2.4.4 I
Hello linux-kernel,
I'm trying to get stable running kernel from 2.4 series for about 3
months now, I thought it should become stable up to this time but it
still not at least in VM area.
I'm Testing various kernels from Linus, Alan, Andrea as well as
some other patches provided but
On Thu, Jul 19, 2001 at 12:02:59PM +1000, Steve Kieu wrote:
> --- Erik Mouw <[EMAIL PROTECTED]> wrote: > On
> > FUD. I've been using reiserfs on quite some systems
>
> Probably !. I said just from my computer, :-)
>
> Reiserfs uses system resources more than others.
> Perfomance is ok (not as
Hi,
I was thinking of starting a project to implement a Cisco-like
"NetFlow" architecture for Linux. This would be relevant for edge routers
and/or network monitoring devices.
What this would do is keep a "cache" of all the "flows" that are passing
through the system; a flow is defined as
Edouard Soriano wrote:
>
> Hello Folks,
>
> Environment: linux 2.2.16smp
> RedHat 7.0
> My problem are the 63892K
If you upgrade to the 2.2.19 kernel, this will just work,
no need for extra options. (Red Hat also has a 2.2.19 kernel
available as errata release for 7.0)
-
To unsubscribe from
Hi,
I'm running a dual PIII, 3GB box (2.4.0.SuSE and 2.4.4.SuSE) getting the error
above, despite the fact the ~700MB are still available. In conjunction w/ the
log message I get fork failures (out of memory)...
I'm running 5500 processes having devices open and doing IP. Many of the
processes
On Thu, 19 Jul 2001, Wakko Warner wrote:
> I'm using a kernel that is dd'd to a floppy to net boot linux on random
> machines. I noticed that 2.4.6 won't get it's IP from the server (it won't
> even attempt it). 2.4.4 works
>
> If any more info is needed, just ask.
It sounds as though you
Edouard Soriano <[EMAIL PROTECTED]> wrote:
> I remember there is a solution to turn around this problem forcing LILO to
> configure 1GB saying, I think but not sure:
>
> append='memory=1024'
>
> I searched in the lilo doc for memory parameter definition, but as being
> coverd by append
Add this:
append="mem=1024M"
to your lilo boot profiles.
... 2.4 correctly detects memory size more often than 2.2.16 ...
- Original Message -
From: "Edouard Soriano" <[EMAIL PROTECTED]>
Subject: 1GB system working with 64MB
> Hello Folks,
> Environment: linux 2.2.16smp
> RedHat
Hello Folks,
Environment: linux 2.2.16smp
RedHat 7.0
I am setting up a system with 1GB RAM recongized by the
BIOS during power-on procedure.
This system having troubles, I set a top command and
with surprise I got this status:
4:33pm up 4:42, 3 users, load average: 4.18, 2.01, 1.09
125
Hello Folks,
Environment: linux 2.2.16smp
RedHat 7.0
I am setting up a system with 1GB RAM recongized by the
BIOS during power-on procedure.
This system having troubles, I set a top command and
with surprise I got this status:
4:33pm up 4:42, 3 users, load average: 4.18, 2.01, 1.09
125
Add this:
append=mem=1024M
to your lilo boot profiles.
... 2.4 correctly detects memory size more often than 2.2.16 ...
- Original Message -
From: Edouard Soriano [EMAIL PROTECTED]
Subject: 1GB system working with 64MB
Hello Folks,
Environment: linux 2.2.16smp
RedHat 7.0
My
Edouard Soriano [EMAIL PROTECTED] wrote:
I remember there is a solution to turn around this problem forcing LILO to
configure 1GB saying, I think but not sure:
append='memory=1024'
I searched in the lilo doc for memory parameter definition, but as being
coverd by append parameter I found
On Thu, 19 Jul 2001, Wakko Warner wrote:
I'm using a kernel that is dd'd to a floppy to net boot linux on random
machines. I noticed that 2.4.6 won't get it's IP from the server (it won't
even attempt it). 2.4.4 works
If any more info is needed, just ask.
It sounds as though you left
Hi,
I'm running a dual PIII, 3GB box (2.4.0.SuSE and 2.4.4.SuSE) getting the error
above, despite the fact the ~700MB are still available. In conjunction w/ the
log message I get fork failures (out of memory)...
I'm running 5500 processes having devices open and doing IP. Many of the
processes
Edouard Soriano wrote:
Hello Folks,
Environment: linux 2.2.16smp
RedHat 7.0
My problem are the 63892K
If you upgrade to the 2.2.19 kernel, this will just work,
no need for extra options. (Red Hat also has a 2.2.19 kernel
available as errata release for 7.0)
-
To unsubscribe from this
Hi,
I was thinking of starting a project to implement a Cisco-like
NetFlow architecture for Linux. This would be relevant for edge routers
and/or network monitoring devices.
What this would do is keep a cache of all the flows that are passing
through the system; a flow is defined as the set
On Thu, Jul 19, 2001 at 12:02:59PM +1000, Steve Kieu wrote:
--- Erik Mouw [EMAIL PROTECTED] wrote: On
FUD. I've been using reiserfs on quite some systems
Probably !. I said just from my computer, :-)
Reiserfs uses system resources more than others.
Perfomance is ok (not as far more or
1 - 100 of 184 matches
Mail list logo
