In mailing-lists.linux-kernel, you wrote:
> We've noticed the following kernel error since 2.4 (2.4.1-2.4.6).
> It appears to be swap (kswapd thread specific?) related. The same
> error is reported on several SMP machines after only a short period
> (an hour or less).
FYI, I see a similar probl
In mailing-lists.linux-kernel, you wrote:
> I have discovered that while running 2.4.6pre5, the kernel does not
> see all available RAM - I have 1GB and the kernel only sees ~899MB.
The 1GB memory option in the kernel configuration is really the 896MB
memory option. So for more than 896MB, you
em since early 2.4, when I was not
running MOSIX, and I have confirmed that the slowdown problem does occur
under plain 2.4.5 with mem=1G.
I'd be happy to provide any additional information or test any patches.
Cheers,
Wayne
[whitney@mf1 whitney]$ diff -u --unified=1000 /tmp/tulip.diag.{bad
In mailing-lists.linux-kernel, you wrote:
>i'm having problems to convince java (1.3.1) to allocate more
>than 1.9gb of memory on 2.4.2-ac2 (SMP/6gb phys mem) or more
>than 1.1gb on 2.2.18 (SMP/2gb phys mem)...
Take a look at a thread from January starting at this point:
http://www.uwsg.indiana
On Mon, 14 May 2001, Rik van Riel wrote:
> It would be cool if one of you two could update the docs ;)
OK, here is my attempt, as a patch to Configure.help in 2.4.5-pre1. I
hope it is clear, accurate, and not too long-winded, and that my mailer
does not munge patches.
Cheers,
Wayne
--- linux-
In mailing-lists.linux-kernel, you wrote:
> You need to compile highmem support into the kernel if you want to
> use more than 890 MB of RAM, set it to maximum 4GB for best
> performance...
On a similar note, what is the maximum physical memory supported by
the 4GB option?
Cheers, Wayne
-
To u
In mailing-lists.linux-kernel, you wrote:
>Have a look at:
>http://reality.sgi.com/cbrady_denver/memtest86/
>
>IMHO this is one of the best memory tests I have ever seen.
The original poster has an Alpha, not an x86.
Wayne
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel
OK, I captured some tulip-diag info about my tulip problem. Again,
intermittently my tulip card gets "slow", so that, for example, pinging it
from another machine on the same segment takes on the order of seconds,
rather than milliseconds (this time it was 0.4 seconds instead of the
usual 0.19 m
On Sat, 5 May 2001, Manfred Spraul wrote:
> Do you know if transmit or receive is slow? tcpdump on both ends of
> the ping might help.
Sorry, I don't currently know.
OK, the next time I see this, I'll give tulip-diag a whirl and report
back. Until then, I can't really provide any more details.
Hello,
I'm having a small intermittent problem with the tulip driver in linux
2.4.4, and I'm looking for some guidance on how to debug it.
What happens is that on one of my boxes the card ocasionally gets wedged.
That is, network traffic gets painfully slow, e.g. pinging another host on
the sam
In mailing-lists.linux-kernel, Seth wrote:
> Because lspci does not display all 256 bytes of pci configuration
>information.
Umm, "lspci -xxx"? At least, on lspci version 2.1.8 from RedHat 7.1.
Wayne
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a me
need to translate any
numbers into symbols, sorry. Let me know if you'd like anything else.
Cheers, Wayne
[whitney@pizza whitney]$ ps auxwOT
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
[ . . . ]
root 1792 0.1 0.2 2300 1068 pts/0S22:19 0:00 /bin/su
In mailing-lists.linux-kernel, Manuel A. McLure wrote:
> Did you try nesting more than one "su -"? The first one after a boot
> works for me - every other one fails.
Same here: the first "su -" works OK, but a second nested one hangs:
8825 pts/2S 0:00 /bin/su -
8826 pts/2S 0
On Fri, 6 Apr 2001, Mark Hahn wrote:
> note, though, that you *CAN* actually malloc a lot more than 1G: you
> just have to avoid causing mmaps that chop your VM at
> TASK_UNMAPPED_BASE:
Neat trick. I didn't realize that you could avoid allocating the mmap()
buffers for stdin and stdout.
As was
In mailing-lists.linux-kernel, you wrote:
> Essentially, the problem can be summarized to be that on a machine
> with ample ram (2G, 4G, etc), I am unable to malloc a gig if I ask
> for the memory in small ( <= 128k) chunks.
Take a look at this message by Szabolcs Szakacsits:
http://marc.t
In mailing-lists.linux-kernel, you wrote:
> I run into some major disk corruptions on my IDE disk with the new
> 2.4.3 kernel version. [ . . . ] Now I did some more testing and found
> out that the Alan Cox series of kernel patches does not show these
> problems.
Hmm, 2.4.2-ac28 and 2.4.3 have t
On 29 Mar 2001, Juan Quintela wrote:
> Hi I have the same motherboard and BIOS version. I was having
> filesystem corruption. There is a bugfix (from Arjan van der Ven) in
> the ac tree (around ac20 I think), could you test the last ac patch
> and test if the filesystem corruption persist??
I
Hi,
I'm running kernel 2.4.3-pre8 on an ASUS A7V (BIOS 1007) motherboard and
recently noticed that it sometimes corrupts my hard disk, an IBM 75GXP on
the onboard PDC20265 IDE controller. The corruption is detectable with a
simple 'dd if=/dev/urandom of=test bs=16384 count=32768; cp test test2
Hi,
I got the following OOPS yesterday while simultaneously doing a big 'rpm
-U' and a big computation (magma.exe) on an SMP i686 machine. I copied
the OOPS down by hand from the console, but it should be accurate. When
running ksymooops, I don't know that I reconstructed the module stack
comp
In mailing-lists.linux-kernel, you wrote:
> Make sure you use the latest 2.4.2-acxx drivers. Most other versions of
> my drivers have little bugs in the 686b support. Harmless but somewhat
> annoying.
Does this mean that the version 3.21 of your driver in the latest
2.4.2-acxx is newer than the
In mailing-lists.linux-kernel, you wrote:
> I know that 2.2.19 is still in the -pre state. [ . . . ] Have
> significant VM problems been fixed?
Yes, 2.2.19-pre incorporates what was known as Andrea's VM-global
patch, and it is widely reported to fix the exact problem you
mentioned.
Wayne
-
To
In mailing-lists.linux-kernel, you wrote:
> -ac is currently testing versions of the new VIA IDE driver
What is the relationship between the version 3.21 in -ac12 and the
version 4.3 that was distributed on this list a week or two ago?
Cheers, Wayne
-
To unsubscribe from this list: send the l
Hi,
I have a system with an MSI-6321 motherboard with the Via 686a
southbridge, and I'm having a little trouble with the via82cxxx_audio
sound driver. The stock 2.4.2 driver produces only a rhythmic a buzzing
sound. I saw a patch here a week or two ago for 'rate locking', so I
tried that (it d
In mailing-lists.linux-kernel, you wrote:
>I encountered with problem: one process can not allocate more then 2Gb of
>memory.
This is a problem that I have run into myself. I am no kernel expert,
but I think I understand how this issue. Here is how the standard
kernel maps the 4Gb 32-bit addr
In mailing-lists.linux-kernel, you wrote:
>I am running a web server under the new 2.4.0 kernel and am experiencing
>some intermittent odd behavior from the kernel. The machine will sometimes
>go through cycles where network response becomes slow even though top
>reports over 60% idle CPU tim
In mailing-lists.linux-kernel, you wrote:
>Michael Guntsche wrote:
>
>> While playing around with the agpgart module I noticed the following strange
>> behaviour.
>>
>> The hardware in question is an Asus K7V with the KX133 chipset and has been
>> tested on both 2.4.0 and 2.2.18 kernels.
>
>Can
As suggested in the thread "Subtle MM bug (really 830MB barrier
question)", it would be beneficial on 32-bit hardware for mmap()
allocations without MAP_FIXED to grow downward from TASK_SIZE, rather than
upwards from TASK_UNMAPPED_BASE. This would allow both brk()-using and
mmap()-using programs
On Tue, 9 Jan 2001, Szabolcs Szakacsits wrote:
> 3) ask kernel developers to get rid of this "brk hits the fixed start
> address of mmapped areas" or the other way around complaints "mmapped
> area should start at lower address" limitation. E.g. Solaris does
> growing up heap, growing down mmap a
On Tue, 9 Jan 2001, Szabolcs Szakacsits wrote:
> 3) ask kernel developers to get rid of this "brk hits the fixed start
> address of mmapped areas" or the other way around complaints "mmapped
> area should start at lower address" limitation. E.g. Solaris does
> growing up heap, growing down mmap a
On Tue, 9 Jan 2001, Szabolcs Szakacsits wrote:
> Wayne, the patch below should fix your barrier problem [1 GB physical
> memory configuration].
First, I just wanted to thank you and everyone else (Linus, Andrea, Dan
Maas, Rik and others) who has responded to my emails. You guys are
wonderful!
On Mon, Jan 08, 2001 at 03:22:44PM -0800, Wayne Whitney wrote:
> I guess I conclude that either (1) MAGMA does not use libc's malloc
> (checking on this, I doubt it)
I'm still a bit unclear on this one. I now have two executables,
magma.exe and magma.exe.dyn (ignore the .exe
On Mon, 8 Jan 2001, Wayne Whitney wrote:
> On Mon, 8 Jan 2001, Szabolcs Szakacsits wrote:
>
> > AFAIK newer glibc = CVS glibc but the malloc() tune parameters work
> > via environment variables for the current stable ones as well,
>
> I'll arrange a binary linked ag
On Mon, 8 Jan 2001, Szabolcs Szakacsits wrote:
> AFAIK newer glibc = CVS glibc but the malloc() tune parameters work
> via environment variables for the current stable ones as well, e.g. to
> overcome the above "out of memory" one could do,
>
> % export MALLOC_MMAP_MAX_=100
> % export MALLOC_
On Mon, 8 Jan 2001, Szabolcs Szakacsits wrote:
> AFAIK newer glibc = CVS glibc but the malloc() tune parameters work
> via environment variables for the current stable ones as well,
Hmm, this must have been introduced in libc6? Unfortunately, I don't have
the source code to MAGMA, and the binar
On Mon, 8 Jan 2001, Rik van Riel wrote:
> How does 2.4 perform when you add an extra GB of swap ?
OK, some more data:
First, I tried booting 2.4.0 with "nosmp" to see if the behavior I observe
is SMP related. It isn't, there was no difference under 2.4.0 between
512MB/512MB/1CPU and 512MB/512M
On Sunday, January 7, 20001, Rik van Riel <[EMAIL PROTECTED]> wrote:
> Now if 2.4 has worse _performance_ than 2.2 due to one reason or
> another, that I'd like to hear about ;)
Well, here is a workload that performs worse on 2.4.0 than on 2.2.19pre,
and as it is the usual workload on my little
Hello,
When I use 'make menuconfig' on 2.4.0-test13-pre3 to select DRM and the
Matrox DRM driver as a module, I get a .config with CONFIG_DRM=y and
CONFIG_DRM_MGA=m. However, this causes drivers/char/Makefile to skip the
drm subdirectory when compiling modules: its only reference to CONFIG_DRM
On Wed, 1 Nov 2000, Wayne Whitney wrote:
> On Wed, 1 Nov 2000, Rik van Riel wrote (in "Re: [BUG] /proc//stat
> access stalls badly for swapping process, 2.4.0-test10"):
>
> > 3) combine this with the elevator starvation stuff (ask Jens
> >Axboe for blk-7 t
Hi,
My group runs computations on a small linux cluster of RedHat 7.0 dual
PIII-700's with 512MB RAM/512MB swap. We have been experiencing some
lockups/poor performance on 2.4.x kernels when running two computations at
once. I've narrowed it down to a reproducible problem under 2.4.0-test10
(g
On Sat, 14 Oct 2000, Andi Kleen wrote:
> That would be weird, because 2.2 does not support loopback creation on
> NFS (and has an explicit check for it)
Hmm, now that you jar my memory, I remember that I had actually loopback
mounted an iso filesystem image on one machine and then NFS exported
Hi all,
[ My apologies if this is a duplicate; I tried sending this a week ago,
but I didn't see my message in the mailing list archives, so I assume that
it did not go through for some reason . . . ]
This is my first time posting a possible kernel bug, so I hope I get
everything right; I am fol
41 matches
Mail list logo