Re: Linux should better cope with power failure

[Otto Wyss]

> 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.
> 
You probably haven't tried to use sync or you would have noticed the
performace penalty. I think nobody really considers sync an alternative.

O. Wyss
-
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: athlon+2.2+pdc20267=hang?

[Henrik Størner]

In <[EMAIL PROTECTED]> Derrick J Brashear 
<[EMAIL PROTECTED]> writes:

>Earlier today I swapped an Athlon (tbird) 850 and an Epox 8KTA3 in for the 
>dual Celeron I had, moving all the cards into the new system. One of these 
>was a Promise PDC20267 with 4 40gb disks attached. The machine would not 
>boot; I assumed it was the i686-smp kernel and installed a Redhat 
>7.0-provided i386 kernel. Several hours and a dozen or so boots later, it 
>looks like when the bios on the PDC20267 is installed, the system hangs 
>while booting at the point where it would probe C/H/S from the devices 
>attached to the PDC20267 (they've already been identified by that point)

I see the same thing with an ASUS A7V133 motherboard that has a
PDC20265 installed on the motherboard. If I disable the PDC BIOS, the
system boots normally - but trying to use any UDMA mode hangs.
Ordinary mdma2 mode works fine. 

So I suspect that the real culprit is the UDMA mode which the BIOS
probably enables - when I boot the the BIOS disabled, the device shows
up as running in pio mode.

All in all, I haven't had much success with the PDC controllers - 
both cases I have tried will hang the system when enabling UDMA
(and there is no common hardware involved).
-- 
Henrik Storner  | "ATA100 is another testimony to the fact that 
<[EMAIL PROTECTED]> |  pigs can be made to fly given sufficient thrust"
| 
|  Linux kernel hacker Alan Cox, on IDE drives
-
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] mdacon needs to use __setup()

[Paul Gortmaker]

The kernel command line setup function for MDA console support is
currently dangling in outer space and not called (and hence non
functional).  There was also a warning about a non used function
whose callers were half  /* */ 'ed out so I cleaned that up as well.

Patch should apply to any recent 2.4.x kernel.

Paul.

--- drivers/video/mdacon.c~ Wed Feb 14 02:41:44 2001
+++ drivers/video/mdacon.c  Mon Mar 12 19:37:21 2001
@@ -21,6 +21,9 @@
  *  This file is subject to the terms and conditions of the GNU General Public
  *  License.  See the file COPYING in the main directory of this archive for
  *  more details.
+ *
+ *  Changelog:
+ *  Paul G. (03/2001) Fix mdacon= boot prompt to use __setup().
  */
 
 #include 
@@ -129,6 +132,7 @@
spin_unlock_irqrestore(&mda_lock, flags);
 }
 
+#ifdef TEST_MDA_B
 static int test_mda_b(unsigned char val, unsigned char reg)
 {
unsigned long flags;
@@ -143,6 +147,7 @@
spin_unlock_irqrestore(&mda_lock, flags);
return val;
 }
+#endif
 
 static inline void mda_set_origin(unsigned int location)
 {
@@ -182,20 +187,27 @@
 
 
 #ifndef MODULE
-void __init mdacon_setup(char *str, int *ints)
+static int __init mdacon_setup(char *str)
 {
/* command line format: mdacon=, */
 
+   int ints[3];
+
+   str = get_options(str, ARRAY_SIZE(ints), ints);
+
if (ints[0] < 2)
-   return;
+   return 0;
 
if (ints[1] < 1 || ints[1] > MAX_NR_CONSOLES || 
ints[2] < 1 || ints[2] > MAX_NR_CONSOLES)
-   return;
+   return 0;
 
-   mda_first_vc = ints[1]-1;
-   mda_last_vc  = ints[2]-1;
+   mda_first_vc = ints[1];
+   mda_last_vc  = ints[2];
+   return 1;
 }
+
+__setup("mdacon=", mdacon_setup);
 #endif
 
 static int __init mda_detect(void)
@@ -237,17 +249,19 @@
 * memory location, so now we do an I/O port test.
 */
 
+#ifdef TEST_MDA_B
/* Edward: These two mess `tests' mess up my cursor on bootup */
 
/* cursor low register */
-   /* if (! test_mda_b(0x66, 0x0f)) {
+   if (! test_mda_b(0x66, 0x0f)) {
return 0;
-   } */
+   }
 
/* cursor low register */
-   /* if (! test_mda_b(0x99, 0x0f)) {
+   if (! test_mda_b(0x99, 0x0f)) {
return 0;
-   } */
+   }
+#endif
 
/* See if the card is a Hercules, by checking whether the vsync
 * bit of the status register is changing.  This test lasts for


-
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.

[Jakob Østergaard]

On Fri, Mar 23, 2001 at 09:02:30PM -0800, Linus Torvalds wrote:
> 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.

I was unable to compile gcc-3.0 from CVS this morning - so no tests there
for now...

First the "small" test case:
-
2.4.2:
  gcc-2.96:  -O6 -felide-constructors -fPIC
  real7m31.748s
  user3m52.340s
  sys 3m38.180s
  Memory consumption:  ~200MB

2.4.3-pre7:
  gcc-2.96:  -O6 -felide-constructors -fPIC
  real3m52.347s
  user3m46.120s
  sys 0m3.370s

That's pretty darn impressive Linus !  3m38 -> 3sec !  Now if the GCC people
could only repeat that trick   ;)


Then the bigger one:
-
2.4.2:
  gcc-2.96:  -O6 -felide-constructors -fPIC
  Fails compilation with "Virtual memory exhausted!" after
  real37m28.305s
  user23m39.930s
  sys 13m44.900s
  Memory consumption:  ~300MB before failure

Note - there are no ulimits set, and the machine has more than enough memory

2.4.3-pre7:
  gcc-2.96:  -O6 -felide-constructors -fPIC
  real31m48.898s
  user31m21.460s
  sys 0m26.980s
  Memory consumption:  ~400MB - successful completion

Cool !  I can work again   ;)
 
> 
> 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.

Beautiful !

Also, the speedup gained here is ~70 times, which may be more than the changed
allocation in gcc-3 will buy us (was that 32 times?).  And,  after all,  there
_has_ to be some other case out there which is not as easily fixed as the GCC
one.

>   Linus

-- 

:   [EMAIL PROTECTED]   : And I see the elder races, :
:.: putrid forms of man:
:   Jakob Østergaard  : See him rise and claim the earth,  :
:OZ9ABN   : his downfall is at hand.   :
:.:{Konkhra}...:
-
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:

> > 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.
> >
> You probably haven't tried to use sync or you would have noticed the
> performace penalty. I think nobody really considers sync an alternative.
>
> O. Wyss

You can't have the best of everything.  There are tradeoffs.  A viable option is a
journaled filesystem.  Linux boasts a few, two of which are at your fingertips by
way of config options.  Read up on JFS or ReiserFS.

-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] Prevent OOM from killing init

[Mike Galbraith]

On Sat, 24 Mar 2001, Doug Ledford wrote:

[snip list of naughty behavior]

> What was that you were saying about "should *never* happen"?  Oh, and let's
> not overlook the fact that it killed off mostly system daemons to start off
> with while leaving the real culprits alone.  Once it did get around to the
> real culprits (diff and tar), it wasn't even killing them because they were
> overly large, it was killing them because it wasn't reclaiming space from the
> buffer cache and page cache.  All of the programs running on this machine were
> never more than roughly 256MB of program code, and this is a 1GB machine.
> This behavior is totally unacceptable and, as Alan put it, is a bug in the
> code.  It should never trigger the oom killer with 750+MB of cache sitting
> around, but it does.  If you want people to buy into the value of the oom
> killer, you've at least got to get it to quit killing shit when it absolutely
> doesn't need to.
>
> To those people that would suggest I send in code I only have this to say.
> Fine, I'll send in a patch to fix this bug.  It will make the oom killer call
> the cache reclaim functions and never kill anything.  That would at least fix
> the bug you see above.

That won't fix the problem, but merely paper it over.  The problem is
in the balancing code that lets swap be exausted while at the same time
allowing cache to become obscenely obese in the first place.  I can't
trigger that behavior here, but it obviously exists for some workloads.

General thread comment:
To those who are griping, and obviously rightfully so, Rik has twice
stated on this list that he could use some help with VM auto-balancing.
The responses (visible on this list at least) was rather underwhelming.
I noted no public exchange of ideas.. nada in fact.

Get off your lazy butts and do something about it.  Don't work on the
oom-killer though.. that's only a symptom.  Work on the problem instead.

-Mike  (who doesn't give a rats ass if he gets flamed;-)

-
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]

From [EMAIL PROTECTED] Sat Mar 24 03:00:17 2001

> 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. How would you use it? Compute individual limits for
each process? One typically has a few very large processes
that may easily take most of memory, and lots of small processes.
With a low ulimit these large processes do not run.
With a large ulimit it does not help against OOM.
The job of accounting what is available belongs to the system,
not the user.

Note that ulimit does not limit the sum of your processes,
it limits each individual process.

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: Linux should better cope with power failure

[Otto Wyss]

> > You probably haven't tried to use sync or you would have noticed the
> > performace penalty. I think nobody really considers sync an alternative.
> >
> > O. Wyss
> 
> You can't have the best of everything.  There are tradeoffs.  A viable option is > a 
>journaled filesystem.  Linux boasts a few, two of which are at your fingertips > by 
>way of config options.  Read up on JFS or ReiserFS.
> 
How about the following solution: During high activity _any_ FS is
treated as if it were mounted asynch, during low/no activity it's
treaded as synch. This simple solution certainly will be acceptable for anyone.

O. Wyss
-
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] [RESEND] update chipsfb driver

[Paul Mackerras]

Linus,

At present, drivers/video/chipsfb.c can only be used on PPC, and it
doesn't compile even on PPC.  The patch below makes it compile, and by
changing it to use the generic inb/outb, means that there is at least
a chance it can be used on other platforms.  The patch is against
2.4.3-pre7, could you apply it please?

Paul.

diff -urN linux/drivers/video/chipsfb.c pmac/drivers/video/chipsfb.c
--- linux/drivers/video/chipsfb.c   Thu Feb 22 14:25:27 2001
+++ pmac/drivers/video/chipsfb.cSat Mar  3 21:17:19 2001
@@ -29,17 +29,19 @@
 #include 
 #include 
 #include 
+#include 
+
 #ifdef CONFIG_FB_COMPAT_XPMAC
 #include 
-#endif
-#include 
-#include 
 #include 
+#endif
 #ifdef CONFIG_PMAC_BACKLIGHT
 #include 
 #endif
+#ifdef CONFIG_PMAC_PBOOK
 #include 
 #include 
+#endif
 
 #include 
 #include 
@@ -56,14 +58,13 @@
struct {
__u8 red, green, blue;
} palette[256];
+   struct pci_dev *pdev;
unsigned long frame_buffer_phys;
__u8 *frame_buffer;
unsigned long blitter_regs_phys;
__u32 *blitter_regs;
unsigned long blitter_data_phys;
__u8 *blitter_data;
-   unsigned long io_base_phys;
-   __u8 *io_base;
struct fb_info_chips *next;
 #ifdef CONFIG_PMAC_PBOOK
unsigned char *save_framebuffer;
@@ -74,10 +75,10 @@
 };
 
 #define write_ind(num, val, ap, dp)do { \
-   out_8(p->io_base + (ap), (num)); out_8(p->io_base + (dp), (val)); \
+   outb((num), (ap)); outb((val), (dp)); \
 } while (0)
 #define read_ind(num, var, ap, dp) do { \
-   out_8(p->io_base + (ap), (num)); var = in_8(p->io_base + (dp)); \
+   outb((num), (ap)); var = inb((dp)); \
 } while (0);
 
 /* extension registers */
@@ -97,10 +98,10 @@
 #define read_sr(num, var)  read_ind(num, var, 0x3c4, 0x3c5)
 /* attribute registers - slightly strange */
 #define write_ar(num, val) do { \
-   in_8(p->io_base + 0x3da); write_ind(num, val, 0x3c0, 0x3c0); \
+   inb(0x3da); write_ind(num, val, 0x3c0, 0x3c0); \
 } while (0)
 #define read_ar(num, var)  do { \
-   in_8(p->io_base + 0x3da); read_ind(num, var, 0x3c0, 0x3c1); \
+   inb(0x3da); read_ind(num, var, 0x3c0, 0x3c1); \
 } while (0)
 
 static struct fb_info_chips *all_chips;
@@ -117,7 +118,7 @@
  */
 int chips_init(void);
 
-static void chips_of_init(struct device_node *dp);
+static void chips_pci_init(struct pci_dev *dp);
 static int chips_get_fix(struct fb_fix_screeninfo *fix, int con,
 struct fb_info *info);
 static int chips_get_var(struct fb_var_screeninfo *var, int con,
@@ -253,29 +254,29 @@
 #endif /* CONFIG_PMAC_BACKLIGHT */
/* get the palette from the chip */
for (i = 0; i < 256; ++i) {
-   out_8(p->io_base + 0x3c7, i);
+   outb(i, 0x3c7);
udelay(1);
-   p->palette[i].red = in_8(p->io_base + 0x3c9);
-   p->palette[i].green = in_8(p->io_base + 0x3c9);
-   p->palette[i].blue = in_8(p->io_base + 0x3c9);
+   p->palette[i].red = inb(0x3c9);
+   p->palette[i].green = inb(0x3c9);
+   p->palette[i].blue = inb(0x3c9);
}
for (i = 0; i < 256; ++i) {
-   out_8(p->io_base + 0x3c8, i);
+   outb(i, 0x3c8);
udelay(1);
-   out_8(p->io_base + 0x3c9, 0);
-   out_8(p->io_base + 0x3c9, 0);
-   out_8(p->io_base + 0x3c9, 0);
+   outb(0, 0x3c9);
+   outb(0, 0x3c9);
+   outb(0, 0x3c9);
}
} else {
 #ifdef CONFIG_PMAC_BACKLIGHT
set_backlight_enable(1);
 #endif /* CONFIG_PMAC_BACKLIGHT */
for (i = 0; i < 256; ++i) {
-   out_8(p->io_base + 0x3c8, i);
+   outb(i, 0x3c8);
udelay(1);
-   out_8(p->io_base + 0x3c9, p->palette[i].red);
-   out_8(p->io_base + 0x3c9, p->palette[i].green);
-   out_8(p->io_base + 0x3c9, p->palette[i].blue);
+   outb(p->palette[i].red, 0x3c9);
+   outb(p->palette[i].green, 0x3c9);
+   outb(p->palette[i].blue, 0x3c9);
}
}
 }
@@ -307,11 +308,11 @@
p->palette[regno].red = red;
p->palette[regno].green = green;
p->palette[regno].blue = blue;
-   out_8(p->io_base + 0x3c8, regno);
+   outb(regno, 0x3c8);
udelay(1);
-   out_8(p->io_base + 0x3c9, red);
-   out_8(p->io_base + 0x3c9, green);
-   out_8(p->io_base + 0x3c9, blue);
+   outb(red, 0x3c9);
+   outb(green, 0x3c9);
+   outb(blue, 0x3c9);
 
 #ifdef FBCON_HAS_CFB16
if (regno < 16)
@@ -388,7 +389,7 @@
disp->visual = fix->

IDE drive status error 0x058 under load

[Nick Clark]

Hey. Using Kernel 2.2.18 + E-IDE patches Rev 6.30 + Raid patches

Putting together a fileserver setup with two mirrored FSs over four 
disks & two IDE controllers (ie each disk on controller 1 is mirrored to 
a second on Controller 2, using raid 1).

No problems accessing disks separately, can create FS on each Ok with 
out errors. Can build each raid pair separately with no errors.

But when attempting to build raid devices on all four disks at the same 
time get many of these

Mar 22 15:41:11 uther kernel: hdk: status error: status=0x58 { 
DriveReady SeekComplete DataRequest }
Mar 22 15:41:11 uther kernel: hdk: drive not ready for command

.. from all four disks. Also get these when attempting mke2fs on all 
disks at the same time (no raid).

Im guessing (probably incorrectly) that this is a warning message only & 
that I can ignore them; can anyone confirm / deny that for me? Got a bit 
out of my depth with this..

Hardware is
ABit VP6 M/B, 2x1Ghz PIII, 512MB
2x Promise ultra100 PCI IDE controllers with 4x IBM-DTLA-307075 73Gb Drives
3Com 3C980 NIC
5th IBM-DTLA-307075 as root disk (no mirror), on M/B IDE controller. 
Onboard 'raid' controler disabled in bios.

Software is
RedHat 7.01 distribution
Kernel 2.2.18 + E-IDE patches Rev 6.30 + Raid patches
(also tried with 2.4.2 + E-IDE patches Rev 6.31, same problem)

... let me know if there is any other info I can give you. Thanx,

Nick.

-- 
Nick Clark is now --> [EMAIL PROTECTED] <-- Thanking you.

-
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

[Udo A. Steinberg]

Alan Cox wrote:
> 
> 2.4.2-ac24
> 2.4.2-ac23
> o   Back out problem via bridge change  (me)

That fixed the bttv problems I had. I've noticed that there are
four VIA vt8363 PCI fixups by now. Are these experimental to see if
some people's problems go away or have VIA confirmed that there
is a problem? 

Regards,
-Udo.
-
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/

..supermount ? no! (The Ultimate Solution :)

[Gerry]

Change the removable device-drivers to detect change. Fx, with cdrom, change 
the cdrom-part to detect when the disc tray ejects and when it goes back in, 
both for manual (user push eject) and automatic (program sends 
eject-request). This way the kernel just have to send a signal when this 
happens on a device (to processes who have requested to get to know).

This has several advantages:

* Supermount don't need to be kernel-related at all, and so doesn't need to 
be updated for each new kernel revision (cleaner kernel)
* Possible to get autorun on linux
* Can get rid of "insert cd and press ok"-like things (replace with "insert 
cd or press cancel")
* Imagination is the only limit :)

So, what do you say ? (I'm a newbie to this, so don't flame me to hard :)

Gerry
-
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/

sigtimedwait timeout

[Henrik Nordstrom]

Noticed that my sigtimedwait timeout patch got into the kernel, so polled signal I/O 
should now
work much better.

The question on why the timeout is calculated with an +1 for non-zero timeouts is 
still open.
AFAICT is is not needed as timespec_to_jiffies() does a correct rounding. The effect 
now is

 timeoutsleeping
 0  0
 1ns2 jiffies
 1 jiffies  2 jiffies
 2 jiffies  3 jiffies
 3 jiffies  4 jiffies
 ...

If the "+1" is taken out then the timeout scale becomes the expected one, starting at 
1 jiffie, not
2.


--
Henirk Nordstrom


Henrik Nordstrom wrote 22 September 2000:

> As I mentioned earlier sigtimedwait with a zero timeout (0,0) should not
> block, but it currently does for 10msec (one jiffie). This is a
> performance problem for applications using polled signal queues. SUSV2
> says specifically for this case "returns immediately with an error".
>
> Attached is a new version of my patch. The previous version messed up
> the signal mask if the signal queue was empty and a zero timeout was
> selected.
>
> It is still waiting one more jiffie than what is indicated by the
> timeout value if other than zero, caused by the following code fragment:
>
> timeout = (timespec_to_jiffies(&ts)
>+ (ts.tv_sec || ts.tv_nsec));
>
> Does anyone have any clue on why this +1 is there? I think this should
> also go away to only read
>
> timeout = timespec_to_jiffies(&ts);
>
> --
> Henrik Nordstrom

[patch deleted]


-
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]

>General thread comment:
>To those who are griping, and obviously rightfully so, Rik has twice
>stated on this list that he could use some help with VM auto-balancing.
>The responses (visible on this list at least) was rather underwhelming.
>I noted no public exchange of ideas.. nada in fact.
>
>Get off your lazy butts and do something about it.  Don't work on the
>oom-killer though.. that's only a symptom.  Work on the problem instead.

Since I'm hacking around in this area anyway (warning: kernel newbie
alert!), I'd be happy to help examine the balancing code from a fresh
perspective.  Where should I be looking?

--
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] Prevent OOM from killing init

[Jonathan Morton]

At 6:58 am + 24/3/2001, Rik van Riel wrote:
>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 ;)

I thought of some things which could break it, which I want to try and deal
with before releasing a patch.  Specifically, I want to make freepages.min
sacrosanct, so that malloc() *never* tries to use it.  This should be
fairly easy to implement - simply subtract freepages.min from the freemem
part.  An even nicer way would be to subtract freepages.low (or some
similar value) instead of freepages.min for non-root or non-privileged
processes.

BTW, is the 'current' pointer always valid when vm_enough_memory() is
called?  If so, I can remove one redundant check.

My NetBSD friend appears to have found code in the BSD kernel which sets up
ulimit values sensibly by default - eg. it's not handled by the boot
scripts.  Presumably a root process is capable of changing the limits, but
I'm guessing that sensible defaults in the kernel have to be a Good Thing.
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: Performance is weird (fwd)

[Sampsa Ranta]

Hi,

I got my ATM driver working properly, both LE155 and PCA200E did
good throughput when I found out the problem. I had some fancy option in
BIOS setup described like "Enhance chip performance", after turning this
on everything started to rock. So, my best guess is that there was
something terribly wrong in my PCI or chipset setup and this option fixed
the configuration.

My benchmark results on can be found from
http://www.netsonic.fi/~sampsa/netpipe/ if anyone else is interested on
the results. Based on my benchmark results I would say ForeRunner LE155
and PCA-200E and their Linux drivers seemed to benchmark equally well on
throughput, I have no idea on CPU usage, tho.

Thanks,
Sampsa


> --
> Subject: Performance is weird
> The following message was first posted to linux-atm mailing list, it
> is followed with one of the replies I got, thanks Werner Almesberger
> <[EMAIL PROTECTED]>.
>
> Actually, with 2.4.3pre4 kernel I got something like 66Mbit/s which were
> better than the 2.4.2 results.
> --
>
>  Hello,
>
> I am running a set of ForeRunner LE 155 cards on two Athlon 900
> machines. The cards are currently back to back connected. I am having
> problems with performance and this problem seems a bit curious to me.
>
> The boxes are running kernel versions 2.4.2 with the builtin ATM
> functionality.
>
> First when the machine is idle and i run ttcp_atm, the record is:
>
> [root@akvagw test]# ./ttcp_atm -t -a -s 0.90
> ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5013  atm  -> 0.90
> ttcp-t: socket
> ttcp-t: 16777216 bytes in 3.805066 real seconds = 4305.838585 KB/sec
> (35.273430
> Mb/sec)
>
> I can get the same result when I run it as many times as I want when the
> machine is idle, however, the performance of the increases a lot when I
> give the processor something to do, for example compile the kernel, when
> gcc is compiling the kernel, I get better results:
>
> [root@akvagw test]# ./ttcp_atm -t -a -s 0.90
> ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5013  atm  -> 0.90
> ttcp-t: socket
> ttcp-t: 16777216 bytes in 0.997561 real seconds = 16424.058278 KB/sec (134.545885 
>Mb/sec)
>
> For the record, the remote machine does not affect the tests, because the
> machine just sends data even when none listens.
>
> Can someone explain, and maybe do something, please? Or am I supposed to
> compile kernel all the time on my production ATM routers.
>
> Same seems to apply when I stream UDP via my 3C905C card to one of my
> routers, first I get 60Mbytes / s, then 94Mbytes/s when I start to compile
> the kernel.
>
>  Thanks,
>Sampsa Ranta
>[EMAIL PROTECTED]
>
>
> "
> Don't know where those "negative CPU cycles" come from. It's probably
> a driver problem. Could be that either you're triggering scheduling of a
> softirq or such, where there normally wouldn't be one (but should be),
> or that there's a race condition leading to the loss of an event
> (softirq, tasklet, wait queue, etc.), and background activity makes this
> happen in the correct order.
> "
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-net" in
> the body of a message to [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

[Gérard Roudier]

On Fri, 23 Mar 2001, Stephen E. Clark wrote:

> 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.

What about the following (it is an estimate):

early nineties  -->  early eighties
18 developers   -->  18 developers
16mb of memory  -->   1 mb of memory
600 mb of disk  -->  70 mb of disk

Most current applications are so huge BLOATAGE that they should not 
deserve to be run just once. :-)
The kernel must try to cope with that and also with its own BLOATAGE.

Human nature is to eat what can be eaten, regardless if it is useful or
not.

> My $.02.

What about 'My M$.02' in some decades. :)

Btw, 'decade' comes from Latin 'deca'=10 and dies=days (not sure for
dies). As a result, it should have meant a period of 10 days instead of 10
years. It means a period of 10 days in French.

May-be, a knowledgeable person at this list has an explanation for this
misinterpretation. Could it be due to the word 'decadent' that has a 
very different ethymology.

10 days is too short for getting decadent, but 10 years should be enough,
no ? :-)

> Steve

  Gérard.

-
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: athlon+2.2+pdc20267=hang?

[Arjan van de Ven]

In article <[EMAIL PROTECTED]> you wrote:
> Earlier today I swapped an Athlon (tbird) 850 and an Epox 8KTA3 in for the 
> dual Celeron I had, moving all the cards into the new system. One of these 
> was a Promise PDC20267 with 4 40gb disks attached. The machine would not 
> boot; I assumed it was the i686-smp kernel and installed a Redhat 
> 7.0-provided i386 kernel. Several hours and a dozen or so boots later, it 
> looks like when the bios on the PDC20267 is installed, the system hangs 
> while booting at the point where it would probe C/H/S from the devices 
> attached to the PDC20267 (they've already been identified by that point)

Your motherboard probably has a VIA chipset. I've been chasing several of
such problems in the last weeks, and fixed most of them for the 2.4 kernel.
Unfortionatly, some PCI cards (TV capture and 3C905C) somehow don't like the
fix.

You can achieve the same effect by setting the PCI tuning in the bios to
conservative settings instead of "optimal"

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/

etymology was: OOM fest

[Andries . Brouwer]

> Btw, 'decade' comes from Latin 'deca'=10 and dies=days

No. It is from the Greek dekas, dekados (group of ten).

> Could it be due to the word 'decadent'

Unrelated. (MLatin: to fall down.)
-
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]

>I thought of some things which could break it, which I want to try and deal
>with before releasing a patch.  Specifically, I want to make freepages.min
>sacrosanct, so that malloc() *never* tries to use it.  This should be
>fairly easy to implement - simply subtract freepages.min from the freemem
>part.  An even nicer way would be to subtract freepages.low (or some
>similar value) instead of freepages.min for non-root or non-privileged
>processes.

Hmm, interesting.  Even with my modification - which means that
vm_enough_memory() will always return false if the allocation would clobber
freepages.min - I can still trigger OOM quite easily.  Even with no swap on
my box, there's a lot of disk activity, probably due to there being
virtually no disk cache left - could the generation of disk buffer and
cache pages be bypassing vm_enough_memory()?  If so, would using
freepages.low as the threshold rather than freepages.min help at all? (or
have I got everything muddled...)

--
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/

MD5 check failes for ISDN related files on 2.4.2-ac24

[André Dahlqvist]

I spotted these messages during 'make dep' on
2.4.2-ac24:

make -C hisax fastdep
md5sum: MD5 check failed for 'isac.c'
md5sum: MD5 check failed for 'isdnl1.c'
md5sum: MD5 check failed for 'isdnl2.c'
md5sum: MD5 check failed for 'isdnl3.c'
md5sum: MD5 check failed for 'tei.c'
md5sum: MD5 check failed for 'callc.c'
md5sum: MD5 check failed for 'cert.c'
md5sum: MD5 check failed for 'l3dss1.c'
md5sum: MD5 check failed for 'l3_1tr6.c'
md5sum: MD5 check failed for 'elsa.c'
md5sum: MD5 check failed for 'diva.c'
md5sum: MD5 check failed for 'sedlbauer.c'

They all seam to be related to the ISDN code. Is this
something to worry about?
-- 

André Dahlqvist <[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/

[PATCH] Bug in do_mount()

[Jorgen Cederlof]

do_mount() can sometimes fail to mount a filesystem, but still
increment the filesystem module count.

This patch against 2.4.2 should fix the problem.

   Jörgen

--- fs/super.c.orig Sun Mar 11 20:25:26 2001
+++ fs/super.c  Sun Mar 11 20:05:27 2001
@@ -1414,6 +1414,8 @@
 fail:
if (list_empty(&sb->s_mounts))
kill_super(sb, 0);
+   else
+   put_filesystem(fstype);
goto unlock_out;
 }
 

-
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] Bug in do_mount()

[Alexander Viro]

On Sat, 24 Mar 2001, Jorgen Cederlof wrote:

>   if (list_empty(&sb->s_mounts))
>   kill_super(sb, 0);
> + else
> + put_filesystem(fstype);
>   goto unlock_out;

That's completely wrong. Reference acquired by get_fs_type() is
released by put_filesystem() (near fs_out), _NOT_ by kill_super().
kill_super() releases the reference stored in ->s_type (created
by get_sb_...()). If superblock stays alive you should not release it.

What bug are you trying to fix?
Al

-
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/

Larger dev_t

[Andries . Brouwer]

Dear Linus and all,

One of these days we must change dev_t.

There are several aspects to this, but this letter touches
only the kernel-*libc interface.

We need a size, and I am strongly in favor of sizeof(dev_t) = 8;
this is already true in glibc.

The two main uses of dev_t are in struct stat and as parameter
of the mknod system call. There are a few other occurrences,
such as ustat() and the use of dev_t as a field in struct loopinfo
returned by some ioctl.
- For stat all is fine already since we got stat64.
- For mknod a little work is required.
- The state of affairs with loopinfo is sad today (the fact that
kernel and glibc use dev_t of different size causes problems)
but all will be well with 64-bit dev_t.
- With ustat the converse is true. Of course it is obsolete,
but with 64-bit dev_t we are forced to throw it out - libc5
has xustat just like xstat and xmknod, but glibc hasn't so it
is not easy to save it. There are still some programs that use it:
in CD players to test (before eject) whether a CD is mounted;
in various programs such as sendmail and uucp to test how much
free space we have.
So, glibc will have to return EINVAL (or EOVERFLOW) here
for device numbers that actually use more than 16 bits.

The transformation from 64 bits to pair (major,minor) is
if ((major = (dev >> 32)) != 0)
minor = (dev & 0x);
else if ((major = (dev >> 16)) != 0)
minor = (dev & 0x);
else {
major = (dev >> 8);
minor = (dev & 0xff);
}
This means that old device numbers remain valid.

The stuff below describes a working interface where 64-bit values
are passed to and from the kernel, and to and from the filesystem.
That is, it is dev_t stuff. Some other time on kernel-internal matters,
that is, kdev_t stuff.

Details of my setup of today (with 64-bit dev_t):
(i) ext2:

diff -r linux-2.4.2/linux/fs/ext2/inode.c linux-2.4.2kdevt/linux/fs/ext2/inode.c
1076,1078c1076,1081
<   } else 
<   init_special_inode(inode, inode->i_mode,
<  le32_to_cpu(raw_inode->i_block[0]));
---
>   } else {
>   unsigned int lo = le32_to_cpu(raw_inode->i_block[0]);
>   unsigned int hi = le32_to_cpu(raw_inode->i_block[1]);
>   dev_t devno = ((unsigned long long) hi << 32) | lo;
>   init_special_inode(inode, inode->i_mode, devno);
>   }
1211,1213c1214,1221
<   if (S_ISCHR(inode->i_mode) || S_ISBLK(inode->i_mode))
<   raw_inode->i_block[0] = cpu_to_le32(kdev_t_to_nr(inode->i_rdev))
;
<   else for (block = 0; block < EXT2_N_BLOCKS; block++)
---
>   if (S_ISCHR(inode->i_mode) || S_ISBLK(inode->i_mode)) {
>   /* we use that EXT2_N_BLOCKS > 1 */
>   dev_t devno = kdev_t_to_nr(inode->i_rdev);
>   unsigned int hi = (devno >> 32);
>   unsigned int lo = (devno & 0x);
>   raw_inode->i_block[0] = cpu_to_le32(lo);
>   raw_inode->i_block[1] = cpu_to_le32(hi);
>   } else for (block = 0; block < EXT2_N_BLOCKS; block++)

Ted, please complain if I am mistaken in thinking that
raw_inode->i_block[1] can be used.
There is a minor conversion problem here: there is no guarantee
that raw_inode->i_block[1] will be zero in old systems.


(ii) vfs:

diff -r linux-2.4.2/linux/fs/devices.c linux-2.4.2kdevt/linux/fs/devices.c
200c200
< void init_special_inode(struct inode *inode, umode_t mode, int rdev)
---
> void init_special_inode(struct inode *inode, umode_t mode, dev_t rdev)

(iii) mknod:
Then there is the prototype of mknod.
I changed it for all filesystems to

diff -r linux-2.4.2/linux/fs/ext2/namei.c linux-2.4.2kdevt/linux/fs/ext2/namei.c
387c387,388
< static int ext2_mknod (struct inode * dir, struct dentry *dentry, int mode, int rdev)
---
> static int ext2_mknod (struct inode * dir, struct dentry *dentry, int mode,
>  dev_t rdev)

The system call itself cannot easily be changed to take a larger dev_t,
mostly because under old glibc the high order part would be random.
So, mknod64, with

diff linux-2.4.2/linux/fs/namei.c linux-2.4.2kdevt/linux/fs/namei.c
1205c1208
< asmlinkage long sys_mknod(const char * filename, int mode, dev_t dev)
---
> static long mknod_common(const char * filename, int mode, dev_t dev)
1245a1249,1259
> }
> 
> asmlinkage long sys_mknod64(const char * filename, int mode,
>   unsigned int ma, unsigned int mi)
> {
>   return mknod_common(filename, mode, ((dev_t) ma << 32) | mi);
> }
> 
> asmlinkage long sys_mknod(const char * filename, int mode, unsigned short dev)
> {
>   return mknod_common(filename, mode, dev);

and __NR_mknod64 in unistd.h and .long SYMBOL_NAME(sys_mknod64) in entry.S.

Changes to glibc2:

--- glibc-2.2.1/sysdeps/unix/sysv/linux/xmknod.cFri Jul  7 19:57:38 2000
+++ glibc-2.2.1mk/sysdeps/uni

Re: Larger dev_t

[Jeff Garzik]

Also for 2.5, kdev_t needs to go away, along with all those arrays based
on major number, and be replaced with either "struct char_device" or
"struct block_device" depending on the device.

I actually went through the kernel in 2.4.0-test days and did this. 
Most kdev_t usages should really be changed to "struct block_device". 
The only annoyance in the conversion was ROOT_DEV and similar things
that are tied into the boot process.  I didn't want to change that and
potentially break the boot protocol...

-- 
Jeff Garzik   | May you have warm words on a cold evening,
Building 1024 | a full moon on a dark night,
MandrakeSoft  | and a smooth road all the way to your door.
-
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/

Cannot compile 2.4.2-ac23 kernel

[Boris Pisarcik]

Hello anybody.

Today i applied A.COX's patch 2.4.2-ac23 on 2.4.0 kernel previsiously patched
with 2.4.1 and 2.4.2 patches.

Before everything used to compile well, but with this patch i get this
error message:

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.)

and compilation stops.

Did i do wrong, if i patched ac23 over clean 2.4.2, or should i have to patch
ac23 directly over 2.4.1 (2.4.0 ?). I tried both, but got lots of error
messages.

My current gcc:   2.95.3
   make:  3.79.1
   as:2.10.90

CPU:   Intel P1 166 MMX

Can somebody help me, what did i do wrong ?

Thanks   B.
-
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: Larger dev_t

[Alexander Viro]

On Sat, 24 Mar 2001, Jeff Garzik wrote:

> Also for 2.5, kdev_t needs to go away, along with all those arrays based
> on major number, and be replaced with either "struct char_device" or
> "struct block_device" depending on the device.
> 
> I actually went through the kernel in 2.4.0-test days and did this. 
> Most kdev_t usages should really be changed to "struct block_device". 
> The only annoyance in the conversion was ROOT_DEV and similar things
> that are tied into the boot process.  I didn't want to change that and
> potentially break the boot protocol...

Jeff, check the namespace patch - it simplifies this area big way.
Since it's independent from the namespace code I can pull these
parts into separate patch.

Basic idea: _always_ use ramfs (initially empty) for absolute root.
"real" root is overmounted atop of it. The thing being, by the time
when we deal with initrd, unpacking, mounting real root, etc. we
have full-blown fs context. I.e. we can call sys_mknod(), sys_mount(),
etc. I've pulled the late stages of boot into init/do_mounts.c and
had rewritten them - essentially into sequence of syscalls. The thing
became seriosuly simpler (not to mention the fact that it's not scattered
anymore).

If anyone is interested in seeing it as a separate patch - tell and I'll
do it; it's pretty straightforward.
Al

-
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

[Mike Galbraith]

On Sat, 24 Mar 2001, Jonathan Morton wrote:

> >General thread comment:
> >To those who are griping, and obviously rightfully so, Rik has twice
> >stated on this list that he could use some help with VM auto-balancing.
> >The responses (visible on this list at least) was rather underwhelming.
> >I noted no public exchange of ideas.. nada in fact.
> >
> >Get off your lazy butts and do something about it.  Don't work on the
> >oom-killer though.. that's only a symptom.  Work on the problem instead.
>
> Since I'm hacking around in this area anyway (warning: kernel newbie
> alert!), I'd be happy to help examine the balancing code from a fresh
> perspective.  Where should I be looking?

Everything in mm plus fs/buffer.c at least. (plus includes)  A good
place to start is with __alloc_pages().. that will drag you through
a lot of the balancing code.  Following entry points (sys_brk, sys_mmap
etc) is highly recommended.  Be prepared for dizzy spells if you've
never toured mm-land before :)

-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/

usb insmod hang w/2.4.2

[Michael Rothwell]

I'm installing Linux onto a Compaq iPaq IA-1 -- the little "MSN
Companion" thing. I wish Compaq didn't feel compelled to name everything
"iPaq." This device is essentially a laptop with a strange case, no hard
drive, and 32MB of RAM. It has a VIA chipset and four USB ports. The
southbridge is a VT82C686 ("Apollo Super South"). It sports to UHCI USB
controllers sharing IRQ 11.

I have patched a long, thin logo into the kernel to replace the Tux
logo, but that is the only change I made.

When I insmod usb-uhci.o or uhci.o, it gets as far as ":
detected 2 ports" and then hangs, terminally. It does t his whether I
have usbcore compiled in or loaded as a module.

I have attached my .config file. Any help would be appreciated!

-M


#
# Automatically generated make config: don't edit
#
CONFIG_X86=y
CONFIG_ISA=y
# CONFIG_SBUS is not set
CONFIG_UID16=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y

#
# Loadable module support
#
CONFIG_MODULES=y
# CONFIG_MODVERSIONS is not set
CONFIG_KMOD=y

#
# Processor type and features
#
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUM4 is not set
CONFIG_MK6=y
# CONFIG_MK7 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_X86_ALIGNMENT_16=y
CONFIG_X86_TSC=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
# CONFIG_TOSHIBA is not set
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_SMP is not set
CONFIG_X86_UP_IOAPIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_LOCAL_APIC=y

#
# General setup
#
CONFIG_NET=y
# CONFIG_VISWS is not set
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_NAMES=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
CONFIG_HOTPLUG=y

#
# PCMCIA/CardBus support
#
CONFIG_PCMCIA=y
CONFIG_CARDBUS=y
CONFIG_I82365=y
# CONFIG_TCIC is not set
CONFIG_SYSVIPC=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_SYSCTL=y
CONFIG_KCORE_ELF=y
# CONFIG_KCORE_AOUT is not set
# CONFIG_BINFMT_AOUT is not set
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_MISC is not set
CONFIG_PM=y
# CONFIG_ACPI is not set
CONFIG_APM=y
# CONFIG_APM_IGNORE_USER_SUSPEND is not set
# CONFIG_APM_DO_ENABLE is not set
# CONFIG_APM_CPU_IDLE is not set
CONFIG_APM_DISPLAY_BLANK=y
# CONFIG_APM_RTC_IS_GMT is not set
# CONFIG_APM_ALLOW_INTS is not set
CONFIG_APM_REAL_MODE_POWER_OFF=y

#
# Memory Technology Devices (MTD)
#
CONFIG_MTD=y
# CONFIG_MTD_DEBUG is not set

#
# Disk-On-Chip Device Drivers
#
# CONFIG_MTD_DOC1000 is not set
# CONFIG_MTD_DOC2000 is not set
# CONFIG_MTD_DOC2001 is not set
# CONFIG_MTD_DOCPROBE is not set

#
# RAM/ROM Device Drivers
#
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_PMC551 is not set
# CONFIG_MTD_MTDRAM is not set

#
# Linearly Mapped Flash Device Drivers
#
CONFIG_MTD_CFI=y
CONFIG_MTD_CFI_INTELEXT=y
CONFIG_MTD_CFI_AMDSTD=y
# CONFIG_MTD_RAM is not set
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_JEDEC is not set
# CONFIG_MTD_PHYSMAP is not set

#
# Drivers for chip mappings
#
# CONFIG_MTD_NORA is not set
# CONFIG_MTD_PNC2000 is not set
# CONFIG_MTD_RPXLITE is not set

#
# User modules and translation layers for MTD devices
#
# CONFIG_MTD_CHAR is not set
# CONFIG_MTD_BLOCK is not set
# CONFIG_FTL is not set
# CONFIG_NFTL is not set

#
# Parallel port support
#
# CONFIG_PARPORT is not set

#
# Plug and Play configuration
#
CONFIG_PNP=y
# CONFIG_ISAPNP is not set

#
# Block devices
#
CONFIG_BLK_DEV_FD=y
# CONFIG_BLK_DEV_XD is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_NBD=y
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_INITRD=y

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
CONFIG_NETLINK=y
# CONFIG_RTNETLINK is not set
# CONFIG_NETLINK_DEV is not set
# CONFIG_NETFILTER is not set
# CONFIG_FILTER is not set
CONFIG_UNIX=y
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_INET_ECN is not set
CONFIG_SYN_COOKIES=y
# CONFIG_IPV6 is not set
# CONFIG_KHTTPD is not set
# CONFIG_ATM is not set

#
#  
#
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_DECNET is not set
# CONFIG_BRIDGE is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_LLC is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is

Re: network unusable

[Ingo Oeser]

On Fri, Mar 23, 2001 at 10:44:58PM +0100, Michael Devogelaere wrote:
> 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.

Could you tell more about your hardware? Does it still happen
with 2.4.2-ac20 (which I consider most stable for now ;-))?

Full dmesg from booting and after inserting the proper networking
modules, your .config and lscpi - would be nice.

I don't experience any problems like that here.

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: etymology was: OOM fest

[Gérard Roudier]

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

> > Btw, 'decade' comes from Latin 'deca'=10 and dies=days
> 
> No. It is from the Greek dekas, dekados (group of ten).

All my french dictionnaries agree with you. Thanks for the fix. :-)

> > Could it be due to the word 'decadent'
> 
> Unrelated. (MLatin: to fall down.)

This one was intended to be the joke, but given the previous
show-stopper... :-(


Regards,
  Gérard.

-
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: Larger dev_t

[Andries . Brouwer]

> Also for 2.5, kdev_t needs to go away, along with all those arrays

Yes, it has been said many times, and I get the impression
that many people actually did it.

Maybe everybody with code or at least a detailed setup
should demonstrate what was done so that we can compare merits
of several approaches.

The stuff I sent earlier today was the dev_t part.
The next part I hope to send one of these days is the
interface between dev_t and kdev_t.
(Most people think that kdev_t is an integer, I think that
it is a pointer. Since dev_t now can be large and arrays
cannot be used, we need some hash lookup to find the
structure corresponding to the number. And the code is
roughly speaking identical to Al's bdev code, only now used
both for bdev and cdev.)

(Funny enough Al's code does not solve the only small problem
I had six years ago: a mknod with funny numbers does not mean
that some such device actually exists. In reality we only
want to convert number into device pointer when the device is
opened, but the current kernel code does
init_special_inode(inode, mode, rdev);
for a mknod, and if it was a block device
inode->i_bdev = bdget(rdev);
so that it does allocate a struct to this nonsense device.)

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: Cannot compile 2.4.2-ac23 kernel

[Adrian Bunk]

On Sat, 24 Mar 2001, Boris Pisarcik wrote:

> Hello anybody.

Ho Boris,

>...
> 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.)
>
> and compilation stops.
>...
> Can somebody help me, what did i do wrong ?

Nothing. :-)

This is a known bug in 2.4.2ac23 that is fixed in 2.4.2ac24 .

> Thanks   B.

cu
Adrian

-- 

Nicht weil die Dinge schwierig sind wagen wir sie nicht,
sondern weil wir sie nicht wagen sind sie schwierig.

-
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/

NCR53c8xx driver and multiple controllers...(not new prob)

[LA Walsh]

I have a machine with 3 of these controllers (a 4 CPU server).  The
3 controllers are:
ncr53c810a-0: rev=0x23, base=0xfa101000, io_port=0x2000, irq=58
ncr53c810a-0: ID 7, Fast-10, Parity Checking
ncr53c896-1: rev=0x01, base=0xfe004000, io_port=0x3000, irq=57
ncr53c896-1: ID 7, Fast-40, Parity Checking
ncr53c896-2: rev=0x01, base=0xfe004400, io_port=0x3400, irq=56
ncr53c896-2: ID 7, Fast-40, Parity Checking
ncr53c896-2: on-chip RAM at 0xfe002000

I'd like to be able to make a kernel with the driver compiled in and
no loadable module support.  It don't see how to do this from the
documentation -- it seems to require a separate module loaded for
each controller.  When I compile it in, it only see the 1st controller
and the boot partition I think is on the 3rd.  Any ideas?

This problem is present in the 2.2.x series as well as 2.4.x (x up to 2).

Thanks,
-linda
-- 
L A Walsh| Trust Technology, Core Linux, SGI
[EMAIL PROTECTED]  | Voice: (650) 933-5338
-
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

[Jesse Pollard]

On Fri, 23 Mar 2001, 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

Not lucky. I've used V6 - It would not start a process if the resources
werent available (no overcommit). It was also a swap based system and
not a page based system (PDP-11/45 1123+... supported both, but UNIX
only used swapping because it was easy to swap a 64Kbyte process).

>> The old Unix guarantee that a program only crashes because of
>> its own behaviour is lost. That is very sad.
>
>No such guarantee ever existed. There are systems that had stuff like per
>user memory quotas but those were mostly much more mainframe oriented

Only the swapping based systems gave this guarantee. Even AT&T System V
release 2 was swap based (M68020 systems).

>> 200 MB then the rest of that memory is not wasted. But it can
>> only be used for things that can be freed when needed, like
>> inode and buffer cache.
>
>No. You cannot free the inode and buffer cache arbitarily. You only have a
>probability - that puts you back at square 1.
>
>> But inefficient or not, I much prefer a system with guarantees,
>> something that is reliable by default, above something that
>> works well if you are lucky and fails at unpredictable moments.
>
>malloc is merely an accounting exercise (actually its mostly mmap 
>accounting). ptrace is the only quirk. Nobody feels its very important because
>nobody has implemented it.

Small correction - It was implemented, just not included in the standard
kernel.

Check mailing lists around March-April of 2000. The patch was generated
by Eduardo Horvath <[EMAIL PROTECTED]> for  2.3.99-pre3 and allowed the
administrator to:

"Available virtual memory is calculated as the sum of all swap space as
 well as free and reclaimable RAM, essentially the same value as used
 before.  The kernel will now operate in 4 different modes depending on the
 value of sysctl_overcommit_memory:
 
 1   Do accounting but do not prevent any allocations (old behavior)
 
 0   Do accounting but only prevent individual allocations that exceed
total VM (old behavior)
 
 -1  Do accounting and prevent a user from making the amount of
reserved memory exceed the total virtual memory.
 
 -2  Same as above but also for root.
 
 The default is set to -1 to allow root to essentially do whatever it
 wants.  But then if someone's broken root you're in trouble anyway.
 
 If the kernel itself requires memory it can allocate as much as it wants
 and can bring the system into an unsafe state (reserved > total).
 
 Memory segments that are not COW, ZFOD or otherwise swap backed do not
 require reservation."

It was a limited implementation, but worked quite well in testing.

-- 
-
Jesse I Pollard, II
Email: [EMAIL PROTECTED]

Any opinions expressed are solely my own.
-
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/

tmpfs: a way to get your system down

[Alex Riesen]

Hi, all,

just hit by tmpfs on 2.4.2-ac20

mount -t tmpfs mnt
dd if=/dev/zero mnt/tmpfile

resulted in hardly slowed system and lockup,
and not in "No space left on device", as expected.

Alex Riesen

-
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/

ACPI power-off doesn't work on Asus CUV4X (VIA Apollo 133)

[Alex Riesen]

Hi, dear all

As i recompiled 2.4.2-ac20 with ACPI support
the system cannot switch itself off.
With APM it work without any problem.

I get a message "Couldn't switch to S5" if
try to call reboot(2).
At load it shows that the mode is supported.

Alex Riesen

P.S.
Motheboard Asus CUV4X

/proc/cpuinfo:
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 8
model name  : Pentium III (Coppermine)
stepping: 3
cpu MHz : 701.605
cache size  : 256 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 3
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat 
pse36 mmx fxsr sse
bogomips: 1399.19


-
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] Bug in do_mount()

[Jorgen Cederlof]

> >   if (list_empty(&sb->s_mounts))
> >   kill_super(sb, 0);
> > + else
> > + put_filesystem(fstype);
> >   goto unlock_out;
 
> Reference acquired by get_fs_type() is
> released by put_filesystem() (near fs_out), _NOT_ by kill_super().

Yes.

> kill_super() releases the reference stored in ->s_type (created
> by get_sb_...()). If superblock stays alive you should not release it.

get_sb_...() will do get_filesystem() even if superblock stays alive.

We get the filesystem twice, in get_fs_type() and get_sb_...(), but if
we goto 'fail:' and don't call kill_super(), we put the filesystem
only once (near fs_out). 

> What bug are you trying to fix?

foofs is a FS_SINGLE filesystem: 
(but the !nd.dentry->d_inode case should be no different)

# grep foofs /proc/modules 
foofs 6736   0 (unused)
# mount NONE /mnt -t foofs
# grep foofs /proc/modules 
foofs 6736   1
# mount NONE /mnt -t foofs
mount: NONE already mounted or /mnt busy
mount: according to mtab, NONE is already mounted on /mnt
# grep foofs /proc/modules 
foofs 6736   2
# mount NONE /mnt -t foofs
mount: NONE already mounted or /mnt busy
mount: according to mtab, NONE is already mounted on /mnt
# grep foofs /proc/modules 
foofs 6736   3
# umount /mnt
# grep foofs /proc/modules 
foofs 6736   2
# umount /mnt
umount: /mnt: not mounted
# grep foofs /proc/modules 
foofs 6736   2
# rmmod foofs
foofs: Device or resource busy

-
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)

[Jesse Pollard]

On Fri, 23 Mar 2001, Doug McNaught wrote:
>Gerhard Mack <[EMAIL PROTECTED]> writes:
>
>> 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. 
>
>Is there an alternative to BIND that's free software?  Never seen
>one. 

Not one that is Open Source

Bind itself has been proven over many years. This is the first major
problem found. If you want a fix, get bind v9. Besides handling IP version
4, it also handles version 6.

The only current limitation is the inability to control sort order of
hosts with multiple interfaces. I think this is due to the new IP v 6
resource handling.

Bind 9 works well (see ISC web page http://www.isc.org/products/BIND/)

>
>-Doug (who doesn't think this is a Good Thing)

It really isn't, but the new bind may be. There is even an update
to bind 8 that contains a fix for the problem.

-
Jesse I Pollard, II
Email: [EMAIL PROTECTED]

Any opinions expressed are solely my own.
-
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] Bug in do_mount()

[Alexander Viro]

On Sat, 24 Mar 2001, Jorgen Cederlof wrote:

> > kill_super() releases the reference stored in ->s_type (created
> > by get_sb_...()). If superblock stays alive you should not release it.
> 
> get_sb_...() will do get_filesystem() even if superblock stays alive.

Sigh... I see what happens, and yes, it's a bug, but fix is wrong.
The real problem is with get_sb_single(), not with do_mount().
get_sb_bdev() and get_sb_nodev() are actually fine and your fix will
break them.

The problem is in the way we keep count for FS_SINGLE - in my current
tree I switched to cleaner variant, but doing the same in 2.4 may be tricky.

_Probably_ the right way to deal with that (for the time being) is add
if (fstype->fs_flags & FS_SINGLE)
put_filesystem(fstype);
before the if (list_empty(...))

IOW, 
--- fs/super.c.old Sat Mar 24 12:39:23 2001
+++ fs/super.c Sat Mar 24 12:39:56 2001
@@ -1412,6 +1412,8 @@
return retval;
 
 fail:
+   if (fstype->fs_flags & FS_SINGLE)
+   put_filesystem(fstype);
if (list_empty(&sb->s_mounts))
kill_super(sb, 0);
goto unlock_out;

should be OK for now. Once we get clean refcounting for struct super_block
we will be able to get rid of the kludges in that area completely.
Al

-
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] [checker] 120 potential dereference to invalid pointers errors for linux 2.4.1

[Andrew Morton]

This gets us about 1/3 of the way through this one.

Affected files:

fs/proc/generic.c
arch/i386/kernel/irq.c
arch/i386/kernel/mtrr.c
drivers/acpi/dispatcher/dswload.c
drivers/atm/zatm.c
drivers/block/DAC960.c
drivers/block/ll_rw_blk.c
drivers/char/pc_keyb.c
drivers/char/rio/rio_linux.c
drivers/message/i2o/i2o_core.c

Four reports (drm and ip2main.c) were non-obvious and the
maintainers have been poked.

The ll_rw_blk.c change could be a little more elegant.
Really, we should propagate a failure of blk_init_queue()
all the way back to the caller.  In this patch we simply
leave the device with a less-than-expected pool of requests
and just limp along.  Seems to be better than crashing.


Patch is against -ac24.



--- linux-2.4.2-ac24/fs/proc/generic.c  Sat Mar 24 14:28:22 2001
+++ ac/fs/proc/generic.cSun Mar 25 02:16:59 2001
@@ -531,6 +531,8 @@
proc_register(parent, ent);

 out:
+   if (ent == NULL)
+   printk(KERN_EMERG "create_proc_entry: failed to create entry for 
+%s\n", name);
return ent;
 }
 
--- linux-2.4.2-ac24/arch/i386/kernel/irq.c Sat Mar 24 14:28:02 2001
+++ ac/arch/i386/kernel/irq.c   Sun Mar 25 02:15:00 2001
@@ -1155,10 +1155,12 @@
/* create /proc/irq/1234/smp_affinity */
entry = create_proc_entry("smp_affinity", 0600, irq_dir[irq]);
 
-   entry->nlink = 1;
-   entry->data = (void *)(long)irq;
-   entry->read_proc = irq_affinity_read_proc;
-   entry->write_proc = irq_affinity_write_proc;
+   if (entry) {
+   entry->nlink = 1;
+   entry->data = (void *)(long)irq;
+   entry->read_proc = irq_affinity_read_proc;
+   entry->write_proc = irq_affinity_write_proc;
+   }
 
smp_affinity_entry[irq] = entry;
}
--- linux-2.4.2-ac24/arch/i386/kernel/mtrr.cSat Mar 24 14:28:02 2001
+++ ac/arch/i386/kernel/mtrr.c  Sun Mar 25 02:20:08 2001
@@ -1809,7 +1809,8 @@
 }
 devfs_set_file_size (devfs_handle, ascii_buf_bytes);
 #  ifdef CONFIG_PROC_FS
-proc_root_mtrr->size = ascii_buf_bytes;
+if (proc_root_mtrr)
+   proc_root_mtrr->size = ascii_buf_bytes;
 #  endif  /*  CONFIG_PROC_FS  */
 }   /*  End Function compute_ascii  */
 
@@ -2118,8 +2119,10 @@
 
 #ifdef CONFIG_PROC_FS
 proc_root_mtrr = create_proc_entry ("mtrr", S_IWUSR | S_IRUGO, &proc_root);
-proc_root_mtrr->owner = THIS_MODULE;
-proc_root_mtrr->proc_fops = &mtrr_fops;
+if (proc_root_mtrr) {
+   proc_root_mtrr->owner = THIS_MODULE;
+   proc_root_mtrr->proc_fops = &mtrr_fops;
+}
 #endif
 #ifdef CONFIG_DEVFS_FS
 devfs_handle = devfs_register (NULL, "cpu/mtrr", DEVFS_FL_DEFAULT, 0, 0,
--- linux-2.4.2-ac24/drivers/acpi/dispatcher/dswload.c  Tue Jan 23 08:23:42 2001
+++ ac/drivers/acpi/dispatcher/dswload.cSun Mar 25 02:26:24 2001
@@ -455,6 +455,11 @@
arg = acpi_ps_get_arg (op, 2);
}
 
+   if (arg == NULL) {
+   status = AE_NOT_FOUND;
+   break;
+   }
+   
/*
 * Enter the Name_string into the namespace
 */
--- linux-2.4.2-ac24/drivers/atm/zatm.c Wed Jul 19 07:55:01 2000
+++ ac/drivers/atm/zatm.c   Sun Mar 25 02:37:13 2001
@@ -1826,9 +1826,13 @@
devs++;
zatm_dev = (struct zatm_dev *) kmalloc(sizeof(struct
zatm_dev),GFP_KERNEL);
-   if (!zatm_dev) break;
+   if (!zatm_dev) {
+   printk(KERN_EMERG "zatm.c: memory shortage\n");
+   goto out;
+   }
}
}
+out:
return devs;
 }
 
--- linux-2.4.2-ac24/drivers/block/DAC960.c Sat Mar 24 14:28:03 2001
+++ ac/drivers/block/DAC960.c   Sun Mar 25 02:52:27 2001
@@ -506,16 +506,20 @@
  void *DataPointer)
 {
   DAC960_Command_T *Command = DAC960_AllocateCommand(Controller);
-  DAC960_V1_CommandMailbox_T *CommandMailbox = &Command->V1.CommandMailbox;
-  DAC960_V1_CommandStatus_T CommandStatus;
-  DAC960_V1_ClearCommand(Command);
-  Command->CommandType = DAC960_ImmediateCommand;
-  CommandMailbox->Type3.CommandOpcode = CommandOpcode;
-  CommandMailbox->Type3.BusAddress = Virtual_to_Bus32(DataPointer);
-  DAC960_ExecuteCommand(Command);
-  CommandStatus = Command->V1.CommandStatus;
-  DAC960_DeallocateCommand(Command);
-  return (CommandStatus == DAC960_V1_NormalCompletion);
+  if (Command == NULL) {
+   return false;
+  } else {
+DAC960_V1_CommandMailbox_T *CommandMailbox = &Command->V1.CommandMailbox;
+DAC960_V1_CommandStatus_T CommandStatus;
+DAC960_V1_ClearCommand(Command);
+Command->CommandType = DAC960_ImmediateCommand;
+CommandMailbox->Type3.CommandOpcode = CommandOpco

Re: [OT] Linux Worm (fwd)

[Edward S. Marshall]

On Sat, Mar 24, 2001 at 11:11:50AM -0600, Jesse Pollard wrote:
> Bind itself has been proven over many years. This is the first major
> problem found.

This is so blatantly incorrect as to be laughable. BIND 4 and 8 had a
long and glorious history of serious security flaws; a quick search of
the www.securityfocus.com vulnerability archives for "BIND" returns a
ton of results, ranging from root compromises to denial of service
attacks to cache poisoning problems.

> If you want a fix, get bind v9. Besides handling IP version
> 4, it also handles version 6.

I'll believe in BIND 9's safety after it's been widely deployed; with few
OS vendors actually bundling BIND 9 at this point, it's received very
little real-world attention.

> It really isn't, but the new bind may be. There is even an update
> to bind 8 that contains a fix for the problem.

Until the next design flaw produces yet-another-vulnerability?

While other packages might not be free software, I don't have the luxury
of following principles in lieu of security.

Last post from me on the subject, because this has next to nothing to do
with the Linux kernel.

-- 
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: NCR53c8xx driver and multiple controllers...(not new prob)

[Gérard Roudier]

On Sat, 24 Mar 2001, LA Walsh wrote:

> I have a machine with 3 of these controllers (a 4 CPU server).  The
> 3 controllers are:
> ncr53c810a-0: rev=0x23, base=0xfa101000, io_port=0x2000, irq=58
> ncr53c810a-0: ID 7, Fast-10, Parity Checking
> ncr53c896-1: rev=0x01, base=0xfe004000, io_port=0x3000, irq=57
> ncr53c896-1: ID 7, Fast-40, Parity Checking
> ncr53c896-2: rev=0x01, base=0xfe004400, io_port=0x3400, irq=56
> ncr53c896-2: ID 7, Fast-40, Parity Checking
> ncr53c896-2: on-chip RAM at 0xfe002000
> 
> I'd like to be able to make a kernel with the driver compiled in and
> no loadable module support.  It don't see how to do this from the
> documentation -- it seems to require a separate module loaded for
> each controller.  When I compile it in, it only see the 1st controller
> and the boot partition I think is on the 3rd.  Any ideas?

The driver tries to detect all controllers it supports. Since the
ncr53c8xx supports both the 810a and the 896, all your controllers should
have been detected. When loaded as a module, the driver must be loaded
once (btw, a seconf load should fail).

> This problem is present in the 2.2.x series as well as 2.4.x (x up to 2).

What hardware are you using (CPU, Core Logic and tutti quanti) ?
Is the 896 on PCI BUS #0 or on some sort of secondary PCI BUS ?
Does the sym53c8xx driver show same behaviour ?

  Gérard.

-
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]

Mike Galbraith wrote:
> 
> On Sat, 24 Mar 2001, Doug Ledford wrote:
> > To those people that would suggest I send in code I only have this to say.
> > Fine, I'll send in a patch to fix this bug.  It will make the oom killer call
> > the cache reclaim functions and never kill anything.  That would at least fix
> > the bug you see above.
> 
> That won't fix the problem, but merely paper it over.  The problem is
> in the balancing code that lets swap be exausted while at the same time
> allowing cache to become obscenely obese in the first place.  I can't
> trigger that behavior here, but it obviously exists for some workloads.

I would be more than happy to fix the problem properly if I knew the first
thing about the vm subsystem, but I don't.

> General thread comment:
> To those who are griping, and obviously rightfully so, Rik has twice
> stated on this list that he could use some help with VM auto-balancing.
> The responses (visible on this list at least) was rather underwhelming.
> I noted no public exchange of ideas.. nada in fact.

While my post didn't give an exact formula, I was quite clear on the fact that
the system is allowing the caches to overrun memory and cause oom problems. 
I'm more than happy to test patches, and I would even be willing to suggest
some algorithms that might help, but I don't know where to stick them in the
code.  Most of the people who have been griping are in a similar position.

> Get off your lazy butts and do something about it.  Don't work on the
> oom-killer though.. that's only a symptom.  Work on the problem instead.
> 
> -Mike  (who doesn't give a rats ass if he gets flamed;-)
> 
> -
> 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/

-- 

 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/

kernel-2.4.2 and ax25-utils

[Ted Gervais]

Wondering if this new kernel presents a problem to the ax25 utils.
In particular the ax25-0.0.7-tools.

I heard that maybe there were patches available to correct any problems
created by the newer kernel and was wondering that if anyone knows about
this, if they could post the location..

---
Earth is a beta site. 

Ted Gervais <[EMAIL PROTECTED]>
44.135.34.201 linux.ve1drg.ampr.org


-
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)

[Sandy Harris]

Jesse Pollard wrote:

> >Is there an alternative to BIND that's free software?  Never seen
> >one.
> 
> Not one that is Open Source

Australia's RMIT and Ercisson have an Open Source load-balancing distributed
web server, including a DNS server to do the balancing.

The link I have, www.eddieware.org and www.rmit.edu.au both currently appear
to be down.
-
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-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:
> 
> Times are fine.  Local APIC timer interrupts are used.

Okay, thanks.  That's good.

> Testing's easy, thanks for the fix.

This is where I'd submit the patch, but Alan evidently works 80 hours
a day.  ;)  The new patch is already in ac24.

Alan, FYI, I tested the patch on my SMP motherboard with CONFIG_SMP
(and maxcpus=0,1,unspecified) and with all combinations of
CONFIG_X86_UP_{,IO}APIC) and Michael tested CONFIG_SMP and
CONFIG_X86_UP_APIC on his non-SMP motherboard, so I don't think this
will come back to bite anyone.

Thanks!

Kevin <[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/

ReiserFS phenomenon with 2.4.2 ac24/ac12

[Christoph Lameter]

I got a directory /a/yy that I tried to erase with rm -rf /a/yy.

rm hangs...

ls gives the following output:

ls: /a/yy/cache3A0F94EA0A00557.html: No such file or directory
ls: /a/yy/cache3A0F94EA0A00557.html: No such file or directory
ls: /a/yy/cache3A8CCC6A0490B05.gifcache393C2B6A2CD2DF1.crumb: No such file
or directory
ls: /a/yy/cache3A0F94EA0A00557.html: No such file or directory
ls: /a/yy/cache3A0F94EA0A00557.html: No such file or directory
ls: /a/yy/cache3A8CCC6A0490B05.gifcache393C2B6A2CD2DF1.crumb: No such file
or directory

and so on and so on

I tried a reiserfscheck -x on the /a volume but the strangeness still
persists. What is going on here?



-
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]

>While my post didn't give an exact formula, I was quite clear on the fact that
>the system is allowing the caches to overrun memory and cause oom problems.
>I'm more than happy to test patches, and I would even be willing to suggest
>some algorithms that might help, but I don't know where to stick them in the
>code.  Most of the people who have been griping are in a similar position.

Meanwhile, I'm looking *very* hard at the VM system and trying to figure
out how it works.  So far I've got an "improved" system under test which
requires a little stress to cause an OOM-before-malloc-failure.  Right now
I'm working on making the OOM happen only when it *really* needs to -
previously, as some pointed out, it could trigger far too early, for
example when there was lots of buffer and cache memory that could
potentially be cannibalised.

Right now my best approximation is to make the OOM test be as optimistic as
it is safe to be, and the vm_enough_memory() test as pessimistic as
sensible.  Expect a test patch to appear on this list soon.

--
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/

Constant Crash in scsi_eh_0

[Pete Toscano]

Hello,

I'm currently running 2.4.3-pre4.  (I tried 2.4.3-pre6, but it wouldn't
boot.  I'm about to try -pre7.)  This seemed worse with 2.4.2, but it's
still a problem.

My system's about as stable as Crispin Glover after a week-long meth
binge.  =8]  

I'm running an SMP system (dual P3 600s) with 640M of RAM.  It's using a
Tyan Tiger 133 motherboard (VIA Apollo Pro 133a chipset).  It's got 2
ATA66 IDE drives, an IDE CD-ROM, and a SCSI CD burner (connected to an
Adaptec 2940 adaptor).  I also have a few USB devices: mouse, rio500,
and Sandisk SDDR-31 compact flash reader.  The burner and CF reader use
SCSI.  These are the only two SCSI-related devices on my system (that
I'm aware of, at least).

For every crash that I remember, I have not once been using either the
CF reader or the burner.  The usb-storage and scsi_mod devices were
loaded by the hotplug driver (version 2001_02_28).  None of these were
used.

I do have KDB compiled into the kernel, so I was able to get some
debugging info captured via a serial console.  Unfortunately, I don't
know what would be useful and what's not that useful.  Anyway, I've
attached the log.  If there's other information that'd be good to have,
please let me know and I'll try to get it *sigh* the next time my
machine crashes.  As far as I can tell, something bad happens in
scsi_eh_0 every time.

Also attached is my config file.  

Please let me know if there's anything I can do to try to fix the
problem.  I'm not adverse to trying experimental patches.

pete


#
# Automatically generated make config: don't edit
#
CONFIG_X86=y
CONFIG_ISA=y
# CONFIG_SBUS is not set
CONFIG_UID16=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODVERSIONS=y
CONFIG_KMOD=y

#
# Processor type and features
#
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
CONFIG_MPENTIUMIII=y
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_X86_TSC=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_PGE=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
# CONFIG_TOSHIBA is not set
CONFIG_MICROCODE=m
CONFIG_X86_MSR=m
CONFIG_X86_CPUID=m
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
CONFIG_SMP=y
CONFIG_HAVE_DEC_LOCK=y

#
# General setup
#
CONFIG_NET=y
# CONFIG_VISWS is not set
CONFIG_X86_IO_APIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_NAMES=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
CONFIG_HOTPLUG=y

#
# PCMCIA/CardBus support
#
# CONFIG_PCMCIA is not set
CONFIG_SYSVIPC=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_SYSCTL=y
CONFIG_KCORE_ELF=y
# CONFIG_KCORE_AOUT is not set
CONFIG_BINFMT_AOUT=m
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=m
CONFIG_PM=y
# CONFIG_ACPI is not set
CONFIG_APM=m
# CONFIG_APM_IGNORE_USER_SUSPEND is not set
# CONFIG_APM_DO_ENABLE is not set
CONFIG_APM_CPU_IDLE=y
# CONFIG_APM_DISPLAY_BLANK is not set
CONFIG_APM_RTC_IS_GMT=y
# CONFIG_APM_ALLOW_INTS is not set
CONFIG_APM_REAL_MODE_POWER_OFF=y

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
CONFIG_PARPORT_PC_FIFO=y
CONFIG_PARPORT_PC_SUPERIO=y
# CONFIG_PARPORT_AMIGA is not set
# CONFIG_PARPORT_MFC3 is not set
# CONFIG_PARPORT_ATARI is not set
# CONFIG_PARPORT_SUNBPP is not set
# CONFIG_PARPORT_OTHER is not set
CONFIG_PARPORT_1284=y

#
# Plug and Play configuration
#
CONFIG_PNP=m
CONFIG_ISAPNP=m

#
# Block devices
#
CONFIG_BLK_DEV_FD=m
# CONFIG_BLK_DEV_XD is not set
# CONFIG_PARIDE is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
CONFIG_BLK_DEV_LOOP=m
# CONFIG_BLK_DEV_NBD is not set
CONFIG_BLK_DEV_RAM=m
CONFIG_BLK_DEV_RAM_SIZE=4096
# CONFIG_BLK_DEV_INITRD is not set

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set
# CONFIG_BLK_DEV_MD is not set
# CONFIG_MD_LINEAR is not set
# CONFIG_MD_RAID0 is not set
# CONFIG_MD_RAID1 is not set
# CONFIG_MD_RAID5 is not set
# CONFIG_BLK_DEV_LVM is not set

#
# Networking options
#
CONFIG_PACKET=m
CONFIG_PACKET_MMAP=y
CONFIG_NETLINK=y
CONFIG_RTNETLINK=y
# CONFIG_NETLINK_DEV is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_FILTER=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
# CONFIG_IP_PNP is not set
CONFIG_NET_IPIP=m
# CONFIG_NET_IPGRE is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
CONFIG_INET_ECN=y
CONFIG_SYN_COOKIES=y

#
#   IP: Netfilter

Re: [PATCH] Prevent OOM from killing init

[Jesse Pollard]

On Fri, 23 Mar 2001, Paul Jakma wrote:
>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..)

Process specific. Each forked process gets the same limits. You get OOM
as soon as all processes together use more than the system capacity.

>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.

Admin has no real control is the problem. Limits are only good for one
process. As soon as that process forks one other process then the
useage limit is twice the limit established.

>> Andries
>
>regards,
>
>--paulj

-- 
-
Jesse I Pollard, II
Email: [EMAIL PROTECTED]

Any opinions expressed are solely my own.
-
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]

>Right now my best approximation is to make the OOM test be as optimistic as
>it is safe to be, and the vm_enough_memory() test as pessimistic as
>sensible.  Expect a test patch to appear on this list soon.

...and here it is!

This fixes a number of small but linked problems:

- malloc() never returned 0 when the system ran out of memory, instead the OOM killer 
was triggered.  Now, malloc() will return 0 if the calling process is more than 4 
times the size of the amount of free memory.  As a speedup, available swap space is 
not considered unless physical memory is not sufficient to contain the process.  Note 
that if overcommit_memory is switched on, malloc() will never return 0 anyway.

- OOM killer was triggered too early - now takes account of buffer and cache memory, 
which can be cannibalised before the system has completely run out.

- OOM killer badness() factors readjusted in favour of Oracle-like processes 
(consuming 10's of MB of RAM but up for 3 days or so and with a low-order UID?  Now 
less likely to be killed...)

--- begin oom-patch.diff ---
diff -u linux-2.4.1.orig/mm/mmap.c linux/mm/mmap.c
--- linux-2.4.1.orig/mm/mmap.c  Mon Jan 29 16:10:41 2001
+++ linux/mm/mmap.c Sat Mar 24 19:29:51 2001
@@ -54,6 +54,7 @@
 */

long free;
+   struct sysinfo swp_info;

 /* Sometimes we want to use more memory than we have. */
if (sysctl_overcommit_memory)
@@ -62,8 +63,32 @@
free = atomic_read(&buffermem_pages);
free += atomic_read(&page_cache_size);
free += nr_free_pages();
-   free += nr_swap_pages;
-   return free > pages;
+
+   /* Attempt to curtail memory allocations before hard OOM occurs.
+* Based on current process size, which is hopefully a good and fast heuristic.
+* Also fix bug where the real OOM limit of (free == freepages.min) is not 
+taken into account.
+* In fact, we use freepages.high as the threshold to make sure there's still 
+room for buffers+cache.
+*
+* -- Jonathan "Chromatix" Morton, 24th March 2001
+*/
+
+   if(current && current->mm)
+ free -= (current->mm->total_vm / 4);
+
+   free -= freepages.high;
+
+   /* Since getting swap info is expensive, see if our allocation can happen in 
+physical RAM */
+   if(free > pages)
+ return 1;
+
+   /* Use the number of FREE swap pages, not the total */
+   si_swapinfo(&swp_info);
+   free += swp_info.freeswap;
+
+   if(free > pages)
+ return 1;
+
+   return 0;
 }

 /* Remove one vm structure from the inode's i_mapping address space. */
Only in linux/mm/: mmap.c~
diff -u linux-2.4.1.orig/mm/oom_kill.c linux/mm/oom_kill.c
--- linux-2.4.1.orig/mm/oom_kill.c  Tue Nov 14 18:56:46 2000
+++ linux/mm/oom_kill.c Sat Mar 24 20:35:20 2001
@@ -76,7 +76,9 @@
run_time = (jiffies - p->start_time) >> (SHIFT_HZ + 10);

points /= int_sqrt(cpu_time);
-   points /= int_sqrt(int_sqrt(run_time));
+
+   /* Long-running processes are *very* important, so don't take the 4th root */
+   points /= run_time;

/*
 * Niced processes are most likely less important, so double
@@ -93,6 +95,10 @@
p->uid == 0 || p->euid == 0)
points /= 4;

+   /* Much the same goes for processes with low UIDs */
+   if(p->uid < 100 || p->euid < 100)
+ points /= 2;
+
/*
 * We don't want to kill a process with direct hardware access.
 * Not only could that mess up the hardware, but usually users
@@ -192,12 +198,20 @@
 int out_of_memory(void)
 {
struct sysinfo swp_info;
+   long free;

/* Enough free memory?  Not OOM. */
-   if (nr_free_pages() > freepages.min)
+   free = nr_free_pages();
+   if (free > freepages.min)
+   return 0;
+
+   if (free + nr_inactive_clean_pages() > freepages.low)
return 0;

-   if (nr_free_pages() + nr_inactive_clean_pages() > freepages.low)
+   /* Buffers and caches can be freed up (Jonathan "Chromatix" Morton) */
+   free += atomic_read(&buffermem_pages);
+   free += atomic_read(&page_cache_size);
+   if (free > freepages.low)
return 0;

/* Enough swap space left?  Not OOM. */
Only in linux/mm/: oom_kill.c~
--- end oom-patch.diff ---

--
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

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

[Kevin Buhr]

Linus Torvalds <[EMAIL PROTECTED]> writes:
> >
[ under kernel 2.4.2 ]
> >
> >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.

Okay.  One note about the above results: as Zach pointed out, my
2.95.3 number for "maps" was wrong.  I must have forgotten to collect
the data but thought I had.  In fact, there are ~10 lines in "maps"
for the 2.95.3 "cc1plus" process.  The other "maps" numbers for 3.0
and 2.96 are correct, at least within an order of magnitude.

Under 2.4.3-pre7, I get the following disappointing numbers:

CVS gcc 3.0:  Debian gcc 2.95.3:   RedHat gcc 2.96:

real16m10.660sreal7m58.874sreal10m36.368s
user15m27.900suser7m23.090suser10m0.290s 
sys 0m48.400s sys 0m40.350ssys 0m40.790s 
maps:   <20 lines ~10 lines~10 lines

A huge win for 2.96 and absolutely no benefit whatsoever for 3.0, even
though it obviously had a 10-fold effect on maps counts.  On the
positive side, there was no performance *hit* either.

As a blind "have not looked at relevant kernel source" guess, this
looks like a hash scaling problem to me: the hash size works great for
~300 maps and falls apart in a major way at ~3000 maps, presumably
when we get multiple hits per hash bin and start walking 10-member
lists.

How this translates into a course of action---some combination of
keeping your patch, enlarging the hash, and performance tweaking the
list-walking---I'm not sure.

Kevin <[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/

[PATCH] Kawasaki USB-Ethernet Controller Driver

[Sam]

This driver adds support for Kawasaki USB-Ethernet 1-Chip Controler
based devices.

Sam

 kaweth.patch.gz

[BUG] problem with pci=biosirq

[Andrzej Krzysztofowicz]

Hi,

   While attempting to use pci=biosirq kernel parameter in 2.4.3pre6 (same
observed with ac20) I've got the following oops (manually rewritten) during
3c59x network adapter (compiled into kernel) initialization:

Unable to handle kernel paging request at virtual address dde5
 printing eip:
c00fde03
*pde = 
Oops: 
CPU:0
EIP:0010:[]
EFLAGS: 00010292
eax: 0009   ebx: dde5   ecx: 0c0a   edx: c1170cc9
esi: c02964f0   edi:    ebp:    esp: c1177e92
ds: 0018   es: 0018   ss: 0018
Process swapper (pid: 1, stackpage=c1177000)
Stack: 0cc9 64f0 c029 7eb4 0030c117 def8 0c0ac117 0cc9
   deba c00f 64f0 c029 7ed8 0030c117 0c01 0c0ac117
   b10c dd41 b10fc00f 0c0a0c00 c00fdba2 eecc0206 0010c010 000c
Call Trace: [] [] [] [] [] 
[] []

  [and long, probably infinite trace here...]

Unfortunately ksymoops tracing gives no effect as the problem seems to
appear in a BIOS call. Some printk() debugging shows trace:

vortex_init()
  ...
vortex_init_one()[ drivers/net/3c59x.c ]
  pci_enable_device()[ drivers/pci/pci.c ]
pcibios_enable_device()  [ arch/i386/kernel/pci-pc.c ]
  pcibios_enable_irq()   [ arch/i386/kernel/pci-irq.c ]
pcibios_lookup_irq() [ arch/i386/kernel/pci-irq.c ]
  [ pci-irq.c:555:   r->set(pirq_router_dev, dev, pirq, newirq) ]
  pirq_bios_set()[ arch/i386/kernel/pci-irq.c ]
pcibios_set_irq_routing(..., 0, 12)
 [ arch/i386/kernel/pci-pc.c ]

What is the reason of this situation:
1. pci=biosirq option is generally broken,
2. my BIOS is not compatible with pci=biosirq kernel parameter,
3. pcibios_set_irq_routing() call with pin=0 is incorrect,
4. ... another problem ?


My PCI bus works at 30MHz and its configuration:

00:00.0 Host bridge: Acer Laboratories Inc. [ALi] M1531 [Aladdin IV] (rev b3)
Subsystem: Acer Laboratories Inc. [ALi]: Unknown device 1531
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- 
SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- 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.

[Kevin Buhr]

"Zack Weinberg" <[EMAIL PROTECTED]> writes:
> 
> Let me inject some information about what gcc's doing in each version.

Thanks...  very useful information.

> 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.

You are correct.  My "maps" numbers for 2.96 and 3.0 are correct (at
least within an order of magnitude), but I must have plucked the
number for 2.95.3 out of thin air---there are only ~10 maps, as you
predict.

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

Maybe.  It looks like the performance drop is quite sharp as a
function of vma count.  In another note to the list, I observed no
system time change (not even a half a second) using GCC 3.0 on my
gtk-- test case between 2.4.2 and 2.4.3-pre7, even though the vma
count dropped from ~200 to ~15.  On the other hand, 2.96 dropped from
>3000 to ~10 and dropped from a system time of 2m13s to a system time
of 41sec (in line with the 3.0 and 2.95.3 system times).

Given your data, it'll really depend on where the performance hit is
taken.  If it's taken at 4000 vmas, then it'll take a 500 meg arena
under 3.0 before the patch makes a difference.  It it's taken at 1000
vmas, then we'll see it around 125 megs, and it'll really make a big
difference in some of the test cases people are talking about.

Kevin <[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.

[Kevin Buhr]

Jakob Østergaard <[EMAIL PROTECTED]> writes:
> 
> It's important that you use at least -O3 to get inlining too.
[ . . . ]
> 25 MB doesn't count  ;)

Aggh!  I feel like I'm in a comedy sketch.  You tell me "do that".  
I do that.  You tell me, "you should try this instead", so I do this.
Then, you tell me, "but you should really do the other."

You're the one who suggested "gtk--" as a test case.  Built out of the
box, it uses "-O2".  If there were magical settings or sekret
incantations, I wish you'd mentioned them when you suggested it.

> No, map merging is obviously a good idea if it can be done at little cost.
> There has to be other cases out there than GCC 2.96 (which is still the
> best damn C++ compiler to ship on any GNU/Linux distribution in history)

If something has a cost, even a little cost, and no one can find a
benefit, then implementing it is not "obviously" a good idea.  That's
why Linus asked for a real-world example before he spent time
complicating the algorithms and adding checks that incur a cost for
every process, even those that won't get any benefit.

> As someone else already pointed out GCC-3.0 will improve it's allocation,
> but it *still* allocates many maps - less than before, but still potentially
> lots...

Yes.  Zach's explanation is the first thing I've seen that makes a
case for some benefit (besides babysitting GCC 2.96) without
conflicting with the data I'm getting.

As I've noted elsewhere, I see no change at all in system time for GCC
3.0 between 2.4.2 and 2.4.3-pre7.  Given Zach's explanation, I'm
prepared to believe there might be a difference with, say, a 500meg
arena (or perhaps something as small as a 100meg arena).

> It will still have the 70x performance increase on kernel memory map
> handling as demonstrated in my benchmark just posted.  However, it will
> be 70x of much less than with 2.96.

For my test cases under 3.0, it looks like 70 times zero.  However,
I'm now prepared to believe that it could be 70 times something
non-zero for certain very hairy source files.

Kevin <[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] gcc-3.0 warnings

[Tim Waugh]

On Sat, Mar 24, 2001 at 01:55:15AM +0100, J . A . Magallon wrote:

> 
> 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 ?).

The GCC warning has nothing to do with the (good) practice of having a
single exit point.  It is the difference between this:

...
out:
}

and this:

...
out:
return;
}

I think that the latter looks better, and the C standard says that
it's also the only one that's correct.

You are the one arguing about coding religion, by saying that
_neither_ of them is any good.

Tim.
*/

 PGP signature

Re: ACPI power-off doesn't work on Asus CUV4X (VIA Apollo 133)

[Ingo Oeser]

On Sat, Mar 24, 2001 at 06:25:16PM +0100, Alex Riesen wrote:
> As i recompiled 2.4.2-ac20 with ACPI support
> the system cannot switch itself off.
> With APM it work without any problem.
 
APM doesn't work for me either.

> I get a message "Couldn't switch to S5" if
> try to call reboot(2).
> At load it shows that the mode is supported.

Same with AMR P6BAP-AP and P6VAP-AP () mainboards.

Firmware supports C2 C3 S0 S1 S4 S5.

All options for acpi tried.

#define APCI_DEBUG 1 has NO effect on verbosity of messages :-(

What should I do to get more debug info?

I'll try backing out all changes between 2.4.0 and 2.4.2-ac20,
because there it worked ;-)

Regards

Ingo Oeser

cat /proc/cpuinfo
processor   : 0
vendor_id   : CentaurHauls
cpu family  : 6
model   : 6
model name  : VIA Samuel
stepping: 0
cpu MHz : 501.155
cache size  : 128 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu de tsc msr mce cx8 mtrr pge mmx 3dnow
bogomips: 999.42

-- 
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/

IP layer bug?

[Oleg Drokin]

Hello!

   2.4.x kernel. have not tried 2.2
   I just found somethig, I believe is kernel bug.
   I am working with usbnet.c driver, which stores some of its
   internal state in sk_buff.cb area. But once such skb passed to
   upper layer with netif_rx, net/ipv4/ip_input.c reuses content of cb
   (line #345), and all packets that should go outside of beyond hosts
   we have direct routes to, fails, because we think, they have source routing
   enabled.
   For now I workarounded it with filling skb->cb with zeroes before
   netif_rx(), but I believe it is a kludge and networking layer should be fixed
   instead.

   Thank you.

Bye,
Oleg
-
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:

> free = atomic_read(&buffermem_pages);
> free += atomic_read(&page_cache_size);
> free += nr_free_pages();
> -   free += nr_swap_pages;

> +   /* Since getting swap info is expensive, see if our allocation can happen in 
>physical RAM */

Actually, getting swap info is as cheap as reading the variable
nr_swap_pages. I should fix this in the OOM killer ;)

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

[Mike Galbraith]

On Sat, 24 Mar 2001, Doug Ledford wrote:

> Mike Galbraith wrote:
> >
> > General thread comment:
> > To those who are griping, and obviously rightfully so, Rik has twice
> > stated on this list that he could use some help with VM auto-balancing.
> > The responses (visible on this list at least) was rather underwhelming.
> > I noted no public exchange of ideas.. nada in fact.
>
> While my post didn't give an exact formula, I was quite clear on the fact that
> the system is allowing the caches to overrun memory and cause oom problems.

Yes.  A testcase would be good.  It's not happening to everybody nor is
it happening under all loads.  (if it were, it'd be long dead)

> I'm more than happy to test patches, and I would even be willing to suggest
> some algorithms that might help, but I don't know where to stick them in the
> code.  Most of the people who have been griping are in a similar position.

First step toward killing the critter is to lure him onto open ground.
Once there.. well, I've seen some pretty fancy shooting on this list.

-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] Fix for serial.c to work with Xircom Cardbus Ethernet+Modem

[Alessandro Suardi]

Tom Sightler wrote:
> 
[snip]
> 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.

[snipped patch]

It seems something changed in 2.4.3-pre7 (against which I applied your
 patch) so that it doesn't make a difference. On startup I now get this,
 which I am CC:ing as per printk to [EMAIL PROTECTED]

Mar 24 23:59:05 princess cardmgr[374]: initializing socket 1
Mar 24 23:59:05 princess kernel:   got res[10c04000:10c07fff] for resource 6 of PCI 
device 115d:0103
Mar 24 23:59:05 princess cardmgr[374]: socket 1: Xircom CBEM56G-100 CardBus 10/100 
Ethernet + 56K Modem
Mar 24 23:59:05 princess kernel: PCI: Enabling device 05:00.1 ( -> 0003)
Mar 24 23:59:05 princess kernel: Redundant entry in serial pci_table.  Please send the 
output of
Mar 24 23:59:05 princess kernel: lspci -vv, this message (4445,259,4445,4481)
Mar 24 23:59:05 princess kernel: and the manufacturer and name of serial board or 
modem board
Mar 24 23:59:05 princess kernel: to [EMAIL PROTECTED]
Mar 24 23:59:05 princess kernel: register_serial(): autoconfig failed

The card is a Xircom RBEM56G-100, despite what the card advertises.

(in case you wonder, cardmgr is from pcmcia_cs-3.1.25).


Thanks & ciao,

--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/

Re: MD5 check failes for ISDN related files on 2.4.2-ac24

[Keith Owens]

On Sat, 24 Mar 2001 14:43:34 +0100 (MET), 
Andr Dahlqvist <[EMAIL PROTECTED]> wrote:
>I spotted these messages during 'make dep' on
>2.4.2-ac24:
>
>make -C hisax fastdep
>md5sum: MD5 check failed for 'isac.c'
>They all seam to be related to the ISDN code. Is this
>something to worry about?

No, the code should not be executed during make dep but nobody cares
enought about the problem to fix 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

[Jonathan Morton]

>> free = atomic_read(&buffermem_pages);
>> free += atomic_read(&page_cache_size);
>> free += nr_free_pages();
>> -   free += nr_swap_pages;
>
>> +   /* Since getting swap info is expensive, see if our allocation
>>can happen in physical RAM */
>
>Actually, getting swap info is as cheap as reading the variable
>nr_swap_pages. I should fix this in the OOM killer ;)

Just fixed that for myself (in both places) and about to test.  I'm almost
sure I actually encountered an error related to this, but I'll retest and
make sure...

--
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] Prevent OOM from killing init

[Benoit Garnier]

Szabolcs Szakacsits wrote :

> But if you start
> to think you get the conclusion that process killing can't be avoided if
> you want the system keep running.

What's the point in keeping the OS running if the applications are silently
killed?

If your box is running for example a mail server, and it appears that
another process is juste eating the free memory, do you really want to kill
the mail server, just because it's the main process and consuming more
memory and CPU than others?

Well, fine, your OS is up, but your application is not here anymore.

I just think there's no general solution, users must have the chance to
choose processes not to be killed, or malloc() returning errors.


Benoît GARNIER


-
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]

>> While my post didn't give an exact formula, I was quite clear on the
>>fact that
>> the system is allowing the caches to overrun memory and cause oom problems.
>
>Yes.  A testcase would be good.  It's not happening to everybody nor is
>it happening under all loads.  (if it were, it'd be long dead)
>
>> I'm more than happy to test patches, and I would even be willing to suggest
>> some algorithms that might help, but I don't know where to stick them in the
>> code.  Most of the people who have been griping are in a similar position.
>
>First step toward killing the critter is to lure him onto open ground.
>Once there.. well, I've seen some pretty fancy shooting on this list.

My patch already fixes OOM problems caused by overgrown caches/buffers, by
making sure OOM is not triggered until these buffers have been cannibalised
down to freepages.high.  If balancing problems still exist, then they
should be retuned with my patch (or something very like it) in hand, to
separate one problem from the other.  AFAIK, balancing should now be a
performance issue rather than a stability issue.

--
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: Constant Crash in scsi_eh_0

[Keith Owens]

On Sat, 24 Mar 2001 15:06:23 -0500, 
Pete Toscano <[EMAIL PROTECTED]> wrote:
>[0]kdb> btp 862
>EBP   EIP Function(args)
>0xe2bdbf6c 0xc011526a schedule+0x41e (0xe2ce0960, 0xe2bda000)
>0xe2bdbf9c 0xc0107bb8 __down_interruptible+0x94
>0xe2bdbfac 0xc0107c96 __down_failed_interruptible+0xa (0x100, 0xe2c9dd14, 0xe2c9dd6c, 
>0xe2bdbfd8, 0x0)
>   0xeaf94d7f [scsi_mod].text.lock+0x1fb
>0xe2bdbfec 0xeaf90281 [scsi_mod]scsi_error_handler+0x101
>   0xc0107547 kernel_thread+0x23

scsi_error_handler has tried to get a lock and somebody else has
already got it and is not letting go.  It is not clear from the source
of scsi_error_handler which lock is the problem.

objdump -S --start-address=0xeaf90180 --end-address=0xeaf902f0 vmlinux

will disassemble the scsi_error_handler routine, the object code will
probably mean something to the scsi maintainers.

The trick is to find out which routine is holding the lock.  It could
be an active routine or it could be caused by code that failed to
release a lock when it should.  To check for active routines, in kdb

set BTSECT=0
bta

that will do a backtrace on every process, without the section lines.
Look for any other process with scsi code in its backtrace, it is
suspect.

kdb can help diagnose the problem but the fix will have to come from
the scsi maintainers.

-
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

[Stephen C. Tweedie]

Hi,

On Fri, Mar 23, 2001 at 11:58:50AM -0800, Linus Torvalds wrote:

> Ehh.. Sleeping with the spin-lock held? Sounds like a truly bad idea.

Uggh --- the shmem code already does, see:

shmem_truncate->shmem_truncate_part->shmem_free_swp->
lookup_swap_cache->find_lock_page

It looks messy: lookup_swap_cache seems to be abusing the page lock
gratuitously, but there are probably callers of it which rely on the
assumption that it performs an implicit wait_on_page().

Rik, do you think it is really necessary to take the page lock and
release it inside lookup_swap_cache?  I may be overlooking something,
but I can't see the benefit of it --- we can still race against
page_launder, so the page may still get locked behind our backs after
we get the reference from lookup_swap_cache (page_launder explicitly
avoids taking the pagecache hash spinlock which might avoid this
particular race).

--Stephen
-
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

[Kurt Garloff]

On Fri, Mar 23, 2001 at 05:26:22PM +, James A. Sutherland wrote:
> If SuSE's install program needs more than a quarter Gb of RAM, you need a
> better distro.

Well, it's rpm ...
I guess the Debian packager is more friendly.
But if you choose to install a huge number of packages, the job to do for
the package manager (dependencies ...) is no trivial to do with few resources.

But that's not the point of the discussion.

Kernel related questions IMHO are:
(1) Why do we get into OOM? Can we avoid it?
(2) Is OOM sometimes misdetected (or triggered too early) and why?
(3) Does the OOM killer choose the right processes?

Regards,
-- 
Kurt Garloff  <[EMAIL PROTECTED]>  Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE GmbH, Nuernberg, FRG   SCSI, Security

 PGP signature

[PATCH] 2.4.2-ac24 buffer.c oops on highmem

[Stephen C. Tweedie]

Hi,

We've just seen a buffer.c oops in:

>>EIP; c013ae4b <__block_prepare_write+2bb/300>   <=
Trace; c013b732 
Trace; c015dbba 
Trace; c012a67e 
Trace; c015dbba 
Trace; c01281c0 
Trace; c01384a6 
Trace; c010910b 

__block_prepare_write()'s "out:" error handler tries to do a

memset(bh->b_data, 0, bh->b_size);

even if the buffer's page has already been kmapped for highmem.
Highmem pages will obviously have b_data being NULL.  Patch below.

I had a quick look through the rest of buffer.c and apart from the
initialisation of bh->b_data in set_bh_page(), there are no other
references left to b_data once we fix this.

Cheers,
 Stephen



--- fs/buffer.c.~1~ Sat Mar 24 17:30:13 2001
+++ fs/buffer.c Sat Mar 24 18:16:55 2001
@@ -1629,12 +1629,14 @@
return 0;
 out:
bh = head;
+   block_start = 0;
do {
if (buffer_new(bh) && !buffer_uptodate(bh)) {
-   memset(bh->b_data, 0, bh->b_size);
+   memset(kaddr+block_start, 0, bh->b_size);
set_bit(BH_Uptodate, &bh->b_state);
mark_buffer_dirty(bh);
}
+   block_start += bh->b_size;
bh = bh->b_this_page;
} while (bh != head);
return err;

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

[Rik van Riel]

On Sun, 25 Mar 2001, Stephen C. Tweedie wrote:

> Rik, do you think it is really necessary to take the page lock and
> release it inside lookup_swap_cache?  I may be overlooking something,
> but I can't see the benefit of it ---

I don't think we need to do this, except to protect us from
using a page which isn't up-to-date yet and locked because
of disk IO.

Reclaim_page() takes the pagecache_lock before trying to
free anything, so there's no reason to lock against that.

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: Linux 2.4.2 fails to merge mmap areas, 700% slowdown.

[Jakob Østergaard]

On Sat, Mar 24, 2001 at 01:54:39PM -0600, Kevin Buhr wrote:
> Jakob Østergaard <[EMAIL PROTECTED]> writes:
> > 
> > It's important that you use at least -O3 to get inlining too.
> [ . . . ]
> > 25 MB doesn't count  ;)
> 
> Aggh!  I feel like I'm in a comedy sketch.  You tell me "do that".  
> I do that.  You tell me, "you should try this instead", so I do this.
> Then, you tell me, "but you should really do the other."

I'm sorry, I was wrong about gtk-- being hairy enough, and I should have
apologized earler.

> 
> You're the one who suggested "gtk--" as a test case.  Built out of the
> box, it uses "-O2".  If there were magical settings or sekret
> incantations, I wish you'd mentioned them when you suggested it.

Yes, yes.  I guess even Qt won't do the trick either. I know at least one of
the KDE packages will, it uses Qt and if you set compilation options to -O6 it
will grow to ~100MB.

A few years ago when I compiled Mico, that one would make GCC chew up a few
hundred megs as well, if compilation options were set to use heavy
optimization.

But never mind about C++ test cases now...

> 
> > No, map merging is obviously a good idea if it can be done at little cost.
> > There has to be other cases out there than GCC 2.96 (which is still the
> > best damn C++ compiler to ship on any GNU/Linux distribution in history)
> 
> If something has a cost, even a little cost, and no one can find a
> benefit, then implementing it is not "obviously" a good idea.  That's
> why Linus asked for a real-world example before he spent time
> complicating the algorithms and adding checks that incur a cost for
> every process, even those that won't get any benefit.

I just felt that many other parts of the kernel try hard to make it as
inexpensive as possible to use kernel functionality, and that the VM naturally
should do the same (to a reasonable extent, of course, as with the other
layers).

For example, if I use thousands of TCP connections, the network layer folks
have been working hard to ensure that I can actually do that with good
performance.

It would feel "wrong" - I think - if the VM had this special rule that "you can
use MMAP, but if you do it a lot the kernel becomes horribly inefficient".
Especially because it was just proved that such behaviour could be completely
eliminated without a big performance overhead on other more simpler users of
the VM.

It's just my oppinion - of course - but I think it's very nice that under Linux
you can actually use the system calls to do lots of neat tricks (such as the
GCC mmap one, or having a thousand TCP connnections open), without being
penalized too heavily.  Using lots of system calls is not necessarily always
bad design.

> 
> > As someone else already pointed out GCC-3.0 will improve it's allocation,
> > but it *still* allocates many maps - less than before, but still potentially
> > lots...
> 
> Yes.  Zach's explanation is the first thing I've seen that makes a
> case for some benefit (besides babysitting GCC 2.96) without
> conflicting with the data I'm getting.

But the bad case was a garbage collector in GCC.  The mmap tricks seem like
some you may be inclined to actually use in something like garbage collectors.
Are we sure that the developers of all other garbage collectors out there
foresaw this problem and didn't do mmap tricks ?

When running the Haskell interpreter "Hugs", I see lots of lines like this from
strace:
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x40017000
But I don't have any "big" haskell codes, so I don't know if Haskell does actually
exhibit the gcc-2.96 pattern too...

Maybe some Haskell / ML / Java folks could comment further on this ?

> 
> As I've noted elsewhere, I see no change at all in system time for GCC
> 3.0 between 2.4.2 and 2.4.3-pre7.  Given Zach's explanation, I'm
> prepared to believe there might be a difference with, say, a 500meg
> arena (or perhaps something as small as a 100meg arena).
> 
> > It will still have the 70x performance increase on kernel memory map
> > handling as demonstrated in my benchmark just posted.  However, it will
> > be 70x of much less than with 2.96.
> 
> For my test cases under 3.0, it looks like 70 times zero.  However,
> I'm now prepared to believe that it could be 70 times something
> non-zero for certain very hairy source files.

Or maybe 70x something large for some case we just don't know about yet ?

-- 

:   [EMAIL PROTECTED]   : And I see the elder races, :
:.: putrid forms of man:
:   Jakob Østergaard  : See him rise and claim the earth,  :
:OZ9ABN   : his downfall is at hand.   :
:.:{Konkhra}...:
-
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/major

Re: Larger dev_t

[Linus Torvalds]

On Sat, 24 Mar 2001 [EMAIL PROTECTED] wrote:
>
> We need a size, and I am strongly in favor of sizeof(dev_t) = 8;
> this is already true in glibc.

The fact that glibc is a quivering mass of bloat, and total and utter crap
makes you suggest that the Linux kernel should try to be as similar as
possible?

Not a very strong argument.

There is no way in HELL I will ever accept a 64-bit dev_t.

I _will_ accept a 32-bit dev_t, with 12 bits for major numbers, and 20
bits for minor numbers.

If people cannot fit their data in that size, they have some serious
problems. And for people who think that you should have meaningful minor
numbers where the bit patterns get split up some way, I can only say "get
a frigging clue". That's what you have filesystem namespaces for. Don't
try to make binary name-spaces.

And I don't care one _whit_ about the fact that Ulrich Drepper thinks that
it's a good idea to make things too large.

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: Linux 2.4.2 fails to merge mmap areas, 700% slowdown.

[Linus Torvalds]

On 24 Mar 2001, Kevin Buhr wrote:
>
> A huge win for 2.96 and absolutely no benefit whatsoever for 3.0, even
> though it obviously had a 10-fold effect on maps counts.  On the
> positive side, there was no performance *hit* either.

I don't think the system time in 3.0 has anything to do the the mmap size.

The 40 seconds of system time you see is probably mostly something else.
It's not as if gcc _only_ does mmap's.

Do a kernel profile, and I bet that the mmap stuff is pretty low in the
noise, and the 40 seconds are for things like clearing pages in
do_anonymous_page() and for actually reading and writing to the file. Note
how the sys numbers are now all pretty much the same across the board for
different gcc versions - regardless of whether they use mmap  for the
memory management or not.

(Well, gcc-2.95 and 2.96 are the same. Gcc-3.0 is higher, but it was
higher already before, and that's probably not the memory management per
se. I suspect it's because of other things, like bigger memory footprint
or similar. Or maybe the integrated preprocessor tends to do IO in smaller
chunks or something).

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 for serial.c to work with Xircom Cardbus Ethernet+Modem

[Tom Sightler]

>> It seems something changed in 2.4.3-pre7 (against which I applied your
>>  patch) so that it doesn't make a difference. On startup I now get this,
>>  which I am CC:ing as per printk to [EMAIL PROTECTED]
>>
>> Mar 24 23:59:05 princess cardmgr[374]: initializing socket 1
>> Mar 24 23:59:05 princess kernel:   got res[10c04000:10c07fff] for
resource 6 of PCI device 115d:0103
>> Mar 24 23:59:05 princess cardmgr[374]: socket 1: Xircom CBEM56G-100
CardBus 10/100 Ethernet + 56K Modem
>> Mar 24 23:59:05 princess kernel: PCI: Enabling device 05:00.1 ( ->
0003)
>> Mar 24 23:59:05 princess kernel: Redundant entry in serial pci_table.
Please send the output of
>> Mar 24 23:59:05 princess kernel: lspci -vv, this message
(4445,259,4445,4481)
>> Mar 24 23:59:05 princess kernel: and the manufacturer and name of serial
board or modem board
>> Mar 24 23:59:05 princess kernel: to
[EMAIL PROTECTED]
>> Mar 24 23:59:05 princess kernel: register_serial(): autoconfig failed
>>
>> The card is a Xircom RBEM56G-100, despite what the card advertises.
>>
>> (in case you wonder, cardmgr is from pcmcia_cs-3.1.25).

> OK, I'll take a look at it.  I made the patch against -ac21 which I think
> was only synced up to 2.4.3-pre6, I should have mentioned that.  Perhaps
> someone added the proper Xircom stuff already or some other change made my
> patch irrelavent.  BTW, are you building serial.c as a module, or built
in?
> I have mine as a module so it doesn't load until after the card is
> initialized.  Just curious.

I tested 2.4.3-pre7 and it still fails without my patch.  With my patch I
get the above message about 'Redundant entry in serial pci_table' but it
still manages to setup my serial device as /dev/ttyS4 (the same patch
applied to 2.4.2-ac21 sets the device to /dev/ttyS1).  However it only works
if I load serial.c as a module AFTER the card is inserted, if serial.c is
already loaded it doesn't register correctly with a messages similar to
above.  Perhaps I need to check my hotplug setup.

Could your try serial.c as a module and see if it works for you like that?
That way I'd know I'm on the right track and haven't just found some strange
way to make it work on my system alone.

Later,
Tom


-
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.3 pre Question

[George R . Kasica]

Hello:

I've ftp'd the 2.4.3-pre7 patch here, but I'm wondering what I should
be applying it against? Is there a 2.4.3 "stock" kernel(if so where
would I locate it) or go against 2.4.2 stock kernel or 2.4.2-ac? 

TIA,

George

===[George R. Kasica]===+1 262 513 8503
President   +1 206 374 6482 FAX 
Netwrx Consulting Inc.  Waukesha, WI USA 
http://www.netwrx1.com
[EMAIL PROTECTED]
ICQ #12862186
-
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.3 pre Question

[jens]

On Sat, 24 Mar 2001 22:38:01 -0600, you wrote:

>Hello:
>
>I've ftp'd the 2.4.3-pre7 patch here, but I'm wondering what I should
>be applying it against? Is there a 2.4.3 "stock" kernel(if so where
>would I locate it) or go against 2.4.2 stock kernel or 2.4.2-ac? 


2.4.2 stock

Jens
-
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 Satchell]

At 12:41 AM 3/25/01 +0100, you wrote:
>If your box is running for example a mail server, and it appears that
>another process is juste eating the free memory, do you really want to kill
>the mail server, just because it's the main process and consuming more
>memory and CPU than others?
>
>Well, fine, your OS is up, but your application is not here anymore.

If you have a mission-critical application running on your box, add it to 
the inittab file with the RESPAWN attribute.  That way, OOM killer kills 
it, init notices it, and init restarts your server.

By the way, are the people working on the OOM-killer also working to avoid 
killing task 1?

Satch

-
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 Clouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sat, Mar 24, 2001 at 09:45:01PM -0800, Stephen Satchell wrote:
> If you have a mission-critical application running on your box, add it to 
> the inittab file with the RESPAWN attribute.  That way, OOM killer kills 
> it, init notices it, and init restarts your server.

Ah, that's great for simple daemons.  Now tell me how to help an app like this 
(Oracle exampled here):

oracle  89  0.0  0.4 41076 1776 ?SMar22   0:00 ora_pmon_slash
oracle  91  0.0  0.6 40676 2620 ?SMar22   0:00 ora_dbw0_slash
oracle  93  0.0  0.4 40544 1788 ?SMar22   0:00 ora_lgwr_slash
oracle  95  0.0  0.4 40544 1744 ?SMar22   0:00 ora_ckpt_slash
oracle  97  0.0  1.1 40556 4404 ?SMar22   0:00 ora_smon_slash
oracle  99  0.0  0.5 40536 2188 ?SMar22   0:00 ora_reco_slash
oracle 101  0.0  0.4 40656 1756 ?SMar22   0:00 ora_arc0_slash

In this example, when oom_kill reaps one of these autonomous threads, Oracle 
opts to crash and burn.  Database corruption is almost guaranteed.

In all reality, I'm sure any daemon (threads or no) that works heavily with disk
files is likely to screw itself and its data if it gets sigkilled for no
reason.  And in our environment, there is no reason for it to get sigkilled.

I'm going to severely hurt the first person that says such a program should be
*expecting* random untrappable annihilation of its threads.  (And what happens
when the master process *is* the target?)

- -- 
Stephen Clouse <[EMAIL PROTECTED]>
Senior Programmer, IQ Coordinator Project Lead
The IQ Group, Inc. 

-BEGIN PGP SIGNATURE-
Version: PGP 6.5.8

iQA/AwUBOr2XDgOGqGs0PadnEQK0rACfQELDid11+m90bS/DrGyrsHW45ZEAn19G
mL3fSCdi2TeHDxGLA8uXT8l5
=oQPV
-END PGP SIGNATURE-
-
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/