All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: ISO-9660 Rock Ridge gives different links different inums
From: Peter Chubb @ 2003-01-10  3:34 UTC (permalink / raw)
  To: Andrew McGregor; +Cc: Peter Chubb, eric, linux-kernel
In-Reply-To: <1345590000.1042169011@localhost.localdomain>

>>>>> "Andrew" == Andrew McGregor <andrew@indranet.co.nz> writes:

Andrew> --On Friday, January 10, 2003 14:08:59 +1100 Peter Chubb
Andrew> <peter@chubb.wattle.id.au> wrote:

>> In linux 2.5.54, multiple links to the same file on a rock-ridge CD
>> have different inode numbers.  This confuses cpio, tar and cp -ra
>> because the multiple links are each copied separately as a single
>> file.
>> 
>> It'll probably also confuse NFS, but I haven't tried that.

Andrew> Shouldn't do, but it will probably make the buffer cache on
Andrew> the server less effective.

>> Currently the inode number appears to be the offset in bytes from
>> the start of the file system to the iso directory entry.  Files
>> with multiple directory entries (i.e., links) therefore have
>> different inums.
>> 
>> I don't know enough about the ISO9660 standard to be sure what's
>> best to do about this.

Andrew> Change it to be the offset to the data area, which should be
Andrew> the same for all of them?

I thought about that, but I'm unsure if there's any way to get from
that offset to the directory information.  As far as I can tell,
there's no concept of an inode separate from directory entry on iso9660
--- the directory entry/entries all contain all the information that
describes a file.  Which means that the inumber has to point to some
directory node.

Preferably, all the inumbers for the same file would point to the same
directory entry; but I can see no easy way to do that.  Keeping an
in-memory table for files with multiple links might be the best way,
as there aren't that many on a typical filesystem.

--
Dr Peter Chubb				    peterc@gelato.unsw.edu.au
You are lost in a maze of BitKeeper repositories, all almost the same.

^ permalink raw reply

* gcc version conflict
From: Jonathan Kallay @ 2003-01-10  3:30 UTC (permalink / raw)
  To: linux-newbie

Hi all,
  I'm trying to compile the kernel module for some NVidia drivers.  I'm
getting an error message saying that I'm compiling a module with a different
version of the compiler than the one used to compile the kernel (gcc 2.95.4
is what's installed; the kernel version is 2.2.20 and at one point I was
able to check the compiler version that compiled it but I can't remember how
I did it).  What's the best way to work around this problem?

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

^ permalink raw reply

* Re: 2.4.20, .text.lock.swap cpu usage? (ibm x440)
From: Brian Tinsley @ 2003-01-10  3:42 UTC (permalink / raw)
  To: William Lee Irwin III; +Cc: linux-kernel
In-Reply-To: <20030110032937.GI23814@holomorphy.com>

William Lee Irwin III wrote:

>At some point in the past, I wrote:
>  
>
>>>There is no extant implementation of paged stacks yet.
>>>      
>>>
>
>On Thu, Jan 09, 2003 at 09:17:56PM -0600, Brian Tinsley wrote:
>  
>
>>For the most part, this is probably a boundary condition, right? Anyone 
>>that intentionally has 800+ threads in a single application probably 
>>needs to reevaluate their design :)
>>    
>>
>
>IMHO multiprogramming is as valid a use for memory as any other. Or
>even otherwise, it's not something I care to get in design debates
>about, it's just how the things are used.
>
I agree with the philosophy in general, but if I sit down to write a 
threaded application for Linux on IA-32 and wind up with a design that 
uses 800+ threads in any instance (other than a bug, which was our 
case), it's time to give up the day job and start riding on the back of 
the garbage truck ;)

>The only trouble is support for what you're doing is unimplemented.
>
You mean the 800+ threads or Java on Linux?

>At some point in the past, I wrote:
>  
>
>>>I'm working on a different problem (mem_map on 64GB on 2.5.x). I
>>>probably won't have time to implement it in the near future, I
>>>probably won't be doing it vs. 2.4.x, and I won't have to if someone
>>>else does it first.
>>>      
>>>
>
>On Thu, Jan 09, 2003 at 09:17:56PM -0600, Brian Tinsley wrote:
>  
>
>>Is that a hint to someone in particular?
>>    
>>
>
>Only you, if anyone. My intentions and patchwriting efforts on the 64GB
>and highmem multiprogramming fronts are long since public, and publicly
>stated to be targeted at 2.7. Since there isn't a 2.7 yet, 2.5-CURRENT
>must suffice until there is.
>
In all honesty, I would enjoy nothing more than contributing to kernel 
development. Unfortunately it's a bit out of my scope right now (but not 
forever). If I only believed aliens seeded our gene pool with clones, I 
could hook up with those folks that claim to have cloned a human and get 
one of me made! ;)



^ permalink raw reply

* Can't start raid 5 when device names have changed
From: bugzilla @ 2003-01-10  3:35 UTC (permalink / raw)
  To: linux-raid

This is reported on http://bugzilla.redhat.com/bugzilla as bug # 81258

Description of problem:
I have a raid 5 with 4 disks.  sda1, sda2, sda3, sda4
I have added 2 disks to my system.
The new disks are sdb and sdd.  At first they did not have a valid partion 
table.  I got this error on both disks:
md: could not lock sdb1, zero-size? Marking faulty.
md: could not import sdb1, trying to run array nevertheless.
 [events: 00000004]
md: could not lock sdd1, zero-size? Marking faulty.
md: could not import sdd1, trying to run array nevertheless.

That should not be a problem because the raid 5 disks are now sda1, sdc1, sde1 
and sdf1.

I did change raidtab before I shutdown to add the new disks.  The system seems 
to ignore raidtab for existing arrays.  Must only use the file when you use 
mkraid.

I have since partitioned the 2 disks sdb and sdd with type fd.
raidstart still fails.

I have created a raid 1 array on the 2 disks sdb and sdd.  I did not need to 
use the force option with mkraid.

The OS is on 2 IDE disks (hda and hdb).

/dev/md0 is swap
/dev/md1 is /
/dev/md2 is /boot
/dev/md3 is the problem array.
/dev/md4 is the array on the 2 new disks.
Here is a copy of my raidtab file:
raiddev             /dev/md1
raid-level                  1
nr-raid-disks               2
chunk-size                  64k
persistent-superblock       1
nr-spare-disks              0
    device          /dev/hda2
    raid-disk     0
    device          /dev/hdb3
    raid-disk     1

raiddev             /dev/md2
raid-level                  1
nr-raid-disks               2
chunk-size                  64k
persistent-superblock       1
nr-spare-disks              0
    device          /dev/hda1
    raid-disk     0
    device          /dev/hdb1
    raid-disk     1

raiddev             /dev/md0
raid-level                  1
nr-raid-disks               2
chunk-size                  64k
persistent-superblock       1
nr-spare-disks              0
    device          /dev/hda3
    raid-disk     0
    device          /dev/hdb2
    raid-disk     1

raiddev             /dev/md3
raid-level                  5
parity-algorithm            left-symmetric
nr-raid-disks               4
chunk-size                  64k
persistent-superblock       1
nr-spare-disks              0
    device          /dev/sda1
    raid-disk     0
    device          /dev/sdc1
    raid-disk     1
    device          /dev/sde1
    raid-disk     2
    device          /dev/sdf1
    raid-disk     3

raiddev             /dev/md4
raid-level                  1
#parity-algorithm            left-symmetric
nr-raid-disks               2
chunk-size                  64k
persistent-superblock       1
nr-spare-disks              0
    device          /dev/sdb1
    raid-disk     0
    device          /dev/sdd1
    raid-disk     1

I did remove the 2 new disks.  Then my device names were back to normal.  The 
array /dev/md3 did come up after a re-boot.  /dev/md4 did not (as expected, 
the drives had no power)!

Please help!  I can resolve the problem by addressing the new disks so they 
will be sde and sdf.  But this seems like it could be a major problem for 
others in the future.  You should be able to add disks to a system without 
such problems.

I will keep the disks configured like this for a while.  If someone wants me 
to try something I will.  If I lose data I don't care.  I have 2 or more 
backups.

Thanks.

 


------- Additional Comment #1 From Mr Watkins on 2003-01-09 22:20 -------  

I will be trashing the array soon.  I will re-create it with 7 disks.  If 
anyone wants to debug this issue, they need to start within the next few 
days.  I may play first, add a hot spare, fail a drive, raidhotadd.  Stuff 
like that.  I want to determine if this stuff is top notch, or not.

^ permalink raw reply

* re: problem with ./runme in --batch mode. -- current p-o-m
From: Alistair Tonner @ 2003-01-10  3:44 UTC (permalink / raw)
  To: netfilter


	Hi folks:
	
	Its too late at night, and I shouldn't be mucking with scripts. ... I realize 
now that my previous email was in error ... and now realize what is actually 
happening when passing a long list to ./runme ... its just disconcerting to 
see patches that I don't want in the "already applied" list that ./runme 
spits up when running in batch mode ... I can now see that the $EXCLUDED are 
copied to $SEEN and listed in already applied list because of that ... 

   perhaps we could put a *bypassed* tag in there so that others don't get as 
confused as I..... 

	(hangs head in shame)

	Alistair Tonner
	Alistair@nerdnet.ca

	(Actually ... since I just flipped email addys on the mailing list ... this 
message migh show up before the one of which I speak.....)



^ permalink raw reply

* Re: 2.4.20, .text.lock.swap cpu usage? (ibm x440)
From: William Lee Irwin III @ 2003-01-10  3:54 UTC (permalink / raw)
  To: Brian Tinsley; +Cc: linux-kernel
In-Reply-To: <3E1E410E.5050905@emageon.com>

William Lee Irwin III wrote:
>> IMHO multiprogramming is as valid a use for memory as any other. Or
>> even otherwise, it's not something I care to get in design debates
>> about, it's just how the things are used.

On Thu, Jan 09, 2003 at 09:42:06PM -0600, Brian Tinsley wrote:
> I agree with the philosophy in general, but if I sit down to write a 
> threaded application for Linux on IA-32 and wind up with a design that 
> uses 800+ threads in any instance (other than a bug, which was our 
> case), it's time to give up the day job and start riding on the back of 
> the garbage truck ;)

I could care less what userspace does: mechanism, not policy. Userspace
wants, and I give if I can, just as the kernel does with system calls.

800 threads isn't even a high thread count anyway, the 2.5.x testing
was with a peak thread count of 100,000. 800 threads, even with an 8KB
stack, is no more than 6.4MB of lowmem for stacks and so shouldn't
stress the system unless many instances of it are run. I suspect your
issue is elsewhere. I'll submit accounting patches for Marcelo's and/or
Andrea's trees so you can find out what's actually going on.


William Lee Irwin III wrote:
>> Only you, if anyone. My intentions and patchwriting efforts on the 64GB
>> and highmem multiprogramming fronts are long since public, and publicly
>> stated to be targeted at 2.7. Since there isn't a 2.7 yet, 2.5-CURRENT
>> must suffice until there is.

On Thu, Jan 09, 2003 at 09:42:06PM -0600, Brian Tinsley wrote:
> In all honesty, I would enjoy nothing more than contributing to kernel 
> development. Unfortunately it's a bit out of my scope right now (but not 
> forever). If I only believed aliens seeded our gene pool with clones, I 
> could hook up with those folks that claim to have cloned a human and get 
> one of me made! ;)

I don't know what to tell you here. I'm lucky that this is my day job
and that I can contribute so much. However, there are plenty who
contribute major changes (many even more important than my own) without
any such sponsorship. Perhaps emulating them would satisfy your wish.


Bill

^ permalink raw reply

* [PATCH]  Add __gpl_ksymtab section to v850 linker script
From: Miles Bader @ 2003-01-10  3:59 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linux-kernel

diff -ruN -X../cludes linux-2.5.55-moo.orig/arch/v850/vmlinux.lds.S linux-2.5.55-moo/arch/v850/vmlinux.lds.S
--- linux-2.5.55-moo.orig/arch/v850/vmlinux.lds.S	2002-12-24 15:01:07.000000000 +0900
+++ linux-2.5.55-moo/arch/v850/vmlinux.lds.S	2003-01-09 15:27:41.000000000 +0900
@@ -1,8 +1,8 @@
 /*
  * arch/v850/vmlinux.lds.S -- kernel linker script for v850 platforms
  *
- *  Copyright (C) 2002  NEC Electronics Corporation
- *  Copyright (C) 2002  Miles Bader <miles@gnu.org>
+ *  Copyright (C) 2002,03  NEC Electronics Corporation
+ *  Copyright (C) 2002,03  Miles Bader <miles@gnu.org>
  *
  * This file is subject to the terms and conditions of the GNU General
  * Public License.  See the file COPYING in the main directory of this
@@ -51,6 +51,9 @@
 		___start___ksymtab = . ;/* Kernel symbol table.  */	      \
 			*(__ksymtab)					      \
 		___stop___ksymtab = . ;					      \
+		___start___gpl_ksymtab = . ; /* Same for GPL symbols.  */     \
+			*(__gpl_ksymtab)				      \
+		___stop___gpl_ksymtab = . ;				      \
 		. = ALIGN (4) ;						      \
 		__etext = . ;
 

^ permalink raw reply

* Re: 2.4.20, .text.lock.swap cpu usage? (ibm x440)
From: Brian Tinsley @ 2003-01-10  4:08 UTC (permalink / raw)
  To: William Lee Irwin III; +Cc: linux-kernel
In-Reply-To: <20030110035412.GJ23814@holomorphy.com>

William Lee Irwin III wrote:

>William Lee Irwin III wrote:
>  
>
>>>IMHO multiprogramming is as valid a use for memory as any other. Or
>>>even otherwise, it's not something I care to get in design debates
>>>about, it's just how the things are used.
>>>      
>>>
>
>On Thu, Jan 09, 2003 at 09:42:06PM -0600, Brian Tinsley wrote:
>  
>
>>I agree with the philosophy in general, but if I sit down to write a 
>>threaded application for Linux on IA-32 and wind up with a design that 
>>uses 800+ threads in any instance (other than a bug, which was our 
>>case), it's time to give up the day job and start riding on the back of 
>>the garbage truck ;)
>>    
>>
>
>I could care less what userspace does: mechanism, not policy. Userspace
>wants, and I give if I can, just as the kernel does with system calls.
>
>800 threads isn't even a high thread count anyway, the 2.5.x testing
>was with a peak thread count of 100,000. 800 threads, even with an 8KB
>stack, is no more than 6.4MB of lowmem for stacks and so shouldn't
>stress the system unless many instances of it are run.
>
I understand your perspective here. I won't get into application design 
issues as it is far out of context from this list.

>I suspect your issue is elsewhere. I'll submit accounting patches for Marcelo's and/or Andrea's trees so you can find out what's actually going on.
>
Much appreciated! I look forward to it.


>On Thu, Jan 09, 2003 at 09:42:06PM -0600, Brian Tinsley wrote:
>  
>
>>In all honesty, I would enjoy nothing more than contributing to kernel 
>>development. Unfortunately it's a bit out of my scope right now (but not forever). If I only believed aliens seeded our gene pool with clones, I could hook up with those folks that claim to have cloned a human and get one of me made! ;)
>>    
>>
>
>I don't know what to tell you here. I'm lucky that this is my day job
>and that I can contribute so much. However, there are plenty who
>contribute major changes (many even more important than my own) without
>any such sponsorship. Perhaps emulating them would satisfy your wish.
>
It would!

I cannot say thanks enough for the efforts of you and everyone else out 
there. Frankly, I would not have my day job and would not have been able 
to make Emageon what it is today were it not for you all!

Oh, please excuse the stupid humor tonight. I'm in a giddy mood for some 
reason. Must be the excitement from the prospect of getting resolution 
to this problem!



^ permalink raw reply

* Re: gcc version conflict
From: whitnl73 @ 2003-01-10  4:01 UTC (permalink / raw)
  To: yoni; +Cc: linux-newbie
In-Reply-To: <00f901c2b858$a725cb60$6400a8c0@00arc>

On Thu, 9 Jan 2003, Jonathan Kallay wrote:

> Hi all,
>   I'm trying to compile the kernel module for some NVidia drivers.  I'm
> getting an error message saying that I'm compiling a module with a different
> version of the compiler than the one used to compile the kernel (gcc 2.95.4
> is what's installed; the kernel version is 2.2.20 and at one point I was
> able to check the compiler version that compiled it but I can't remember how
> I did it).  What's the best way to work around this problem?
>
[whit@giftie whit]$ cat /proc/version
Linux version 2.4.13 (whit@giftie) (gcc version 2.95.3 20010315 (release)) #1 Tu
e Oct 30 22:04:20 EST 2001
[whit@giftie whit]$ tty
/dev/vc/5
[whit@giftie whit]$ cat /usr/local/bin/trail
#!/bin/sh
/bin/sed 's/ *$//g' $@
[whit@giftie whit]$ cat /dev/vcs5|fold|trail>oops

I have devfs and devfsd, so I can use either /dev/vcc/<n> or /dev/vcs<n>
but the tty command reports the real (devfs) device name.  Please don't
be confused if tty reports /dev/vcs<n>

I guess the easiest way to work around it would be to recompile the
kernel and modules with the gcc you have installed.

Lawson
--
---oops---
There are many ways.  Some day we will write all the ways in a big
book.  We will then burn the big book.  - M. K. Tulley



________________________________________________________________
Sign Up for Juno Platinum Internet Access Today
Only $9.95 per month!
Visit www.juno.com
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

^ permalink raw reply

* [PATCH]  Add support for ROM kernel on v850 AS85EP1 target [try #2]
From: Miles Bader @ 2003-01-10  4:13 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linux-kernel

[This differs from the patch I sent yesterday in that the file-encoding
 matches what's in the distribution, so should apply cleanly]

diff -ruN -X../cludes linux-2.5.55-moo.orig/arch/v850/kernel/as85ep1.c linux-2.5.55-moo/arch/v850/kernel/as85ep1.c
--- linux-2.5.55-moo.orig/arch/v850/kernel/as85ep1.c	2002-11-28 10:24:54.000000000 +0900
+++ linux-2.5.55-moo/arch/v850/kernel/as85ep1.c	2003-01-09 14:07:36.000000000 +0900
@@ -44,8 +44,10 @@
 
 void __init mach_early_init (void)
 {
+#ifndef CONFIG_ROM_KERNEL
 	const u32 *src;
 	register u32 *dst asm ("ep");
+#endif
 
 	AS85EP1_CSC(0) = 0x0403;
 	AS85EP1_BCT(0) = 0xB8B8;
@@ -53,25 +55,28 @@
 	AS85EP1_BCC    = 0x0012;
 	AS85EP1_ASC    = 0;
 	AS85EP1_LBS    = 0x00A9;
-	AS85EP1_RFS(1) = 0x8205;
-	AS85EP1_RFS(3) = 0x8205;
-	AS85EP1_SCR(1) = 0x20A9;
-	AS85EP1_SCR(3) = 0x20A9;
 
 	AS85EP1_PORT_PMC(6)  = 0xFF; /* A20-25, A0,A1 ^[$BM-8z^[(B */
 	AS85EP1_PORT_PMC(7)  = 0x0E; /* CS1,2,3       ^[$BM-8z^[(B */
 	AS85EP1_PORT_PMC(9)  = 0xFF; /* D16-23        ^[$BM-8z^[(B */
 	AS85EP1_PORT_PMC(10) = 0xFF; /* D24-31        ^[$BM-8z^[(B */
 
-	AS85EP1_IRAMM = 0x3;	/* ^[$BFbB"L?Na^[(BRAM^[$B$O!V^[(Bwrite-mode^[$B!W$K$J$j$^$9^[(B */
+	AS85EP1_RFS(1) = 0x800c;
+	AS85EP1_RFS(3) = 0x800c;
+	AS85EP1_SCR(1) = 0x20A9;
+	AS85EP1_SCR(3) = 0x20A9;
 
-	/* The early chip we have is buggy, so that writing the interrupt
+#ifndef CONFIG_ROM_KERNEL
+	/* The early chip we have is buggy, and writing the interrupt
 	   vectors into low RAM may screw up, so for non-ROM kernels, we
 	   only rely on the reset vector being downloaded, and copy the
 	   rest of the interrupt vectors into place here.  The specific bug
 	   is that writing address N, where (N & 0x10) == 0x10, will _also_
 	   write to address (N - 0x10).  We avoid this (effectively) by
 	   writing in 16-byte chunks backwards from the end.  */
+
+	AS85EP1_IRAMM = 0x3;	/* ^[$BFbB"L?Na^[(BRAM^[$B$O!V^[(Bwrite-mode^[$B!W$K$J$j$^$9^[(B */
+
 	src = (u32 *)(((u32)&_intv_copy_src_end - 1) & ~0xF);
 	dst = (u32 *)&_intv_copy_dst_start
 		+ (src - (u32 *)&_intv_copy_src_start);
@@ -83,6 +88,7 @@
 	} while (src > (u32 *)&_intv_copy_src_start);
 
 	AS85EP1_IRAMM = 0x0;	/* ^[$BFbB"L?Na^[(BRAM^[$B$O!V^[(Bread-mode^[$B!W$K$J$j$^$9^[(B */
+#endif /* !CONFIG_ROM_KERNEL */
 
 	nb85e_intc_disable_irqs ();
 }
@@ -107,16 +113,20 @@
 	*ram_len = RAM_END - RAM_START;
 }
 
+/* Convenience macros.  */
+#define SRAM_END	(SRAM_ADDR + SRAM_SIZE)
+#define SDRAM_END	(SDRAM_ADDR + SDRAM_SIZE)
+
 void __init mach_reserve_bootmem ()
 {
 	extern char _root_fs_image_start, _root_fs_image_end;
 	u32 root_fs_image_start = (u32)&_root_fs_image_start;
 	u32 root_fs_image_end = (u32)&_root_fs_image_end;
 
-	/* We can't use the space between SRAM and SDRAM, so prevent the
-	   kernel from trying.  */
-	reserve_bootmem (SRAM_ADDR + SRAM_SIZE,
-			 SDRAM_ADDR - (SRAM_ADDR + SRAM_SIZE));
+	if (SDRAM_ADDR < RAM_END && SDRAM_ADDR > RAM_START)
+		/* We can't use the space between SRAM and SDRAM, so
+		   prevent the kernel from trying.  */
+		reserve_bootmem (SRAM_END, SDRAM_ADDR - SRAM_END);
 
 	/* Reserve the memory used by the root filesystem image if it's
 	   in RAM.  */

^ permalink raw reply

* Re: 2.4.20, .text.lock.swap cpu usage? (ibm x440)
From: William Lee Irwin III @ 2003-01-10  4:19 UTC (permalink / raw)
  To: Brian Tinsley; +Cc: linux-kernel
In-Reply-To: <3E1E4757.3060206@emageon.com>

William Lee Irwin III wrote:
>> I don't know what to tell you here. I'm lucky that this is my day job
>> and that I can contribute so much. However, there are plenty who
>> contribute major changes (many even more important than my own) without
>> any such sponsorship. Perhaps emulating them would satisfy your wish.

On Thu, Jan 09, 2003 at 10:08:55PM -0600, Brian Tinsley wrote:
> It would!
> I cannot say thanks enough for the efforts of you and everyone else out 
> there. Frankly, I would not have my day job and would not have been able 
> to make Emageon what it is today were it not for you all!
> Oh, please excuse the stupid humor tonight. I'm in a giddy mood for some 
> reason. Must be the excitement from the prospect of getting resolution 
> to this problem!

We're straying from the subject here. Please describe your machine,
in terms of how many cpus it has and how much highmem it has, and
your workload, so I can better determine the issue. Perhaps we can
cooperatively devise something that works well for you.

Or perhaps the kernel version is not up-to-date. Please also provide
the precise kernel version (and included patches). And workload too.


Thanks,
Bill

^ permalink raw reply

* Re: "Mother" == "computer-illiterate"
From: Tom Diehl @ 2003-01-10  4:23 UTC (permalink / raw)
  To: jdow; +Cc: Chris Adams, linux-kernel
In-Reply-To: <04a701c2b84e$2bd7ad70$1125a8c0@wizardess.wiz>

On Thu, 9 Jan 2003, jdow wrote:

> From: "Chris Adams" <cmadams@hiwaay.net>
> 
> > Once upon a time, Alan Cox  <alan@lxorguk.ukuu.org.uk> said:
> > >and of course Sally Floyd, and even Hedy Lamarr (bonus points for those
> > >who know what her networking related patent is on)
> > 
> > That's HEDLEY!  Oh, but he doesn't have any patents.
> 
> No, it's Hedy Lamarr and she invented frequency hopping spread spectrum
> with George Anthiel. I worked on one of the first practical implementations
> of the concept back in the early 70s. Somehow it seems appropriate.

Hehe!! He got you Joanne!! Ever watch Blazing Saddles?? 

I am jealous though. In reading various messages written by you, you have 
clearly had way too much fun in life!! :-)

Enjoy,

-- 
.............Tom	"Nothing would please me more than being able to 
tdiehl@rogueind.com	hire ten programmers and deluge the hobby market 
			with good software." -- Bill Gates 1976

   			We are still waiting ....


^ permalink raw reply

* Re: 2.4.19 -- ac97_codec failure ALi 5451
From: Peter @ 2003-01-10  4:30 UTC (permalink / raw)
  To: Alan Cox; +Cc: linux-kernel
In-Reply-To: <200301100250.h0A2olE20795@devserv.devel.redhat.com>

Quoting Alan Cox <alan@redhat.com>:

> >         Trident 4DWave/SiS 7018/ALi 5451,Tvia CyberPro 5050 PCI Audio, 
> > 		version 0.14.9d, 00:57:19 Jan  9 2003
> >         PCI: Enabling device 00:06.0 (0000 -> 0003)
> >         PCI: Assigned IRQ 10 for device 00:06.0
> >         trident: ALi Audio Accelerator found at IO 0x1000, IRQ 10
> >         ac97_codec: AC97 Audio codec, id: 0x4144:0x5372 (Unknown)
> 
> So far so good.
> 
> >         ali: AC97 CODEC read timed out.
> >         last message repeated 127 times
> >         ali: AC97 CODEC write timed out.
> >         ac97_codec: AC97  codec, id: 0x0000:0x0000 (Unknown)
> 
> Something lost the codec. Could be power management - was the laptop
> suspended before it went funny ?

No, this happens very reliably every time on a large number of occasions, whether 
trident is compiled in or as a module, or with ALSA's snd-ali5451. Dozens of read 
and write timeouts. In fact when the codec loads, it tends to freeze the whole 
system for a short time (from a few seconds to a minute).

That said, it's close to working. There have been times when I've been able to get 
sound -- typically by doing a manual insmod ac97_codec and trident. I had hoped the 
ALSA module would work more reliably, but it seems the problem is with the ac97 
codec.

Is the driver for the ac97 codec the same for OSS and ALSA? They appear to fail in 
very similar ways.

Peter

^ permalink raw reply

* Re: 2.4.20, .text.lock.swap cpu usage? (ibm x440)
From: Brian Tinsley @ 2003-01-10  4:50 UTC (permalink / raw)
  To: William Lee Irwin III; +Cc: linux-kernel
In-Reply-To: <20030110041918.GK23814@holomorphy.com>

>
>
>We're straying from the subject here.
>
Sorry

>Please describe your machine,
>in terms of how many cpus it has and how much highmem it has, and
>your workload, so I can better determine the issue. Perhaps we can
>cooperatively devise something that works well for you.
>
IBM x360
Pentium 4 Xeon MP processors

2 processor system has 4GB RAM
4 processor system has 8GB RAM

1 IBM ServeRAID controller
2 Intel PRO/1000MT NICs
2 QLogic 2340 Fibre Channel HBAs

>Or perhaps the kernel version is not up-to-date. Please also provide
>the precise kernel version (and included patches). And workload too.
>
The kernel version is stock 2.4.20 with Chris Mason's data logging and 
journal relocation patches for ReiserFS (neither of which are actually 
in use for any mounted filesystems). It is compiled for 64GB highmem 
support. And just to refresh, I have seen this exact behavior on stock 
2.4.19 and stock 2.4.17 (no patches on either of these) also compiled 
with 64GB highmem support.

Workload:
When the live-lock occurs, the system is performing intensive network 
I/O and intensive disk reads from the fibre channel storage (i.e., the 
backup program is reading files from disk and transferring them to the 
backup server). I posted a snapshot of sar data collection earlier today 
showing selected stats leading up to and just after the live-lock occurs 
(which is noted by a ~2 minute gap in sar logging). After the live-lock 
is released, the only thing that stands out is an unusual increase in 
runtime for kswapd (as reported by ps).

The various Java programs mentioned in prior postings are *mostly* idle 
at this point in time as it is after hours for our clients.



^ permalink raw reply

* Does anyone know what triggers the digests to be sent ?
From: Ian Batterbee @ 2003-01-10  4:42 UTC (permalink / raw)
  To: netfilter

I asked this question to the list admin but got no response, so I'll try 
  here and see if have more luck.

Does anyone know what triggers the digest version of this list to be 
sent out ? It seems to come too frequently to really be much of a digest 
- I've had several arrive per day with maybe half a dozen messages in 
them, where I'ld have preferred one message with 25 messages.


Does anyone have admin rights to check/change these settings ?




^ permalink raw reply

* Re: [2.5.54][PATCH] SB16 convertation to new PnP layer.
From: Shawn Starr @ 2003-01-10  4:56 UTC (permalink / raw)
  To: Ruslan U. Zakirov; +Cc: Linux Kernel

Is this for ALSA or OSS? Right now I have this card on my P233MMX an AWE32 
EMU8000 w/ 2MB installed.

It's using OSS under 2.4 right now and I'd like to try this. Does it work for 
OSS? I don't want to build the ALSA userland tools right now ;-)

Shawn.


^ permalink raw reply

* Re: 2.5.x inspiron touchpad breakage
From: Andres Salomon @ 2003-01-10  4:54 UTC (permalink / raw)
  To: linux-kernel
In-Reply-To: <39260000.1042119837@localhost.localdomain>

The appropriate config section from my kernel:


#
# Input device support
#
CONFIG_INPUT=y

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_MOUSE_SERIAL=m
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set

CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_TSDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set

#
# Input I/O drivers
#
# CONFIG_GAMEPORT is not set
CONFIG_SOUND_GAMEPORT=y
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=y
CONFIG_SERIO_CT82C710=m



The inspiron uses an i8042 for the keyboard and the external ps/2
mouse/keyboard port.  I'm not sure what it uses for the touchpad.


On Fri, 10 Jan 2003 02:43:57 +1300, Andrew McGregor wrote:

> Works for me on an Inspiron 8000.  The trackpoint does not, which is a 
> known bug.  Of course, the 3800 might be different...
> 
> Have you been bitten by the input layer configuration issue?  Here's what I 
> have:
> 
> #
> # Input device support
> #
> CONFIG_INPUT=y
> 
> #
> # Userland interfaces
> #
> CONFIG_INPUT_MOUSEDEV=y
> CONFIG_INPUT_MOUSEDEV_PSAUX=y
> 
> #
> # Input Device Drivers
> #
> CONFIG_INPUT_KEYBOARD=y
> CONFIG_KEYBOARD_ATKBD=y
> CONFIG_INPUT_MOUSE=y
> CONFIG_MOUSE_PS2=y
> 
> Andrew
> 
> --On Thursday, January 09, 2003 03:27:54 -0500 Andres Salomon 
> <dilinger@voxel.net> wrote:
> 
>> 2.5.54 and 2.5.55 do not appear to initialize the touchpad on my Dell
>> Inspiron 3800.  No mouse device is detected until I plug a normal ps/2
>> mouse into the laptop.  I assume this is some weird bios thing.  2.4.x
>> works fine with it.  Does anyone have suggestions about where to look for
>> any changed in the 2.5 series that might've broken it, or any patches that
>> fix it?
>>
>> -
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
>>
>>



^ permalink raw reply

* Reg iptables Connection tracking
From: Amit Kumar Gupta @ 2003-01-10  5:03 UTC (permalink / raw)
  To: netfilter

[-- Attachment #1: Type: text/plain, Size: 631 bytes --]


Hi List,

I am getting a problem with iptables :- 

I have added some rules in which I check the states of the packets which
I receive i.e. whether it is NEW, ESTABLISHED or INVALID and then do
some actions.

Now the problem which I am getting is :- (However I have already posted
a si ilar query reg this but I think this will be more elaborative).

As soon as somebody pings to my m/c , that fellow doesn't get the reply
and on my m/c , kernel keeps dumping certain messages which are like
this :-

Ip_contrack: maximum limit of 1016 entries exceeded.

Please help. 

Thanks & Regards,

Amit Kumar Gupta.

[-- Attachment #2: Wipro_Disclaimer.txt --]
[-- Type: text/plain, Size: 514 bytes --]

**************************Disclaimer************************************************

Information contained in this E-MAIL being proprietary to Wipro Limited is 
'privileged' and 'confidential' and intended for use only by the individual
 or entity to which it is addressed. You are notified that any use, copying 
or dissemination of the information contained in the E-MAIL in any manner 
whatsoever is strictly prohibited.

***************************************************************************************

^ permalink raw reply

* Re: DMA timeouts on Promise 20267 IDE card
From: James Curbo @ 2003-01-10  5:12 UTC (permalink / raw)
  To: Ross Biro; +Cc: linux-kernel
In-Reply-To: <3E1DEF29.8020900@google.com>

On Jan 09, Ross Biro wrote:

> I believe the low bit set in the dma_status means that the DMA transfer 
> is still in progress.  Since the timer has expired, that means it's been 
> in progress for 10 seconds.  Odds are the drive has stopped responding. 
> Since it's a Western Digital drive, it probably needs to be powercycled 
> to come back.
> 
> I don't think this is a problem with the controller card, but I could be 
> wrong.
> 
>    Ross
> 

Well, I have had the first drive for about a year and a half (I think) 
and the second drive since August. I never had any problems out of them
with the same controller card on my previous motherboard (MSI K7T
Turbo). The problems didn't arise until the other day when I got my new
board.

The errors occur over and over; the drive will come back for a few
seconds and then the error will occur again. I usually reboot at this
point.

-- 
James Curbo <hannibal@adtrw.org> <phoenix@sandwich.net>
http://www.adtrw.org/blogs/hannibal/

^ permalink raw reply

* Port 3 hits from internal system to outside Question.
From: Rod Smart @ 2003-01-10  5:05 UTC (permalink / raw)
  To: NetFilter List

    I have a problem where I have "port 3" attempts from my internal
computer trying to connect to "port 3" on a external computer.

    Would anyone be able to explain to me what is happening ?

    Here is a scan from my filter REJECT logs.

Jan  8 17:19:58 jumpgate kernel: Packet log: output REJECT eth1 PROTO=1
192.168.3.130:3 203.22.13.11:3 L=56 S=0x00 I=3940 F=0x0000 T=127 (#
5)
Jan  8 17:19:59 jumpgate kernel: Packet log: output REJECT eth1 PROTO=1
192.168.3.130:3 203.22.13.11:3 L=56 S=0x00 I=3941 F=0x0000 T=127 (#
5)
Jan  8 17:19:59 jumpgate kernel: Packet log: output REJECT eth1 PROTO=1
192.168.3.130:3 203.22.13.11:3 L=56 S=0x00 I=3941 F=0x0000 T=127 (#
5)




^ permalink raw reply

* Re: DMA timeouts on Promise 20267 IDE card
From: James Curbo @ 2003-01-10  5:14 UTC (permalink / raw)
  To: linux-kernel
In-Reply-To: <233C89823A37714D95B1A891DE3BCE5202AB1B6D@xch-a.win.zambeel.com>

On Jan 09, Manish Lachwani wrote:
> Can you also get the SMART data from the drives using smartctl? Also, it
> looks like the errors are happening on both the drives. Which UDMA mode are
> you operating in?
> 
> Thanks
> Manish

UDMA 5 for both of them. Here is the smartctl data:

carthage:/home/james# smartctl -v /dev/hda
Vendor Specific SMART Attributes with Thresholds:
Revision Number: 16
Attribute                    Flag     Value Worst Threshold Raw Value
(  1)Raw Read Error Rate     0x000b   200   199   051       0
(  3)Spin Up Time            0x0007   102   095   021       3733
(  4)Start Stop Count        0x0032   100   100   040       419
(  5)Reallocated Sector Ct   0x0032   160   160   112       160
(  7)Seek Error Rate         0x000b   100   253   051       0
(  9)Power On Hours          0x0032   079   079   000       15858
( 10)Spin Retry Count        0x0013   100   099   051       2
( 11)Calibration Retry Count 0x0013   100   100   051       0
( 12)Power Cycle Count       0x0032   100   100   000       358
(196)Reallocated Event Count 0x0032   126   126   000       74
(197)Current Pending Sector  0x0012   200   200   000       1
(198)Offline Uncorrectable   0x0012   200   200   000       0
(199)UDMA CRC Error Count    0x000a   200   253   000       65884
(200)Unknown Attribute       0x0009   200   199   051       1

carthage:/home/james# smartctl -v /dev/hdc
Vendor Specific SMART Attributes with Thresholds:
Revision Number: 16
Attribute                    Flag     Value Worst Threshold Raw Value
(  1)Raw Read Error Rate     0x000b   200   200   051       0
(  3)Spin Up Time            0x0007   101   093   021       2300
(  4)Start Stop Count        0x0032   100   100   040       96
(  5)Reallocated Sector Ct   0x0033   200   200   140       0
(  7)Seek Error Rate         0x000b   200   200   051       0
(  9)Power On Hours          0x0032   096   096   000       3325
( 10)Spin Retry Count        0x0013   100   253   051       0
( 11)Calibration Retry Count 0x0013   100   253   051       0
( 12)Power Cycle Count       0x0032   100   100   000       93
(196)Reallocated Event Count 0x0032   200   200   000       0
(197)Current Pending Sector  0x0012   200   200   000       0
(198)Offline Uncorrectable   0x0012   200   200   000       0
(199)UDMA CRC Error Count    0x000a   200   253   000       0
(200)Unknown Attribute       0x0009   200   200   051       0



-- 
James Curbo <hannibal@adtrw.org> <phoenix@sandwich.net>
http://www.adtrw.org/blogs/hannibal/

^ permalink raw reply

* Re: 2.4.20, .text.lock.swap cpu usage? (ibm x440)
From: Martin J. Bligh @ 2003-01-10  5:17 UTC (permalink / raw)
  To: Brian Tinsley, William Lee Irwin III; +Cc: linux-kernel
In-Reply-To: <3E1E50FB.4000301@emageon.com>

> IBM x360
> Pentium 4 Xeon MP processors
> 
> 2 processor system has 4GB RAM
> 4 processor system has 8GB RAM
> 
> 1 IBM ServeRAID controller
> 2 Intel PRO/1000MT NICs
> 2 QLogic 2340 Fibre Channel HBAs
> 
>> Or perhaps the kernel version is not up-to-date. Please also provide
>> the precise kernel version (and included patches). And workload too.
>> 
> The kernel version is stock 2.4.20 with Chris Mason's data logging and journal relocation patches for ReiserFS (neither of which are actually in use for any mounted filesystems). It is compiled for 64GB highmem support. And just to refresh, I have seen this exact behavior on stock 2.4.19 and stock 2.4.17 (no patches on either of these) also compiled with 64GB highmem support.
> 
> Workload:
> When the live-lock occurs, the system is performing intensive network I/O and intensive disk reads from the fibre channel storage (i.e., the backup program is reading files from disk and transferring them to the backup server). I posted a snapshot of sar data collection earlier today showing selected stats leading up to and just after the live-lock occurs (which is noted by a ~2 minute gap in sar logging). After the live-lock is released, the only thing that stands out is an unusual increase in runtime for kswapd (as reported by ps).
> 
> The various Java programs mentioned in prior postings are *mostly* idle at this point in time as it is after hours for our clients.


If you don't have any individual processes that need to be particularly
large (eg > 1Gb of data), I suggest you just cheat^Wfinesse the problem
and move PAGE_OFFSET from C0000000 to 80000000 - will give you more than
twice as much lowmem to play with. I think this might even be a config
option in RedHat kernels.

Martin.


^ permalink raw reply

* Re: 2.4.20, .text.lock.swap cpu usage? (ibm x440)
From: William Lee Irwin III @ 2003-01-10  5:24 UTC (permalink / raw)
  To: Brian Tinsley; +Cc: linux-kernel
In-Reply-To: <3E1E50FB.4000301@emageon.com>

At some point in the past, I wrote:
>> Or perhaps the kernel version is not up-to-date. Please also provide
>> the precise kernel version (and included patches). And workload too.

On Thu, Jan 09, 2003 at 10:50:03PM -0600, Brian Tinsley wrote:
> The kernel version is stock 2.4.20 with Chris Mason's data logging and 
> journal relocation patches for ReiserFS (neither of which are actually 
> in use for any mounted filesystems). It is compiled for 64GB highmem 
> support. And just to refresh, I have seen this exact behavior on stock 
> 2.4.19 and stock 2.4.17 (no patches on either of these) also compiled 
> with 64GB highmem support.

Okay, can you try with either 2.4.x-aa or 2.5.x-CURRENT?

I'm suspecting either bh problems or lowpte problems.

Also, could you monitor your load with the scripts I posted?


Thanks,
Bill

^ permalink raw reply

* Re: Nvidia and its choice to read the GPL "differently"
From: Oliver Xymoron @ 2003-01-10  5:33 UTC (permalink / raw)
  To: Richard Stallman; +Cc: lm, linux-kernel
In-Reply-To: <E18Wlsj-0000Zr-00@fencepost.gnu.org>

On Thu, Jan 09, 2003 at 06:14:37PM -0500, Richard Stallman wrote:
[GNU/Linux stuff deleted]

Can we all agree that this is indeed the kernel list and that the
kernel is indeed known as simply 'Linux' and that therefore the
GNU/Linux debate is off-topic here?

-- 
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.." 

^ permalink raw reply

* Re: [Lse-tech] Minature NUMA scheduler
From: Michael Hohnbaum @ 2003-01-10  5:36 UTC (permalink / raw)
  To: Martin J. Bligh
  Cc: Erich Focht, Robert Love, Ingo Molnar, linux-kernel, lse-tech
In-Reply-To: <52570000.1042156448@flay>

On Thu, 2003-01-09 at 15:54, Martin J. Bligh wrote:
> I tried a small experiment today - did a simple restriction of
> the O(1) scheduler to only balance inside a node. Coupled with
> the small initial load balancing patch floating around, this
> covers 95% of cases, is a trivial change (3 lines), performs 
> just as well as Erich's patch on a kernel compile, and actually
> better on schedbench.
> 
> This is NOT meant to be a replacement for the code Erich wrote,
> it's meant to be a simple way to get integration and acceptance.
> Code that just forks and never execs will stay on one node - but
> we can take the code Erich wrote, and put it in seperate rebalancer
> that fires much less often to do a cross-node rebalance. 

I tried this on my 4 node NUMAQ (16 procs, 16GB memory) and got
similar results.  Also, added in the cputime_stats patch and am 
attaching the matrix results from the 32 process run.  Basically,
all runs show that the initial load balancer is able to place the
tasks evenly across the nodes, and the better overall times show
that not migrating to keep the nodes balanced over time results
in better performance - at least on these boxes.

Obviously, there can be situations where load balancing across
nodes is necessary, but these results point to less load balancing
being better, at least on these machines.  It will be interesting
to repeat this on boxes with other interconnects.

$ reportbench hacksched54 sched54 stock54
Kernbench:
                        Elapsed       User     System        CPU
         hacksched54    29.406s    282.18s    81.716s    1236.8%
             sched54    29.112s   283.888s     82.84s    1259.4%
             stock54    31.348s   303.134s    87.824s    1247.2%

Schedbench 4:
                        AvgUser    Elapsed  TotalUser   TotalSys
         hacksched54      21.94      31.93      87.81       0.53
             sched54      22.03      34.90      88.15       0.75
             stock54      49.35      57.53     197.45       0.86

Schedbench 8:
                        AvgUser    Elapsed  TotalUser   TotalSys
         hacksched54      28.23      31.62     225.87       1.11
             sched54      27.95      37.12     223.66       1.50
             stock54      43.14      62.97     345.18       2.12

Schedbench 16:
                        AvgUser    Elapsed  TotalUser   TotalSys
         hacksched54      49.29      71.31     788.83       2.88
             sched54      55.37      69.58     886.10       3.79
             stock54      66.00      81.25    1056.25       7.12

Schedbench 32:
                        AvgUser    Elapsed  TotalUser   TotalSys
         hacksched54      56.41     117.98    1805.35       5.90
             sched54      57.93     132.11    1854.01      10.74
             stock54      77.81     173.26    2490.31      12.37

Schedbench 64:
                        AvgUser    Elapsed  TotalUser   TotalSys
         hacksched54      56.62     231.93    3624.42      13.32
             sched54      72.91     308.87    4667.03      21.06
             stock54      86.68     368.55    5548.57      25.73

hacksched54 = 2.5.54 + Martin's tiny NUMA patch +          
              03-cputimes_stat-2.5.53.patch +
              02-numa-sched-ilb-2.5.53-21.patch
sched54 = 2.5.54 + 01-numa-sched-core-2.5.53-24.patch + 
          02-ilb-2.5.53-21.patch02 +
          03-cputimes_stat-2.5.53.patch
stock54 - 2.5.54 + 03-cputimes_stat-2.5.53.patch

Detailed results from running numa_test 32:

Executing 32 times: ./randupdt 1000000 
Running 'hackbench 20' in the background: Time: 4.557
Job  node00 node01 node02 node03 | iSched MSched | UserTime(s)
  1   100.0    0.0    0.0    0.0 |    0     0    |  57.12
  2     0.0  100.0    0.0    0.0 |    1     1    |  55.89
  3   100.0    0.0    0.0    0.0 |    0     0    |  55.39
  4     0.0    0.0  100.0    0.0 |    2     2    |  56.67
  5     0.0    0.0    0.0  100.0 |    3     3    |  57.08
  6     0.0  100.0    0.0    0.0 |    1     1    |  56.31
  7   100.0    0.0    0.0    0.0 |    0     0    |  57.11
  8     0.0    0.0    0.0  100.0 |    3     3    |  56.66
  9     0.0  100.0    0.0    0.0 |    1     1    |  55.87
 10     0.0    0.0  100.0    0.0 |    2     2    |  55.83
 11     0.0    0.0    0.0  100.0 |    3     3    |  56.01
 12     0.0  100.0    0.0    0.0 |    1     1    |  56.56
 13     0.0    0.0  100.0    0.0 |    2     2    |  56.31
 14     0.0    0.0    0.0  100.0 |    3     3    |  56.40
 15   100.0    0.0    0.0    0.0 |    0     0    |  55.82
 16     0.0  100.0    0.0    0.0 |    1     1    |  57.47
 17     0.0    0.0  100.0    0.0 |    2     2    |  56.76
 18     0.0    0.0    0.0  100.0 |    3     3    |  57.10
 19     0.0  100.0    0.0    0.0 |    1     1    |  57.26
 20     0.0    0.0  100.0    0.0 |    2     2    |  56.48
 21     0.0    0.0    0.0  100.0 |    3     3    |  56.65
 22     0.0  100.0    0.0    0.0 |    1     1    |  55.81
 23     0.0    0.0  100.0    0.0 |    2     2    |  55.77
 24     0.0    0.0    0.0  100.0 |    3     3    |  56.91
 25     0.0  100.0    0.0    0.0 |    1     1    |  56.86
 26     0.0    0.0  100.0    0.0 |    2     2    |  56.62
 27     0.0    0.0    0.0  100.0 |    3     3    |  57.16
 28     0.0    0.0  100.0    0.0 |    2     2    |  56.36
 29   100.0    0.0    0.0    0.0 |    0     0    |  55.72
 30   100.0    0.0    0.0    0.0 |    0     0    |  56.00
 31   100.0    0.0    0.0    0.0 |    0     0    |  55.48
 32   100.0    0.0    0.0    0.0 |    0     0    |  55.59
AverageUserTime 56.41 seconds
ElapsedTime     117.98
TotalUserTime   1805.35
TotalSysTime    5.90

Runs with 4, 8, 16, and 64 processes all showed the same even
distribution across all nodes and 100% time on node for each
process.
-- 
Michael Hohnbaum            503-578-5486
hohnbaum@us.ibm.com         T/L 775-5486


^ permalink raw reply


This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.