Re: 2.4.2-ac20 patch for process time double-counting (was: Linux2.4.2 fails to merge mmap areas, 700% slowdown.)

[Mike Galbraith]

On 23 Mar 2001, Kevin Buhr wrote:

> Mike Galbraith <[EMAIL PROTECTED]> writes:
> >
> > > Mike, would you like to try out the following (untested) patch against
> > > vanilla ac20 to see if it does the trick?
> >
> > Yes, that fixed it.
>
> Great!  Can you test one more configuration, please?  I can't test it
> properly with my SMP motherboard.  Under "ac20", if you disable:
>
> Symmetric multi-processing support (CONFIG_SMP)
>
> you'll get to say yes to:
>
> APIC support on uniprocessors (CONFIG_X86_UP_APIC)
>
> If you say yes to that, you'll also get to say yes to:
>
> IO-APIC support on uniprocessors (CONFIG_X86_UP_IOAPIC)
>
> Can you check that the following patch against vanilla "ac20" works
> correctly with SMP disabled and X86_UP_APIC enabled?  (The original
> patch I gave you won't compile with this configuration, since I put
> the declaration in the wrong include file.)  It shouldn't matter
> whether X86_UP_IOAPIC is enabled or disabled.
>
> In addition to checking that the sys/user times look right, please
> check for the message:
>
> Using local APIC timer interrupts.

Times are fine.  Local APIC timer interrupts are used.

> in your boot messages (I *don't* think it'll be there, but I'm not
> sure, and I'd really like to know one way or the other).  In fact, if
> you could send me your kernel messages up to the PCI probe, that would
> be ideal.

Linux version 2.4.2-ac20 (root@el-kaboom) (gcc version gcc-2.95.3 20010315 (release)) 
#1 Sat Mar 24 07:57:01 CET 2001
BIOS-provided physical RAM map:
 BIOS-e820: 0009fc00 @  (usable)
 BIOS-e820: 0400 @ 0009fc00 (reserved)
 BIOS-e820: 0001 @ 000f (reserved)
 BIOS-e820: 07ef @ 0010 (usable)
 BIOS-e820: 3000 @ 07ff (ACPI NVS)
 BIOS-e820: d000 @ 07ff3000 (ACPI data)
 BIOS-e820: 0001 @  (reserved)
Scan SMP from c000 for 1024 bytes.
Scan SMP from c009fc00 for 1024 bytes.
Scan SMP from c00f for 65536 bytes.
Scan SMP from c009fc00 for 4096 bytes.
On node 0 totalpages: 32752
zone(0): 4096 pages.
zone(1): 28656 pages.
zone(2): 0 pages.
Local APIC disabled by BIOS -- reenabling.
Found and enabled local APIC!
mapped APIC to e000 (fee0)
Kernel command line: root=/dev/hda6,ro sb=220,5,1,7 mpu401=0x300,0 adlib=0x388 
BOOT_IMAGE=242ac20
Initializing CPU#0
Detected 499.176 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 996.14 BogoMIPS
Memory: 126500k/131008k available (1101k kernel code, 4120k reserved, 339k data, 204k 
init, 0k highmem)
Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes)
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 8192 (order: 4, 65536 bytes)
CPU: Before vendor init, caps: 0383fbff  , vendor = 0
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 512K
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: After vendor init, caps: 0383fbff   
CPU: After generic, caps: 0383fbff   
CPU: Common caps: 0383fbff   
CPU: Intel Pentium III (Katmai) stepping 03
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
Getting VERSION: 40011
Getting VERSION: 40011
Getting ID: 0
Getting ID: f00
Getting LVT0: 700
Getting LVT1: 400
enabled ExtINT on CPU#0
ESR value before enabling vector: 0040
ESR value after enabling vector: 
Using local APIC timer interrupts.
calibrating APIC timer ...
. CPU clock speed is 499.1652 MHz.
. host bus clock speed is 99.8329 MHz.
cpu: 0, clocks: 998329, slice: 499164
CPU0

> Thanks muchly!

Testing's easy, thanks for the fix.

-Mike

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Prevent OOM from killing init

[Doug Ledford]

"James A. Sutherland" wrote:
> On Thu, 22 Mar 2001, Guest section DW wrote:
> > (I think 2.4.0.)
> >
> > Clearly, Linux cannot be reliable if any process can be killed
> > at any moment.
> 
> What on earth did you expect to happen when the process exceeded the
> machine's capabilities? Using more than all the resources fails. There
> isn't an alternative.

You might be successful in convincing myself or Andries of this as soon as the
oom killer only kills things when the system is really out of memory.  Right
now, it's not really an oom killer, it's more like an "I'm Too Lazy To Free Up
Some More Pages So Now You Die" (ITLTFUSMPSNYD) killer.

-- 

 Doug Ledford <[EMAIL PROTECTED]>  http://people.redhat.com/dledford
  Please check my web site for aic7xxx updates/answers before
  e-mailing me about problems
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Prevent OOM from killing init

[Doug Ledford]

Horst von Brand wrote:
> 
> "Christian Bodmer" <[EMAIL PROTECTED]> said:
> 
> > I can't say I understand the whole MM system, however the random killing
> > of processes seems like a rather unfortunate solution to the problem. If
> > someone has a spare minute, maybe they could explain to me why running
> > out of free memory in kswapd results in a deadlock situation.
> 
> OOM is not "normal operations", it is a machine under very extreme stress,
> and should *never* happen. To complicate (or even worse, slow down or
> otherwise use up resources like memory) normal operations for "better
> handling of OOM" is total nonsense.

Puh-Leeze.   Let's inject some reality into this conversation:

[dledford@aic-cvs dledford]$ more kill-list 
Mar 10 22:02:34 monster kernel: Out of Memory: Killed process 475 (identd).
Mar 10 22:03:25 monster kernel: Out of Memory: Killed process 660 (xfs).
Mar 10 23:02:43 monster kernel: Out of Memory: Killed process 415 (rpc.statd).
Mar 11 01:20:31 monster kernel: Out of Memory: Killed process 397 (portmap).
Mar 11 01:37:09 monster kernel: Out of Memory: Killed process 474 (identd).
Mar 11 02:56:54 monster kernel: Out of Memory: Killed process 659 (xfs).
Mar 11 03:01:43 monster kernel: Out of Memory: Killed process 414 (rpc.statd).
Mar 11 03:09:30 monster kernel: Out of Memory: Killed process 396 (portmap).
Mar 11 03:37:30 monster kernel: Out of Memory: Killed process 538 (lpd).
Mar 11 03:49:46 monster kernel: Out of Memory: Killed process 493 (atd).
Mar 11 04:02:15 monster kernel: Out of Memory: Killed process 517 (sshd).
Mar 11 04:05:05 monster kernel: Out of Memory: Killed process 724 (bash).
Mar 11 05:02:40 monster kernel: Out of Memory: Killed process 717 (login).
Mar 11 05:54:04 monster kernel: Out of Memory: Killed process 718 (login).
Mar 11 13:34:25 monster kernel: Out of Memory: Killed process 20357 (bash).
Mar 11 16:04:12 monster kernel: Out of Memory: Killed process 5879 (diff).
Mar 11 16:52:41 monster kernel: Out of Memory: Killed process 7948 (tar).
Mar 11 17:37:09 monster kernel: Out of Memory: Killed process 10072 (tar).
Mar 11 17:42:26 monster kernel: Out of Memory: Killed process 10358 (tar).
Mar 11 18:24:30 monster kernel: Out of Memory: Killed process 11300
(run-parts).
Mar 11 19:23:56 monster kernel: Out of Memory: Killed process 11301
(set-time).
Mar 11 20:28:54 monster kernel: Out of Memory: Killed process 18165 (tar).
Mar 11 20:28:55 monster kernel: Out of Memory: Killed process 18167 (gzip).
Mar 11 21:30:51 monster kernel: Out of Memory: Killed process 21205 (tar).
Mar 11 21:33:09 monster kernel: Out of Memory: Killed process 11303 (rdate).
Mar 11 21:50:36 monster kernel: Out of Memory: Killed process 22195 (tar).
Mar 11 22:07:57 monster kernel: Out of Memory: Killed process 23049 (tar).
Mar 11 22:10:01 monster kernel: Out of Memory: Killed process 22987 (diff).
Mar 11 22:12:28 monster kernel: Out of Memory: Killed process 23233 (diff).
Mar 12 00:25:38 monster kernel: Out of Memory: Killed process 29692 (diff).
Mar 12 00:35:34 monster kernel: Out of Memory: Killed process 30229 (tar).
Mar 12 00:57:42 monster kernel: Out of Memory: Killed process 30796 (diff).
Mar 12 01:49:33 monster kernel: Out of Memory: Killed process 1153 (diff).
Mar 12 02:41:31 monster kernel: Out of Memory: Killed process 3488 (tar).
Mar 12 03:06:00 monster kernel: Out of Memory: Killed process 4257 (diff).
Mar 12 04:55:27 monster kernel: Out of Memory: Killed process 8845 (diff).
Mar 12 05:20:07 monster kernel: Out of Memory: Killed process 9712 (sh).
Mar 12 05:50:47 monster kernel: Out of Memory: Killed process 10475 (diff).
Mar 12 05:51:46 monster kernel: Out of Memory: Killed process 10838 (tar).
Mar 12 05:59:07 monster kernel: Out of Memory: Killed process 11162 (tar).
Mar 12 07:45:19 monster kernel: Out of Memory: Killed process 15489 (diff).
Mar 12 08:08:01 monster kernel: Out of Memory: Killed process 16340 (diff).
Mar 12 09:19:18 monster kernel: Out of Memory: Killed process 20182 (diff).
Mar 12 09:29:41 monster kernel: Out of Memory: Killed process 20237 (diff).
Mar 12 11:17:54 monster kernel: Out of Memory: Killed process 25611 (diff).
Mar 12 11:20:05 monster kernel: Out of Memory: Killed process 26133 (diff).
Mar 12 12:34:51 monster kernel: Out of Memory: Killed process 29826 (tar).
Mar 12 13:24:21 monster kernel: Out of Memory: Killed process 32281 (tar).
Mar 12 13:44:20 monster kernel: Out of Memory: Killed process 819 (tar).
Mar 12 13:49:37 monster kernel: Out of Memory: Killed process 1108 (tar).
Mar 12 14:03:46 monster kernel: Out of Memory: Killed process 1304 (diff).
Mar 12 14:26:29 monster kernel: Out of Memory: Killed process 2933 (tar).
Mar 12 14:29:08 monster kernel: Out of Memory: Killed process 3035 (diff).
Mar 12 14:45:53 monster kernel: Out of Memory: Killed process 3828 (diff).
Mar 12 15:06:05 monster kernel: Out of Memory: Killed process 4832 (tar).
Mar 12 16:03:42 monster kernel: Out of Memory: Killed process 7552 (tar).
Mar 12 17:10:35 monster kernel: Out

Re: /linuxrc query

[Stuart Lynne]

In article <[EMAIL PROTECTED]>,
David Woodhouse <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] said:
>>  Also as a note, what we are doing is keeping our rootfs on flash as a
>> tar.gz and  reading it and mounting it on a ramfs in the /linuxrc
>> before doing a pivot_root.  To summarize, pivot_root has been a life
>> saver as the earlier real_root_dev  might not have been useful in this
>> case. Not using the ramfs limits for now, will do soon.
>
>If you're concerned about memory usage - why untar the whole of your root
>filesystem into a ramfs? My preferred solution is to just mount the root
>filesystem directly from the flash as cramfs (or JFFS2), with symlinks into a
>ramfs for appropriate parts like /tmp and /var.
>
>I suppose the best option is actually to union-mount the ramfs over the 
>root, rather than mucking about with symlinks. I just haven't got round to 
>doing that yet.

Union would be fine. But until then I prefer ramfs as root with symlinks
to cramfs for anything that doesn't need to be writeable. 

-- 
__O 
Lineo - For Embedded Linux Solutions  _-\<,_ 
PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 (_)/ (_) 88 EC A3 EE 2D 1C 15 68
Stuart Lynne <[EMAIL PROTECTED]>   www.fireplug.net604-461-7532
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Prevent OOM from killing init

[Rik van Riel]

On Sat, 24 Mar 2001, Jonathan Morton wrote:

> Hmm...  "if ( freemem < (size_of_mallocing_process / 20) ) fail_to_allocate;"
> 
> Seems like a reasonable soft limit - processes which have already got
> lots of RAM can probably stand not to have that little bit more and
> can be curbed more quickly.

This looks like it could nicely in preventing a single process
from getting out of hand and gobbling up all memory.

It won't prevent the system from a mongolian horde of processes,
but nobody should expect your one-liner to fix world piece ;)

I like it, now lets test it ;)

regards,

Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

http://www.surriel.com/
http://www.conectiva.com/   http://distro.conectiva.com.br/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] Prevent OOM from killing init

[Juha Saarinen]

:: Your ideas sound really good, would you have the time to implement
:: them for 2.4 ?

2.4 or 2.5?

-- Juha
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Alert on LAN for Linux?

[Eric W. Biederman]

Alan Cox <[EMAIL PROTECTED]> writes:

> > things correctly they have enhanced Wake-on-LAN to allow you to do
> > things like reset the machine, update the BIOS and such by sending
> > magic packets which are interpreted by the network card. Or maybe I am
> 
> Normally 'sending magic packets resets the machine' is considered a feature
> reported to bugtraq. The alert stuff I have seen is more akin to sending SNMP
> traps for things like people opening the lid, or fan failure

I haven't quite be able to track this but I don't think that is how alert on
lan works.  Rev1 has a watch dog timer that can send a packet when
booting or whatever fails.  It looks like Rev2 hooked up that watchdog
timer to the power or the reset switch.  So it doesn't reboot for
everything but it does look like it can reboot for some specific
special cases.

And if it is of the watchdog timer approach it looks like it could
actually be useful.  Of course someone needs to track down the docs so
we can actually use it.

Eric

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Prevent OOM from killing init

[Rik van Riel]

On Fri, 23 Mar 2001, Guest section DW wrote:
> On Fri, Mar 23, 2001 at 11:56:23AM -0300, Rik van Riel wrote:
> > On Fri, 23 Mar 2001, Martin Dalecki wrote:
> 
> > > > Feel free to write better-working code.
> > > 
> > > I don't get paid for it and I'm not idling through my days...
> > 
> >   
> 
> No lies please.

You mean that you ARE willing to implement what you've been
arguing for?

Cool, I can't wait to see your patch.

Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

http://www.surriel.com/
http://www.conectiva.com/   http://distro.conectiva.com.br/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] MM update for PPC

[Paul Mackerras]

Linus,

The patch below updates the MM code for PowerPC to correspond with the
recent generic MM changes.  The patch is against 2.4.3-pre7, and it
affects only arch/ppc/mm/init.c, include/asm-ppc/pgalloc.h, and
include/asm-ppc/semaphore.h.

The changes to semaphore.h are only necessary because the definition
of INIT_MM in sched.h uses __RWSEM_INITIALIZER with the argument of
RW_LOCK_BIAS, meaning an unlocked semaphore.  I think RW_LOCK_BIAS is
at the very least a horrible name for something that means an unlocked
semaphore, and in fact it is really a private definition used in the
i386 semaphore code which should never be used in generic code like
this.  (But no I don't have a patch to fix this properly at the
moment.)

Paul.

diff -urN linux/arch/ppc/mm/init.c linuxppc_2_4/arch/ppc/mm/init.c
--- linux/arch/ppc/mm/init.cWed Mar 21 15:43:54 2001
+++ linuxppc_2_4/arch/ppc/mm/init.c Thu Mar 22 10:39:23 2001
@@ -110,7 +110,7 @@
 #endif
 
 void MMU_init(void);
-static void *MMU_get_page(void);
+void *early_get_page(void);
 unsigned long prep_find_end_of_memory(void);
 unsigned long pmac_find_end_of_memory(void);
 unsigned long apus_find_end_of_memory(void);
@@ -125,7 +125,7 @@
 unsigned long m8260_find_end_of_memory(void);
 #endif /* CONFIG_8260 */
 static void mapin_ram(void);
-void map_page(unsigned long va, unsigned long pa, int flags);
+int map_page(unsigned long va, unsigned long pa, int flags);
 void set_phys_avail(unsigned long total_ram);
 extern void die_if_kernel(char *,struct pt_regs *,long);
 
@@ -206,41 +206,20 @@
pmd_val(*pmd) = (unsigned long) BAD_PAGETABLE;
 }
 
-pte_t *get_pte_slow(pmd_t *pmd, unsigned long offset)
-{
-pte_t *pte;
-
-if (pmd_none(*pmd)) {
-   if (!mem_init_done)
-   pte = (pte_t *) MMU_get_page();
-   else if ((pte = (pte_t *) __get_free_page(GFP_KERNEL)))
-   clear_page(pte);
-if (pte) {
-pmd_val(*pmd) = (unsigned long)pte;
-return pte + offset;
-}
-   pmd_val(*pmd) = (unsigned long)BAD_PAGETABLE;
-return NULL;
-}
-if (pmd_bad(*pmd)) {
-__bad_pte(pmd);
-return NULL;
-}
-return (pte_t *) pmd_page(*pmd) + offset;
-}
-
 int do_check_pgt_cache(int low, int high)
 {
int freed = 0;
-   if(pgtable_cache_size > high) {
+   if (pgtable_cache_size > high) {
do {
-   if(pgd_quicklist)
-   free_pgd_slow(get_pgd_fast()), freed++;
-   if(pmd_quicklist)
-   free_pmd_slow(get_pmd_fast()), freed++;
-   if(pte_quicklist)
-   free_pte_slow(get_pte_fast()), freed++;
-   } while(pgtable_cache_size > low);
+if (pgd_quicklist) {
+   free_pgd_slow(get_pgd_fast());
+   freed++;
+   }
+   if (pte_quicklist) {
+   pte_free_slow(pte_alloc_one_fast());
+   freed++;
+   }
+   } while (pgtable_cache_size > low);
}
return freed;
 }
@@ -383,6 +362,7 @@
 __ioremap(unsigned long addr, unsigned long size, unsigned long flags)
 {
unsigned long p, v, i;
+   int err;
 
/*
 * Choose an address to map it to.
@@ -453,10 +433,20 @@
flags |= _PAGE_GUARDED;
 
/*
-* Is it a candidate for a BAT mapping?
+* Should check if it is a candidate for a BAT mapping
 */
-   for (i = 0; i < size; i += PAGE_SIZE)
-   map_page(v+i, p+i, flags);
+
+   spin_lock(&init_mm.page_table_lock);
+   err = 0;
+   for (i = 0; i < size && err == 0; i += PAGE_SIZE)
+   err = map_page(v+i, p+i, flags);
+   spin_unlock(&init_mm.page_table_lock);
+   if (err) {
+   if (mem_init_done)
+   vfree((void *)v);
+   return NULL;
+   }
+
 out:
return (void *) (v + (addr & ~PAGE_MASK));
 }
@@ -492,7 +482,7 @@
return (pte_val(*pg) & PAGE_MASK) | (addr & ~PAGE_MASK);
 }
 
-void
+int
 map_page(unsigned long va, unsigned long pa, int flags)
 {
pmd_t *pd;
@@ -501,10 +491,13 @@
/* Use upper 10 bits of VA to index the first level map */
pd = pmd_offset(pgd_offset_k(va), va);
/* Use middle 10 bits of VA to index the second-level map */
-   pg = pte_alloc(pd, va);
+   pg = pte_alloc(&init_mm, pd, va);
+   if (pg == 0)
+   return -ENOMEM;
set_pte(pg, mk_pte_phys(pa & PAGE_MASK, __pgprot(flags)));
if (mem_init_done)
flush_hash_page(0, va);
+   return 0;
 }
 
 #ifndef CONFIG_8xx
@@ -830,21 +823,16 @@
}
 }
 
-/* In fact t

Re: [PATCH] Prevent OOM from killing init

[Rik van Riel]

On Fri, 23 Mar 2001, Szabolcs Szakacsits wrote:

> When I ported your OOM killer to 2.2.x and integrated it into the
> 'reserved root memory' [*] patch, during intensive testing I found two
> cases when init was killed. It happened on low-end machines and when
> OOM killer wasn't triggered so init was killed in the page fault
> handler. The later was also one of the reasons I replaced the "random"
> OOM killer in page fault handler with yours [so there is only one OOM
> killer].

Good idea, we should do this for 2.4.  I cannot remember
reading an email from you about this, it's quite possible
I just missed it and didn't answer because I never read
it ...

> Other things that bothered me,
>  - niced processes are penalized

This can be considered a bug and should be fixed...

>  - trying to kill a task that is permanently in TASK_UNINTERRUPTIBLE
>will probably deadlock the machine [or the random OOM killer will
>kill the box].

This could indeed be a problem, though I cannot really see any
case where a task would be in TASK_UNINTERRUPTIBLE permanently.
OTOH, a 1GB read() will take a (much) too long time to finish.

Your ideas sound really good, would you have the time to implement
them for 2.4 ?

regards,

Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

http://www.surriel.com/
http://www.conectiva.com/   http://distro.conectiva.com.br/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Prevent OOM from killing init

[Rik van Riel]

On Fri, 23 Mar 2001, george anzinger wrote:

> What happens if you just make swap VERY large?  Does the system thrash
> it self to a virtual standstill?

It does.  I need to implement load control code (so we suspend
processes in turn to keep the load low enough so we can avoid
thrashing).

> Is this a possible answer?  Supposedly you could then sneak in and
> blow away the bad guys manually ...

This certainly works.

regards,

Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

http://www.surriel.com/
http://www.conectiva.com/   http://distro.conectiva.com.br/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] gcc-3.0 warnings

[Ion Badulescu]

On Fri, 23 Mar 2001 23:59:09 +0100, J . A . Magallon <[EMAIL PROTECTED]> wrote:
> 
> 
> On 03.23 Linus Torvalds wrote:
>> 
>> I agree. I'd much prefer that syntax also.
>> 
>> Or just remove the "default:" altogether, when it doesn't make any
>> difference.
>> 
> 
> Well, at last some sense. The same is with that ugly out: at the end
> of the function. Just change all that 'goto out' for a return.

No, no. Hell no. Multiple return paths in a function are a sure recipe
for errors creeping in later.

Just change the
out:;
into 
out:
return;
and be done with it. Heck, it even looks like C code for a change. :-)

Ion

-- 
  It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.4.2 fails to merge mmap areas, 700% slowdown.

[Linus Torvalds]

In article <[EMAIL PROTECTED]>,
Kevin Buhr <[EMAIL PROTECTED]> wrote:
>
>The results speak for themselves:
>
>CVS gcc 3.0:  Debian gcc 2.95.3:   RedHat gcc 2.96:
>  
>real16m8.423s real8m2.417s real12m24.939s
>user15m23.710suser7m22.200suser10m14.420s
>sys 0m48.730s sys 0m41.040ssys 2m13.910s 
>maps:<250 lines   <250 lines  >3000 lines
>
>Obviously, the *real* problem is RedHat GCC 2.96.  If Linus bothers to
>write this patch (he probably already has),

Check out 2.4.3-pre7, I'd be interested to hear what the system time is
for that one.

It does seem like gcc-2.96 is kind of special, but considering how easy
it is to merge anonymous memory (most of the changes were cosmetic ones
to get nice ordering to make the merge trivial without having to
allocate a vma that never gets used etc), it's certainly worth doing.

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Fix for serial.c to work with Xircom Cardbus Ethernet+Modem

[Tom Sightler]

> Tom Sightler wrote:
> >
> > Hi all,
> >
> > I saw a discussion on this list about this problem earlier, but could
not
> > find that it had actually been resolved.
>
> That was me :) and no, it doesn't work. Jeff Garzik asked me to enable
>  a couple debug #defines in serial.c, apply patches to serial.c and
>  finally disable i82365 support but as of now it doesn't work.
>
> It looks like we have the same card with modem @ 0x1880.

Yep, almost certainly the same, or at least very similar Xircom card.

> > Any ideas?  I may look at it more tomorrow.  For now I'm back to using
> > serial_cb which still works fine (even though that apparently suprises
many
> > people).
>
> :) this is -pre4 with serial_cb which works fine, and always has...

OK, can you try this patch?  It's very simple, and is probably not the
correct fix (the correct fix is probably to add the Xircom card to the
supported PCI table), but it works for me.  I'm not sure why the generic pci
serial code counts the number of iomem regions and only uses it if it has
exactly 0 or 1, but the Xircom has 2 iomem regions so the generic code fails
to use it.  The following change relaxes the generic code to allow for up to
2 iomem regions on a PCI serial device.  I have no idea what the side
effects would be to this change, but it makes my Xircom work again and that
was my goal.  If I can help someone fix this correctly let me know what you
need.

Later,
Tom

--- serial.c.oldFri Mar 23 23:23:17 2001
+++ serial.cFri Mar 23 23:24:17 2001
@@ -4616,10 +4616,10 @@
}

/*
-* If there is 1 or 0 iomem regions, and exactly one port, use
+* If there is <= 2 iomem regions, and exactly one port, use
 * it.
 */
-   if (num_iomem <= 1 && num_port == 1) {
+   if (num_iomem <= 2 && num_port == 1) {
board->flags = first_port;
return 0;
}


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.4.2 fails to merge mmap areas, 700% slowdown.

[Zack Weinberg]

Kevin Buhr wrote:
> Jakob Østergaard <[EMAIL PROTECTED]> writes:
> >
> > Try compiling something like Qt/KDE/gtk-- which are really heavy on
> > templates (with all the benefits and drawbacks of that).
> 
> Okay, I just compiled gtk-- 1.0.3 (with CFLAGS = "-O2 -g") under three
> versions of GCC (Debian 2.95.3, RedHat 2.96, and a CVS pull of the
> "gcc-3_0-branch") on the same Debian machine running kernel 2.4.2.
> 
> In all cases, the "cc1plus" processes appeared to max out around 25M
> total size. The "maps" pseudofiles for the 2.95.3 and and 3.0
> compiles never grew past 250 lines, but the "maps" pseudofiles for the
> RedHat 2.96 compile were gigantic, jumping to 3000 or 5000 lines at
> times.
> 
> The results speak for themselves:
> 
> CVS gcc 3.0:  Debian gcc 2.95.3:  RedHat gcc 2.96:
>   
> real 16m8.423sreal 8m2.417s   real 12m24.939s
> user 15m23.710s   user 7m22.200s  user 10m14.420s
> sys 0m48.730s sys 0m41.040s   sys 2m13.910s
> maps: <250 lines  <250 lines  >3000 lines

Let me inject some information about what gcc's doing in each version.

2.95.3 allocates its memory via a bunch of 'obstacks' which,
underneath, get memory from malloc, and therefore brk(2).  I'm very
surprised to see it had ~250 vmas; it should be more like 10.

2.96 and later versions use a garbage collecting allocator instead; it
was becoming much too hard to decide which obstack to use when.  The
garbage collector allocates memory with mmap(..., MAP_ANON, ...).
This is to avoid interfering with malloc, which is still used in many
places; and to get page-aligned memory without wasting tons of space,
as valloc(3) does.

In Red Hat's 2.96, that allocator gets memory from mmap one page at a
time.  If I understand what's going on in the kernel correctly, that
means each page is its own vma.  25 megs of GC arena is roughly 6400
vmas in that regime.

In CVS 3.0-to-be (and trunk), the allocator gets memory in 32-page
chunks instead.  So 25 megs of GC arena is only 200 vmas.

However, 25 megs of GC arena is small as these things go.  GCC's
memory consumption can _easily_ get up to 200 or 300 megs.  The
example I'm familiar with is insn-attrtab.c from GCC's own sources
(it's machine-generated code, with several huge functions).  256 megs
of GC arena, in 32-page chunks, is 2048 vmas.  Yes, at this point the
machine is swapping... but if I understand the issue, it's just when
we're swapping that having thousands of vmas causes problems.

In conclusion, I think that GCC's allocator still makes a good case
for merging vmas.

zw
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.4.2-ac24

[John Cavan]

Alan Cox wrote:
> 2.4.2-ac24

Is DRI still hosed?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.4.2-ac24

[Martin Josefsson]

On Sat, 24 Mar 2001, Alan Cox wrote:

> 
>   ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/
> 
>   Intermediate diffs are available from
> 
>   http://www.bzimage.org
> 
> (Note that the cmsfs port to 2.4 is a work in progress)
> 
> 2.4.2-ac24
> o Fix build bug with tsc in ac23  (me)
> o Update contact info for Phil Blundell   (Phil Blundell)
> o Update mm locking comments/rss locking  (Andrew Morton)
> o Update toshiba SMM driver   (Jonathan Buzzard)
> o Update old adaptec driver to 5.2.4  (Doug Ledford)
> o CS46xx updates  (Tom Woller)
> o Quieten input layer printks a bit   (me)
> o Turn off APIC_DEBUG by default to cut noise down(me)
> o Add Orinoco PCMCIA wireless support (David Gibson)
> o Go back to 2.4.3pre6 tulip  (Jeff Garzik)
> o Fix double accounting of cpu time bug   (Kevin Buhr)
> o Drop ppp patch  (me)
[snip a lot of changelogs, maybe drop the 2.4.1-ac ones?]

Alan, I guess the rumor about the gnomes living in a cave beneath Swansea
is true. 13h 23min between the -ac23 and -ac24 announcements.

/Martin

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Incorrect mdelay() results on Power Managed Machines x86

[sfr]

From: Alan Cox <[EMAIL PROTECTED]>
> 
> > On the ThinkPad 600E (at least), we get a Power Status Change APM event.
> 
> Any reason we couldn't recalibrate the bogomips on a power status change,
> at least for laptops we know appear to need it (I can make the DMI code look
> for matches there..)

No reason at all ... I'll have a look.  I don't have my ThinkPad any more
(as of yesterday) so someone will have to supply the DMI info to match.
I will add another field to the apm_info structure that the DMI code can set
and then just test for it in the APM event loop.

Note, however, that there will still be a latency of up to a second
before we discover this situation as that is how often we poll the
BIOS for events.

Cheers,
Stephen Rothwell
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Fwd: Re: [PATCH] Prevent OOM from killing init

[Ed Tomlinson]

,--- Forwarded message (begin)

 Subject: Re: [PATCH] Prevent OOM from killing init
 From: Jonathan Morton <[EMAIL PROTECTED]>
 Date: Fri, 23 Mar 2001 20:45:43 -0500

 >Hmm...  "if ( freemem < (size_of_mallocing_process / 20) ) fail_to_allocate;"

Not sure this is that reasonable on a 4G box... 800M is a big chunk...

Why not base this on the vm's free goal.  If I remember correctly it tries to keep one
second of pages ready for allocating.  If memory is so tight that a second's worth of
memory does not exist.  Note that I mean memory free in main memory and swap.

Think your malloc patch along with UID weighting (1-99 protected, 100-999 endangered, 
1000+ open season - with poaching expected if there is no choise) will make help oom 
processing.

Ed Tomlinson

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Prevent OOM from killing init

[Andreas Franck]

Hi together,

seems like a hot discussion going on, but I couldn't resist and would like to
throw in my $0.02.

Besides misunderstandings and general displeasure, some very interesting
facts have shown up in the discussion (oh, yeah), which I'd like to know more
about, and just extend them with a bit of my latest experience regarding
memory usage.

First one is about buffer/inode cache. What I expect as a medium-skilled
system hacker would be: Before giving up with an OOM-whatever,

a) all non-dirty buffers should be freed, possibly giving tons of memory
b) all dirty buffers should be flushed and freed, alas

I'm not sure if both is tried ATM, but I think enough experts are here to
answer my questions :)

What I saw lately was some general system sluggishness after copying very big
files (ripping a CD image to disk) - it seems the system has paged out most
of its processes (including the calling bash shell) in favor of the copying
task, just for buffers! Up to which degree is this reasonable? It seems to
slow down the system when using swap, so for this task I better had
deactivated it. Not what one "intuitively" expects.

So, what is the second important point? The current system cannot properly
distinguish between memory an application "really" needs and memory an
application "eventually" needs (as internal caches, ...).

A possible solution could be the implementation of something like SIGDANGER,
which would be sent to an application in case of memory overload, so
it should try to free a bit memory if it can. Surely applications would have
to be modified to use that information. How about the C library, does it
maintain any big buffers, for I/O or so? I don't know, changes there could
surely be passed on transparently. Ok, ok, it's the MacOS way of thinking, so
the other possibility. This problems are intimately related to memory
overcommitting, or not doing so, so what might be fatal in overcommitting?

One problem arises if an application gets a huge part of overcommitted memory
and then tries to use it, which spontaneously fails - just because the memory
was committed somewhere else, to the 999 other apps which are already
 running.

The flaw there is that at some time, you can guarantee that the overcommit
would fail, if the memory was really used. At this point, the application
could be halted (so that it does not get the chance to make use of the
overcommit promise), until some more memory is available again - either by
paging, or by waiting for other jobs to terminate. This could lead to
starvation, but it potentially could let the system survive.

A further idea would be to use overcommitted memory only for buffers and
caches, this was already mentioned before. In any situation "near" an OOM,
further memory pressure should be avoided - for example, by letting malloc()
fail. This might also hurt existing processes, so some heuristics could
decide - a malloc() from a freshly started process should fail regardlessly
of its size, while older processes might get some more tolerance, because the
system might trust their behaviour a bit more.

So far from me, this was just a collection of some more or less unrelated
thoughts, which I'd like to know a bit more about, or hear from experts why
all of this is b*llshit (or: already done(TM)!)

Greetings,
Andreas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Prevent OOM from killing init

[Paul Jakma]

On Sat, 24 Mar 2001, Szabolcs Szakacsits wrote:

> Nonsense hodgepodge. See and/or mesaure the impact. I sent numbers in my
> former email. You also missed non-overcommit must be _optional_ [i.e.
> you wouldn't be forced to use it ;)]. Yes, there are users and
> enterprises who require it and would happily pay the 50-100% extra swap
> space for the same workload and extra reliability.

ok.. the last time OOM came up, the main objection to fully
guaranteed vm was the possible huge overhead.

if someone knows how to do it without a huge overhead, i'd love to
see it and try it out.

> At every time you add/delete users, add/delete special apps, etc.

no.. pam_limits knows about groups, and you can specify limit for
that group, one time.

@user ... ... ...

> Rik's killer is quite fine at _default_. But there will be always
> people who won't like it

exactly... so lets try avoid ever needing it. it is a last resort.

> default, use the /proc/sys/vm/oom_killer interface"? As I said
> before there are also such patch by Chris Swiedler and definitely
> not a huge, complex one.

uhmm.. where?

> And these stupid threads could be forgotten for good and all.

:)

>   Szaka

regards,
-- 
Paul Jakma  [EMAIL PROTECTED]   [EMAIL PROTECTED]
PGP5 key: http://www.clubi.ie/jakma/publickey.txt
---
Fortune:
The optimum committee has no members.
-- Norman Augustine

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Prevent OOM from killing init

[Paul Jakma]

On Sat, 24 Mar 2001 [EMAIL PROTECTED] wrote:

> No, ulimit does not work. (But it helps a little.)

no, not perfect, i very much agree. but in daily usage it reduces
chance of OOM to close to 0.

> No, /proc/sys/vm/overcommit_memory does not work.

that's because it disables the very rough resource checking that
linux has. it makes OOM even easier to achieve:

mm/mmap.c::vm_enough_memory():

/* Sometimes we want to use more memory than we have. */
if (sysctl_overcommit_memory)
return 1;

it doesn't make linux go into a 'non-overcommit' mode, cause linux
does not have the accounting to cover it...

solution according to more knowledgable folks than i, sysadmin, is
better accounting so that vm_enough_memory can be more accurate
rather than developing an all-seeing oom_killer().

> Andries

regards,
-- 
Paul Jakma  [EMAIL PROTECTED]   [EMAIL PROTECTED]
PGP5 key: http://www.clubi.ie/jakma/publickey.txt
---
Fortune:
"We are on the verge: Today our program proved Fermat's next-to-last theorem."
-- Epigrams in Programming, ACM SIGPLAN Sept. 1982

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Prevent OOM from killing init

[Jonathan Morton]

>Hmm...  "if ( freemem < (size_of_mallocing_process / 20) ) fail_to_allocate;"
>
>Seems like a reasonable soft limit - processes which have already got lots
>of RAM can probably stand not to have that little bit more and can be
>curbed more quickly.  Processes with less probably don't deserve to die and
>furthermore are less likely to be engineered to handle malloc() failure, so
>failure only occurs closer to the mark.  In this scenario OOM killing
>(which is, after all, a last resort) should trigger rarely and simple
>malloc() failure (which userspace apps can cope with more easily) is an
>early-warning and prevention system.

Following up my own post with some action, I hacked 2.4.1's
mm/mmap.c::vm_enough_pages() to include something similar to the above
algorithm.  In fact, it triggers malloc() failure when 1/16th of
current->mm->total_vm would be greater than the sum of the free space and
the potentially-allocated area.

My very quick tests show that my test program (the rogue allocator) now in
fact does encounter a failed malloc() at approx. 475M, instead of being
killed by the OOM handler at approx. 490M.  This is pretty much the desired
behaviour.

If someone would like me to post a patch and have it tested, I'd be happy
to do so.

--
from: Jonathan "Chromatix" Morton
mail: [EMAIL PROTECTED]  (not for attachments)
big-mail: [EMAIL PROTECTED]
uni-mail: [EMAIL PROTECTED]

The key to knowledge is not to rely on people to teach you it.

Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/

-BEGIN GEEK CODE BLOCK-
Version 3.12
GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS
PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*)
-END GEEK CODE BLOCK-


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Panic] 2.4.2ac22

[Keith Owens]

On Fri, 23 Mar 2001 19:44:16 -0500 (EST), 
[EMAIL PROTECTED] (root) wrote:
>Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(shmem_file_setup) not 
>found in System.map.  Ignoring ksyms_base entry

Against 2.4.2-ac23 to remove above warning.

Index: 2.45/mm/Makefile
--- 2.45/mm/Makefile Fri, 05 Jan 2001 13:42:29 +1100 kaos (linux-2.4/j/19_Makefile 1.1 
644)
+++ 2.45(w)/mm/Makefile Sat, 24 Mar 2001 12:37:25 +1100 kaos (linux-2.4/j/19_Makefile 
+1.1 644)
@@ -9,6 +9,8 @@
 
 O_TARGET := mm.o
 
+export-objs := shmem.o
+
 obj-y   := memory.o mmap.o filemap.o mprotect.o mlock.o mremap.o \
vmalloc.o slab.o bootmem.o swap.o vmscan.o page_io.o \
page_alloc.o swap_state.o swapfile.o numa.o oom_kill.o \

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: VIA vt82c686b and UDMA(100)

[Brian Dushaw]

Thanks to all for their advice on this problem.  So far I've tried
hdparm flags six ways from sunday to no effect, but I have yet to
try suggestions such as those below.  Alas I have to set aside this
problem for the next few weeks.

In the mean time, I note that the linux machines at my Lab are being
subjected to fairly severe security attacks at the moment (the latest
involved a hold in the bind DNS server (?) ) - a reminder
to all to keep applying those updates and security patches.

B.D.

On Fri, 23 Mar 2001, David Balazic wrote:

> Brian Dushaw ([EMAIL PROTECTED]) wrote :
>
> > Dear Linux Kernel Wisemen,
> >I have been following the discussion of the VIA vt82c686b chipset
> > and the troubles people have had in getting UDMA(100) to work. This
> > is to report that I have now tried the 2.4.2-ac20 kernel and the
> > 2.2.18 kernel with Andre's patch (dated March 20) and neither of
> > them get the disk speed up to where it ought to be. hdparm -t reports
> > back 11 MB/s or so for either kernel.
> >VIA82CXXX enabled, and I also tried the ide0=ata66 flag, in desparation.
> >At boot up both kernels report the disk as UDMA(100) - everything
> > seems to be peachy keen, but for the sluggish disk performance.
> >
> > Merely a report from the front lines,
> >
> > B.D.
>
> Do you also have IDE_AUTO_WHATEVER option enabled ,
> as suggested ( no, commanded ) in the VIA_IDE_OPTION help text ?
> ( press '?' when selecting the VIA IDE driver option )
>
> cat /proc/ide/via ?
>
> What do you think is the "correct" transfer rate of the disk ?
>
> For the record , I have a MSI K7T Pro2A board ( VIA KT133 with a
> vt82c686b south bridge ) and a IBM DTLA 307045 hard drive on a 80
> wire IDE cable ( set to CABLE-SELECT , connected to the end connector;
> you must always first use both connectors on the end of the cable !
> never left one end unused )
>
> Without doing any settings with hdparm, I get the full transfer rate
> of the disk, measured with hdparm : ~35MB/s
>
>
> kernel is 2.4.recent or redhat recent 2.4.x versions.
>
>

-- 
%

Brian Dushaw
Applied Physics Laboratory
University of Washington
1013 N.E. 40th Street
Seattle, WA  98105-6698
(206) 685-4198   (206) 543-1300
(206) 543-6785 (fax)
[EMAIL PROTECTED]

Web Page:  http://staff.washington.edu/dushaw/index.html

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Channel bonding kernel crash, workaround

[Jeff Golds]

I heard about this issue, and just joined the mailing list.  I am
working on a driver similar to the bonding driver and am getting the
same results.

If I do the following:
ifconfig fte0 10.0.0.2 up
ifenslave fte0 eth1
ifenslave fte0 eth2
ifconfig fte0 down
ifconfig eth1

I get a kernel panic.  I checked the Oops log and saw the following with
ksymoops:

Oops: 
EIP: 0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
Call Trace: [] [] [] []
[] [] [] [] []
[] []
Code: 0f b6 4b 0b 8d 73 04 8b 7c 24 24 fc 39 c9 89 0c 24 f3 a6 0f
 
>>EIP; c020c7c9<=
Trace; c0232d52 
Trace; c0232d80 
Trace; c02330d6 
Trace; c02310f7 
Trace; c011f1d7 
Trace; c020a943 
Trace; c020b9cf 
Trace; c0230a04 
Trace; c0206388 
Trace; c0142977 
Trace; c0109127 
Code;  c020c7c9 
 <_EIP>:
Code;  c020c7c9<=
   0:   0f b6 4b 0b   movzbl 0xb(%ebx),%ecx   <=
Code;  c020c7cd 
   4:   8d 73 04  lea0x4(%ebx),%esi
Code;  c020c7d0 
   7:   8b 7c 24 24   mov0x24(%esp,1),%edi
Code;  c020c7d4 
   b:   fccld
Code;  c020c7d5 
   c:   39 c9 cmp%ecx,%ecx
Code;  c020c7d7 
   e:   89 0c 24  mov%ecx,(%esp,1)
Code;  c020c7da 
  11:   f3 a6 repz cmpsb %es:(%edi),%ds:(%esi)
Code;  c020c7dc 
  13:   0f 00 00  sldt   (%eax)

This is AFTER I removed the code in my driver to set the slave devices'
multicast lists to be equal to the master's.  When I put that code back
in (see bond_set_multicast_list in bonding.c), I get a crash at the same
location, but the call trace is slightly different.

It's looking like the multicast list is either corrupted or the data was
freed elsewhere.

Anyone have any ideas what might be wrong?  The driver I am working on
is a close match to the bonding driver, so that can be used as a
reference.

Thanks for any feedback.

-Jeff

P.S.  I saw the workaround posted earlier, but I am trying to fix this
crash.

-- 
Jeff Golds
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Linux 2.4.2-ac24

[Alan Cox]

ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/

Intermediate diffs are available from

http://www.bzimage.org

(Note that the cmsfs port to 2.4 is a work in progress)

2.4.2-ac24
o   Fix build bug with tsc in ac23  (me)
o   Update contact info for Phil Blundell   (Phil Blundell)
o   Update mm locking comments/rss locking  (Andrew Morton)
o   Update toshiba SMM driver   (Jonathan Buzzard)
o   Update old adaptec driver to 5.2.4  (Doug Ledford)
o   CS46xx updates  (Tom Woller)
o   Quieten input layer printks a bit   (me)
o   Turn off APIC_DEBUG by default to cut noise down(me)
o   Add Orinoco PCMCIA wireless support (David Gibson)
o   Go back to 2.4.3pre6 tulip  (Jeff Garzik)
o   Fix double accounting of cpu time bug   (Kevin Buhr)
o   Drop ppp patch  (me)

2.4.2-ac23
o   Fix a nasty shared memory locking bug   (Stephen Tweedie)
o   Fix off by one bootmem memory corruptor (Ben LaHaise)
o   Fix avmb1 oops on init  (Carsten Paeth)
o   Fix isdn makefile bugs  (Kai Germaschewski)
o   Clean up isdn minor checks  (Julien Gaulmin)
o   Workaround PPP CCP negotiation bugs (Kai Germaschewski)
o   Fix timer handling bug in ISDN  (Henk-Jan Slotboom)
o   Fix i386 #ifdef bug with notsc disable  (Anton Blanchard)
o   Fix NMI docs(Keith Owens)
o   Fix oops on out of memory in proc_symlink   (me)
| Found by Stanford tools
o   Fix oops caused by devfs changes to soundcore   (me)
| Found by Stanford tools
o   Fix rmmod crash on sundance alta(me)
| Found by Stanford tools
o   Fix potential crash in nsc-ircc.c   (me)
| Found by Stanford tools
o   Fix memory leak in i810 audio   (Doug Ledford)
o   Fix several compile warnings with gcc 3.0 cvs   (J Magallon)
o   Mark 60Hz modes in mac fb modes (Geert Uytterhoeven)
o   Chkconfig and ver_linux updates (Niels Jensen)
o   Fix ctrlfb dac timing   (Takashi Oe)
o   Add vesa powerdown support for ctrlfb   (Takashi Oe)
o   Back out problem via bridge change  (me)
o   Fix bug in aironet4500_cs changes   (Arjan van de Ven)

2.4.2-ac22
o   Fix dereference after free in megaraid driver   (me)
o   Fix crash if we run out of memory during a link (me)
follow [found by Stanford tools]
o   Fix crash if we run out of memory during
block_truncate_page [found by Stanford tools]   (me)
o   Update Alpha to pre6 style pte/pmd_alloc(Ivan Kokshaysky)
o   Fix ppp memory corruption   (Kevin Buhr)
| Bizzarely enough a direct re-invention of a 1.2 ppp bug
o   Fix heavy stack usage in tty_foo_devfs()(Jeff Dike)
o   Make alloc_tty_struct always use kmalloc(Andrew Morton)
o   Document task struct locking rules  (Andrew Morton)
o   Document SAK properly   (Andrew Morton)
o   Fix SAK deadlocks   (Andrew Morton)
o   Fix inline/type order for picky compiler tools  (Dave Jones)
o   Fix printk levels for various fs printks that   (Andrey Panin)
lacked them
o   Next incarnation of the i810 audio driver   (Doug Ledford)
o   Add __init stuff to 3c515 driver(Andrzej Krzysztofowicz)
o   Add __init stuff to ppp layer   (Andrzej Krzysztofowicz)
o   Remove duplicate NF_TARGET_TCPMSS config text   (Steven Cole)
o   Fix missing unlock_kernel in pcwd   (me)
| Found by Stanford tools
o   Fix missing unlock_kernels in es1371(me)
| Found by Stanford tools
o   Fix missing unlock_kernels in es1370(me)
| Found by Stanford tools
o   Fix missing unlock_kernels in esssolo1  (me)
| Found by Stanford tools
o   Fix missing unlock kernels in sonicvibes(me)
| Found by Stanford tools
o   Fix missing unlock kernels in fb mmap   (me)
| Found by Stanford tools
o   Fix missing unlock_super in UFS code(me)
| Found by Stanford tools


2.4.2-ac21
o   Merge with Linus 2.4.3pre6
o   Close last known reiserfs tail bug  (Chris Mason)
o   Fix link order bug with iso8859_8 and cp1255(Dan Aloni)
o   Generate generic CPU namings for 386/486(Cesar Eduardo Barros)
o   First set of ISDN fixes from Stanford code  (Kai Germaschewski)
analyser
o   Allow 

Re: [PATCH] gcc-3.0 warnings

[Stephen Satchell]

At 04:31 PM 3/23/01 -0800, you wrote:
>This has nothing to do with fastpathing and object code optimization. C
>doesn't have exception handling, so you either have to remember to undo
>allocations etc.  in failure cases all through the code, or you stick your
>undo code at the end of the function and have all failure cases jump to the
>relevant label.  It's not pretty, but it's much less error-prone e.g.

Really?  I have a "cleanup" function that can be called during failure 
cases (and success cases -- but you didn't mention that) so that the cost 
is very low and I don't have to code ANY labels.

But then again, I'm a double-pipe abuser, in that I tend to code "atomic" 
sequences as

if ((a) || (b) || (c) || (d) || (e) || (f) || (g) || ... ) { something 
failed}  else {it all worked!}

and make sure that the failure value is non-zero for each a, b, c, d, and 
so forth.

I remember looking at the generated code from one compiler for x86 and 
seeing a series of short jumps to short jumps to short jumps... to the 
failure case, which in that particular sequence saved about 100 bytes.  I 
haven't looked at GCC output yet to see what it does, but working in a 
32-bit system instead of a 16-bit system I tend to care a little less about 
"efficiency".

Does that mean that I avoid "goto"?  No. Like every other construct in the 
C language, there is a valid and appropriate use for every single 
thing.  The key is recognizing when the goto is appropriate.

Another thing you will see in my code is resource pointers being 
initialized to zero on entry, set to non-zero values as resources are 
allocated, and then conditionally released based on whether the value is 
zero or non-zero.  It makes recovery from malloc failures easier, for one 
thing.

Satch. the || Abuser.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

PATCH: fix comments in

[Tim Wright]

Micro patchlet :-)
In wandering around the kernel recently, I found that 
contains stale comments at the head of the file relating to the old static
timers which were deleted for 2.4.
So, here's a trivial patch to try to bring things back in sync.

Regards,

Tim


--- timer.h.2.4.2   Fri Mar 23 13:57:51 2001
+++ timer.h Fri Mar 23 14:07:00 2001
@@ -5,17 +5,13 @@
 #include 
 
 /*
- * This is completely separate from the above, and is the
- * "new and improved" way of handling timers more dynamically.
- * Hopefully efficient and general enough for most things.
+ * In Linux 2.4, static timers have been removed from the kernel.
+ * Timers may be dynamically created and destroyed, and should be initialized
+ * by a call to init_timer() upon creation.
  *
- * The "hardcoded" timers above are still useful for well-
- * defined problems, but the timer-list is probably better
- * when you need multiple outstanding timers or similar.
- *
- * The "data" field is in case you want to use the same
- * timeout function for several timeouts. You can use this
- * to distinguish between the different invocations.
+ * The "data" field enables use of a common timeout function for several
+ * timeouts. You can use this field to distinguish between the different
+ * invocations.
  */
 struct timer_list {
struct list_head list;


-- 
Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED]
IBM Linux Technology Center, Beaverton, Oregon
Interested in Linux scalability ? Look at http://lse.sourceforge.net/
"Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Prevent OOM from killing init

[Andries . Brouwer]

> It was actually worse than that. Grab your copy of "Lions", and check lines
> 4375-4377 in function xswap(). A failure to allocate space in the swapmap
> caused a panic. Same problem in xalloc().

[no Lions nearby; somewhere I still have the printout but am
too lazy to search; I also have the tape but nothing to read it with]

yes, you may well be right if you say that my picture
of the distant past is too rosy - maybe I forgot all
this trouble
still - yesterday I lost three edit sessions -
I do not recall any such occurrence in the 25 years before

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: your mail

[Tim Wright]

Hmmm...
you don't really give enough information to make much of a guess.
I'd do the following:
Grab at least 2.2.18, or even better, get Alan's 2.2.19pre (which is almost
2.2.19 now, I believe), and build and install that kernel.

Now, if you run into the same problems, record the crash details, especially
if the kernels oopses, and then send the information (kernel version, output
of ksymoops if there is an oops, kernel .config used etc.) to the mailing list.

Tim

On Sat, Mar 24, 2001 at 05:34:39AM +0530, dhar wrote:
> Hi,
> 
> I am not a member of either of these lists and would appreciate if you could send 
>your replies to me personally.
> 
> Now the problem:
> 
> I have an IBM Netfinity X330 server. Dual Processor (PIII 800). I compiled kernel 
>2.2.14 with SMP support. NFS was however compiled as a module. 
> 
> Now the problem is as follows:
> 
> Most of the times the machine just works fine. 
> But whenever there is heavy disk write activity it just hangs/crashes. Also this is 
>when the SMP kernel is used. If I use the normal kernel then there is no problem. 
> 
> Could any one tell me what has to be done to prevent this from happening? 
> 
> Any help in this regard will be very much appreciated.
> 
> Once again, kindly reply to me personally as I am not a member of either of these 
>lists.
>  
> Regards
> Dhar 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED]
IBM Linux Technology Center, Beaverton, Oregon
Interested in Linux scalability ? Look at http://lse.sourceforge.net/
"Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] gcc-3.0 warnings

[J . A . Magallon]

On 03.24 Andrew Morton wrote:
> "J . A . Magallon" wrote:
> > 
> >  The same is with that ugly out: at the end
> > of the function. Just change all that 'goto out' for a return.
> 
> Oh no, no, no.  Please, no.
> 
> Multiple return statements are a maintenance nightmare.
> 

Well, I do not want this to restart a religion war.

The real thing is: gcc 3.0 (ISO C 99) does not like that practice
(let useless things there for someday using them ?). And there can be
other languaje issues also (I'm just thinkin of some issues with case and
no default:) And gcc-3 is what we will
have to live with. I suppose people will like to see a kernel build
without tons of wanings. They hide real errors.

I think its a good thing to decide what to do (and start doing), than wait
until gcc2.95 is buried.

-- 
J.A. Magallon  #  Let the source
mailto:[EMAIL PROTECTED]  #  be with you, Luke... 

Linux werewolf 2.4.2-ac22 #3 SMP Fri Mar 23 02:06:00 CET 2001 i686

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Panic] 2.4.2ac22

[root]

Hi,

Yet another one.  This time with all the traceback entries...

Ed

ksymoops 2.3.7 on i586 2.4.2-ac22.  Options used
 -V (default)
 -k 20010323183444.ksyms (specified)
 -l 20010323183444.modules (specified)
 -o /lib/modules/2.4.2-ac22/ (default)
 -m /boot/System.map-2.4.2-ac22 (default)

Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(shmem_file_setup) not 
found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): snd symbol pm_register not found in 
/usr/lib/alsa-modules/2.4.2-ac22/0.5/snd.o.  Ignoring 
/usr/lib/alsa-modules/2.4.2-ac22/0.5/snd.o entry
Warning (compare_maps): snd symbol pm_send not found in 
/usr/lib/alsa-modules/2.4.2-ac22/0.5/snd.o.  Ignoring 
/usr/lib/alsa-modules/2.4.2-ac22/0.5/snd.o entry
Warning (compare_maps): snd symbol pm_unregister not found in 
/usr/lib/alsa-modules/2.4.2-ac22/0.5/snd.o.  Ignoring 
/usr/lib/alsa-modules/2.4.2-ac22/0.5/snd.o entry
8139too Fast Ethernet driver 0.9.15 loaded
Unable to handle kernel paging request at virtual address ef1f
c01b2b53
*pde = 
Oops: 
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010202
eax: d1ce1b00   ebx: ef1f   ecx:    edx: ef1f
esi: c8fd25a0   edi: d1ce1ba0   ebp: 0060   esp: c0227de0
ds: 0018   es: 0018   ss: 0018
Process swapper (pid: 0, stackpage=c0227000)
Stack: 0100 c01b2bfb c8fd25a0 0100 c8fd25a0 c01b310a c8fd25a0 c8fd25a0 
   d3eae800 d1a122a0 d3eae800 c01b589a c8fd25a0 0002 c6b4b160 c8fd25a0 
   c01b8973 c8fd25a0 c8fd25a0  0004 c01c268c c01c2705 c8fd25a0 
Call Trace: [] [] [] [] [] 
[] [] 
   [] [] [] [] [] [] 
[] [] 
   [] [] [] [] [] [] 
[] [] 
   [] [] [] [] [] [] 
[] 
Code: 8b 1b 8b 42 70 83 f8 01 74 0a ff 4a 70 0f 94 c0 84 c0 74 09 

>>EIP; c01b2b53<=
Trace; c01b2bfb 
Trace; c01b310a 
Trace; c01b589a 
Trace; c01b8973 
Trace; c01c268c 
Trace; c01c2705 
Trace; c01ba937 
Trace; c01bff2c 
Trace; c01c2672 
Trace; c01c268c 
Trace; c01bff7a 
Trace; c01ba937 
Trace; c01bfed8 
Trace; c01bff2c 
Trace; c01bf200 
Trace; c01bf34f 
Trace; c01bf200 
Trace; c01ba937 
Trace; c01bf075 
Trace; c01bf200 
Trace; c01b5e2b 
Trace; c0117510 
Trace; c010a172 
Trace; c01071f0 
Trace; c0108e80 
Trace; c01071f0 
Trace; c0107213 
Trace; c0107277 
Trace; c0105000 
Trace; c0100191 
Code;  c01b2b53 
 <_EIP>:
Code;  c01b2b53<=
   0:   8b 1b mov(%ebx),%ebx   <=
Code;  c01b2b55 
   2:   8b 42 70  mov0x70(%edx),%eax
Code;  c01b2b58 
   5:   83 f8 01  cmp$0x1,%eax
Code;  c01b2b5b 
   8:   74 0a je 14 <_EIP+0x14> c01b2b67 

Code;  c01b2b5d 
   a:   ff 4a 70  decl   0x70(%edx)
Code;  c01b2b60 
   d:   0f 94 c0  sete   %al
Code;  c01b2b63 
  10:   84 c0 test   %al,%al
Code;  c01b2b65 
  12:   74 09 je 1d <_EIP+0x1d> c01b2b70 


 <0>Kernel panic: Aiee, killing interrupt handler!
invalid operand: 
CPU:0
EIP:0010:[]
EFLAGS: 00010282
eax: 0018   ebx: c0227bac   ecx: c9da8000   edx: c0213a44
esi: c9226c60   edi: c0226000   ebp: c0227b98   esp: c0227b70
ds: 0018   es: 0018   ss: 0018
Process swapper (pid: 0, stackpage=c0227000)
Stack: c01eab96 c0227bac c9226c60 c0226000 c01177a4 c0280a60 c0227bac c9226c60 
   
Call Trace: [] [] [] [] [] 
[] [] 
   [] [] [] [] [] [] 
[] [] 
   [] [] [] [] [] [] 
[] [] 
   [] [] [] [] [] [] 
[] [] 
   [] [] [] [] [] [] 
[] [] 
   [] [] [] [] [] [] 
[] [] 
   [] [] [] [] [] [] 
[] [] 
   [] 
Code: 0f 0b 8d 65 dc 5b 5e 5f c9 c3 90 55 89 e5 83 ec 10 57 56 53 

>>EIP; c0111d7d<=
Trace; c01177a4 <__run_task_queue+4c/68>
Trace; c012daaa <__wait_on_buffer+6a/8c>
Trace; d682f284 <[lvm-mod].bss.end+1f5f9/14f3d5>
Trace; c0164bde 
Trace; d682f2b8 <[lvm-mod].bss.end+1f62d/14f3d5>
Trace; d682f2ac <[lvm-mod].bss.end+1f621/14f3d5>
Trace; c01685db 
Trace; d682f284 <[lvm-mod].bss.end+1f5f9/14f3d5>
Trace; d68528a0 <[lvm-mod].bss.end+42c15/14f3d5>
Trace; c016753d 
Trace; c0159185 
Trace; c0131406 
Trace; c012dcb7 
Trace; c0187b9a 
Trace; c0187c24 
Trace; c0113aae 
Trace; c011645b 
Trace; c0109329 
Trace; c0111438 
Trace; c02c 
Trace; d6ab4000 <[8139too]__module_parm_full_duplex+134e/33ae>
Trace; c01bae03 
Trace; c01b595e 
Trace; d6a08ab6 <[ipchains]ip_fw_check+4b6/59c>
Trace; c0108f04 
Trace; c01b2b53 
Trace; c01b2bfb 
Trace; c01b310a 
Trace; c01b589a 
Trace; c01b8973 
Trace; c01c268c 
Trace; c01c2705 
Trace; c01ba937 
Trace; c01bff2c 
Trace; c01c2672 
Trace; c01c268c 
Trace; c01bff7a 
Trace; c01ba937 
Trace; c01bfed8 
Trace; c01bff2c 
Trace; c01bf200 
Trace; c01bf34f 
Trace; c01bf200 
Trace; c01ba937 
Trace; c01bf075 
Trace; c01bf200 
Trace; c01b5e2b 
Trace; c0117510 
Trace; c010a172 
Trace; c01071f0 
Trace; c0108e80 
Trace; c01071f0 
Trace; c0107213 
Trace; c0107277 
Trace; c0105000 
Trace; c0100191 
Code;  c0111d7d 
 <_

promise fasttrak 20265R (onboard) ide raid drivers for linux 2.4 ?

[Erik van Asselt]

>

i have the source files for compiling the module for 2.2 kernels but i
can't get the module to work in 2.4
is anyone programming a 2.4 driver/module ?
or can someone help me to convert the existing source code to a working 2.4
kernelmodule (or better in the kernel)

Erik

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Prevent OOM from killing init

[Tim Wright]

On Fri, Mar 23, 2001 at 06:38:37PM +, Alan Cox wrote:
> > infinite storage. After all, earlier Unix flavours did not need
> > an OOM killer either, and my editor was not killed under Unix V6
> > on 64k when I started some other process.
> 
> You were lucky. Its quite possible for V6 to kill processes when you run out
> of swap
> 

It was actually worse than that. Grab your copy of "Lions", and check lines
4375-4377 in function xswap(). A failure to allocate space in the swapmap
caused a panic. Same problem in xalloc().

Tim

-- 
Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED]
IBM Linux Technology Center, Beaverton, Oregon
Interested in Linux scalability ? Look at http://lse.sourceforge.net/
"Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: use the kernel to change an irq?

[Tim Wright]

They're sharing an IRQ because they're attached to the same interrupt line
on the motherboard. Nothing you can do in software is ever going to change
this. For most BX chipset motherboards I've seen, the AGP slot shares the
same interrupt as the first (i.e. physically closest) PCI slot. If you change
the IRQ for one, you just changed it for the other. If you don't want it to
share, you can't have anything in the other slot. Sounds like you're out of
luck :-(

Tim

On Thu, Mar 22, 2001 at 11:10:28PM -0800, Jacob Luna Lundberg wrote:
> 
> Oh Great Gurus:
> 
> I have an agp video card that seems quite picky about interrupts, and a
> bios that is insisting on sharing the video card's interrupt with whatever
> is in the first pci slot.  So my question is, is there any way for the
> kernel to more or less say ``screw you'' to the bios and pick the irq for
> the video card itself?  I have a spare irq I'd love for it to use...
> 
> Oh, almost forgot:  Yes, I'd just vacate the pci slot below the video
> card, but sadly all my pci slots are in use.  :(
> 
> Ok, I'll admit the card is an nVidia card and I'm trying to use the (evil)
> binary drivers.  But note I'm *not* asking for help with that directly.
> I'm merely asking if there's a way to avoid sharing the interrupt...
> 
> Thanks Muchly,
> -Jacob
> 

-- 
Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED]
IBM Linux Technology Center, Beaverton, Oregon
Interested in Linux scalability ? Look at http://lse.sourceforge.net/
"Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] gcc-3.0 warnings

[Andrew Morton]

"J . A . Magallon" wrote:
> 
>  The same is with that ugly out: at the end
> of the function. Just change all that 'goto out' for a return.

Oh no, no, no.  Please, no.

Multiple return statements are a maintenance nightmare.

Go back and look at the "checker" reports.  Think about them.

-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: eepro100 question: why SCBCmd byte is 0x80?

[Steven Walter]

I'm having a similar problem with the onboard network card of a Sony
Vaio Laptop.  I haven't tracked it down as far as you can; how can I
confirm its the same problem as yours?

On Fri, Mar 23, 2001 at 09:34:36AM -0800, Jun Sun wrote:
> christophe barbe wrote:
> > 
> > Which kernel are you using.
> > 
> > I've had a similar problem with 2.2.18.
> > I've backported 2.2.19pre changes to it.
> > (i.e. apply on 2.2.18 a diff of the file drivers/net/eepro100.c made between 
>2.2.18 and the last 2.2.19pre)
> > And since I've never seen this problem again.
> > 
> > Christophe
> > 
> 
> Kernel is 2.4.2.  It is a MIPS machine.
> 
> I don't really think it is a driver problem, because the same dirver works
> fine on many other boards (including MIPS boards).  In addition, I also tested
> with tulip cards and I had the same symptom.  I am convinced it is a low-level
> problem (bus timing, PCI setting, buggy hardware, etc).
> 
> On the other hand, it could be a driver problem which is only exposed in this
> particular board, although very unlikely.
> 
> BTW, does the eepro100 patch for 2.2.19pre apply to 2.4.2?  Or it is already
> in it?
> 
> Thanks.
> 
> Jun
> 
> > On jeu, 22 mar 2001 22:04:45 Jun Sun wrote:
> > >
> > > I am trying to get netgear card working on a new (read as potentially buggy
> > > hardware) MIPS board.
> > >
> > > The eepro100 driver basically works fine.  It is just after a little while
> > > (usually 2 sec to 15 sec) network communication suddenly stops and I start see
> > > error message like "eepro100: wait_for_cmd_done timeout!".
> > >
> > > I looked into this, and it appears that the SCBCmd byte in the command word
> > > has value 0x80 instead of the expected 0.  I looked at the Intel manual, and
> > > it says nothing about the value being 0x80.
> > >
> > > Does anybody have a clue here?  I suspect some timing is wrong or a buggy PCI
> > > controller.
> > >
> > > Please cc your reply to my email address.  Thanks.
> > >
> > > Jun
> > > -
> > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > > the body of a message to [EMAIL PROTECTED]
> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > > Please read the FAQ at  http://www.tux.org/lkml/
> > >
> > --
> > Christophe Barbé
> > Software Engineer
> > Lineo High Availability Group
> > 42-46, rue Médéric
> > 92110 Clichy - France
> > phone (33).1.41.40.02.12
> > fax (33).1.41.40.02.01
> > www.lineo.com
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
-Steven
Freedom is the freedom to say that two plus two equals four.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [OT] Linux Worm (fwd)

[Edward S. Marshall]

On Fri, Mar 23, 2001 at 02:39:07PM -0500, Michael Bacarella wrote:
> On Fri, Mar 23, 2001 at 01:51:11PM -0500, Doug McNaught wrote:
> > Is there an alternative to BIND that's free software?  Never seen
> > one. 
> 
> Have a look at djbdns.

I use djbdns myself and am very happy with it, but the original poster was
asking for free software. djbdns doesn't even meet the DFSG/OSD, let alone
the FSF definition of "free software". Please refer to the archives of the
[EMAIL PROTECTED] mailing list if you're interested in seeing all the old
arguments.

If you're looking for a GPL'd DNS server, there's Mindspring's DENTS
project, although it hasn't seen much development lately:

http://sourceforge.net/projects/dents/

That being said, none of this is on-topic for linux-kernel.

-esm (picking nits for fun and profit)

-- 
Edward S. Marshall <[EMAIL PROTECTED]>http://www.nyx.net/~emarshal/
---
[  Felix qui potuit rerum cognoscere causas.  ]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] gcc-3.0 warnings

[Tim Wright]

On Fri, Mar 23, 2001 at 11:59:09PM +0100, J . A . Magallon wrote:
> 
> On 03.23 Linus Torvalds wrote:
> > 
> > I agree. I'd much prefer that syntax also.
> > 
> > Or just remove the "default:" altogether, when it doesn't make any
> > difference.
> > 
> 
> Well, at last some sense. The same is with that ugly out: at the end
> of the function. Just change all that 'goto out' for a return.
> It does not matter, -O2 is going to do what it wants.
> 

This has nothing to do with fastpathing and object code optimization. C
doesn't have exception handling, so you either have to remember to undo
allocations etc.  in failure cases all through the code, or you stick your
undo code at the end of the function and have all failure cases jump to the
relevant label.  It's not pretty, but it's much less error-prone e.g.

func()
{
error = 0;
a = alloc_something();
if (some failure) {
error = XXX;
goto out;
}
b = alloc_something_else();
if (some other failure) {
error = YYY;
goto out1;
}
...
out1:
dealloc(b);
out:
dealloc(a);
return(error);
}

This is arguably easier to follow and less likely to get broken than the
alternative of embedding all the unwind code at each error point.

Tim

--
Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED]
IBM Linux Technology Center, Beaverton, Oregon
Interested in Linux scalability ? Look at http://lse.sourceforge.net/
"Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ANNOUNCE] The Janitor Project

[Arnaldo Carvalho de Melo]

Hi,

The Kernel Janitor's Project grew out of our search for things to help in
the development of the Linux kernel, and learning from other patches
submitted by more experienced people, we saw that some of these patches
indicated error patterns that could exist in other parts of the kernel, we
looked and... yes, we discovered that some parts of the kernel suffered
from the same problems and in the process we found code bitrotting...

I (acme) started maintaining a TODO list for things to fix or clean up and
people started submitting suggestions for things to fix that I collected at
http://bazar.conectiva.com.br/~acme/TODO, looking at the httpd logs I
discovered that _lots_ of people accessed it, so this indeed was something
useful as a starting point for people also wanting to help in cleaning
up/fixing parts of the kernel.

Now we're expanding this so that this continues to be useful, hosting it at
sourceforge to make possible for other people to include more things to
clean/fix.

So, get your broom and start cleaning! 8)

regards,

The kernel-Janitor team.

-
One anouncement is not enough, so here's another one 8)
-

The kernel janitor project has been created at
http://www.sourceforge.net/projects/kernel-janitor

Acme's TODO list is now held there in CVS, and there are also mailing lists
announcing new addtions, and another for discussion.

This project does not replace, but instead compliments the existing janitor
list maintained by Acme.  By keeping this in CVS with multiple maintainers,
updates will happen more frequently.

The mailing list will contain many discussions of patches fixing problems
on the TODO, and also explanations of how these things can be fixed.

regards,

The kernel-Janitor team.
-

And yes, the Stanford team work is helping to make the TODO bigger 8)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

ext2 corruption in 2.4.2-ac20

[Eric Buddington]

I have been using 2.4.0-ac20 for about a week, and today suddenly got a slew of 
messages:

EXT2-fs error (device ide0(3,1)): ext2_new_block: Free blocks count corrupted for 
block group 43

while copying the mozilla tree (a great way to stress out a filesystem! :)). This is 
the first such
problem I have had.

-Eric


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Prevent OOM from killing init

[Tom Diehl]

On Fri, 23 Mar 2001, Tim Wright wrote:

> Netscape 4 has some very nasty habits like suddenly consuming ~80MB of memory.
> Disabling java support seems to eradicate most occurences of this particularly
> obnoxious behaviour. Under these circumstances, the OOM killer is doing exactly
> the right thing i.e. killing a runaway app.

Thanks for the info. I sus[ected as much but I was not sure.

-- 
..Tom   ATA100 is another testimony to the fact that pigs can be
[EMAIL PROTECTED]  made to fly given sufficient thrust (to borrow an RFC)
Alan Cox lkml 11 Jan 01

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

No Subject

[dhar]

Hi,

I am not a member of either of these lists and would appreciate if you could send your 
replies to me personally.

Now the problem:

I have an IBM Netfinity X330 server. Dual Processor (PIII 800). I compiled kernel 
2.2.14 with SMP support. NFS was however compiled as a module. 

Now the problem is as follows:

Most of the times the machine just works fine. 
But whenever there is heavy disk write activity it just hangs/crashes. Also this is 
when the SMP kernel is used. If I use the normal kernel then there is no problem. 

Could any one tell me what has to be done to prevent this from happening? 

Any help in this regard will be very much appreciated.

Once again, kindly reply to me personally as I am not a member of either of these 
lists.
 
Regards
Dhar 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Prevent OOM from killing init

[Jonathan Morton]

>[to various people]
>
>No, ulimit does not work. (But it helps a little.)
>No, /proc/sys/vm/overcommit_memory does not work.

Entirely correct.  ulimit certainly makes it much harder for a single
runaway process to take down important parts of the system - now why
doesn't $(MAJOR_DISTRO_VENDOR) set it up by default?  NetBSD does.  It's
not an infallible solution by any means, but it sure does help.

I just asked a friend to run my test program on his NetBSD box - it ran
into ulimit and malloc() returned 0.  Setting ulimit on my RH 6.2 box -
which defaults to unlimited - also caused it to fail gracefully.

>[to Alan]
>
>> Nobody feels its very important because nobody has implemented it.
>
>Yes, that is the right response.
>What can one say? One can only do.

Ah, but what does one do?  Badger major distro vendors to set ulimit
properly by default?  Improve the OOM-killer so it gives less "badness" to
low-UID processes?  Implement an early-failure mechanism for malloc(), so
hard OOM is not hit except by an extremely determined process (or set of
processes)?

Personally, I think all of the above.  Your views may differ.

Hmm...  "if ( freemem < (size_of_mallocing_process / 20) ) fail_to_allocate;"

Seems like a reasonable soft limit - processes which have already got lots
of RAM can probably stand not to have that little bit more and can be
curbed more quickly.  Processes with less probably don't deserve to die and
furthermore are less likely to be engineered to handle malloc() failure, so
failure only occurs closer to the mark.  In this scenario OOM killing
(which is, after all, a last resort) should trigger rarely and simple
malloc() failure (which userspace apps can cope with more easily) is an
early-warning and prevention system.

Comments?

--
from: Jonathan "Chromatix" Morton
mail: [EMAIL PROTECTED]  (not for attachments)
big-mail: [EMAIL PROTECTED]
uni-mail: [EMAIL PROTECTED]

The key to knowledge is not to rely on people to teach you it.

Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/

-BEGIN GEEK CODE BLOCK-
Version 3.12
GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS
PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*)
-END GEEK CODE BLOCK-


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mm/memory.c, 2.4.1 : memory leak with swap cache (updated)

[Rik van Riel]

On Fri, 23 Mar 2001, Richard Jerrell wrote:
> > Your idea is nice, but the patch lacks a few things:
> > 
> > - SMP locking, what if some other process faults in this page
> >   between the atomic_read of the page count and the test later?
> 
> It can't happen.  free_pte is called with the page_table_lock held in 
> addition to having the mmap_sem downed.

The page_table_lock and the mmap_sem only protect the *current*
task. Think about something like an apache with 500 children who
COW share the same page...

> > - testing if our process is the _only_ user of this swap page,
> >   for eg. apache you'll have lots of COW-shared pages .. it would
> >   be good to keep the page in memory for our siblings
> 
> This is already done in free_page_and_swap_cache.

Ok ...

regards,

Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

http://www.surriel.com/
http://www.conectiva.com/   http://distro.conectiva.com.br/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] gcc-3.0 warnings

[Ingo Oeser]

On Fri, Mar 23, 2001 at 01:38:00AM +0100, J . A . Magallon wrote:
> Is there a non-written standard for coding that asm's ?
> For example:
> "  adcl 12(%1), %0\n"
> "1:adcl 16(%1), %0\n"
> "  lea 4(%1), %1\n"
> 
> or
> 
> "adcl 12(%1), %0\n\t"
 ^[1]
> "1:  adcl 16(%1), %0\n\t"
> "lea 4(%1), %1\n\t"

The first one is better readable and the latter one is more
portable (since the first may contain tabs in the string, instead
of spaces and no one sees this).

You'll see, what I mean with readable, if you omit the tab in [1].


Regards

Ingo Oeser
-- 
10.+11.03.2001 - 3. Chemnitzer LinuxTag 
  been there and had much fun   
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Prevent OOM from killing init

[Guest section DW]

On Fri, Mar 23, 2001 at 05:26:22PM +, James A. Sutherland wrote:

> > Clearly, Linux cannot be reliable if any process can be killed
> > at any moment.
> 
> What on earth did you expect to happen when the process exceeded the
> machine's capabilities? Using more than all the resources fails. There
> isn't an alternative.

That is the wrong way to phrase these things.
Large processes usually do not have a definite set of needed resources.
They can use lots of memory for buffers and cache and hash and be a bit
faster, or use much less and be a bit slower.
Linux first promises a lot of memory, but then fails to deliver,
without returning any error to the program.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Interesting post from the MC project to linux-kernel. :block while spinlock held...

[Ishikawa]

Hello Garloff-san,

Actually, a good question.

I have been trying to find the details of the verification tool from stanford

but to no avail.
Maybe we should ask the posters from the Stanford directly.

(Oops. I thought I posted this to linux-scsi, but did I post
linux-kernel instead? Apologies.)

Kurt Garloff wrote:

> On Thu, Mar 22, 2001 at 02:24:56AM +0900, Chiaki Ishikawa wrote:
> > --- begin quote ---
> > > enclosed are 163 potential bugs in 2.4.1 where blocking functions are
> > > called with either interrupts disabled or a spin lock held. The
> > > checker works by:
> >
> > Here's the file manifest. Apologies.
> >
> > drivers/atm/idt77105.c
> > drivers/atm/iphase.c
> > drivers/atm/uPD98402.c
> > drivers/block/cciss.c
> > drivers/block/cpqarray.c
> > drivers/char/applicom.c
> > ...
> > drivers/scsi/aha1542.c<--- some scsi files
> > drivers/scsi/atp870u.c <
> > drivers/scsi/psi240i.c   <
> > drivers/scsi/sym53c416.c<
> > drivers/scsi/tmscsim.c  <
>   ^^
>
> How do I fond about about details?
>
> R

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Prevent OOM from killing init

[Tim Wright]

Netscape 4 has some very nasty habits like suddenly consuming ~80MB of memory.
Disabling java support seems to eradicate most occurences of this particularly
obnoxious behaviour. Under these circumstances, the OOM killer is doing exactly
the right thing i.e. killing a runaway app.

Tim

On Fri, Mar 23, 2001 at 03:20:41PM -0500, Tom Diehl wrote:
> On Fri, 23 Mar 2001, Rik van Riel wrote:
> 
> > Well, in that case you'll have to live with the current OOM
> > killer.  Martin wrote down a pretty detailed description of
> > what's wrong with my algorithm, if it really bothers him he
> > should be able to come up with something better.
> >
> > Personally, I think there is more important VM code to look
> > after, since OOM is a pretty rare occurrance anyway.
> 
> Well actually it is not that rare at least for me. Every 3 or 4 days I run
> into it (It happened again this morning). The machine has 128 Megs of ram
> and 256 Megs of swap. It is my desktop machine and I keep 3 or 4 netscape
> windows running all of the time. Well I try to at least. Every 3 or 4 days
> the OOM Killer kills netscape, it happened this morning. If I could fix it
> I would but alas I do not have the knowledge. The best I can do is test. :(
> 
> This is NOT a complaint I just bring this up as another data point.
> It used to lock the machine so things are getting better. fwiw, I am
> currently running 2.4.2-ac18. The old ac kernels (do not remember exactly
> which ones but it was single digits) would allow the machine to start
> thrashing. I could usually see that it was running out of memory and if I
> was fast enough could kill Netscape b4 the machine locked. If I was not
> fast enough it would lock hard. Nothing in the logs.
> 
> HTH,
> 
> -- 
> ..Tom ATA100 is another testimony to the fact that pigs can be
> [EMAIL PROTECTED]made to fly given sufficient thrust (to borrow an RFC)
>   Alan Cox lkml 11 Jan 01
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED]
IBM Linux Technology Center, Beaverton, Oregon
Interested in Linux scalability ? Look at http://lse.sourceforge.net/
"Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Use semaphore for producer/consumer case...

[Nigel Gamble]

On Fri, 23 Mar 2001, Stelian Pop wrote:
> I want to use a semaphore for the classic producer/consumer case
> (put the consumer to wait until X items are produced, where X != 1).
> 
> If X is 1, the semaphore is a simple MUTEX, ok.
> 
> But if the consumer wants to wait for several items, it doesn't
> seem to work (or something is bad in my code).
> 
> What is wrong in the following ?
> 
>   DECLARE_MUTEX(sem);

For the producer/consumer case, you want to initialize the semaphore to
0, not 1 which DECLARE_MUTEX(sem) does.  So I would use

__DECLARE_SEMAPHORE_GENERIC(sem, 0)

The count is then the number of items produced but not yet consumed.

>   producer() {
>   /* One item produced */
>   up(&sem);
>   }
>   
>   consumer() {
>   /* Let's wait for 10 items */
>   atomic_set(&sem->count, -10);
>   
>   /* This starts the producers, they will call producer()
>  some time in the future */
>   start_producers();
>   
>   /* Wait for completion */
>   down(&sem);
>   }

Then consumer could be:

consumer()
{
int i;

start_producers();

/* Wait for 10 items to be produced */
for (i = 0; i < 10; i++)
down(&sem);
}


Nigel Gamble[EMAIL PROTECTED]
Mountain View, CA, USA. http://www.nrg.org/

MontaVista Software [EMAIL PROTECTED]

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Prevent OOM from killing init

[Eric W. Biederman]

Guest section DW <[EMAIL PROTECTED]> writes:

> On Fri, Mar 23, 2001 at 07:50:25AM -0700, Eric W. Biederman wrote:
> 
> > > Mar 23 11:48:49 mette kernel: Out of Memory: Killed process 2019 (emacs).
> > > Mar 23 11:48:49 mette kernel: Out of Memory: Killed process 1407 (emacs).
> > > Mar 23 11:48:50 mette kernel: Out of Memory: Killed process 1495 (emacs).
> > > Mar 23 11:48:50 mette kernel: Out of Memory: Killed process 2800 (rpm).
> > > 
> > > [yes, that was rpm growing too large, taking a few emacs sessions]
> > > [2.4.2]
> > 
> > Let me get this straight you don't have enough swap for your workload?
> > And you don't have per process limits on root by default?
> > 
> > So you are complaining about the OOM killer?  
> 
> I should not react - your questions are phrased rhetorically.

To some extent I was also very puzzled by your complaint.

You have setup a system that by your definition unreliably and then
you complain it is unreliable.

> 
> But yes, I am complaining because Linux by default is unreliable.
> I strongly prefer a system that is reliable by default,
> and I'll leave it to others to run it in an unreliable mode.

Now all I know the system didn't have enough resources to do what
you asked to it do and it failed.  That sounds reliable to me.  

Obviously you were suprised at how the system failed.  Given
that unix has been doing this kind of thing for decades, you obviously
missed how the unix malloc overcommited memory.

Does you application trap sigsegv on a different stack so you can
catch stack growth failure?  And how does your app handle this case?

Having a no over commit kernel option would help.  

A cheap workaround is to call mlock_all(MCL_FUTRE...).  Then you are
garantteed you will always have ram locked into memory for your
program.   This assumes you have enough ram for your program.

Eric

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Prevent OOM from killing init

[Stephen E. Clark]

Alan Cox wrote:
> 
> > You don't beleve me if I tell you: DOS extender and JVM (Java Virtual
> > Machine)
> 
> The JVM doesnt actually. The JVM will itself spontaenously explode in real
> life when out of memory. Maybe the JVM on a DOS extender 8)
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Back in the early nineties I was working with 18 developers on a Data
General Aviion running DGUX. The system had only 16mb of memory and
600mb of disk. We were all continuously going thru the edit, compile,
debug steps developing as large Computer Aided Dispatch System. Never
did this system with its limited resources crash, or randomly start
killing user or system processes.

My $.02.
Steve
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Prevent OOM from killing init

[Martin Dalecki]

[EMAIL PROTECTED] wrote:
> 
> [to various people]
> 
> No, ulimit does not work. (But it helps a little.)
> No, /proc/sys/vm/overcommit_memory does not work.
> 
> [to Alan]
> 
> > Nobody feels its very important because nobody has implemented it.
> 
> Yes, that is the right response.
> What can one say? One can only do.

Please just expect a patch for tomorrow ;-).

The only thing I have currently to do is testing.
I will be using the installation process of the ORACLE iAS 9i for
linux on my notebook, becouse it used to trigger oom for me VERY
frequently. So far all things BEHAVE...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Prevent OOM from killing init

[Eric W. Biederman]

Jonathan Morton <[EMAIL PROTECTED]> writes:

> >It would make much sense to make the oom killer
> >leave not just root processes alone but processes belonging to a UID
> >lower
> >then a certain value as well (500). This would be:
> >
> >1. Easly managable by the admin. Just let oracle/www and analogous users
> >   have a UID lower then let's say 500.
> 
> That sounds vaguely sensible.  However, make it a "much less likely" rather
> than an "impossible", otherwise we end up with an unkillable runaway root
> process killing everything else in userland.
> 
> I'm still in favour of a failing malloc(), and I'm currently reading a bit
> of source and docs to figure out where this should be done and why it isn't
> done now.  So far I've found the overcommit_memory flag, which looks kinda
> promising.

Lookup mlock & mlock_all they will handle the single process case.

Of course if you OOM you still have problems but that should make
them much harder to trigger.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Prevent OOM from killing init

[Andries . Brouwer]

[to various people]

No, ulimit does not work. (But it helps a little.)
No, /proc/sys/vm/overcommit_memory does not work.

[to Alan]

> Nobody feels its very important because nobody has implemented it.

Yes, that is the right response.
What can one say? One can only do.

Andries

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.4.2-ac21

[Arjan van de Ven]

On Fri, Mar 23, 2001 at 01:12:06AM +, Andrew Morton wrote:
> Lawrence Walton wrote:
> > 
> > Hello all
> > 2.4.2-ac21 seems to have a couple problems.
> > ...
> > 
> > Mar 22 15:15:55 the-penguin kernel: NETDEV WATCHDOG: eth0: transmit timed out
> > ...
> > 00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] (prog-if 
>00 [Normal decode])
> 
> People have recently been changing VIA PCI bridge settings
> to try to fix the file corruption thing.  There has been one
> report that this change causes a 3c905C to go silly.
> 
> This looks like the same problem to me.

Could very well be. The problem is that your VIA chipset (or rather the
chipset as used on at least some of the boards out there) will corrupt your
data if this setting is not done.

Greetings,
   Arjan van de Ven
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Can't get serial.c to work with Xircom Cardbus Ethernet+Modem

[Alessandro Suardi]

Tom Sightler wrote:
> 
> Hi all,
> 
> I saw a discussion on this list about this problem earlier, but could not
> find that it had actually been resolved.

That was me :) and no, it doesn't work. Jeff Garzik asked me to enable
 a couple debug #defines in serial.c, apply patches to serial.c and
 finally disable i82365 support but as of now it doesn't work.

It looks like we have the same card with modem @ 0x1880.

[snip]

> Any ideas?  I may look at it more tomorrow.  For now I'm back to using
> serial_cb which still works fine (even though that apparently suprises many
> people).

:) this is -pre4 with serial_cb which works fine, and always has...

--alessandro  <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Linux:  kernel 2.2.19p17/2.4.3p6 glibc-2.2 gcc-2.96-69 binutils-2.11.90.0.1
Oracle: Oracle8i 8.1.7.0.1 Enterprise Edition for Linux
motto:  Tell the truth, there's less to remember.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Panic] Linux-2.4.2ac22

[Ed Tomlinson]

Hi,

Got this with ac22...

ksymoops 2.3.7 on i586 2.4.2-ac22.  Options used
     -V (default)
     -k /var/log/ksymoops/20010323122909.ksyms (specified)
     -l /var/log/ksymoops/20010323122909.modules (specified)
     -o /lib/modules/2.4.2-ac22/ (default)
     -m /boot/System.map-2.4.2-ac22 (default)

Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(shmem_file_setup) not 
found in System.map.  Ignoring ksyms_base entry
Unable to handle kernel NULL pointer dereference at virtual address 022e
c01b2b53
*pde = 
Oops: 
CPU:    0
EIP:    0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010206
eax: d2636f00   ebx: 022e   ecx:    edx: 022e
esi: d2cba0a0   edi: d2636ca0   ebp: 0060   esp: cdee1df8
ds: 0018   es: 0018   ss: 0018
Process setiathome (pid: 10662, stackpage=cdee1000)
Stack: fe00 c01b2bfb d2cba0a0 fe00 d2cba0a0 c01b310a d2cba0a0 d2cba0a0
       d3eae800 d22e02a0 d3eae800 c01b589a d2cba0a0 0002 c56a1940 d2cba0a0
       c01b8973 d2cba0a0 d2cba0a0  0004 c01c268c c01c2705 d2cba0a0
Call Trace: [] [] [] [] [] [<
       [] [] [] [] [] [] [] [] [] [] []
Code: 8b 1b 8b 42 70 83 f8 01 74 0a ff 4a 70 0f 94 c0 84 c0 74 09

>>EIP; c01b2b53    <=

Trace; c01b2bfb 
Trace; c01b310a 
Trace; c01b589a 
Trace; c01b8973 
Trace; c01c268c 
Trace; c01bff2c 
Trace; c01c2672 
Trace; c01c268c 
Trace; c01bff7a 
Trace; c01ba937 
Trace; c01bf34f 
Trace; c01bf200 
Trace; c01ba937 
Trace; c01bf075 
Trace; c01bf200 
Trace; c0108e80 
Code;  c01b2b53 
 <_EIP>:
Code;  c01b2b53    <=
   0:   8b 1b                     mov    (%ebx),%ebx   <=
Code;  c01b2b55 
   2:   8b 42 70                  mov    0x70(%edx),%eax
Code;  c01b2b58 
   5:   83 f8 01                  cmp    $0x1,%eax
Code;  c01b2b5b 
   8:   74 0a                     je     14 <_EIP+0x14> c01b2b67 

Code;  c01b2b5d 
   a:   ff 4a 70                  decl   0x70(%edx)
Code;  c01b2b60 
   d:   0f 94 c0                  sete   %al
Code;  c01b2b63 
  10:   84 c0                     test   %al,%al
Code;  c01b2b65 
  12:   74 09                     je     1d <_EIP+0x1d> c01b2b70 


 <0>Kernel panic: Aiee, killing interrupt handler!

1 warning issued.  Results may not be reliable.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] gcc-3.0 warnings

[J . A . Magallon]

On 03.23 Linus Torvalds wrote:
> 
> I agree. I'd much prefer that syntax also.
> 
> Or just remove the "default:" altogether, when it doesn't make any
> difference.
> 

Well, at last some sense. The same is with that ugly out: at the end
of the function. Just change all that 'goto out' for a return.
It does not matter, -O2 is going to do what it wants.

And the missing return 0 at the end of functions that call a 'noreturn'
function. gcc 2.96 still wants them. But it looks like a religious matter
to put ot not to put that stupid return just to shut up the compiler.
As I understand, the noreturn says that the function that is marked as
noreturn is allowed to have missing correct return paths, and the compiler
can build, for example , without worring about the global state
once it has entered . But  says nothing about functions
that call a 'noreturn' function. So I see as INCORRECT to omit a return path
in a function that calls .

And if people is so worried about fast paths, begin to use 'const' or
'pure' functions. I think that can help the compiler to generate fast code
more than trying to do hancrafted fast paths that the compiler will reorganize.

-- 
J.A. Magallon  #  Let the source
mailto:[EMAIL PROTECTED]  #  be with you, Luke... 

Linux werewolf 2.4.2-ac22 #3 SMP Fri Mar 23 02:06:00 CET 2001 i686

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Advansys SCSI driver old verson?

[Alan Cox]

> Andy Kellner (from ConnectCom Solutions formerly 
> known as Advansys) and Bob Frey (former maintainer) 
> working in concert have posted several "3.3x" versions 
> of the advansys driver to the linux-scsi list. Despite

I don't believe Linus reads linux-scsi. I only glance at it occasionally.
If you care to send me a diff against -ac23 I'll merge it and if it seems to
behave solidly then push it to Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Fix races in 2.4.2-ac22 SysV shared memory

[Linus Torvalds]

On Fri, 23 Mar 2001, Alan Cox wrote:
>
> __find_get_page has I think a misleading comment ?

Ehh..

I only said the _naming_ makes sense. [ Wild hand-waving ]

I suspect that what happened was that we split off the functions (one to
just get the page, one to lock it), and the comment that was associated
with the original "find_page()" never got removed, and just happens to sit
above one of the helper functions now - the one that didn't lock.

I'll fix the comment.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Fix races in 2.4.2-ac22 SysV shared memory

[Alan Cox]

> If you don't want to sleep, you need to use one of the wrappers for
> "__find_page_nolock()". Something like "find_get_page()", which only
> "gets" the page.

 * a rather lightweight function, finding and getting a reference to a
 * hashed page atomically, waiting for it if it's locked.

__find_get_page has I think a misleading comment ?

> The naming actually does make sense in this area.

Yep

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] gcc-3.0 warnings

[Linus Torvalds]

On Fri, 23 Mar 2001, Bill Wendling wrote:

> Also sprach Alan Cox:
>
> } > - default:
> } > + default:;
> }
> } Agree - done
> }
> This kind of coding makes me want to cry. What's so wrong with:
>
>   default:
>   break;
>
> instead? The ';' is hard to notice and

I agree. I'd much prefer that syntax also.

Or just remove the "default:" altogether, when it doesn't make any
difference.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Fix races in 2.4.2-ac22 SysV shared memory

[David S. Miller]

Alan Cox writes:
 > Umm find_lock_page doesnt sleep does it ?

It does lock_page, which sleeps to get the lock if necessary.

Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux should better cope with power failure

[David Ford]

Otto Wyss wrote:

> > I had a similar experience:
> > X crashed , hosing the console , so I could not initiate
> > a proper shutdown.
> >
> > Here I must note that the response you got on linux-kernel is
> > shameful.
> >
> Thanks, but I expected it a little bit. All around Linux is centered
> around getting the highest performance out of it and very low (to low
> IMHO) is done to have a save system. The attitude "It doesn't matter
> making mistakes, they get fix anyhow" annoys me most, especially if it
> were easy to prevent them.

No, the correct answer is if you want a reliable recovery then run your disks
in non write buffered mode.  I.e. turn on sync in fstab.

It's all about RTFM and knowing the difference between buffered actions and
nonbuffered.

Everything you need to have a safely clean and proper crash recovery system
already is within your power, you just need to read the man pages and fix
your fstab instead of blaming linux-kernel for bad attitudes.

Yes, it's very easy to prevent e2fsck runs.  Run synchronous or journaled
file systems.

> > > Don't we tell children never go close to any abyss or doesn't have
> > > alpinist a saying "never go to the limits"? So why is this simple rule
> > > always broken with computers?
> > >
> Is there a similar expression which could be hammered into any
> developers mind, i.e. "Don't make errors, others already do them for you".

There is also a very common expression...RTFM.

Please understand what you are doing before you do it, particularly before
you bad mouth others for having a bad attitude.  Don't blame race car makers
for destructive engine failure when you expect it to act like a family car.

-d


--
  There is a natural aristocracy among men. The grounds of this are virtue and 
talents. Thomas Jefferson
  The good thing about standards is that there are so many to choose from. Andrew S. 
Tanenbaum



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Fix races in 2.4.2-ac22 SysV shared memory

[Alan Cox]

> > >   +   page = find_lock_page(mapping, idx);
> > > 
> > > Ehh.. Sleeping with the spin-lock held? Sounds like a truly bad idea.
> > 
> > Umm find_lock_page doesnt sleep does it ?
> 
> It certainly does. find_lock_page() -> __find_lock_page() -> lock_page() ->
> -> __lock_page() -> schedule().

Ok I missed the lock page one. Yep.

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] gcc-3.0 warnings

[Bill Wendling]

Also sprach Alan Cox:

} > -   default:
} > +   default:;
} 
} Agree - done
} 
This kind of coding makes me want to cry. What's so wrong with:

default:
break;

instead? The ';' is hard to notice and, if people don't leave the
"default:" at the end, then bad things could happen...

-- 
|| Bill Wendling[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Advansys SCSI driver old verson?

[Douglas Gilbert]

icabod <[EMAIL PROTECTED]> wrote:
> I've noticed a small problem that hinders me 
> from updatingmy system to the new 2.4 kernels. 
> I'm using a PowerMac with a Advansys SCSI 3940UW 
> card in it running my drives. I've noticed that 
> since the 2.4 kernel series the advanasys drivers 
> version 3.2M and the driver version that works for 
> me and came with the 2.2.17+ kernels at least 
> workes fid with my card, that version is 3.3D. I 
> was wondering if anyone had noticed this before, 
> or if there s a reason the older driver was used. 
> The reason I bring this up is tht the driver in 
> the 2.4 kernel series does not drive my particular
> card. I hope that the readers of this list find 
> this helpful, if you have any questions please 
> feel free to reply. Thanks.

Andy Kellner (from ConnectCom Solutions formerly 
known as Advansys) and Bob Frey (former maintainer) 
working in concert have posted several "3.3x" versions 
of the advansys driver to the linux-scsi list. Despite
this, there seems no sign of this improved driver 
being included in the 2.4 series kernels. However 
the advansys driver was upgraded to version 3.3D in 
lk 2.2.18 . Have there been any adverse reports about 
the advansys driver in lk 2.2.18 ?

I am currently using advansys driver version 3.3G
without problems on lk 2.4.2 . The changelog at the
top of the advansys.c file shows an impressive number 
of improvements and fixes between versions 3.2M and 
3.3G (including powerpc support, see below).

This is not the first time that I've sent such a post 
trying to press for an update of this driver. I was 
told that the patch was too big to be contemplated for 
lk 2.4 . Well size didn't stop the complete replacement 
of the much used aic7xxx driver.


You do have some short term options. Since the 
advansys driver has the same source in the lk 2.2 
and lk 2.4 series, you can copy the version 3.3D
advansys.[hc] files from your lk 2.2.18 source to
your lk 2.4.2 source and it will build ok.
Alternatively you can get a recent version (version 
3.3F) from:
http://www.connectcom.net/support/evaluation.html

Doug Gilbert



Changelog from advansys.c file between versions
3.2M and 3.3G follows:


 3.2N (4/1/00):
 1. Add CONFIG_ISA ifdef code.
 2. Include advansys_interrupts_enabled name change patch.
 3. For >= v2.3.28 use new SCSI error handling with new function
advansys_eh_bus_reset(). Don't include an abort function
because of base library limitations.
 4. For >= v2.3.28 use per board lock instead of io_request_lock.
 5. For >= v2.3.28 eliminate advansys_command() and
advansys_command_done().
 6. Add some changes for PowerPC (Big Endian) support, but it isn't
working yet.
 7. Fix "nonexistent resource free" problem that occurred on a module
unload for boards with an I/O space >= 255. The 'n_io_port' field
is only one byte and can not be used to hold an ioport length more
than 255.

 3.3A (4/4/00):
 1. Update to Adv Library 5.8.
 2. For wide cards add support for CDBs up to 16 bytes.
 3. Eliminate warnings when CONFIG_PROC_FS is not defined.

 3.3B (5/1/00):
 1. Support for PowerPC (Big Endian) wide cards. Narrow cards
still need work.
 2. Change bitfields to shift and mask access for endian
portability.

 3.3C (10/13/00):
 1. Update for latest 2.4 kernel.
 2. Test ABP-480 CardBus support in 2.4 kernel - works!
 3. Update to Asc Library S123.
 4. Update to Adv Library 5.12.

 3.3D (11/22/00):
 1. Update for latest 2.4 kernel.
 2. Create patches for 2.2 and 2.4 kernels.

 3.3E (1/9/01):
 1. Now that 2.4 is released remove ifdef code for kernel versions
less than 2.2. The driver is now only supported in kernels 2.2,
2.4, and greater.
 2. Add code to release and acquire the io_request_lock in
the driver entrypoint functions: advansys_detect and
advansys_queuecommand. In kernel 2.4 the SCSI mid-level driver
still holds the io_request_lock on entry to SCSI low-level drivers.
This was supposed to be removed before 2.4 was released but never
happened. When the mid-level SCSI driver is changed all references
to the io_request_lock should be removed from the driver.
 3. Simplify error handling by removing advansys_abort(),
AscAbortSRB(), AscResetDevice(). SCSI bus reset requests are
now handled by resetting the SCSI bus and fully re-initializing
the chip. This simple method of error recovery has proven to work
most reliably after attempts at different methods. Also now only
support the "new" error handling method and remove the obsolete
 

Re: Problems with latest changes in kernel and X

[Alan Cox]

>   After upgrading to latest 2.4.2-ac23 (that includes latest changes
> from 2.4.3-pre6) X doesn't start anymore. It was working perfectly for
> 2.4.2-ac20. I'm using DRI CVS, but it seems to have little to do with DRI
> as disabling completely DRI doesn't help. 

DRI will not work with ac23 or 3pre6. The mm locking changed to avoid a deadlock
problem versus procfs and stuff.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Prevent OOM from killing init

[Szabolcs Szakacsits]

On Fri, 23 Mar 2001, Alan Cox wrote:
> > > and rely on it. You might find you need a few Gbytes of swap just to
> > > boot
> > Seems a bit exaggeration ;) Here are numbers,
> NetBSD is if I remember rightly still using a.out library styles.

No, it uses ELF today, moreover the numbers were from Solaris. NetBSD
also switched from non-overcommit to overcommit-only [AFAIK] mode with
"random" process killing with its new UVM.

> > 6-50% more VM and the performance hit also isn't so bad as it's thought
> > (Eduardo Horvath sent a non-overcommit patch for Linux about one year
> > ago).
> The Linux performance hit would be so close to zero you shouldnt be able to
> measure it - or it was in 1.2 anyway

Yep, something like this :)

Szaka

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Fix races in 2.4.2-ac22 SysV shared memory

[Alexander Viro]

On Fri, 23 Mar 2001, Alan Cox wrote:

> > On Fri, 23 Mar 2001, Stephen C. Tweedie wrote:
> > >
> > > The patch below is for two races in sysV shared memory.
> > 
> > +   spin_lock (&info->lock);
> > +
> > +   /* The shmem_swp_entry() call may have blocked, and
> > +* shmem_writepage may have been moving a page between the page
> > +* cache and swap cache.  We need to recheck the page cache
> > +* under the protection of the info->lock spinlock. */
> > +
> > +   page = find_lock_page(mapping, idx);
> > 
> > Ehh.. Sleeping with the spin-lock held? Sounds like a truly bad idea.
> 
> Umm find_lock_page doesnt sleep does it ?

It certainly does. find_lock_page() -> __find_lock_page() -> lock_page() ->
-> __lock_page() -> schedule().

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: cpqarray & 2.4.1+ hang

[Cagle, John]

Marcus Meissner wrote:
>> I have a problem with the 2.4 series kernel running on a number of
>> Compaq ProLiant DL360 servers. The 2.2.x kernels and 2.4.0 work fine,
>> however from 2.4.1 onwards the boxes just hang at the following position
>> on bootup:
>
>> Partition check: 
>> ida/c0d0:
>
>> I have also tested with 2.4.2-ac20 and the same problem occurs. Doing a
>> search on the web some people recommend changing the OS setting in the
>> Compaq BIOS to Linux fixes this problem, however my servers are already
>> running with this BIOS setting and I've also tested with numerous other
>> OS's in the BIOS but the same problem occurs.
>
>Workaround: run the kernel with the 'noapic' option on its commandline. 
>
>The ServerWorks chipset used in this Compaq Server somehow does not pass 
>the the relevant information to Linux mapping routines. :/ 
>

The real problem lies in the OSB4 driver beginning with the 2.4.0 kernel.
Its initialization of the OSB4 breaks APIC interrupt processing, causing a
lockup during boot of any APIC-enabled server that uses the OSB4.  Rolling
back to the version in 2.4.0-prerelease will resolve your lockup during
boot.  Alternatively, you can set CONFIG_BLK_DEV_OSB4=n in your .config.
This will revert to using the generic IDE driver instead of the
OSB4-specific code that is broken.  That's not a problem on ProLiants since
the OSB4 is only used to access the CD-ROM drive, hence you don't need any
enhanced performance.

Regards,
John Cagle
Principal Member Technical Staff
ProLiant Servers, Compaq

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Fix races in 2.4.2-ac22 SysV shared memory

[Linus Torvalds]

On Fri, 23 Mar 2001, Alan Cox wrote:
> >
> > +   spin_lock (&info->lock);
> > +
> > +   /* The shmem_swp_entry() call may have blocked, and
> > +* shmem_writepage may have been moving a page between the page
> > +* cache and swap cache.  We need to recheck the page cache
> > +* under the protection of the info->lock spinlock. */
> > +
> > +   page = find_lock_page(mapping, idx);
> >
> > Ehh.. Sleeping with the spin-lock held? Sounds like a truly bad idea.
>
> Umm find_lock_page doesnt sleep does it ?

Sure it does. Note the "lock" in find_lock_page(). It will lock the page,
which implies sleeping if somebody is accessing it at the same time.

If you don't want to sleep, you need to use one of the wrappers for
"__find_page_nolock()". Something like "find_get_page()", which only
"gets" the page.

The naming actually does make sense in this area.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Prevent OOM from killing init

[Alan Cox]

> > and rely on it. You might find you need a few Gbytes of swap just to
> > boot
> 
> Seems a bit exaggeration ;) Here are numbers,

NetBSD is if I remember rightly still using a.out library styles. 

> 6-50% more VM and the performance hit also isn't so bad as it's thought
> (Eduardo Horvath sent a non-overcommit patch for Linux about one year
> ago).

The Linux performance hit would be so close to zero you shouldnt be able to
measure it - or it was in 1.2 anyway
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Fix races in 2.4.2-ac22 SysV shared memory

[Alan Cox]

> On Fri, 23 Mar 2001, Stephen C. Tweedie wrote:
> >
> > The patch below is for two races in sysV shared memory.
> 
>   +   spin_lock (&info->lock);
>   +
>   +   /* The shmem_swp_entry() call may have blocked, and
>   +* shmem_writepage may have been moving a page between the page
>   +* cache and swap cache.  We need to recheck the page cache
>   +* under the protection of the info->lock spinlock. */
>   +
>   +   page = find_lock_page(mapping, idx);
> 
> Ehh.. Sleeping with the spin-lock held? Sounds like a truly bad idea.

Umm find_lock_page doesnt sleep does it ?

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: raw access and qlogic isp device driver?

[Alan Cox]

> Any chance of anyone elaborating on any RAWIO flaws?
> 
> *Seems* to work fine with:
> - 2.4.2 (inc Dave Miller's zero copy patch)
> - qlogic fc driver & qla2200
> - PIII
> - Seagate ST39103fc drives in a JBOD
> 
> I really need to know any *specific* issues with RAWIO.

All I know is that Stephen said he had a set of patches needed to fix rawio.
I've not applied them nor afaik has Linus.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Prevent OOM from killing init

[Alan Cox]

> You don't beleve me if I tell you: DOS extender and JVM (Java Virtual
> Machine)

The JVM doesnt actually. The JVM will itself spontaenously explode in real
life when out of memory. Maybe the JVM on a DOS extender 8)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [OT] Linux Worm (fwd)

[Herbert Xu]

Michael Bacarella <[EMAIL PROTECTED]> wrote:
> On Fri, Mar 23, 2001 at 01:51:11PM -0500, Doug McNaught wrote:
>> 
>> Is there an alternative to BIND that's free software?  Never seen
>> one. 

> Have a look at djbdns.

> http://cr.yp.to/djbdns.html

It is NOT free software.
-- 
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Prevent OOM from killing init

[Szabolcs Szakacsits]

On Fri, 23 Mar 2001, Paul Jakma wrote:
> On Fri, 23 Mar 2001, Szabolcs Szakacsits wrote:
> > About the "use resource limits!". Yes, this is one solution. The
> > *expensive* solution (admin time, worse resource utilization, etc).

Thanks for cutting out relevant parts that said how to increase user
base and satisfaction keeping and using the existent possibility as
well.

> traditional user limits have worse resource utilisation? think what
> kind of utilisation a guaranteed allocation system would have. instead
> of 128MB, you'd need maybe a GB of RAM and many many GB of swap for
> most systems.

Nonsense hodgepodge. See and/or mesaure the impact. I sent numbers in my
former email. You also missed non-overcommit must be _optional_ [i.e.
you wouldn't be forced to use it ;)]. Yes, there are users and
enterprises who require it and would happily pay the 50-100% extra swap
space for the same workload and extra reliability.

> - setting up limits on a RH system takes 1 minute by editing
> /etc/security/limits.conf.

At every time you add/delete users, add/delete special apps, etc.
Please note again, some people wants this way, some only for sometimes,
and others really don't care because system guarantees for the admins
they will always have the resources to take action [unfortunately this
is not Linux].

> - Rik's current oom killer may not do a good job now, but it's
> impossible for it to do a /perfect/ job without implementing
> kernel/esp.c.

Rik's killer is quite fine at _default_. But there will be always people
who won't like it [the bastards think humans can still make better
decisions than machines]. Wouldn't it be win for both sides if you could
point out, "Hey, if you don't like the default, use the
/proc/sys/vm/oom_killer interface"? As I said before there are also
such patch by Chris Swiedler and definitely not a huge, complex one.
And these stupid threads could be forgotten for good and all.

> - with limits set you will have:
>  - /possible/ underutilisation on some workloads.

Depends, guaranteed underutilisation or guaranteed extra unreliability
fit the picture many times as well.

> no matter how good or bad Rik's killer is, i'd much rather set limits
> and just about /never/ have it invoked.

Thanks for expressing your opinion but others [not necessarily me] have
"occasionally" other one depending on the job what the box must do.

Szaka


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Prevent OOM from killing init

[george anzinger]

What happens if you just make swap VERY large?  Does the system thrash
it self to a virtual standstill?  Is this a possible answer?  Supposedly
you could then sneak in and blow away the bad guys manually ...

George

Paul Jakma wrote:
> 
> On Fri, 23 Mar 2001, Szabolcs Szakacsits wrote:
> 
> > About the "use resource limits!". Yes, this is one solution. The
> > *expensive* solution (admin time, worse resource utilization, etc).
> 
> traditional user limits have worse resource utilisation? think what
> kind of utilisation a guaranteed allocation system would have. instead
> of 128MB, you'd need maybe a GB of RAM and many many GB of swap for
> most systems.
> 
> some hopefully non-ranting points:
> 
> - setting up limits on a RH system takes 1 minute by editing
> /etc/security/limits.conf.
> 
> - Rik's current oom killer may not do a good job now, but it's
> impossible for it to do a /perfect/ job without implementing
> kernel/esp.c.
> 
> - with limits set you will have:
>  - /possible/ underutilisation on some workloads.
>  - chance of hitting Rik's OOM killer reduced to almost nothing.
> 
> no matter how good or bad Rik's killer is, i'd much rather set limits
> and just about /never/ have it invoked.
> 
> more beancounting will make limits more useful (eg global?) and maybe
> dists can start setting up some kind of limits by default at install
> time based on the RAM installed and whether user selected
> server/workstation/etc.. install.
> 
> Then hopefully we can be a little less concerned about how close Rik
> gets to the impossible task of implementing esp.c.
> 
> > Szaka
> 
> --paulj
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.4.2-ac23

[Horst von Brand]

Adrian Bunk <[EMAIL PROTECTED]> said:
> 2.4.2-ac23
> ...
> o   Fix i386 #ifdef bug with notsc disable  (Anton Blanchard)
> ...
> 
> 
> This change has broken the compile for me (my .config is attached):
> 
> gcc -D__KERNEL__ -I/home/bunk/linux/linux/include -Wall
> -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe
> -mpreferred-stack-boundary=2 -march=k6-c -o setup.o setup.c
> setup.c: In function `identify_cpu':
> setup.c:2280: `tsc_disable' undeclared (first use in this function)
> setup.c:2280: (Each undeclared identifier is reported only once
> setup.c:2280: for each function it appears in.)
> setup.c: In function `get_cpuinfo':
> setup.c:2378: warning: unused variable `x86_udelay_tsc'
> make[1]: *** [setup.o] Error 1
> make[1]: Leaving directory `/home/bunk/linux/linux/arch/i386/kernel'
> make: *** [_dir_arch/i386/kernel] Error 2

Same here. i686 in a Toshiba Satellite Pro laptop.
-- 
Dr. Horst H. von Brand   mailto:[EMAIL PROTECTED]
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CRAMFS

[Amit D Chaudhary]

> I don't know why the comparision is made though, they are used for two
> completely different things... ramfs is for temporary file storage, cramfs
> is for immutable files stored on flash. Each by itself is quite optimal
> for what it's designed for, isn't it ?

Exactly. My mistake earlier to assume cramfs was "compressed ramfs"! ;-)
I should compare it to the tar.gz option and JFFS2. Will do in the next 
evaluation.
This will be more of a replace initrd+custom /linuxrc with a 
CRAMFS-based rootfs on a flash device assuming CRAMFS can be directly 
read by kernel\init for getting the rootfs. Ditto for JFFS2

Also, the platform is PPC, IBM 405GP to be precise.

Regards
Amit

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

network unusable

[Michael Devogelaere]

Hi,

I'm experiencing problems with an rtl8029-nic. The computer acts as a
multicast-client receiving a disk-image from a server. That transfer went
fine during the first 1.5 gb and then the machine stopped responding.
I tried to ping it, but got no answer. On the machine i see that the
error-packets (/sbin/ifconfig) grow very fast, but the machine cannot
send or receive anymore.  The arp-table contains 00:00:.. for all 
hw-addresses.  Dmesg shows: 
eth0: bogus packet size: 65360, status=0x0 nxpg=0x0
(repeated for 100+ times)

The machine runs kernel 2.4.2 without module-support. All other participating 
computers have exactly the same hardware and software (they were all cloned 
with ghost).  If i restart the program, everything goes fine for some 
minutes and then another computer crashes with exactly the same symptoms.
When i restart the network-configuration, everything seems to work again.

Any help would be appreciated !

Kindly regards,
Michael Devogelaere.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CRAMFS

[Bjorn Wesen]

On Fri, 23 Mar 2001, David Woodhouse wrote:
> > 1. RAMFS is just more stable in terms of less complexity, less bugs reported 
> > over the time, etc.
> > 2. RAMFS is a fairly robust filesystem and all features required as far as I can 
> > tell.

Ok, ramfs is really simple, but heck, cramfs is not much more complex :)
It's as simple a flash-filesystem as you can get.

I don't know why the comparision is made though, they are used for two
completely different things... ramfs is for temporary file storage, cramfs
is for immutable files stored on flash. Each by itself is quite optimal
for what it's designed for, isn't it ?

> I'm not aware of any bugs being found in cramfs recently - unless you 
> wanted to use it on Alpha (or anything else where PAGE_SIZE != the 
> hard-coded 4096 in mkcramfs.c).

I committed a patch that disappeared that added the choice of page size
(trivial yes :), we have PAGE_SIZE == 8192 on our systems. Works fine.

> I wouldn't avoid it for those reasons - although if you're _really_ short 
> of flash space, the same argument applies as for JFFS2 - a single 
> compression stream (tar.gz) will be smaller than compressing individual 
> pages like JFFS2 and cramfs do.

Here are some results from a quite mixed filesystem:

[bjornw@godzilla linux]$ ls -l cram*
-rw-r--r--   1 bjornw   users 1179648 Mar 23 22:38 cram32768
-rw-r--r--   1 bjornw   users 1282048 Mar 23 22:38 cram4096
-rw-r--r--   1 bjornw   users 1220608 Mar 23 22:38 cram8192

(the numbers correspond to blocksize)

There's not any big difference here. 

With bigger files though, the difference get larger. YMMV.

Notice that you can change cramfs so it uses a blocksize that is bigger
than PAGE_SIZE, of course, if it really is necessary. You'll get worse
performance at run-time though since you need to cache the page and hope
for read-ahead or similar (you can stuff the pages in the page-cache even
if they are not requested for example).

-BW


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Where's Alan?

[Ion Badulescu]

On Thu, 22 Mar 2001 11:30:46 -0800 (PST), Alan Olsen <[EMAIL PROTECTED]> wrote:

> He found out what happens when you mix Penguin bars and Penguin Mints and
> he has been in detox since. ];>

Wouldn't that be de-tux, though? :-)

Ion

-- 
  It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.4.2-ac20 patch for process time double-counting (was: Linux 2.4.2 fails to merge mmap areas, 700% slowdown.)

[Kevin Buhr]

Mike Galbraith <[EMAIL PROTECTED]> writes:
> 
> > Mike, would you like to try out the following (untested) patch against
> > vanilla ac20 to see if it does the trick?
> 
> Yes, that fixed it.

Great!  Can you test one more configuration, please?  I can't test it
properly with my SMP motherboard.  Under "ac20", if you disable:

Symmetric multi-processing support (CONFIG_SMP)

you'll get to say yes to:

APIC support on uniprocessors (CONFIG_X86_UP_APIC)

If you say yes to that, you'll also get to say yes to:

IO-APIC support on uniprocessors (CONFIG_X86_UP_IOAPIC)

Can you check that the following patch against vanilla "ac20" works
correctly with SMP disabled and X86_UP_APIC enabled?  (The original
patch I gave you won't compile with this configuration, since I put
the declaration in the wrong include file.)  It shouldn't matter
whether X86_UP_IOAPIC is enabled or disabled.

In addition to checking that the sys/user times look right, please
check for the message:

Using local APIC timer interrupts.

in your boot messages (I *don't* think it'll be there, but I'm not
sure, and I'd really like to know one way or the other).  In fact, if
you could send me your kernel messages up to the PCI probe, that would
be ideal.

Thanks muchly!

Kevin <[EMAIL PROTECTED]>

*   *   *

diff -ru linux-2.4.2-ac20-vanilla/arch/i386/kernel/apic.c 
linux-2.4.2-ac20/arch/i386/kernel/apic.c
--- linux-2.4.2-ac20-vanilla/arch/i386/kernel/apic.cFri Mar 23 14:21:47 2001
+++ linux-2.4.2-ac20/arch/i386/kernel/apic.cFri Mar 23 15:12:15 2001
@@ -30,6 +30,9 @@
 #include 
 #include 
 
+/* Using APIC to generate smp_local_timer_interrupt? */
+int using_apic_timer = 0;
+
 int prof_multiplier[NR_CPUS] = { 1, };
 int prof_old_multiplier[NR_CPUS] = { 1, };
 int prof_counter[NR_CPUS] = { 1, };
@@ -872,6 +875,9 @@
 
 void __init setup_APIC_clocks (void)
 {
+   printk("Using local APIC timer interrupts.\n");
+   using_apic_timer = 1;
+
__cli();
 
calibration_result = calibrate_APIC_clock();
diff -ru linux-2.4.2-ac20-vanilla/arch/i386/kernel/time.c 
linux-2.4.2-ac20/arch/i386/kernel/time.c
--- linux-2.4.2-ac20-vanilla/arch/i386/kernel/time.cFri Mar 23 14:21:47 2001
+++ linux-2.4.2-ac20/arch/i386/kernel/time.cFri Mar 23 14:04:43 2001
@@ -422,7 +422,7 @@
if (!user_mode(regs))
x86_do_profile(regs->eip);
 #else
-   if (!smp_found_config)
+   if (!using_apic_timer)
smp_local_timer_interrupt(regs);
 #endif
 
diff -ru linux-2.4.2-ac20-vanilla/include/asm-i386/mpspec.h 
linux-2.4.2-ac20/include/asm-i386/mpspec.h
--- linux-2.4.2-ac20-vanilla/include/asm-i386/mpspec.h  Mon Jan  8 13:35:28 2001
+++ linux-2.4.2-ac20/include/asm-i386/mpspec.h  Fri Mar 23 14:20:19 2001
@@ -182,6 +182,7 @@
 extern int mp_current_pci_id;
 extern unsigned long mp_lapic_addr;
 extern int pic_mode;
+extern int using_apic_timer;
 
 #endif
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Prevent OOM from killing init

[Jonathan Morton]

>The main point is letting malloc fail when the memory cannot be
>guaranteed.

If I read various things correctly, malloc() is supposed to fail as you
would expect if /proc/sys/vm/overcommit_memory is 0.  This is the case on
my RH 6.2 box, dunno about yours.  I can write a simple test program which
simply allocates tons of memory if you like...

...and I did.  It filled up my physical and swap memory, and got killed by
the OOM handler before malloc() failed, even though overcommit_memory was
set to 0.

*BAD!*

Here's my test program and output (on a Duron with 256M physical and 250M
swap):

[chromi@beryllium compsci]$ cat make_mem.c
#include 
#include 

int main(void)
{
  /* Allocate tons of RAM, print out how far, we get, and exit when we
malloc() fails.
   * We also access each page we allocate, to ensure we really are getting
the memory we reserve.
   * If we are killed by SIGSEGV or by OOM instead of malloc() failing, the
VM system is broken.
   */

  char *p;
  unsigned long pages = 0;

  while(1) {
p = malloc(1024);
if(!p)
  break;
*p = 1;
pages++;
printf("%lu K\r", pages);
  }

  printf("\n*** malloc() failed!\n");

  return 0;
}
[chromi@beryllium compsci]$ gcc -O -Wall -o make_mem make_mem.c
[chromi@beryllium compsci]$ ./make_mem
493625 KKilled
[chromi@beryllium compsci]$


--
from: Jonathan "Chromatix" Morton
mail: [EMAIL PROTECTED]  (not for attachments)
big-mail: [EMAIL PROTECTED]
uni-mail: [EMAIL PROTECTED]

The key to knowledge is not to rely on people to teach you it.

Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/

-BEGIN GEEK CODE BLOCK-
Version 3.12
GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS
PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*)
-END GEEK CODE BLOCK-


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: UDMA 100 / PIIX4 question

[Tim Moore]

> I am afraid that I do not know how to change my partition type.  I can confirm. 
>however, that the BIOS is set to Auto / LBA and that BIOS confirms UDMA 5 is set (and 
>cannot be set unless the correct cabling is detected).

[tim@abit tim]# fdisk /dev/hdc

Command (m for help): t
Partition number (1-4): 1
Hex code (type L to list codes): c
Changed system type of partition 1 to c (Win95 FAT32 (LBA))
...

> But is my controller, though detected as a PIIX4 (and described as such in the Asus 
>manual), really a PIIX4?  lspci :
> 
> 00:00.0 Host bridge: Intel Corporation: Unknown device 1130 (rev 02)
> 00:01.0 PCI bridge: Intel Corporation: Unknown device 1131 (rev 02)
> 00:1e.0 PCI bridge: Intel Corporation: Unknown device 244e (rev 01)
> 00:1f.0 ISA bridge: Intel Corporation: Unknown device 2440 (rev 01)
> 00:1f.1 IDE interface: Intel Corporation: Unknown device 244b (rev 01)
> 00:1f.2 USB Controller: Intel Corporation: Unknown device 2442 (rev 01)
> ...
> 
> On the other hand, cat /proc/ide/piix :
> 
>Intel PIIX4 Ultra 100 Chipset.
> --- Primary Channel  Secondary Channel -
>  enabled  enabled
> --- drive0 - drive1  drive0 -- drive1 --
> DMA enabled:yes  no  yes   no
> UDMA enabled:   yes  no  yes   no
> UDMA enabled:   5X   2 X
> UDMA
> DMA
> PI

ICH2 is marked '80821BA' and is rated ATA/100 by intel, PIIX4 is '82371AB'
so you can look on your motherboard.  Andre is the one to say if the driver
is compatible.  I can't find a single reference to the 80821 in
drivers/block/*.c for 2.2.19pre17 + ide.2.2.18.1221.

Here's what a PIIX4 looks like.

[tim@smp ide]# cat /proc/ide/ide0/config
pci bus 00 device 39 vid 8086 did 7111 channel 0
86 80 11 71 05 00 80 02 01 80 01 01 00 20 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
01 f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
07 a3 00 80 00 00 00 00 01 00 02 00 00 00 00 00
...
00 00 00 00 00 00 00 00 30 0f 00 00 00 00 00 00

[tim@smp ide]# cat /proc/ide/piix

Intel PIIX4 Ultra 33 Chipset.
--- Primary Channel  Secondary Channel
-
 enabled  enabled
--- drive0 - drive1  drive0 -- drive1
--
DMA enabled:yes  no  nono 
UDMA enabled:   yes  no  nono 
UDMA enabled:   2X   X X
UDMA
DMA
PIO

[tim@smp tim]# lspci | grep IDE
00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01)
[tim@smp tim]# lspci -n | grep 7.1
00:07.1 Class 0101: 8086:7111 (rev 01)

--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Prevent OOM from killing init

[Martin Dalecki]

SodaPop wrote:
> 
> On Fri, 23 Mar 2001, Martin Dalecki wrote:
> 
> > SodaPop wrote:
> > >
> > > Rik, is there any way we could get a /proc entry for this, so that one
> > > could do something like:
> >
> > I will respond; NO there is no way for security reasons this is not a
> > good idea.
> >
> > > cat /proc/oom-kill-scores | sort +3
> 
> Oh, you mean like /proc/kcore is a bad idea for security reasons?

Yes. It should be the good old /dev/core anyway.
But its far more obscure to hack at, since it isn't plain text,
so basically it's far more difficult to get mands on it...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Prevent OOM from killing init

[Paul Jakma]

On Fri, 23 Mar 2001, Szabolcs Szakacsits wrote:

> About the "use resource limits!". Yes, this is one solution. The
> *expensive* solution (admin time, worse resource utilization, etc).

traditional user limits have worse resource utilisation? think what
kind of utilisation a guaranteed allocation system would have. instead
of 128MB, you'd need maybe a GB of RAM and many many GB of swap for
most systems.

some hopefully non-ranting points:

- setting up limits on a RH system takes 1 minute by editing
/etc/security/limits.conf.

- Rik's current oom killer may not do a good job now, but it's
impossible for it to do a /perfect/ job without implementing
kernel/esp.c.

- with limits set you will have:
 - /possible/ underutilisation on some workloads.
 - chance of hitting Rik's OOM killer reduced to almost nothing.

no matter how good or bad Rik's killer is, i'd much rather set limits
and just about /never/ have it invoked.

more beancounting will make limits more useful (eg global?) and maybe
dists can start setting up some kind of limits by default at install
time based on the RAM installed and whether user selected
server/workstation/etc.. install.

Then hopefully we can be a little less concerned about how close Rik
gets to the impossible task of implementing esp.c.

> Szaka

--paulj

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: aic7xxx in 2.4.3-pre6 missing db.h

[Justin T. Gibbs]

>I am trying to compile the 2.4.3-pre6 linux kernel and it is failing
>because it cannot find the "db.h" header file.

Please upgrade to the latest aic7xxx driver.  Patches are available
here:

http://people.freebsd.org/~gibbs/linux/

That code will not attempt to build the firmware unless you set your
kernel config to do so.

--
Justin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH for 2.5] preemptible kernel

[Nigel Gamble]

On Thu, 22 Mar 2001, Rusty Russell wrote:
> Nigel's "traverse the run queue and mark the preempted" solution is
> actually pretty nice, and cheap.  Since the runqueue lock is grabbed,
> it doesn't require icky atomic ops, either.

You'd have to mark both the preempted tasks, and the tasks currently
running on each CPU (which could become preempted before reaching a
voluntary schedule point).

> Despite Nigel's initial belief that this technique is fragile, I
> believe it will become an increasingly fundamental method in the
> kernel, so (with documentation) it will become widely understood, as
> it offers scalability and efficiency.

Actually, I agree with you now that I've had a chance to think about
this some more.

Nigel Gamble[EMAIL PROTECTED]
Mountain View, CA, USA. http://www.nrg.org/

MontaVista Software [EMAIL PROTECTED]

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.4.2 fails to merge mmap areas, 700% slowdown.

[James Lewis Nance]

On Thu, Mar 22, 2001 at 07:35:49PM +0100, Jakob Østergaard wrote:

> My code here is quite template heavy, and I suspect that's what's triggering
> it.  In fact, I can't compile our development code with optimization, because
> GCC runs out of memory (it only allocates some 300-500 MB, but each page has
> it's own map in /proc/pid/maps, and a wc -l /proc/pid/maps doesn't finish for
> minutes).  My typical GCC eats 100-200 MB and runs for several minutes.

Would it be possible for you to post the preprocessor outout to this list?
It would be quite nice to have this testcase.

Jim
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Advansys SCSI driver old verson?

[icabod]

I've noticed a small problem that hinders me from updatingmy system to the
new 2.4 kernels. I'm using a PowerMac with a Advansys SCSI 3940UW card in
it running my drives. I've noticed that since the 2.4 kernel series the
advanasys driver s version 3.2M and the driver version that works for me
and came with the 2.2.17+ kernels at least workes fid with my card, that
version is 3.3D. I was wondering if anyone had noticed this before, or if
there s a reason the older driver was used. The reason I bring this up is
tht the driver in the 2.4 kernel series does not drive my particular
card. I hope that the readers of this list find this helpful, if you have
any questions please feel free to reply. Thanks. 

-Icabod
 [EMAIL PROTECTED]

-- 
No sooner said than done -- so acts your man of worth.
-- Quintus Ennius

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Prevent OOM from killing init

[Tom Diehl]

On Fri, 23 Mar 2001, Rik van Riel wrote:

> Well, in that case you'll have to live with the current OOM
> killer.  Martin wrote down a pretty detailed description of
> what's wrong with my algorithm, if it really bothers him he
> should be able to come up with something better.
>
> Personally, I think there is more important VM code to look
> after, since OOM is a pretty rare occurrance anyway.

Well actually it is not that rare at least for me. Every 3 or 4 days I run
into it (It happened again this morning). The machine has 128 Megs of ram
and 256 Megs of swap. It is my desktop machine and I keep 3 or 4 netscape
windows running all of the time. Well I try to at least. Every 3 or 4 days
the OOM Killer kills netscape, it happened this morning. If I could fix it
I would but alas I do not have the knowledge. The best I can do is test. :(

This is NOT a complaint I just bring this up as another data point.
It used to lock the machine so things are getting better. fwiw, I am
currently running 2.4.2-ac18. The old ac kernels (do not remember exactly
which ones but it was single digits) would allow the machine to start
thrashing. I could usually see that it was running out of memory and if I
was fast enough could kill Netscape b4 the machine locked. If I was not
fast enough it would lock hard. Nothing in the logs.

HTH,

-- 
..Tom   ATA100 is another testimony to the fact that pigs can be
[EMAIL PROTECTED]  made to fly given sufficient thrust (to borrow an RFC)
Alan Cox lkml 11 Jan 01

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Worm (fwd)

[Michael H. Warfield]

On Fri, Mar 23, 2001 at 10:31:49AM -0800, Gerhard Mack wrote:
> On Fri, 23 Mar 2001, Bob Lorenzini wrote:

> > I'm annoyed when persons post virus alerts to unrelated lists but this
> > is a serious threat. If your offended flame away.

> This should be a wake up call... distributions need to stop using product
> with consistently bad security records. 

Bullshit.

This is a wake up call that admins need to keep installations up
to date.  When a security hole is found, I DON'T CARE if it's in a package
with a good security record or a poor security record.  It has to be
fixed and you can't put it off.  Certainly not in the current climate
with script driven worms like Ramen and 1i0n.

Having a poor security record is a warning to the developers that
it's time to clean up their act and do better.  Sendmail use to be the
bug of the month club.  Hell!  It use to be the bug of the week club.  Last
couple of years, it's been pretty solid.  If you only went on security
track record, we would all be using MMDF, which is still arguibly the most
secure mail transport around.  MMDF has had what?  One advisory in something
like 15 years of deployment?  It was the default MTA in SCO Unix for
years and was mandated at military installations for a long time...  Still,
when that one advisory comes out, you better update or you are toast.

You don't solely rely on packages that have "good security records"
never getting broken and then become complacent.  Sites that do that are
what we call "Warez" sites.  :-/


>   Gerhard

> --
> Gerhard Mack

> [EMAIL PROTECTED]

> <>< As a computer I find your faith in technology amusing.

Mike
-- 
 Michael H. Warfield|  (770) 985-6132   |  [EMAIL PROTECTED]
  (The Mad Wizard)  |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9  |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471|  possible worlds.  A pessimist is sure of it!

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Prevent OOM from killing init

[Paul Jakma]

On Fri, 23 Mar 2001, Guest section DW wrote:

> But yes, I am complaining because Linux by default is unreliable.

no, your distribution is unreliable by default.

> I strongly prefer a system that is reliable by default,
> and I'll leave it to others to run it in an unreliable mode.

currently, setting sensible user limits on my machines means i never
get a hosed machine due to OOM. These limits are easy to set via
pam_limits. (not perfect though, i think its session specific..)

granted, if the machine hasn't been setup with user limits, then linux
doesn't deal at all well with OOM, so this should be fixed. but it can
easily be argued that admin error in not configuring limits is the
main cause for OOM.

> Andries

regards,

--paulj

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Prevent OOM from killing init

[SodaPop]

On Fri, 23 Mar 2001, Martin Dalecki wrote:

> SodaPop wrote:
> >
> > Rik, is there any way we could get a /proc entry for this, so that one
> > could do something like:
>
> I will respond; NO there is no way for security reasons this is not a
> good idea.
>
> > cat /proc/oom-kill-scores | sort +3

Oh, you mean like /proc/kcore is a bad idea for security reasons?

Duh, make its permission bits 400.

-dennis T


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: raw access and qlogic isp device driver?

[Joel Gallun]

On Fri, 23 Mar 2001, Alan Cox wrote:

> > I'm trying to use Stephen Tweedie's raw device support to access disks
> > attached to a Qlogic ISP 1040/B controller and kernel oopses.
>
> 2.2 or 2.4 ?

2.4.2

> > Has anyone used the raw device with qlogicisp driver? Does anyone have any
> > interest in looking at this?
>
> It shouldnt matter which driver is involved, but 2.4 raw stuff is reported
> broken still

We've used raw with the compaq smart2 and symbios 53c8xx drivers without
problems on 2.4.2, but shortly after we touch a raw device over top of the
qlogicisp we get an oops.

Joel

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/