Can't compile 2.4.2-ac25

[Chung Won-young]

Hello,
I receive the following error with make zImage:

es1370.c: In function `es1370_probe':
es1370.c:2667: structure has no member named `trigger'
es1370.c:2667: structure has no member named `read'
make[3]: *** [es1370.o] Error 1
make[3]: Leaving directory `/usr/src/linux-2.4.2/drivers/sound'
make[2]: *** [first_rule] Error 2
make[2]: Leaving directory `/usr/src/linux-2.4.2/drivers/sound'
make[1]: *** [_subdir_sound] Error 2
make[1]: Leaving directory `/usr/src/linux-2.4.2/drivers'
make: *** [_dir_drivers] Error 2



maybe 'Update es1370, es1371,esssolo' has some problem.


- ÆóÀÎ -

ICQ : 36602496
E - Mail : [EMAIL PROTECTED], [EMAIL PROTECTED]
Homepage : http://kernel.pe.kr, http://pain.kernel.pe.kr

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

[Francois Romieu]

LA Walsh <[EMAIL PROTECTED]> écrit :
> Here is the 'alternate' output when the ncr53c8xx driver is
> compiled in:
> 
> SCSI subsystem driver Revision: 1.00
> scsi-ncr53c7,8xx : at PCI bus 0, device 8, function 0
> scsi-ncr53c7,8xx : warning : revision of 35 is greater than 2.
> scsi-ncr53c7,8xx : NCR53c810 at memory 0xfa101000, io 0x2000, irq 58
[...]

Even if the ncr53c8xx is compiled in, these messages only appear
in 53c7,8xx.c. Did you give a try to:
 SCSI support
 SCSI disk support
 NCR53C8XX SCSI support
with no other ncr/symbios driver ?

-- 
Ueimor
-
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: [kbuild-devel] Re: CML1 cleanup patch

[Eric S. Raymond]

Jeff Garzik <[EMAIL PROTECTED]>:
> There is no good reason to restrict the CML2 identifier namespace.

I've already listed a couple of good reasons.  As Peter said, maintanicus 
selector est.
-- 
http://www.tuxedo.org/~esr/">Eric S. Raymond

No one who's seen it in action can say the phrase "government help" without
either laughing or crying.
-
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: [kbuild-devel] Re: CML1 cleanup patch

[Jeff Garzik]

Keith Owens wrote:
> That just leaves the 17 names of the form CONFIG_[0-9]*.  Only the 8139
> is likely to affect outside the kernel and the argument that renaming
> config options might affect external packages does not hold.  The
> recent aic7xxx change broke pcmcia on 2.2 kernels but we can work round
> it.

There is no good reason to restrict the CML2 identifier namespace.

This is a policy change not a cleanup.

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

Re: [kbuild-devel] Re: CML1 cleanup patch

[Keith Owens]

On Mon, 26 Mar 2001 02:09:02 -0500, 
"Eric S. Raymond" <[EMAIL PROTECTED]> wrote:
>Jeff Garzik <[EMAIL PROTECTED]>:
>> If we are moving to CML2 in 2.5, I see no point in big CML1 cleanups.
>
>Yes, I know, that's what I said about Peter's DERIVED patch a week ago.

Hey, that was my DERIVED patch, not Peter's.  Point the blame where it
is due, even I think that my patch was a bad idea.  -ENOTENOUGHCOFFEE.

The 20 cris variables must be renamed to CONFIG_xxx, otherwise make dep
will not find them and config changes will only cause partial
recompiles - or do the cris people like inconsistent kernels?

Correcting the two old names is obviously the right thing to do.

That just leaves the 17 names of the form CONFIG_[0-9]*.  Only the 8139
is likely to affect outside the kernel and the argument that renaming
config options might affect external packages does not hold.  The
recent aic7xxx change broke pcmcia on 2.2 kernels but we can work round
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: CML1 cleanup patch

[Eric S. Raymond]

Jeff Garzik <[EMAIL PROTECTED]>:
> You updated Linux-Mandrake's kernel RPM and Linux-Mandrake's installer? 
> Cool!

No, I didn't.  But I can't even imagine how these changes could break those.
 
> Please post a patch with only these 19 changes, and make sure to CC it
> to linux-kernel.

I don't think this is your decision to make, is it?
-- 
http://www.tuxedo.org/~esr/">Eric S. Raymond

Where rights secured by the Constitution are involved, there can be no
rule making or legislation which would abrogate them.
-- Miranda vs. Arizona, 384 US 436 p. 491
-
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: CML1 cleanup patch

[Eric S. Raymond]

Peter Samuelson <[EMAIL PROTECTED]>:
> 
>   [Jeff Garzik]
> > > It stays "8139too".  Donald Becker's rtl8139.c continues to exist
> > > outside the kernel.
> 
> Honestly, Jeff, I don't see how it matters -- because if you are
> downloading an external driver, you are not going through the config
> system anyway.
> 
> But ... "maintanicus selector est" (my pseudo-Latin for "the maintainer
> gets to choose") so I support your stand.

And that's an argument I can buy, too.  I'll restore the TOO prefix
in my change list.
 
> Eric, the issue arose because you are obliquely proposing -- nay,
> insisting on -- a policy change.  CONFIG_8139TOO is a perfectly valid
> preprocessor token and a perfectly valid GNU Make macro name.  It
> corresponds with a source file '8139too.c' which is also perfectly
> valid.
> 
> Did it never occur to you that by insisting on a policy change (and
> related code changes), with no discussion, consensus or mandate, and
> which fixes no current bugs ... that a few toes may feel stepped on?

Actually, that's not what I did.  One of the principal PPC maintainers
agreed to get the PPC numeric-prefix symbols (9 of the 20) cleaned up,
but dropped the ball.  I waited on this as long as I thought I could.

> The burden of proof is yours.  Why should a CML2 design decision
> (stripping of CONFIG_ in the configuration files) change what seems to
> be an entirely reasonable policy?  Especially since there are multiple
> ways, which you have rejected, to work around the lexical problem in
> CML2 itself?

The workarounds would be slow, or ugly, or both.  As I said -- I might
have gone with them, but there since had to be a fix patch anyway, and
I had buy-in for all but 11 of the 39 changes...
-- 
http://www.tuxedo.org/~esr/">Eric S. Raymond

According to the National Crime Survey administered by the Bureau of
the Census and the National Institute of Justice, it was found that
only 12 percent of those who use a gun to resist assault are injured,
as are 17 percent of those who use a gun to resist robbery. These
percentages are 27 and 25 percent, respectively, if they passively
comply with the felon's demands. Three times as many were injured if
they used other means of resistance.
-- G. Kleck, "Policy Lessons from Recent Gun Control Research,"
-
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: [kbuild-devel] Re: CML1 cleanup patch

[Michael Elizabeth Chastain]

Eric Raymond writes:
> (1) 19 of the 39 changes fix things that are outright bugs even in CML1.
> These should not be allowed to persist in the stable branch.

I think that things that are bugs in CML1, on its own terms, are
worth fixing in 2.4.

Michael
-
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: CML1 cleanup patch

[Peter Samuelson]

  [Jeff Garzik]
> > It stays "8139too".  Donald Becker's rtl8139.c continues to exist
> > outside the kernel.

Honestly, Jeff, I don't see how it matters -- because if you are
downloading an external driver, you are not going through the config
system anyway.

But ... "maintanicus selector est" (my pseudo-Latin for "the maintainer
gets to choose") so I support your stand.

[esr]
> Now, wait, Jeff.  I'm not attached to Peter's change, but I don't
> think we can reasonably be expected to worry about every possible
> driver left over from every old version of Linux when managing the
> configuration-symbol namespace.  That way madness lies.

Eric, the issue arose because you are obliquely proposing -- nay,
insisting on -- a policy change.  CONFIG_8139TOO is a perfectly valid
preprocessor token and a perfectly valid GNU Make macro name.  It
corresponds with a source file '8139too.c' which is also perfectly
valid.

Did it never occur to you that by insisting on a policy change (and
related code changes), with no discussion, consensus or mandate, and
which fixes no current bugs ... that a few toes may feel stepped on?

The burden of proof is yours.  Why should a CML2 design decision
(stripping of CONFIG_ in the configuration files) change what seems to
be an entirely reasonable policy?  Especially since there are multiple
ways, which you have rejected, to work around the lexical problem in
CML2 itself?

Peter
-
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: CML1 cleanup patch

[Jeff Garzik]

"Eric S. Raymond" wrote:
> Jeff Garzik <[EMAIL PROTECTED]>:
> > You updated Linux-Mandrake's kernel RPM and Linux-Mandrake's installer?
> > Cool!

> No, I didn't.  But I can't even imagine how these changes could break those.

Our kernel build process has to look at CONFIG_xxx because we build
multiple kernels from the same base .config.


> > Please post a patch with only these 19 changes, and make sure to CC it
> > to linux-kernel.

> I don't think this is your decision to make, is it?

I have no control over what you choose to do.  It's a free 'net, and you
are free to ignore any and all suggestions.

The normal way to get patches into the kernel is to split them up.  I
just sent Linus 21 patches, which got condensed into

> -pre8:
> [...]
>   - Jeff Garzik: network driver updates, i810 rng driver, and
> "alloc_etherdev()" network driver insert race condition fix.

Separate out your changes.  Make the maintainers aware of your changes. 
ie. if it modifies my driver's CONFIG_xxx usage or my subsystem's
Config.in, let me know.  ("me" == any maintainer)

Read Documentation/SubmittingPatches.

Jeff


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

Re: CML1 cleanup patch

[Jeff Garzik]

"Eric S. Raymond" wrote:
> Jeff Garzik <[EMAIL PROTECTED]>:
> > FWIW I am opposed to any large-scale cleanup of the configuration
> > language and/or identifiers in -any- 2.4.x series kernel.
> 
> This is tweaking 39 symbols out of 1831, hardly large-scale.  These
> irregularities in the namespace cause trouble out of all proportion to
> their size, is my problem.  If you knew what I've been through trying
> to write analysis tools...*shudder*...

They cause trouble for you, solely, at the moment.  Changing the CML1
namespace potentially causes trouble for many people.


> > Not only C code but installer utilities are affected by changes in the
> > CONFIG_xxx identifiers.  If we change that namespace, we are changing
> > part of the API that is exported to drivers.  Definitely not 2.4.x
> > stuff.
> 
> My patch fixes those installer utilities.  All three of them.  And no driver
> code is or possibly could be broken by it, that's a red herring.  *No
> object code will change as a result of this patch*.

You updated Linux-Mandrake's kernel RPM and Linux-Mandrake's installer? 
Cool!


> I want this in before the 2.5 fork for several reasons:
> 
> (1) 19 of the 39 changes fix things that are outright bugs even in CML1.
> These should not be allowed to persist in the stable branch.

Please post a patch with only these 19 changes, and make sure to CC it
to linux-kernel.

Thanks,

Jeff


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

Re: CML1 cleanup patch

[Eric S. Raymond]

Jeff Garzik <[EMAIL PROTECTED]>:
> FWIW I am opposed to any large-scale cleanup of the configuration
> language and/or identifiers in -any- 2.4.x series kernel.

This is tweaking 39 symbols out of 1831, hardly large-scale.  These
irregularities in the namespace cause trouble out of all proportion to
their size, is my problem.  If you knew what I've been through trying
to write analysis tools...*shudder*...
 
> Not only C code but installer utilities are affected by changes in the
> CONFIG_xxx identifiers.  If we change that namespace, we are changing
> part of the API that is exported to drivers.  Definitely not 2.4.x
> stuff.

My patch fixes those installer utilities.  All three of them.  And no driver
code is or possibly could be broken by it, that's a red herring.  *No
object code will change as a result of this patch*.
 
> If we are moving to CML2 in 2.5, I see no point in big CML1 cleanups.

Yes, I know, that's what I said about Peter's DERIVED patch a week ago.
You notice *he* ain't bitching about this one?

I want this in before the 2.5 fork for several reasons:

(1) 19 of the 39 changes fix things that are outright bugs even in CML1.
These should not be allowed to persist in the stable branch.

(2) I want to finish my analysis tools and do some really thorough
consistency and correctness checking before the stable branch
separates.  Alan will thank me for this later.

(2) If we do adopt CML2, having these changes in will make it *far* 
easier to contemplate back-porting it to 2.4.x later on.

The present configuration system is a mess, everybody agrees on that.
I'm trying to clean it up, and it's a tedious and grubby enough job
even with the full cooperation of the kbuild team.  Jeff, would you
please support this instead of obstructing it?
-- 
http://www.tuxedo.org/~esr/">Eric S. Raymond

  "You have taught us much. Come with us and join the movement."
  "This movement of yours, does it have slogans?" inquired the Chink.
  "Right on!" they cried. And they quoted him some.
  "Your movement, does it have a flag?" asked the Chink.
  "You bet!" and they described their emblem.
  "And does your movement have leaders?"
  "Great leaders."
  "Then shove it up your butts," said the Chink. "I have taught you nothing."

-- Tom Robbins, "Even Cowgirls Get The Blues"
-
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: CML1 cleanup patch

[Eric S. Raymond]

Alan Cox <[EMAIL PROTECTED]>:
> > months ago, and they did -- but the 2.5 fork is nearly upon us and I
> > feel a strong need to get this in before then.
> 
> Fix it in 2.5 not before

I hope you will reconsider after you've seen the reasons I posted in a later
message, Alan.  You're one of the people I'm tring to save a lot of hassle
for later on.  In fact, you are likely to be the largest beneficiary of
this change.
-- 
http://www.tuxedo.org/~esr/">Eric S. Raymond

"Are we to understand," asked the judge, "that you hold your own interests
above the interests of the public?"

"I hold that such a question can never arise except in a society of cannibals."
-- Ayn Rand
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: via-rhine driver: wicked 2005 problem

[Manfred Spraul]

> [Kernel 2.4.2,

the -ac kernels contain a patch that automatically resets the nic if it
dies. I've attached my old patch, it applies to 2.4.2.

> 
> I tried the diagnostic utilities from Donald Becker at Scyld.com,
> but I don't  know what I should be looking for. The text output
> seems ok to me. 
>
Could you post the output?
And a few more lines from your kernel log.

--
Manfred

--- 2.4/drivers/net/via-rhine.c Mon Feb  5 16:44:59 2001
+++ build-2.4/drivers/net/via-rhine.c   Mon Feb  5 19:46:23 2001
@@ -55,6 +55,9 @@
LK1.1.6:
- Urban Widmark: merges from Beckers 1.08b version (VT6102 + mdio)
 set netif_running_on/off on startup, del_timer_sync
+   
+   LK1.1.7:
+   - Manfred Spraul: added reset into tx_timeout
 */
 
 
@@ -121,13 +124,14 @@
 #include 
 #include 
 #include 
+#include 
 #include  /* Processor type for cache alignment. */
 #include 
 #include 
 
 /* These identify the driver base version and may not be removed. */
 static char version1[] __devinitdata =
-"via-rhine.c:v1.08b-LK1.1.6  8/9/2000  Written by Donald Becker\n";
+"via-rhine.c:v1.08b-LK1.1.7  8/9/2000  Written by Donald Becker\n";
 static char version2[] __devinitdata =
 "  http://www.scyld.com/network/via-rhine.html\n";
 
@@ -380,6 +384,7 @@
CmdNoTxPoll=0x0800, CmdReset=0x8000,
 };
 
+#define MAX_MII_CNT4
 struct netdev_private {
/* Descriptor rings */
struct rx_desc *rx_ring;
@@ -421,7 +426,8 @@
 
/* MII transceiver section. */
u16 advertising;/* NWay media 
advertisement */
-   unsigned char phys[2];  /* MII device addresses. */
+   unsigned char phys[MAX_MII_CNT];/* MII device 
+addresses. */
+   unsigned int mii_cnt;   /* number of MIIs found, but only the 
+first one is used */
u16 mii_status; /* last read MII 
status */
 };
 
@@ -431,7 +437,6 @@
 static void via_rhine_check_duplex(struct net_device *dev);
 static void via_rhine_timer(unsigned long data);
 static void via_rhine_tx_timeout(struct net_device *dev);
-static void via_rhine_init_ring(struct net_device *dev);
 static int  via_rhine_start_tx(struct sk_buff *skb, struct net_device *dev);
 static void via_rhine_interrupt(int irq, void *dev_instance, struct pt_regs *regs);
 static void via_rhine_tx(struct net_device *dev);
@@ -443,6 +448,25 @@
 static int  via_rhine_close(struct net_device *dev);
 static inline void clear_tally_counters(long ioaddr);
 
+static void wait_for_reset(struct net_device *dev)
+{
+   long ioaddr = dev->base_addr;
+   int i;
+
+   i = 0;
+   do {
+   udelay(5);
+   i++;
+   if(i > 2000) {
+   printk(KERN_ERR "%s: reset did not complete in 10 ms.\n",
+   dev->name);
+   break;
+   }
+   } while(readw(ioaddr + ChipCmd) & CmdReset);
+   if (debug > 1)
+   printk(KERN_INFO "%s: reset finished after %d microseconds.\n",
+   dev->name, 5*i);
+}
 
 static int __devinit via_rhine_init_one (struct pci_dev *pdev,
 const struct pci_device_id *ent)
@@ -451,14 +475,11 @@
struct netdev_private *np;
int i, option;
int chip_id = (int) ent->driver_data;
-   int irq = pdev->irq;
static int card_idx = -1;
static int did_version = 0;
long ioaddr;
int io_size;
int pci_flags;
-   void *ring;
-   dma_addr_t ring_dma;

/* print version once and once only */
if (! did_version++) {
@@ -471,6 +492,10 @@
io_size = via_rhine_chip_info[chip_id].io_size;
pci_flags = via_rhine_chip_info[chip_id].pci_flags;
 
+   if (pci_enable_device (pdev))
+   goto err_out;
+
+
/* this should always be supported */
if (!pci_dma_supported(pdev, 0x)) {
printk(KERN_ERR "32-bit PCI DMA addresses not supported by the 
card!?\n");
@@ -484,20 +509,7 @@
goto err_out;
}
 
-   /* allocate pci dma space for rx and tx descriptor rings */
-   ring = pci_alloc_consistent(pdev, 
-   RX_RING_SIZE * sizeof(struct rx_desc) +
-   TX_RING_SIZE * sizeof(struct tx_desc),
-   &ring_dma);
-   if (!ring) {
-   printk(KERN_ERR "Could not allocate DMA memory.\n");
-   goto err_out;
-   }
-
ioaddr = pci_resource_start (pdev, pci_flags & PCI_ADDR0 ? 0 : 1);
-
-   if (pci_enable_device (pdev))
-   goto err_out_free_dma;

if (pci_flags & PCI_USES_MASTER)
pci_set_master (pdev);
@@ -506,7 +518,7 @@
if (dev == NULL) {
p

Re: IP layer bug?

[Oleg Drokin]

Hello!

On Mon, Mar 26, 2001 at 05:51:43PM +0530, Manoj Sontakke wrote:
> > > ip_options_compile() when called with first argument NULL resets cb to 0.
> > I have found that already.
> > > underlying layer(link and phy) could be anything so where from the
> > > ip_options should start will depend upon the underlying layer.
> > But here's the problem!
> > If I won't zero cb in my driver before netif_rx() call,
> > IP layer thinks that all my packets have various ip options set
> > (source routing most notable)
> U can set cb to zero, but u also plan to use cb for storing ur data. If
I use it for storing data, but when I do netif_rx() on skb, I cannot touch it
anymore, so no data there is belong to me, and if I read that code in
ip_input.c, it gets zeroed.
BTW, I found that it's not ip_input.c that sends me 'source routing rejected'
message, because no message is logged. It might be some other place.
But anyway something is wrong in IP layer.

> that happens then u need to modify the way the macro IPCB
> (probably in net/ip.h) is defined. Also make sure to increase the size 
> of cb to accomodate ur data. This will solve ur problem but making this
My data perfectly fits in cb of current size.

> general (part of the standard kernel code) needs a lot of work in the ip
> layer. The cb is also used by TCP. The same needs to be done in IP layer
> but this will again largly depend on the layers below and hence the
> complexity.
But comment in skbuff.h claims that any owner of skb can use cb for its own needs, 
till it passes ownership to whoever else.

> The alternative to this is that u can add another buffer like cb in
> sk_buff.
What for?

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/

2.2.19 aic7xxx breaks pcmcia

[Keith Owens]

2.2.19 Documentation/Changes says pcmcia-cs 3.0.14.  I am using 3.1.21
and it breaks if you compile the kernel with scsi support then try to
compile pcmcia.  clients/apa1480_stub.c in 3.1.21 has
  #include <../drivers/scsi/aic7xxx.h>
but in 2.2.19 that file is drivers/scsi/aic7xxx/aic7xxx.h.  You need at
least pcmcia-cs 3.1.25 for kernel 2.2.19 with scsi support.

In the kernel and associated utilities I want to remove lines like
  #include <../drivers/scsi/aic7xxx.h>
and replace them with
  #include "aic7xxx.h"
with the Makefile specifying -I $(TOPDIR)/drivers/scsi (2.2.18) or -I
$(TOPDIR)/drivers/scsi/aic7xxx (2.2.19).  Hard coding long path names
for #include is bad, especially when they contain '..'.  It stops
kernel developers moving code around and makes it difficult to do some
of the things I plan for the 2.5 Makefile rewrite.  David, how easy
would it be to change pcmcia to this style of include?

-
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: IP layer bug?

[Manoj Sontakke]

Hi,
On Mon, 26 Mar 2001, Oleg Drokin wrote:

> Hello!
> 
> On Mon, Mar 26, 2001 at 04:06:19PM +0530, Manoj Sontakke wrote:
> > >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), 
> > ip_options_compile() when called with first argument NULL resets cb to 0.
> I have found that already.
> 
> > This is probably because the cb is supposed to be used IP and above. The
> Sure.
> 
> > underlying layer(link and phy) could be anything so where from the
> > ip_options should start will depend upon the underlying layer.
> But here's the problem!
> If I won't zero cb in my driver before netif_rx() call,
> IP layer thinks that all my packets have various ip options set
> (source routing most notable)

U can set cb to zero, but u also plan to use cb for storing ur data. If
that happens then u need to modify the way the macro IPCB
(probably in net/ip.h) is defined. Also make sure to increase the size 
of cb to accomodate ur data. This will solve ur problem but making this
general (part of the standard kernel code) needs a lot of work in the ip
layer. The cb is also used by TCP. The same needs to be done in IP layer
but this will again largly depend on the layers below and hence the
complexity.

The alternative to this is that u can add another buffer like cb in
sk_buff.

Manoj Sontakke

-
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: CML1 cleanup patch

[Jeff Garzik]

"Eric S. Raymond" wrote:
> I don't care, as long as the result has a non-numeric
> prefix -- bare "8139whatever" is out.

Bullshit.  Numeric prefixes work fine in CML1.

With regards to CML2, hardware and driver filenames quite often begin
with numerals, so it is quite logical that config variables may begin
with a numeral.

You're writing CML2.  Don't create a stupid namespace with stupid
limitations.  I'm glad my filesystem and my sysctl namespace don't have
such limitations.

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

Re: CML1 cleanup patch

[Alan Cox]

> months ago, and they did -- but the 2.5 fork is nearly upon us and I
> feel a strong need to get this in before then.

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

Re: CML1 cleanup patch

[Eric S. Raymond]

Peter Samuelson <[EMAIL PROTECTED]>:
> > CONFIG_8139TOO  CONFIG_RTL8139TOO
> > CONFIG_8139TOO_PIO  CONFIG_RTL8139TOO_PIO
> > CONFIG_8139TOO_TUNE_TWISTER CONFIG_RTL8139TOO_TUNE_TWISTER
> 
> The -TOO suffix was to distinguish between this and the former 8139
> driver, as the two coexisted in 2.2 and 2.3.  As the old driver has
> been dropped from 2.4, I propose likewise dropping the -TOO.

I'm preparing an updated version of the patch for 2.4.3-pre8.  I'll
incorporate this change.
 
> Oh, BTW -- an alternate approach to making the kernel tree compatible
> with CML2 would be to make CML2 compatible with the kernel tree.
> Define a character (say '%') as an optional prefix for a configuration
> symbol.  This character would only be required where the symbol would
> otherwise by misparsed, as with '[0-9].*'.

I considered two workarounds:

1. Adding some cruft to the language to support this case, as you suggest.

I might have gone this route, until I tripped over the two bugs and
the bad config symbols in the CRIS port tree.  That meant there was
going to have to be a cleanup patch anyway, so why not fix those 20 
symbols (out of 1831) rather than grubbifying the language?

2. Hacking the CML2 lexical analyzer to handle this case.

I could have done this, allowing tokens to be recognized as numeric only
if all chars are digits.  I didn't, for two reasons: (1) Lexical analysis
is, as it turns out, a hotspot in the CML2 compiler code -- the last thing
it needs is more overhead, and (2) interpreting symbols with leading digits
as nonnumeric tokens is just *wrong*.  Ugh.  Violates the Principle of Least
Surprise big-time.
-- 
http://www.tuxedo.org/~esr/">Eric S. Raymond

Every election is a sort of advance auction sale of stolen goods. 
-- H.L. Mencken 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Linux 2.4.2ac25

[Alan Cox]

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

Intermediate diffs are available from

http://www.bzimage.org

This one is very much resychronizing with people. It does boot 8) but I've
not tested it hard. Alpha has probably been broken by the pre8 merge.

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

2.4.2-ac25
o   Handle PCI/ISA simple MP tables via ELCR(John William)
o   Fix get_sb_single   (Al Viro)
o   Update es1370, es1371,esssolo   (Thomas Sailer,
 Tjeerd Mulder,
 Nathanial Daw)
o   Update orinoco_cs   (Jean Tourilhes)
o   Fix races found in the new kbd/console code (Andrew Morton)
o   Remove dead timer.h docs(Tim Wright)
o   Update ppc to new generic mm changes(Paul Mackerras)
o   Clean up mdacon (Paul Gortmaker)
o   Remove duplicate configure.help texts   (Steven Cole)
o   Fix symbol export for shm_file_open (Keith Owens)
o   First batch of pointer reference bug fixes  (Andrew Morton)
from Stanford report
o   Fix de4x5 oops on Alpha XP1000  (George France)
o   Chipsfb update  (Paul Mackerras)
o   Fix higmem block_prepare_write crash(Stephen Tweedie)
o   Bring PAE36 back up to date, handle x86 errata  (Ingo Molnar)
o   Fix ov511 crash if opened while loading (Pete Zaitcev)
o   Merge Linus 2.4.3pre8
o   Update Advansys scsi driver (Bob Frey)

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

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

2.4.2-ac22
o   Fix dereference after free in megaraid driver   (me)
o   Fix crash if we run out of memory during a link (me)
follow [found by Stanford tools]
o   Fix crash if we run out of memory during
block_truncate_page [found by Stanford tools]   (me)
o   Update Alpha to pre6 style pte/pmd_alloc(Ivan Kokshaysky)
o   Fix ppp memory corruption   (Kevin Buhr)
| Bizzarely enough a direct re-invention of a 1.2 ppp bug
o   Fix heavy stack usage in tty_foo_devfs()(Jeff Dike)
o   Make alloc_tty_struct always use kmalloc(Andrew Morton)
o   Document task struct locking rules  (Andrew Morton)
o   Document SAK properly   (An

Re: [PATCH] Prevent OOM from killing init

[Mike Galbraith]

On Sun, 25 Mar 2001, Jonathan Morton wrote:

> >> 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.
> >
> >Great.  I haven't seen your patch yet as my gateway ate it's very last
> >disk.  I look forward to reading it.
>
> I'm currently investigating the old non-overcommit patch, which (apart from
> needing manual applying to recent kernels) appears to be rather broken in a
> trivial way.  It prevents allocation if total reserved memory is greater
> than the total unallocated memory.  Let me say that again, a different way
> - it prevents memory usage from exceeding 50%...
>
> Is there a fast way of getting total VM size?  Eg. equivalent to the
> following code:
>
> si_meminfo(&i);
> si_swapinfo(&i);
> free = i.totalram + i.totalswap;

Other than using their components?.. don't know.

> If not, I have to do some jiggery to keep good performance along with true
> non-overcommittance.

(thinking about mlock and what that could do to any saved state.. and
how long allocations can block and where.. egad.  then there's zones)

I'm no VM expert, but I wonder if the overhead of obtaining this info
will be the worst you have to deal with.

-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: CML1 cleanup patch

[Eric S. Raymond]

Jeff Garzik <[EMAIL PROTECTED]>:
> > The -TOO suffix was to distinguish between this and the former 8139
> > driver, as the two coexisted in 2.2 and 2.3.  As the old driver has
> > been dropped from 2.4, I propose likewise dropping the -TOO.
> 
> It stays "8139too".  Donald Becker's rtl8139.c continues to exist
> outside the kernel.  
> 
> And "rtl8139too" should have never crept into 2.2.  That needs to be
> changed to "8139too."  That's what I get for saying that I don't support
> 2.2...

Now, wait, Jeff.  I'm not attached to Peter's change, but I don't think
we can reasonably be expected to worry about every possible driver
left over from every old version of Linux when managing the
configuration-symbol namespace.  That way madness lies.

I'll cheerfully ship a supplementary patch to fix this one name later,
but we can't afford to have a wrangle over this bit of trivia delay
adoption of this one.  I have a hell of a lot of work to do for
which this is critical path.  

I left it pretty late as it is, out of hope that other people would
clean up some of the messes I noticed in the config namespace six
months ago, and they did -- but the 2.5 fork is nearly upon us and I
feel a strong need to get this in before then.

Would you and Peter please fight this out and tell me what to do in the
supplementary patch?  I don't care, as long as the result has a non-numeric
prefix -- bare "8139whatever" is out.
-- 
http://www.tuxedo.org/~esr/">Eric S. Raymond

Sometimes it is said that man cannot be trusted with the government
of himself.  Can he, then, be trusted with the government of others?
-- Thomas Jefferson, in his 1801 inaugural address
-
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: CML1 cleanup patch

[Jeff Garzik]

Well, bummer.  I can't seem to find Eric's message archived anywhere.

FWIW I am opposed to any large-scale cleanup of the configuration
language and/or identifiers in -any- 2.4.x series kernel.

Not only C code but installer utilities are affected by changes in the
CONFIG_xxx identifiers.  If we change that namespace, we are changing
part of the API that is exported to drivers.  Definitely not 2.4.x
stuff.

If we are moving to CML2 in 2.5, I see no point in big CML1 cleanups.

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

Re: CML1 cleanup patch

[Jeff Garzik]

Peter Samuelson wrote:
> 
> [esr]
> > CONFIG_8139TOOCONFIG_RTL8139TOO
> > CONFIG_8139TOO_PIOCONFIG_RTL8139TOO_PIO
> > CONFIG_8139TOO_TUNE_TWISTER   CONFIG_RTL8139TOO_TUNE_TWISTER
> 
> The -TOO suffix was to distinguish between this and the former 8139
> driver, as the two coexisted in 2.2 and 2.3.  As the old driver has
> been dropped from 2.4, I propose likewise dropping the -TOO.

It stays "8139too".  Donald Becker's rtl8139.c continues to exist
outside the kernel.  

And "rtl8139too" should have never crept into 2.2.  That needs to be
changed to "8139too."  That's what I get for saying that I don't support
2.2...

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

Re: CML1 cleanup patch

[Peter Samuelson]

[esr]
> CONFIG_8139TOOCONFIG_RTL8139TOO
> CONFIG_8139TOO_PIOCONFIG_RTL8139TOO_PIO
> CONFIG_8139TOO_TUNE_TWISTER   CONFIG_RTL8139TOO_TUNE_TWISTER

The -TOO suffix was to distinguish between this and the former 8139
driver, as the two coexisted in 2.2 and 2.3.  As the old driver has
been dropped from 2.4, I propose likewise dropping the -TOO.

Oh, BTW -- an alternate approach to making the kernel tree compatible
with CML2 would be to make CML2 compatible with the kernel tree.
Define a character (say '%') as an optional prefix for a configuration
symbol.  This character would only be required where the symbol would
otherwise by misparsed, as with '[0-9].*'.

Peter
-
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: IP layer bug?

[Oleg Drokin]

Hello!

On Mon, Mar 26, 2001 at 04:06:19PM +0530, Manoj Sontakke wrote:
> >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), 
> ip_options_compile() when called with first argument NULL resets cb to 0.
I have found that already.

> This is probably because the cb is supposed to be used IP and above. The
Sure.

> underlying layer(link and phy) could be anything so where from the
> ip_options should start will depend upon the underlying layer.
But here's the problem!
If I won't zero cb in my driver before netif_rx() call,
IP layer thinks that all my packets have various ip options set
(source routing most notable)

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: IP layer bug?

[Manoj Sontakke]

Hi
On Sun, 25 Mar 2001, Oleg Drokin wrote:

> 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), 
ip_options_compile() when called with first argument NULL resets cb to 0.
This is probably because the cb is supposed to be used IP and above. The
underlying layer(link and phy) could be anything so where from the
ip_options should start will depend upon the underlying layer.

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

-- 
Regards,
Manoj Sontakke

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

Re: Advansys SCSI driver old verson?

[Bob Frey]

On Fri, Mar 23, 2001 at 10:46:54PM +, Alan Cox wrote:
> > Andy Kellner (from ConnectCom Solutions formerly 
> > known as Advansys) and Bob Frey (former maintainer) 
> > working in concert have posted several "3.3x" versions 
> > of the advansys driver to the linux-scsi list. Despite
> 
> I don't believe Linus reads linux-scsi. I only glance at it occasionally.
> If you care to send me a diff against -ac23 I'll merge it and if it seems to
> behave solidly then push it to Linus

Thanks for the prodding. I've sent to Alan Advansys SCSI driver
3.3G patches against 2.4.2 + ac24 and for 2.2.19. The driver can
be gotten from:
http://www.turbolinux.com.cn/~bfrey/advansys-33G.tgz
http://www.turbolinux.com.cn/~bfrey/advansys-33G.tgz-MD5SUM
Andy at www.connectcom.net, www.advansys.com has been busy,
but I'm sure will soon update the www, ftp sites.

-- 
Bob Frey
[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]

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

Yes, that's what I meant.  I was assuming that there was 40sec of
baseline system time in each compilation representing everything
*except* searching lists of unmerged mmaps.

Before doing the pre7 test, I figured that---given Zack's 32-factor
observation---my benchmarks indicated that 2.96 was spending 2m14-40 =
214sec doing unmerged mmaps while 3.0 was spending 49-40 = 9 sec doing
unmerged mmaps.  This ratio is more or less in line with a 32-fold
difference in number of maps predicted by Zack plus or minus a couple
seconds.

That is, I was assuming that the total time wasted because of unmerged
mmaps was roughly linear in the number of vmas.  Actually, it'll be
O(n log n)---the number of maps times the O(log n) search time once
the AVL tree gets big enough to matter.  Anyway, the factor should
still be around 30-50 or so.

When I did the test and 2.96 fell right in line with 2.95.3, I was
disappointed that 3.0 *didn't* fall right in line with the other
two---I thought I'd get those extra 8 seconds back.

> Do a kernel profile, and I bet that the mmap stuff is pretty low in the
> noise,

I'll bet your right---that's why I was disappointed.  I thought 3.0's
mmap overhead would be higher than it turned out to be.

As it is, it looks like only the most extreme cases (thousands or ten
of thousands of mergeable maps) will benefit from the patch.

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: mouse problems in 2.4.2

[linas]

It's been rumoured that Stephen Satchell said:
> 
> I'm experiencing the same thing 
[...]
>  Central problem appears to be the KVM 
> switch I'm using. Save yourself the problem.

Am not using a KVM switch, or any cable extenders, etc.  The USB-to-PS2
connecter came with the mouse, so I assume its OK ... Besides, the
symptoms don't point at the connector.

--linas
-
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] OOM handling

[Matthew Chappee]

> OK I just did it. as I already told I have "stress tested it" by 

> Since I'm one day late up to my promise to provide this
> patch it's actually fascinating that already 4 people (in esp. not
> newbees requesting a new /proc entry for everything)
> for reassurance that I will indeed implement it... Well 
> this kind of "high" and "eager" feadback seems for me to indicate  that
> there is very serious desire for it. And then of course I
> just have to ask our people working with DB's here at work as well :-).


I'm one of the four that contacted you. :-)  I'm certainly not a newbie and it appears 
that you nailed the reason that I'm interested.  I'm an Oracle DBA that runs a fairly 
large database(s) on Linux.  A patch like this is important.  Case in point:

We do not have loads of money, so we have to double up our servers.  A database server 
can also be an app server, or a web server, etc.  Now, let's say that Joe Surfer has 
10 netscape sessions open on my database server (hey, talk to my boss, it's not my 
fault). He's grabbing Pr0n/MP3s/whatever as fast as our 'T' will allow.  One of the 
websites that he visits has some nasty java that bloats his browser to the point of 
OOM.  Something has to die in order for the machine to stay alive.  Remember the 100 
sided die from D&D?  Roll it and kill -9?  Hopefully not, I should be able to tell the 
OOM_Killer to wipe out this user's stuff first, based on the prowess of his UID.

The point being, my database shouldn't be selected for termination.  Nobody ever got 
fired for kill -9'ing netscape, but Oracle is a different story.  I urge you, consider 
the patch.

> Ah... and of course I think this patch can already go directly 
> into the official kernel. The quality of code should permit 
> it. I would esp. request Rik van Riel to have a closer look
> at it...

Whoa, easy there trigger.  I'd rather have a wacked out OOM_Killer than a 
barely-tested alternative.

Matthew


-
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: mouse problems in 2.4.2

[Keith Owens]

On Sun, 25 Mar 2001 16:27:37 -0800, 
Stephen Satchell <[EMAIL PROTECTED]> wrote:
>I'm experiencing the same thing with an ASUS P5A-B running a K6-2/266 with 
>Linux 2.2.17, and Windows 98.   Central problem appears to be the KVM 
>switch I'm using. Save yourself the problem.
>
>I had to reboot all the systems to get regular mouse operation back with 
>the Logitech.

I sometimes have keyboard and mouse problems after changing machines
using a mechanical KVM, on a Logitech mouse.  This script fixes it for
me.

/usr/local/bin/switched

#!/bin/sh
/etc/rc.d/init.d/gpm restart
/sbin/kbdrate -r 30

I run gpm in redirect -R mode as
  daemon gpm -t $MOUSETYPE -R -m /dev/ttyS0
and tell X11 to read from /dev/gpmdata as
   Protocol"MouseSystems"
   Device  "/dev/gpmdata"
not directly from the mouse; the redirect protocol is always
MouseSystems, no matter what the underlying mouse type is.  Restarting
gpm after KVM switch then fixes everything else.

-
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: mouse problems in 2.4.2

[Stephen Satchell]

I'm experiencing the same thing with an ASUS P5A-B running a K6-2/266 with 
Linux 2.2.17, and Windows 98.   Central problem appears to be the KVM 
switch I'm using. Save yourself the problem.

I had to reboot all the systems to get regular mouse operation back with 
the Logitech.

Satch


At 04:33 PM 3/25/01 -0600, you wrote:
>I am experiencing debilitating intermittent mouse problems & was about
>to dive into the kernel to see if I could debug it.  But first, I thought
>a quick note to the mailing list may help.
>
>Symptoms:
>After a long time of flawless operation (ranging from nearly a week to
>as little as five minutes), the X11 pointer flies up to top-right corner,
>and mostly wants to stay there.  Moving the mouse causes a cascade of
>spurious button-press events get generated.
>
>This did not occur with 2.4.0test2 or 2.2.16 (to the best of my
>recollection) and first showed up in 2.4.0test7 or 2.4.1 (not sure).
>With 2.4.2, the symptoms seem slightly different (almost all pointer
>movement events seem to be lost; although spurious button-press events
>still happen).
>
>Mouse is a logitech trackman marble, with USB connector to
>logitech-supplied USB to ps/2 DIN plug.  Configured as a PS/2 mouse.
>Motherboard is a Athalon/VIA Apollo KA7.

-
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: question on /dev/tap0

[Lennert Buytenhek]

Intended behaviour. This is because of the access checks done in the
netlink code. Misleading, yes.


On Sun, 25 Mar 2001, James Stevenson wrote:

>
> Hi
>
> would somebody be able to explain to me
> when you try to open /dev/tap0 which is a
> character device file which has the permissions
>
> File: "tap0"
> Size: 0Filetype: Character Device
> Mode: (0666/crw-rw-rw-)
>
> when tried to open
>
> [mistral@linux /dev]$ cat tap0
> cat: tap0: Operation not permitted
>
> and strace shows that it gets a permission error
> open("tap0", O_RDONLY|0x8000)   = -1 EPERM
>
> is it just me or is this either
> a) a bug
> b) very misleading
>
> thanks
>   James
>
>


-
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: /proc/stat disk_io entries

[Tony . Young]

The structure tables size is a concern for me too. Hence the suggestion that
perhaps a hash table implementationg is better suited to the job. The larger
sizes that you need for your Array seem to bear this out. Until a fix is
implemented I'm just going to modify DK_MAX_MAJOR to fix my own
requirements.

> -Original Message-
> From: Dupuis, Don [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, 24 March 2001 02:02
> To: Tony Young; [EMAIL PROTECTED]
> Subject: RE: /proc/stat disk_io entries
> 
> 
> I have sent a patch to Alan and Linus about this also.  We 
> have cpqarray and
> cciss controllers that use major 72-79 and 104-111.  Alan 
> said he doesn't
> have time to look at it till mid April and Linus hasn't 
> responded to me at
> all about it.  The best way is to actually rewrite the kstat 
> architecture,
> but the patch I sent it will do the job.  There is concern 
> about structure
> table size I believe.  My patch increased DK_MAX_MAJOR to 112 
> and added
> about 4 lines to genhd.h to support the cpqarray and cciss 
> driver.  This
> works on Compaq servers and I get the data that is needed.  
> Any thoughts?
> 
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, March 22, 2001 9:55 PM
> To: [EMAIL PROTECTED]
> Subject: /proc/stat disk_io entries
> 
> 
> All,
> 
> Firstly, my relevant system stats:
>   kernel  linux 2.4.3-pre6
>   hda IDE Drive
>   hdb CD drive
>   hdc IDE Drive
>   hdd IDE Drive
>   sda SCSI Drive
> 
> The problem I'm seeing is that IO stats (disk_io) aren't 
> being shown in
> /proc/stats for the 2 harddrives on the second ide controller 
> (hdc and hdd).
> 
> I checked the kernel code and found the function kstat_read_proc in
> fs/proc/proc_misc.c which loops through from 0 up to 
> DK_MAX_MAJOR and prints
> out the stats to /proc/stat for each drive. However, 
> DK_MAX_MAJOR is set to
> 16 in include/linux/kernel_stat.h, which means that the 
> drives on my second
> ide controller, with a major number of 22, aren't included in 
> the loop.
> 
> I modified the value of DK_MAX_MAJOR to 23 and rebuilt and 
> /proc/stats now
> shows the 2 missing harddrives. I'm uncomfortable sending in 
> a patch for
> this as I'm not familiar enough with the code to understand the full
> ramifications of changing this value. Considering also that 
> the value 23
> stills doesn't include any tertiary or quaternary ide 
> controllers (33 and
> 34) makes me wonder what the correct value should really be.
> 
> I'm also curious, after considering the above, about whether 
> or not a hash
> table(s) would be better suited to the current implementation of
> 2-dimensional arrays for disk stats (dk_drive, dk_drive_rio, 
> dk_drive_wio,
> etc).
> 
> I've brought this to the list because I'm not sure of the 
> correct solution
> and I couldn't work out if there was a specific maintainer of 
> this code.
> 
> It also seems strange to me that the identifiers for the 
> values for disk_io
> in /proc/stat are (major_number,disk_number) tuples rather than
> (major,minor). The current implementation with my change now 
> shows my first
> ide drive to be identified as (8,0), while my second and 
> third ide drives
> (hdc and hdd) are identified as (22,2) and (22,3) 
> respectively rather than
> (22,0) and (22,1) - I presume because they are the in the 3rd 
> and 4th ide
> positions. Using disk_number instead of minor number also 
> makes it more
> difficult for any user programs reading /proc/stat to trace 
> the entry back
> to a physical device. Any program must make assumptions that 
> major numbers 8
> and 22 refer to /dev/hd* entries, and that disk number 0 
> translates to 'a',
> 1 to 'b', 2 to 'c', etc and can then work out that 22,2 means 
> /dev/hdc.
> These assumption, of course, break with the use of devfs when 
> not using
> devfsd to provide the necessary links.
> 
> I welcome any comments, but please CC me directly as I'm not 
> subscribed to
> the list.
> 
> Tony...
> --
> Tony Young
> Senior Software Engineer
> Integrated Research Limited
> Level 10, 168 Walker St
> North Sydney, NSW 2060, Australia
> Ph:  +61 2 9966 1066
> Fax: +61 2 9966 1042
> Mob: 0414 649942
> 
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

swap file vs swap partition

[M.]

kernel 2.4.2-ac24.

first, i have 256MB of RAM and a 128MB swap. i know the recommendation
is RAM*2 for swap, but is that a *requirement* as well? i understand the
active/inactive page debate and why *2 is needed (lets not argue that),
but am i just wasting space with a 128MB swap?

second, is there any performance issues with a swap partition vs a swap
file. without resizing, i am stuck with the 128mb partition.

thanks,


-- 
Robert M. Love
[EMAIL PROTECTED]
[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: NCR53c8xx driver and multiple controllers...(not new prob)

[Mitch Adair]

> Here is the 'alternate' output when the ncr53c8xx driver is
> compiled in:
> 
> SCSI subsystem driver Revision: 1.00
> scsi-ncr53c7,8xx: at PCI bus 0, device 8, function 0
> scsi-ncr53c7,8xx: warning : revision of 35 is greater than 2.
> scsi-ncr53c7,8xx: NCR53c810 at memory 0xfa101000, io 0x2000, irq 58
> scsi0: burst length 16
> scsi0: NCR code relocated to 0x37d6c610 (virt 0xf7d6c610)
> scsi0: test 1 started
> scsi0: NCR53c{7,8}xx (rel 17)
> request_module[block-major-8]: Root fs not mounted
> VFS: Cannot open root device "807" or 08:07
> Please append a correct "root=" boot option
> Kernel panic: VFS: Unable to mount root fs on 08:07
> -

I don't believe that's the ncr53c8xx driver.  That looks like the
53c7,8xx driver.  I don't think it's really maintained any more, or
frankly that it could ever handle a 53c896 card, which could explain
it only seeing the 810a and not the 896 your boot disk is on.

You really want to use the sym53c8xx driver anyway - it is the one
being worked on in earnest now.  I believe it will pick up 810a
controllers as well.

(yes that's three ncr/symbios/lsi drivers in the kernel - "53c7,8xx",
"ncr53c8xx" and "sym53c8xx" ...)

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

BUG at buffer.c:1276! in 2.4.3-pre7

[Arthur Pedyczak]

The subject says it all. The bug got trigerred under _Heavy_ load
(bootstraping gcc ang building Xfree at the same time).


My hardware:
Motherboard: Asus P2B
CPU: P-III 600 (no overclocking)
RAM: 384 MB
IDE: PIIX4: IDE controller on PCI bus 00 dev 21
 PIIX4: chipset revision 1
 hda: WDC WD200BB-00AUA1, ATA DISK drive
 hdb: MATSHITA CR-589, ATAPI CD/DVD-ROM drive  (ide-scsi)
 hdc: WDC AC313000R, ATA DISK drive
 hdd: MITSBICDRW4420a, ATAPI CD/DVD-ROM drive  (ide-scsi)
eth0   : eepro100
eth1   : 3c590
sound  : es1370


Ksymoops output:

ksymoops 2.3.4 on i686 2.4.3-pre7.  Options used
 -v /usr/src/linux/vmlinux (specified)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.4.3-pre7/ (default)
 -m /usr/src/linux/System.map (specified)

Mar 25 17:12:33 cs865114-a kernel: invalid operand: 
Mar 25 17:12:33 cs865114-a kernel: CPU:0
Mar 25 17:12:33 cs865114-a kernel: EIP:0010:[set_bh_page+46/64]
Mar 25 17:12:33 cs865114-a kernel: EFLAGS: 00210286
Mar 25 17:12:33 cs865114-a kernel: eax: 001d   ebx: 1000   ecx:
0001   edx:
 
Mar 25 17:12:33 cs865114-a kernel: esi: c133cdec   edi: d5390c20   ebp:
   esp:
 c7947e50
Mar 25 17:12:33 cs865114-a kernel: ds: 0018   es: 0018   ss: 0018
Mar 25 17:12:33 cs865114-a kernel: Process fini (pid: 26089,
stackpage=c7947000)
Mar 25 17:12:33 cs865114-a kernel: Stack: c01fbdcf c01fbffa 04fc
c133cdec d5390c20
1000 c0133fc8 d5390c20
Mar 25 17:12:33 cs865114-a kernel:c133cdec 1000 c17a2260
c099e7e0 ce12c5c0
cde0f000 c4e993e0 c133cdec
Mar 25 17:12:33 cs865114-a kernel:2c28 c133cdec c0134219
c133cdec 
0001 c4e993e0 
Mar 25 17:12:33 cs865114-a kernel: Call Trace: [create_buffers+104/432]
[create_empty_b
uffers+25/112] [block_read_full_page+98/608] [__alloc_pages+228/720]
[do_generic_file_r
ead+817/1296] [ext2_get_block+0/1264] [generic_file_read+98/128]
Mar 25 17:12:33 cs865114-a kernel: Code: 0f 0b 83 c4 0c 8b 4e 3c 01 cb 89
5f 34 5b 5e 5
f c3 90 55 57
Using defaults from ksymoops -t elf32-i386 -a i386

Code;   Before first symbol
 <_EIP>:
Code;   Before first symbol
   0:   0f 0b ud2a
Code;  0002 Before first symbol
   2:   83 c4 0c  add$0xc,%esp
Code;  0005 Before first symbol
   5:   8b 4e 3c  mov0x3c(%esi),%ecx
Code;  0008 Before first symbol
   8:   01 cb add%ecx,%ebx
Code;  000a Before first symbol
   a:   89 5f 34  mov%ebx,0x34(%edi)
Code;  000d Before first symbol
   d:   5bpop%ebx
Code;  000e Before first symbol
   e:   5epop%esi
Code;  000f Before first symbol
   f:   5fpop%edi
Code;  0010 Before first symbol
  10:   c3ret
Code;  0011 Before first symbol
  11:   90nop
Code;  0012 Before first symbol
  12:   55push   %ebp
Code;  0013 Before first symbol
  13:   57push   %edi


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

2.4.2-ac24 Oops on boot

[Jure Pecar]

Got this right after entering init 3 at startup ...
Oops written from screen, so there might be typos.


ksymoops 2.3.4 on i686 2.4.0-test10.  Options used
 -V (specified)
 -K (specified)
 -l /proc/modules (default)
 -o /lib/modules/2.4.2-ac24/ (specified)
 -m /boot/System.map-2.4.2-ac24 (specified)

No modules in ksyms, skipping objects
No ksyms, skipping lsmod
Unable to handle kernel NULL pointer dereference at virtual address
0258
c0127d65
*pde = 
Oops: 0002
CPU: 0
EIP: 0010: []
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010003
eax: 080f18c0 ebx: d7889000 ecx: d7d4a000 edx: 0254
esi: e166fae8 edi: 0086 ebp:  esp: d7b53f78
Stack: d76d3c00 d7b52000 d7b52000  bd10 c011bf4f c166fae8
d7d4a040
   d7ee5180 c0117a4f d7b52000 d7b52000 d7b52000 0007 c0112070
d7b52000
   4013b378  c0108ee7   4013c1c8 4013b378

Call trace: [] [] [] []
Code: 89 42 04 89 10 8b 43 04 89 4b 04 89 19 89 41 04 89 08 eb 2e

>>EIP; c0127d65<=
Trace; c011bf4f 
Trace; c0117a4f 
Trace; c0112070 
Trace; c0108ee7 
Code;  c0127d65 
 <_EIP>:
Code;  c0127d65<=
   0:   89 42 04  mov%eax,0x4(%edx)   <=
Code;  c0127d68 
   3:   89 10 mov%edx,(%eax)
Code;  c0127d6a 
   5:   8b 43 04  mov0x4(%ebx),%eax
Code;  c0127d6d 
   8:   89 4b 04  mov%ecx,0x4(%ebx)
Code;  c0127d70 
   b:   89 19 mov%ebx,(%ecx)
Code;  c0127d72 
   d:   89 41 04  mov%eax,0x4(%ecx)
Code;  c0127d75 
  10:   89 08 mov%ecx,(%eax)
Code;  c0127d77 
  12:   eb 2e jmp42 <_EIP+0x42> c0127da7



My .config:#
# Automatically generated by make menuconfig: 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 is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
CONFIG_MK7=y
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MCYRIXIII 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=6
CONFIG_X86_TSC=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_USE_3DNOW=y
CONFIG_X86_PGE=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
# CONFIG_TOSHIBA is not set
# CONFIG_MICROCODE is not set
CONFIG_X86_MSR=y
# 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_APIC=y
# CONFIG_X86_UP_IOAPIC is not set
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 is not set
# CONFIG_PCMCIA is not set
CONFIG_SYSVIPC=y
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y
CONFIG_KCORE_ELF=y
# CONFIG_KCORE_AOUT is not set
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=y
# CONFIG_PM is not set
# CONFIG_ACPI is not set
# CONFIG_APM is not set

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

#
# Parallel port support
#
# CONFIG_PARPORT is not set

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

#
# 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 is not set
# CONFIG_BLK_DEV_INITRD is not set

#
# Multi-device support (RAID and LVM)
#
CONFIG_MD=y
CONFIG_BLK_DEV_MD=y
CONFIG_MD_LINEAR=m
CONFIG_MD_RAID0=y
CONFIG_MD_RAID1=y
CONFIG_MD_RAID5=m
CONFIG_BLK_DEV_LVM=m

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
# CONFIG_NETLINK is not set
# CONFIG_NETFILTER 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 is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_INET_ECN is not set
# CONFIG_SYN_COOKIES is not set
# 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_

via-rhine driver: wicked 2005 problem

[wing tung Leung]

Hello,

[Kernel 2.4.2, gcc-2.9.3 (same problem with egcs-2.91.66),
binutils-2.9.5.0.22-6]

[AMD Thunderbird, ABIT KT7A, no overclocking, D-Link DFE-530TX, 3Com
10Mbit hub, ATI Radeon AGP video, Matrox Mystique PCI video.]

When I download a big sized a few MB from the LAN using FTP, the hub
collision LED burns a lot, and after a few downloads the connection suddenly
hangs and syslog dumps:

Mar 25 16:44:03 localhost kernel: NETDEV WATCHDOG: eth0: transmit timed out 
Mar 25 16:44:03 localhost kernel: eth0: Transmit timed out, status , PHY
status 782d, resetting... 

I just need the restart the device using "/etc/rc.d/init.d/network restart"
and the connection is back. I just need to start a heavy download to initiate
the problem, uploading seems to work fine.

If I increase the debug level to 7, the logs contains:

Mar 25 16:44:01 localhost kernel: eth0: Transmit error, Tx status 8100. 
Mar 25 16:44:01 localhost kernel: eth0: Something Wicked happened! 2009. 
Mar 25 16:44:01 localhost kernel: eth0: exiting interrupt, status=0x. 
Mar 25 16:44:01 localhost kernel: eth0: Interrupt, status 0001. 
Mar 25 16:44:01 localhost kernel:  In via_rhine_rx(), entry 5 status 05ee8f00. 
Mar 25 16:44:01 localhost kernel:   via_rhine_rx() status is 05ee8f00. 
Mar 25 16:44:01 localhost kernel: eth0: exiting interrupt, status=0x. 

I tried the diagnostic utilities from Donald Becker at Scyld.com, but I don't
know what I should be looking for. The text output seems ok to me.

I also tried to move the network card into other PCI slots, even tried to
throw out the AGP and PCI video card, but with no succes. This is an extract
from /proc/pci, and I don't think see any IRQ conflict there.

  Bus  0, device  11, function  0:
Ethernet controller: VIA Technologies, Inc. Ethernet Controller (rev 67).
  IRQ 15.
  Master Capable.  Latency=32.  Min Gnt=3.Max Lat=8.
  I/O at 0xec00 [0xecff].
  Non-prefetchable 32 bit memory at 0xde00 [0xdeff].

Last fact: when using M$ Windows, I get comparable FTP speeds, without the
locking. The subjective collision rate is about the same. I also have the
problem to need a cold boot after having used Windows, the network card
completely refuses to send or/and receive before pulling the power cord. The
via-rhine module *does* recognize the card correctly, but just is not able
to use it.

I know this kind of issues have come up in the past, but I haven't found any
real solution in the archives. Please redirect me to it if it does exist.

Regards,

Tung

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

2.4.2 NINI_PARTITION

[goldencat]

msdos.c MINI_PARTITION underclared (first use in this function)
msdos.c MINI_NR_SUBPARTITIONS' undeclared (first use in this function)
check msdos.c msdos.h
can not find MINI_PARTITION/MINI_NR_SUBPARTITIONS
is this a bug?
-
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 2.4.3.7: net drvr probe fix

[Jeff Garzik]

The attached patch provides a solution for the problem where an
interface is not completely ready by the time /sbin/hotplug is called,
from init_etherdev.  The patch also includes semi-related cleanups and
fixes found along the way.

Changes:
* Add alloc_etherdev, alloc_fddidev, alloc_hippi_dev, alloc_trdev, alloc_fcdev
* Add register_hipdev for API completeness
* Add inline source docs for init_fddidev, init_hippi_dev, init_trdev,
  init_fcdev
* Move EXPORT_SYMBOL for public functions from net/netsyms.c to
  drivers/net/net_init.c.
* Remove duplicate code by making unregister_foo functions simply call
  unregister_netdev()
* Remove duplicate code by making register_foo functions simply call
  new static function __register_netdev()
* Propagate returned error codes in register_netdev()
* Rename private tr_configure() to public tr_setup(), and remove no-op
  tr_setup() function.



diff -u linux_2_4/drivers/net/net_init.c:1.1.1.8 
linux_2_4/drivers/net/net_init.c:1.1.1.8.38.2
--- linux_2_4/drivers/net/net_init.c:1.1.1.8Mon Feb 26 19:03:50 2001
+++ linux_2_4/drivers/net/net_init.cSun Mar 25 12:43:06 2001
@@ -28,10 +28,12 @@
up. We now share common code and have regularised name
allocation setups. Abolished the 16 card limits.
03/19/2000 - jgarzik and Urban Widmark: init_etherdev 32-byte align
+   03/21/2001 - jgarzik: alloc_etherdev and friends
 
 */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -68,6 +70,33 @@
 */
 
 
+static struct net_device *alloc_netdev(int sizeof_priv, const char *mask,
+  void (*setup)(struct net_device *))
+{
+   struct net_device *dev;
+   int alloc_size;
+
+   /* ensure 32-byte alignment of the private area */
+   alloc_size = sizeof (*dev) + sizeof_priv + 31;
+
+   dev = (struct net_device *) kmalloc (alloc_size, GFP_KERNEL);
+   if (dev == NULL)
+   {
+   printk(KERN_ERR "alloc_dev: Unable to allocate device memory.\n");
+   return NULL;
+   }
+
+   memset(dev, 0, alloc_size);
+
+   if (sizeof_priv)
+   dev->priv = (void *) (((long)(dev + 1) + 31) & ~31);
+
+   setup(dev);
+   strcpy(dev->name, mask);
+
+   return dev;
+}
+
 static struct net_device *init_alloc_dev(int sizeof_priv)
 {
struct net_device *dev;
@@ -142,6 +171,17 @@
return dev;
 }
 
+static int __register_netdev(struct net_device *dev)
+{
+   dev_init_buffers(dev);
+   
+   if (dev->init && dev->init(dev) != 0) {
+   unregister_netdev(dev);
+   return -EIO;
+   }
+   return 0;
+}
+
 /**
  * init_etherdev - Register ethernet device
  * @dev: An ethernet device structure to be filled in, or %NULL if a new
@@ -164,6 +204,25 @@
return init_netdev(dev, sizeof_priv, "eth%d", ether_setup);
 }
 
+/**
+ * alloc_etherdev - Register ethernet device
+ * @sizeof_priv: Size of additional driver-private structure to be allocated
+ * for this ethernet device
+ *
+ * Fill in the fields of the device structure with ethernet-generic values.
+ *
+ * Constructs a new net device, complete with a private data area of
+ * size @sizeof_priv.  A 32-byte (not bit) alignment is enforced for
+ * this private data area.
+ */
+
+struct net_device *alloc_etherdev(int sizeof_priv)
+{
+   return alloc_netdev(sizeof_priv, "eth%d", ether_setup);
+}
+
+EXPORT_SYMBOL(init_etherdev);
+EXPORT_SYMBOL(alloc_etherdev);
 
 static int eth_mac_addr(struct net_device *dev, void *p)
 {
@@ -184,11 +243,48 @@
 
 #ifdef CONFIG_FDDI
 
+/**
+ * init_fddidev - Register FDDI device
+ * @dev: A FDDI device structure to be filled in, or %NULL if a new
+ * struct should be allocated.
+ * @sizeof_priv: Size of additional driver-private structure to be allocated
+ * for this ethernet device
+ *
+ * Fill in the fields of the device structure with FDDI-generic values.
+ *
+ * If no device structure is passed, a new one is constructed, complete with
+ * a private data area of size @sizeof_priv.  A 32-byte (not bit)
+ * alignment is enforced for this private data area.
+ *
+ * If an empty string area is passed as dev->name, or a new structure is made,
+ * a new name string is constructed.
+ */
+
 struct net_device *init_fddidev(struct net_device *dev, int sizeof_priv)
 {
return init_netdev(dev, sizeof_priv, "fddi%d", fddi_setup);
 }
 
+/**
+ * alloc_fddidev - Register FDDI device
+ * @sizeof_priv: Size of additional driver-private structure to be allocated
+ * for this FDDI device
+ *
+ * Fill in the fields of the device structure with FDDI-generic values.
+ *
+ * Constructs a new net device, complete with a private data area of
+ * size @sizeof_priv.  A 32-byte (not bit) alignment is enforced for
+ * this private data area.
+ */
+
+struct net_device *alloc_fddidev(int sizeof_priv)
+{
+   return alloc_netdev(sizeof_priv, "fddi%d", fddi_setup);
+}
+
+EXPORT_SYMBOL(init_fddidev);

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

[LA Walsh]

Here is the 'alternate' output when the ncr53c8xx driver is
compiled in:

SCSI subsystem driver Revision: 1.00
scsi-ncr53c7,8xx : at PCI bus 0, device 8, function 0
scsi-ncr53c7,8xx : warning : revision of 35 is greater than 2.
scsi-ncr53c7,8xx : NCR53c810 at memory 0xfa101000, io 0x2000, irq 58
scsi0 : burst length 16
scsi0 : NCR code relocated to 0x37d6c610 (virt 0xf7d6c610)
scsi0 : test 1 started
scsi0 : NCR53c{7,8}xx (rel 17)
request_module[block-major-8]: Root fs not mounted
VFS: Cannot open root device "807" or 08:07
Please append a correct "root=" boot option
Kernel panic: VFS: Unable to mount root fs on 08:07
-
Note how this compares to the case where the driver is a module:

(note scsi0 was an IDE emulation in this setup -- something also removed in
the above setup)
ncr53c8xx: at PCI bus 0, device 8, function 0
ncr53c8xx: 53c810a detected
ncr53c8xx: at PCI bus 1, device 3, function 0
ncr53c8xx: 53c896 detected
ncr53c8xx: at PCI bus 1, device 3, function 1
ncr53c8xx: 53c896 detected
ncr53c810a-0: rev=0x23, base=0xfa101000, io_port=0x2000, irq=58
ncr53c810a-0: ID 7, Fast-10, Parity Checking
ncr53c810a-0: restart (scsi reset).
ncr53c896-1: rev=0x01, base=0xfe004000, io_port=0x3000, irq=57
ncr53c896-1: ID 7, Fast-40, Parity Checking
ncr53c896-1: on-chip RAM at 0xfe00
ncr53c896-1: restart (scsi reset).
ncr53c896-1: Downloading SCSI SCRIPTS.
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
ncr53c896-2: restart (scsi reset).
ncr53c896-2: Downloading SCSI SCRIPTS.
scsi1 : ncr53c8xx - version 3.2a-2
scsi2 : ncr53c8xx - version 3.2a-2
scsi3 : ncr53c8xx - version 3.2a-2
scsi : 4 hosts.
  Vendor: SEAGATE   Model: ST318203LCRev: 0002
  Type:   Direct-Access  ANSI SCSI revision: 02
Detected scsi disk sda at scsi2, channel 0, id 1, lun 0
  Vendor: SGI   Model: SEAGATE ST318203  Rev: 2710
  Type:   Direct-Access  ANSI SCSI revision: 02
Detected scsi disk sdb at scsi2, channel 0, id 2, lun 0
  Vendor: SGI   Model: SEAGATE ST336704  Rev: 2742


This is on a 4x550 PIII(Xeon) system.  The 2nd two 
controllers are on pci bus 1.  The boot disk is sda, which is off of
scsi2 in the working example, or scsi1 in the non-working example.

It seems that compiling it in somehow causes controllers
1 and 2 (which are off of the 2nd pci bus, "1", to get missed during 
scsi initialization.  Is there a parameter I need to pass to the 
ncr53c8xx driver to get it to scan the 2nd bus?
-
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/

mouse problems in 2.4.2

[linas]

Hi,

I am experiencing debilitating intermittent mouse problems & was about 
to dive into the kernel to see if I could debug it.  But first, I thought
a quick note to the mailing list may help.

Symptoms:
After a long time of flawless operation (ranging from nearly a week to 
as little as five minutes), the X11 pointer flies up to top-right corner, 
and mostly wants to stay there.  Moving the mouse causes a cascade of 
spurious button-press events get generated.

This did not occur with 2.4.0test2 or 2.2.16 (to the best of my
recollection) and first showed up in 2.4.0test7 or 2.4.1 (not sure).
With 2.4.2, the symptoms seem slightly different (almost all pointer
movement events seem to be lost; although spurious button-press events
still happen).

Mouse is a logitech trackman marble, with USB connector to
logitech-supplied USB to ps/2 DIN plug.  Configured as a PS/2 mouse.
Motherboard is a Athalon/VIA Apollo KA7.

Unplugging mouse for 10 seconds sometimes fixes the problem on the sixth
try, sometimes. 

Switching to virtual terminal running gpm, and back to X11 used to fix
the problem, sometimes, after some magic incantations, unplugging,
starting gpm, moving mouse, etc.  This no longer does the trick w/
2.4.2.

Rebooting X11 frequently, but not always, fixed the problem.

The *only* sure-fire fix is to reboot the system. 

Sometimes, the mouse seemed usable with gpm even as it wasn't with X11;
sometimes it had the same bad behaviour (scooting to the corner,
spurious button-press) even under gpm.

Changing mouse protocols to imps2 from ps2 in gpm/X11 seems to make no
difference.

Disabling power management in kernel and bios to various degrees (including 
disabling *all* power management) doesn't seem to fix anything.  (It
was suggested to me that this was an APM bug; indeed, an early
manifestation of the bug seemed to be that it triggered if/when I moved
the mouse just as the video-powersave triggered. )

Sometimes, the problem seems to be associated with moving the mouse
during CPU-intensive or disk-i/o intensive operations (e.g. a large 
file copy, compile; or system activity during mp3 playing) Lost
interrupt?

On rare ocasions, its associated with system lockup.  (specifically,
some keyboard buffer seems to fill up, and everything seems hung,  
not even ctrl-alt-del works).  (I haven't checked to see if I can 
still telnet in). 

I've been living with this problem for 6+ months, and it is getting to
be infuriating.  As you can see above, all sorts of different attempts
above make subtle variations in the symptoms, but no fixes.  

I conclude that this is probably a hardware (motherboard chipset)
bug, that its rare (google/deja  searches are unfruitful) and that 
the only place to hunt is in the kernel. 

---
So: any advice, comments, suggestions before I embark on a long and
possibly fruitless hunt?  Any recommendations for best tools/proceedures
to catch it 'in the act'?  

--linas

p.s. direct replies to [EMAIL PROTECTED] appreciated.



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

OK, now I'm in 2.4.3-pre7 plus your patch and serial as a module (it was
 built in kernel previously) and indeed I have my modem detected
 automatically by the PCMCIA startup sequence (I don't need to manually
 do anything).

I lost the IrDA port, though - ttyS2. Now I only see ttyS0 and ttyS4.


Thanks & ciao,

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

Linux:  kernel 2.2.19p18/2.4.3p7 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/

[TAKE3] [PATCH] non-overcommit memory, improved OOM handling, safetymargin (was Re: Prevent OOM from killing init)

[Jonathan Morton]

Ugh, something was going screwy.  Trying from a different machine.

--

The attached patch is against 2.4.1 and incorporates the following:

- More optimistic OOM checking, and slightly improved OOM-kill algorithm,
as per my previous patch.

- Accounting of reserved memory, allowing for...

- Non-overcommittal of memory if sysctl_overcommit_memory < 0, enforced
even for root if < -1 (as per old non-overcommittal patch for 2.3.99, but
fixed).

- Behaviour when sysctl_overcommit_memory == 0 or 1 is as per my original
patch (eg. soft-limited overcommittal and full overcommittal
respectively). Defaults to -1.

- If a process is larger than 4 times the free VM on the system, it is not
allowed to allocate or reserve any more, unless overcomittal is allowed as
above.  Note that root may have less privilege to hog memory when
sysctl_overcommit_memory == 0 than when == -1.

- As part of the above, a new function vm_invalidate_totalmem() is
available which should be called whenever the total amount of VM changes -
at the moment this is done in sys_swap{on,off}().  This is to avoid having
to recalculate the amount of available memory and swap whenever an
allocation is needed.  If someone knows a better way, let me know.



diff -ur -x via-rhine* linux-2.4.1.orig/fs/exec.c linux/fs/exec.c
--- linux-2.4.1.orig/fs/exec.c  Tue Jan 30 07:10:58 2001
+++ linux/fs/exec.c Sun Mar 25 17:05:03 2001
@@ -385,19 +385,27 @@
 static int exec_mmap(void)
 {
struct mm_struct * mm, * old_mm;
+   struct task_struct * tsk = current;
+   unsigned long reserved = 0;
 
-   old_mm = current->mm;
+   old_mm = tsk->mm;
if (old_mm && atomic_read(&old_mm->mm_users) == 1) {
+   /* Keep old stack reservation */
mm_release();
exit_mmap(old_mm);
return 0;
}
 
+   reserved = vm_enough_memory(tsk->rlim[RLIMIT_STACK].rlim_cur >> 
+   PAGE_SHIFT);
+   if(!reserved)
+   return -ENOMEM;
+
mm = mm_alloc();
if (mm) {
-   struct mm_struct *active_mm = current->active_mm;
+   struct mm_struct *active_mm = tsk->active_mm;
 
-   if (init_new_context(current, mm)) {
+   if (init_new_context(tsk, mm)) {
mmdrop(mm);
return -ENOMEM;
}
@@ -422,6 +430,8 @@
mmdrop(active_mm);
return 0;
}
+
+   vm_release_memory(reserved);
return -ENOMEM;
 }
 
diff -ur -x via-rhine* linux-2.4.1.orig/fs/proc/proc_misc.c linux/fs/proc/proc_misc.c
--- linux-2.4.1.orig/fs/proc/proc_misc.cTue Nov  7 19:08:09 2000
+++ linux/fs/proc/proc_misc.c   Sun Mar 25 16:57:07 2001
@@ -175,7 +175,9 @@
 "LowTotal: %8lu kB\n"
 "LowFree:  %8lu kB\n"
 "SwapTotal:%8lu kB\n"
-"SwapFree: %8lu kB\n",
+"SwapFree:  %8lu kB\n"
+"VMTotal:   %8lu kB\n"
+"VMReserved:%8lu kB\n",
 K(i.totalram),
 K(i.freeram),
 K(i.sharedram),
@@ -190,7 +192,9 @@
 K(i.totalram-i.totalhigh),
 K(i.freeram-i.freehigh),
 K(i.totalswap),
-K(i.freeswap));
+K(i.freeswap),
+K(vm_total()), 
+K(vm_reserved));
 
return proc_calc_metrics(page, start, off, count, eof, len);
 #undef B
diff -ur -x via-rhine* linux-2.4.1.orig/include/linux/mm.h linux/include/linux/mm.h
--- linux-2.4.1.orig/include/linux/mm.h Tue Jan 30 07:24:56 2001
+++ linux/include/linux/mm.hSun Mar 25 16:57:07 2001
@@ -24,6 +24,13 @@
 #include 
 
 /*
+ * These are used to prevent VM overcommit.
+ */
+extern unsigned long vm_reserved;
+extern spinlock_t vm_lock;
+extern inline unsigned long vm_total(void);
+
+/*
  * Linux kernel virtual memory manager primitives.
  * The idea being to have a "virtual" mm in the same way
  * we have a virtual fs - giving a cleaner interface to the
@@ -444,6 +451,14 @@
 extern unsigned long do_brk(unsigned long, unsigned long);
 
 struct zone_t;
+
+extern long vm_enough_memory(long pages);
+extern inline void vm_release_memory(long pages) {
+   int flags;
+   spin_lock_irqsave(&vm_lock, flags);
+   vm_reserved -= pages;
+   spin_unlock_irqrestore(&vm_lock, flags);
+}
 /* filemap.c */
 extern void remove_inode_page(struct page *);
 extern unsigned long page_unuse(struct page *);
diff -ur -x via-rhine* linux-2.4.1.orig/include/linux/sched.h 
linux/include/linux/sched.h
--- linux-2.4.1.orig/include/linux/sched.h  Tue Jan 30 07:24:56 2001
+++ linux/include/linux/sched.h Sun Mar 25 16:57:07 2001
@@ -424,9 +424,9 @@
 
 /*
  * Limit the stack by to some sane default: root can always
- * increase th

Re: Non keyboard trigger of Alt-SysRQ-S-U-B

[Keith Owens]

On Sun, 25 Mar 2001 10:27:28 -0600, 
Nathan Neulinger <[EMAIL PROTECTED]> wrote:
>Is there any way that this can be triggered remotely? I frequently get
>into situations with a particular machine where 'reboot' or 'reboot -f'
>just plain won't work, and would like to be able do a 'filesystem clean'
>forcible reboot, but don't particularly care about services being shut
>down cleanly. Of course, the key is, I'm not at the keyboard of the
>server in question.

If you have a serial console on the server, you can get sysrq by
sending a serial break followed by the character.  See
drivers/char/serial.c on any 2.4 kernel.  Otherwise you could hack up a
module that calls handle_sysrq() directly.  Unless you are sending a
character that needs regs ('p'), kbd ('r') or tty ('k'), you can set
those parameters to NULL.  Any unrecognised character will try to use
kbd and tty parameters.

-
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] [REPOST] non-overcommit memory, improved OOM handling,safety margin (was Re: Prevent OOM from killing init)

[Jonathan Morton]

ACK!  that last diff got linewrapped somewhere in transit.  Try this one...

-

The attached patch is against 2.4.1 and incorporates the following:

- More optimistic OOM checking, and slightly improved OOM-kill algorithm,
as per my previous patch.

- Accounting of reserved memory, allowing for...

- Non-overcommittal of memory if sysctl_overcommit_memory < 0, enforced
even for root if < -1 (as per old non-overcommittal patch for 2.3.99, but
fixed).

- Behaviour when sysctl_overcommit_memory == 0 or 1 is as per my original
patch (eg. soft-limited overcommittal and full overcommittal respectively).
Defaults to -1.

- If a process is larger than 4 times the free VM on the system, it is not
allowed to allocate or reserve any more, unless overcomittal is allowed as
above.  Note that root may have less privilege to hog memory when
sysctl_overcommit_memory == 0 than when == -1.

- As part of the above, a new function vm_invalidate_totalmem() is
available which should be called whenever the total amount of VM changes -
at the moment this is done in sys_swap{on,off}().  This is to avoid having
to recalculate the amount of available memory and swap whenever an
allocation is needed.  If someone knows a better way, let me know.


diff -ur -x via-rhine* linux-2.4.1.orig/fs/exec.c linux/fs/exec.c
---
linux-2.4.1.orig/fs/exec.c  Tue Jan 30 07:10:58 2001
+++
linux/fs/exec.c Sun Mar 25 17:05:03 2001
@@ -385,19 +385,27 @@
 static int
exec_mmap(void)
 {
struct mm_struct * mm, * old_mm;
+   struct
task_struct * tsk = current;
+   unsigned long reserved = 0;
 
-   old_mm =
current->mm;
+   old_mm = tsk->mm;
if (old_mm &&
atomic_read(&old_mm->mm_users) == 1) {
+   /* Keep old stack
reservation */
mm_release();
exit_mmap(old_mm);

return 0;
}
 
+   reserved =
vm_enough_memory(tsk->rlim[RLIMIT_STACK].rlim_cur >> 
+
PAGE_SHIFT);
+   if(!reserved)
+   return -ENOMEM;
+

mm = mm_alloc();
if (mm) {
-   struct mm_struct
*active_mm = current->active_mm;
+   struct mm_struct *active_mm
= tsk->active_mm;
 
-   if (init_new_context(current, mm)) {
+
if (init_new_context(tsk, mm)) {

mmdrop(mm);
return -ENOMEM;

}
@@ -422,6 +430,8 @@
mmdrop(active_mm);

return 0;
}
+
+   vm_release_memory(reserved);
return
-ENOMEM;
 }
 
diff -ur -x via-rhine* linux-2.4.1.orig/fs/proc/proc_misc.c
linux/fs/proc/proc_misc.c
--- linux-2.4.1.orig/fs/proc/proc_misc.cTue
Nov  7 19:08:09 2000
+++ linux/fs/proc/proc_misc.c   Sun Mar 25 16:57:07
2001
@@ -175,7 +175,9 @@
 "LowTotal: %8lu kB\n"

"LowFree:  %8lu kB\n"
 "SwapTotal:%8lu kB\n"
-
"SwapFree: %8lu kB\n",
+"SwapFree:  %8lu kB\n"
+
"VMTotal:   %8lu kB\n"
+"VMReserved:%8lu kB\n",

K(i.totalram),
 K(i.freeram),

K(i.sharedram),
@@ -190,7 +192,9 @@

K(i.totalram-i.totalhigh),
 K(i.freeram-i.freehigh),

K(i.totalswap),
-K(i.freeswap));
+
K(i.freeswap),
+K(vm_total()), 
+
K(vm_reserved));
 
return proc_calc_metrics(page, start, off, count,
eof, len);
 #undef B
diff -ur -x via-rhine*
linux-2.4.1.orig/include/linux/mm.h linux/include/linux/mm.h
---
linux-2.4.1.orig/include/linux/mm.h Tue Jan 30 07:24:56 2001
+++
linux/include/linux/mm.hSun Mar 25 16:57:07 2001
@@ -24,6 +24,13
@@
 #include 
 
 /*
+ * These are used to prevent VM
overcommit.
+ */
+extern unsigned long vm_reserved;
+extern spinlock_t
vm_lock;
+extern inline unsigned long vm_total(void);
+
+/*
  * Linux
kernel virtual memory manager primitives.
  * The idea being to have a
"virtual" mm in the same way
  * we have a virtual fs - giving a cleaner
interface to the
@@ -444,6 +451,14 @@
 extern unsigned long do_brk(unsigned
long, unsigned long);
 
 struct zone_t;
+
+extern long
vm_enough_memory(long pages);
+extern inline void vm_release_memory(long
pages) {
+   int flags;
+   spin_lock_irqsave(&vm_lock, flags);
+
vm_reserved -= pages;
+   spin_unlock_irqrestore(&vm_lock, flags);
+}

/* filemap.c */
 extern void remove_inode_page(struct page *);
 extern
unsigned long page_unuse(struct page *);
diff -ur -x via-rhine*
linux-2.4.1.orig/include/linux/sched.h linux/include/linux/sched.h
---
linux-2.4.1.orig/include/linux/sched.h  Tue Jan 30 07:24:56 2001
+++
linux/include/linux/sched.h Sun Mar 25 16:57:07 2001
@@ -424,9 +424,9
@@
 
 /*
  * Limit the stack by to some sane default: root can always
- *
increase this limit if needed..  8MB seems reasonable.
+ * increase this
limit if needed..  2MB should be more than enough.
  */
-#define _STK_LIM
(8*1024*1024)
+#define _STK_LIM   (2*1024*1024)
 
 #define
DEF_COUNTER (10*HZ/100) /* 100 ms time slice */
 #define
MAX_COUNTER (20*HZ

2.2.17-RAID: Eating memory

[John Plate]

Hi

I have patched the 2.2.17 kernel (Debian) with the "new RAID" patches
with no errors.

I experienced a the following problem:

Two partitions are set up as RAID-1, but not yet fully
created/initialized. On boot, the process starts/continues
automatically (partitions /dev/hda3 and /dev/hdc3 set to type "Linux
raid autodetect", but not mounted in /etc/fstab).

/proc/mdstat says: 
md2 : active raid1 hdc3[1] hda3[0] 4723008 blocks [2/2] [UU]
resync=11% finish=77.3min

While this is active, I start an rsync between two other partitions
(/dev/hda1 and /dev/hdc1). This should be fine because RAID is
expected to work in background only. After a while the system reports
on the console a lot of "VM: do_try_to_free_pages failed" for many of
the daemon programs running. Before that, the swap usage increases but
there is enough swap space.

I guess that this is some kind of race condition because the RAID
program runs fine with no other heavy load. The rsync also behaves
well under other circumstances. I expect the problem to be with the
RAID code. 

The system is stable, it has never crashed. This is my first problem
with a Linux kernel.

Can anyone please help?
-- 
John Plate 
-
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] non-overcommit memory, improved OOM handling, safetymargin (was Re: Prevent OOM from killing init)

[Jonathan Morton]

The attached patch is against 2.4.1 and incorporates the following:

- More optimistic OOM checking, and slightly improved OOM-kill algorithm,
as per my previous patch.

- Accounting of reserved memory, allowing for...

- Non-overcommittal of memory if sysctl_overcommit_memory < 0, enforced
even for root if < -1 (as per old non-overcommittal patch for 2.3.99, but
fixed).

- Behaviour when sysctl_overcommit_memory == 0 or 1 is as per my original
patch (eg. soft-limited overcommittal and full overcommittal respectively).
Defaults to -1.

- If a process is larger than 4 times the free VM on the system, it is not
allowed to allocate or reserve any more, unless overcomittal is allowed as
above.  Note that root may have less privilege to hog memory when
sysctl_overcommit_memory == 0 than when == -1.

- As part of the above, a new function vm_invalidate_totalmem() is
available which should be called whenever the total amount of VM changes -
at the moment this is done in sys_swap{on,off}().  This is to avoid having
to recalculate the amount of available memory and swap whenever an
allocation is needed.  If someone knows a better way, let me know.


diff -ur -x via-rhine* linux-2.4.1.orig/fs/exec.c linux/fs/exec.c
---
linux-2.4.1.orig/fs/exec.c  Tue Jan 30 07:10:58 2001
+++
linux/fs/exec.c Sun Mar 25 17:05:03 2001
@@ -385,19 +385,27 @@
 static int
exec_mmap(void)
 {
struct mm_struct * mm, * old_mm;
+   struct
task_struct * tsk = current;
+   unsigned long reserved = 0;
 
-   old_mm =
current->mm;
+   old_mm = tsk->mm;
if (old_mm &&
atomic_read(&old_mm->mm_users) == 1) {
+   /* Keep old stack
reservation */
mm_release();
exit_mmap(old_mm);

return 0;
}
 
+   reserved =
vm_enough_memory(tsk->rlim[RLIMIT_STACK].rlim_cur >> 
+
PAGE_SHIFT);
+   if(!reserved)
+   return -ENOMEM;
+

mm = mm_alloc();
if (mm) {
-   struct mm_struct
*active_mm = current->active_mm;
+   struct mm_struct *active_mm
= tsk->active_mm;
 
-   if (init_new_context(current, mm)) {
+
if (init_new_context(tsk, mm)) {

mmdrop(mm);
return -ENOMEM;

}
@@ -422,6 +430,8 @@
mmdrop(active_mm);

return 0;
}
+
+   vm_release_memory(reserved);
return
-ENOMEM;
 }
 
diff -ur -x via-rhine* linux-2.4.1.orig/fs/proc/proc_misc.c
linux/fs/proc/proc_misc.c
--- linux-2.4.1.orig/fs/proc/proc_misc.cTue
Nov  7 19:08:09 2000
+++ linux/fs/proc/proc_misc.c   Sun Mar 25 16:57:07
2001
@@ -175,7 +175,9 @@
 "LowTotal: %8lu kB\n"

"LowFree:  %8lu kB\n"
 "SwapTotal:%8lu kB\n"
-
"SwapFree: %8lu kB\n",
+"SwapFree:  %8lu kB\n"
+
"VMTotal:   %8lu kB\n"
+"VMReserved:%8lu kB\n",

K(i.totalram),
 K(i.freeram),

K(i.sharedram),
@@ -190,7 +192,9 @@

K(i.totalram-i.totalhigh),
 K(i.freeram-i.freehigh),

K(i.totalswap),
-K(i.freeswap));
+
K(i.freeswap),
+K(vm_total()), 
+
K(vm_reserved));
 
return proc_calc_metrics(page, start, off, count,
eof, len);
 #undef B
diff -ur -x via-rhine*
linux-2.4.1.orig/include/linux/mm.h linux/include/linux/mm.h
---
linux-2.4.1.orig/include/linux/mm.h Tue Jan 30 07:24:56 2001
+++
linux/include/linux/mm.hSun Mar 25 16:57:07 2001
@@ -24,6 +24,13
@@
 #include 
 
 /*
+ * These are used to prevent VM
overcommit.
+ */
+extern unsigned long vm_reserved;
+extern spinlock_t
vm_lock;
+extern inline unsigned long vm_total(void);
+
+/*
  * Linux
kernel virtual memory manager primitives.
  * The idea being to have a
"virtual" mm in the same way
  * we have a virtual fs - giving a cleaner
interface to the
@@ -444,6 +451,14 @@
 extern unsigned long do_brk(unsigned
long, unsigned long);
 
 struct zone_t;
+
+extern long
vm_enough_memory(long pages);
+extern inline void vm_release_memory(long
pages) {
+   int flags;
+   spin_lock_irqsave(&vm_lock, flags);
+
vm_reserved -= pages;
+   spin_unlock_irqrestore(&vm_lock, flags);
+}

/* filemap.c */
 extern void remove_inode_page(struct page *);
 extern
unsigned long page_unuse(struct page *);
diff -ur -x via-rhine*
linux-2.4.1.orig/include/linux/sched.h linux/include/linux/sched.h
---
linux-2.4.1.orig/include/linux/sched.h  Tue Jan 30 07:24:56 2001
+++
linux/include/linux/sched.h Sun Mar 25 16:57:07 2001
@@ -424,9 +424,9
@@
 
 /*
  * Limit the stack by to some sane default: root can always
- *
increase this limit if needed..  8MB seems reasonable.
+ * increase this
limit if needed..  2MB should be more than enough.
  */
-#define _STK_LIM
(8*1024*1024)
+#define _STK_LIM   (2*1024*1024)
 
 #define
DEF_COUNTER (10*HZ/100) /* 100 ms time slice */
 #define
MAX_COUNTER (20*HZ/100)
diff -ur -x via-rhine*
linux-2.4.1.orig/kernel/exit.c linux/kernel/exit.c
---

question on /dev/tap0

[James Stevenson]

Hi

would somebody be able to explain to me
when you try to open /dev/tap0 which is a
character device file which has the permissions

File: "tap0"
Size: 0Filetype: Character Device
Mode: (0666/crw-rw-rw-)

when tried to open

[mistral@linux /dev]$ cat tap0
cat: tap0: Operation not permitted

and strace shows that it gets a permission error
open("tap0", O_RDONLY|0x8000)   = -1 EPERM

is it just me or is this either
a) a bug
b) very misleading

thanks
James

-- 
-
Check Out: http://stev.org
E-Mail: [EMAIL PROTECTED]
 10:50pm  up 58 min,  3 users,  load average: 0.30, 0.11, 0.03

-
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 05:30 PM 3/25/01 +0200, you wrote:
> > Ultra reliable systems dont contain memory allocators. There are good 
> reasons
> > for this but the design trade offs are rather hard to make in a real world
> > environment
>
>I esp. they run on CPU's without a stack or what?

No dynamic memory allocation AT ALL.  That includes the prohibition of a 
stack.  I've seen avionics-loop systems that abstract a stack but the 
"allocators" are part of the application and are designed to fall over 
gracefully when they become full -- but getting this past a project manager 
is hard, as it should be.

Then there are those systems with rather interesting watchdog timers.  If 
you don't tickle them just right, they fire and force a restart.  The 
nastiest of these required that you send four specific values to a specific 
I/O port, and the hardware looked to see if the values violated certain 
timing guidelines.  If you sent the code too early or too late, or if the 
value in the sequence was incorrect, BAM.  The hardware was designed by a 
guy with some rather interesting experiences with software "engineers" 
dealing with watchdog timers...

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: IP ROUTE and multi-path route splitting

[Matthew G. Marsh]

On Tue, 20 Mar 2001, Richard A Nelson wrote:

[snip]
> $ ip addr show tr0
> 5: tr0:  mtu 2000 qdisc pfifo_fast qlen 100
>link/[800] 40:00:de:ad:be:ef brd ff:ff:ff:ff:ff:ff
>inet 9.51.81.11/21 brd 9.51.87.255 scope link tr0
>inet6 fe80::4000:dead:beef/10 scope link
>inet6 fe80::4200:deff:fead:beef/10 scope link
> 
> $ ip addr show tr1
> 6: tr1:  mtu 2000 qdisc pfifo_fast qlen 100
> link/[800] 00:06:29:b0:59:63 brd ff:ff:ff:ff:ff:ff
> inet 9.51.81.9/21 brd 9.51.87.255 scope link tr1
> inet6 fe80::206:29ff:feb0:5963/10 scope link
> inet6 fe80::6:29b0:5963/10 scope link

Npte that all ipv4 addresses on the system when leaving the system as
locally originated will appear to leave lo first. So to control them
with rules use the following type of structure:

ip rule add from 9.51.81.11 dev lo table 1 prio 1
ip rule add from 9.51.81.9  dev lo table 2 prio 2

This will capture all originated traffic (such as host responses to pings
etc...) from each address and send it to a different table. Then you can
populate the tables as needed. 
 
[snip]

> If I change the default route thusly:
> $ ip route add default metric 1 src 9.51.81.11 \
>   nexthop via 9.51.80.1 dev tr0 nexthop via 9.51.80.1 dev tr1
> 
> Then things work fine, incomming requests are processed as normal, but
> it appears that outgoing requests are always sent via dev tr0

"appears" as in 'ip link sh dev tr1' never increases... or as in a tcpdump
on the ring only shows ip src 9.51.81.11 ? Please supply the info if
possible as I suspect that that both tr interfaces are being used but the
src command is honored thus the src addresses will always look to be tr0. 

IE: look at 'ip -s link show' and see if both tr0 and tr1 are increasing
the packets sent...
 
> If I leave off the src argument, then incomming smtp sessions to dev tr0
> (9.51.81.11) are not properly handled - I'm guessing because the src address
> could be that dev tr1 (9.51.81.9).
> of tr1

Yes. In this case you could try variations on the rules above with both
route tables having the same default route with different src statements
but I suspect that is not exactly what you want.
 
> What am I misunderstanding...  What I was trying to achieve was:
>  *) Incomming requests are handled on whatever interface the're received on
>  *) Outgoing requests are handled on either interface

Your confusion stems from the fact that the ipv4 addresses are _not_
assigned to the interfaces per se but actually 'exist' as a definition of
a service (ipv4 transport) to the machine itself. Consider DECnetIV type
addressing with multiply connected hosts...  
 
> Is this more than can be done via ip route ?

No - but it is usually not seen for two cards connected to the same
physical network ;-}

> -- 
> Rick Nelson
> Life'll kill ya -- Warren Zevon
> Then you'll be dead -- Life'll kill ya

--
Matthew G. Marsh,  President
Paktronix Systems LLC
1506 North 59th Street
Omaha  NE  68104
Phone: (402) 932-7250
Email: [EMAIL PROTECTED]
WWW:  http://www.paktronix.com
--

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

Re: Larger dev_t

[diego]

On Sun, 25 Mar 2001, Guest section DW wrote:

> On Sun, Mar 25, 2001 at 05:35:01PM +0200, Wichert Akkerman wrote:
> > In article <[EMAIL PROTECTED]>,
> >  <[EMAIL PROTECTED]> wrote:
> > >a large name space allows one to omit checking what part can be
> > >reused - reuse is unnecessary.
> > 
> > You are just delaying the problem then, at some point your uptime will
> > be large enough that you have run through all 64bit pids for example.
> > 
> > Wichert.
> 
> Yes indeed. If my box, after continually spawning 10 processes
> per second for 500 years crashes because pid_t overflows, I'll think
> about whether I should put the test back in, or should upgrade to a
> 128-bit machine.

this is a no point thread, we are not going to live 500 years? a 64 bits
space is more that we are going to need anyway...

Juan Diego

-
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: new aic7xxx driver needs berkeley db?

[Justin T. Gibbs]

>Hi All,
>  I notice that the new aic7xxx driver in 2.4.3-pre7 needs some version
>of the berkeley db.  (the make file has -ldb1 in it).  It blew
>up on my because I apparently don't have it installed.  

Use the latest version of the driver from here:

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

It will only compile the fimware if you ask it.

Hopefully this will make it into the next pre kernel.

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

Re: Linux 2.4.2-ac24

[Chris Liebman]

I am using the Orinoco gold card in a Thinkpad A21p.  I have been using the
wvlan_cs module for this card.  I attempted to use the new orinoco_cs
driver, I updated /etc/pcmcia/config to have the "device wvlan_cs" use the
new orinoco_cs module rather than the old wvlan_cs.  The card is recognized
and the orinoco_cs module is loaded but the module fails to initialize the card. I am 
using pcmcia-cs-3.1.24 and linux-2.4.2-ac24.  Here are the entries from 
/var/log/messages.  Any ideas?  (like just forget it ;-)

Mar 24 18:42:28 xyzzy cardmgr[928]: initializing socket 0
Mar 24 18:42:28 xyzzy cardmgr[928]: socket 0: Lucent Technologies WaveLAN/IEEE Adapter
Mar 24 18:42:28 xyzzy cardmgr[928]: executing: 'modprobe orinoco_cs'
Mar 24 18:42:28 xyzzy kernel: hermes.c: 12 Dec 2000 David Gibson 
<[EMAIL PROTECTED]>
Mar 24 18:42:28 xyzzy kernel: dldwd: David's Less Dodgy WaveLAN/IEEE Driver
Mar 24 18:42:29 xyzzy cardmgr[928]: get dev info on socket 0 failed: Resource 
temporarily unavailable
Mar 24 18:42:30 xyzzy cardmgr[928]: exiting

-- Chris

- Original Message -
From: "Alan Cox" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, March 23, 2001 8:29 PM
Subject: Linux 2.4.2-ac24


>
> ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/
>
> Intermediate diffs are available from
>
> http://www.bzimage.org
>
> (Note that the cmsfs port to 2.4 is a work in progress)
>
> 2.4.2-ac24
> o Fix build bug with tsc in ac23 (me)
> o Update contact info for Phil Blundell (Phil Blundell)
> o Update mm locking comments/rss locking (Andrew Morton)
> o Update toshiba SMM driver (Jonathan Buzzard)
> o Update old adaptec driver to 5.2.4 (Doug Ledford)
> o CS46xx updates (Tom Woller)
> o Quieten input layer printks a bit (me)
> o Turn off APIC_DEBUG by default to cut noise down(me)
> o Add Orinoco PCMCIA wireless support (David Gibson)
> o Go back to 2.4.3pre6 tulip (Jeff Garzik)
> o Fix double accounting of cpu time bug (Kevin Buhr)
> o Drop ppp patch (me)
>
> 2.4.2-ac23
> o Fix a nasty shared memory locking bug (Stephen Tweedie)
> o Fix off by one bootmem memory corruptor (Ben LaHaise)
> o Fix avmb1 oops on init (Carsten Paeth)
> o Fix isdn makefile bugs (Kai Germaschewski)
> o Clean up isdn minor checks (Julien Gaulmin)
> o Workaround PPP CCP negotiation bugs (Kai Germaschewski)
> o Fix timer handling bug in ISDN (Henk-Jan Slotboom)
> o Fix i386 #ifdef bug with notsc disable (Anton Blanchard)
> o Fix NMI docs (Keith Owens)
> o Fix oops on out of memory in proc_symlink (me)
> | Found by Stanford tools
> o Fix oops caused by devfs changes to soundcore (me)
> | Found by Stanford tools
> o Fix rmmod crash on sundance alta (me)
> | Found by Stanford tools
> o Fix potential crash in nsc-ircc.c (me)
> | Found by Stanford tools
> o Fix memory leak in i810 audio (Doug Ledford)
> o Fix several compile warnings with gcc 3.0 cvs (J Magallon)
> o Mark 60Hz modes in mac fb modes (Geert Uytterhoeven)
> o Chkconfig and ver_linux updates (Niels Jensen)
> o Fix ctrlfb dac timing (Takashi Oe)
> o Add vesa powerdown support for ctrlfb (Takashi Oe)
> o Back out problem via bridge change (me)
> o Fix bug in aironet4500_cs changes (Arjan van de Ven)
>
> 2.4.2-ac22
> o Fix dereference after free in megaraid driver (me)
> o Fix crash if we run out of memory during a link (me)
> follow [found by Stanford tools]
> o Fix crash if we run out of memory during
> block_truncate_page [found by Stanford tools] (me)
> o Update Alpha to pre6 style pte/pmd_alloc (Ivan Kokshaysky)
> o Fix ppp memory corruption (Kevin Buhr)
> | Bizzarely enough a direct re-invention of a 1.2 ppp bug
> o Fix heavy stack usage in tty_foo_devfs() (Jeff Dike)
> o Make alloc_tty_struct always use kmalloc (Andrew Morton)
> o Document task struct locking rules (Andrew Morton)
> o Document SAK properly (Andrew Morton)
> o Fix SAK deadlocks (Andrew Morton)
> o Fix inline/type order for picky compiler tools (Dave Jones)
> o Fix printk levels for various fs printks that (Andrey Panin)
> lacked them
> o Next incarnation of the i810 audio driver (Doug Ledford)
> o Add __init stuff to 3c515 driver (Andrzej Krzysztofowicz)
> o Add __init stuff to ppp layer (Andrzej Krzysztofowicz)
> o Remove duplicate NF_TARGET_TCPMSS config text (Steven Cole)
> o Fix missing unlock_kernel in pcwd (me)
> | Found by Stanford tools
> o Fix missing unlock_kernels in es1371 (me)
> | Found by Stanford tools
> o Fix missing unlock_kernels in es1370 (me)
> | Found by Stanford tools
> o Fix missing unlock_kernels in esssolo1 (me)
> | Found by Stanford tools
> o Fix missing unlock kernels in sonicvibes (me)
> | Found by Stanford tools
> o Fix missing unlock kernels in fb mmap (me)
> | Found by Stanford tools
> o Fix missing unlock_super in UFS code (me)
> | Found by Stanford tools
>
>
> 2.4.2-ac21
> o Merge with Linus 2.4.3pre6
> o Close last known reiserfs tail bug (Chris Mason)
> o Fix link order bug with iso8859_8 and cp1255 (Dan Aloni)
> o Generate generic CPU namings for 386/486 (Cesar Eduardo Barros)

Re: [patch] pae-2.4.3-A4

[Ingo Molnar]

On Sun, 25 Mar 2001, Linus Torvalds wrote:

> So my suggestion for PAE is:
>
>  - populate in gdb_alloc() (ie just do the three "alloc_page()" calls to
>allocate the PMD's immediately)
>
>NOTE: This makes the race go away, and will actually speed things up as
>we will pretty much in practice always populate the PGD _anyway_, the
>way the VM areas are laid out.
>
>  - make "pgd_present()" always return 1.
>
>NOTE: This will speed up the page table walkers anyway. It will also
>avoid the problem above.
>
>  - make "free_pmd()" a no-op.
>
> All of the above will (a) simplify things (b) remove special cases and
> (c) remove actual and existing bugs.

yep, this truly makes things so much easier and cleaner! There was only
one thing missing to make it work:

   - make "pgd_clear()" a no-op.

[the reason for the slightly more complex pgd_alloc_slow() code is to
support non-default virtual memory splits as well, where the number of
user pgds is not necesserily 3.]

plus i took to opportunity to reduce the allocation size of PAE-pgds.
Their size is only 32 bytes, and we allocated a full page. Now the code
kmalloc()s a 32 byte cacheline for the pgd. (there is a hardware
constraint on alignment: this cacheline must be at least 16-byte aligned,
which is true for the current kmalloc() code.) So the per-process cost is
reduced by almost 4 KB.

and i got rid of pgalloc-[2|3]level.h - with the pmds merged into the pgd
logic the algorithmic difference between 2-level and this pseudo-3-level
PAE paging is not that big anymore. The pgtable-[2|3]level.h files are
still separate.

the attached pae-2.4.3-B2 patch (against 2.4.3-pre7) compiles & boots just
fine both in PAE and non-PAE mode. The patch removes 217 lines, and adds
only 78 lines.

Ingo


--- linux/include/asm-i386/pgalloc-3level.h.origSun Mar 25 18:55:05 2001
+++ linux/include/asm-i386/pgalloc-3level.h Sun Mar 25 22:38:41 2001
@@ -1,45 +0,0 @@
-#ifndef _I386_PGALLOC_3LEVEL_H
-#define _I386_PGALLOC_3LEVEL_H
-
-/*
- * Intel Physical Address Extension (PAE) Mode - three-level page
- * tables on PPro+ CPUs. Page-table allocation routines.
- *
- * Copyright (C) 1999 Ingo Molnar <[EMAIL PROTECTED]>
- */
-
-extern __inline__ pmd_t *pmd_alloc_one(void)
-{
-   pmd_t *ret = (pmd_t *)__get_free_page(GFP_KERNEL);
-
-   if (ret)
-   memset(ret, 0, PAGE_SIZE);
-   return ret;
-}
-
-extern __inline__ pmd_t *pmd_alloc_one_fast(void)
-{
-   unsigned long *ret;
-
-   if ((ret = pmd_quicklist) != NULL) {
-   pmd_quicklist = (unsigned long *)(*ret);
-   ret[0] = 0;
-   pgtable_cache_size--;
-   } else
-   ret = (unsigned long *)get_pmd_slow();
-   return (pmd_t *)ret;
-}
-
-extern __inline__ void pmd_free_fast(pmd_t *pmd)
-{
-   *(unsigned long *)pmd = (unsigned long) pmd_quicklist;
-   pmd_quicklist = (unsigned long *) pmd;
-   pgtable_cache_size++;
-}
-
-extern __inline__ void pmd_free_slow(pmd_t *pmd)
-{
-   free_page((unsigned long)pmd);
-}
-
-#endif /* _I386_PGALLOC_3LEVEL_H */
--- linux/include/asm-i386/pgalloc.h.orig   Sun Mar 25 18:56:25 2001
+++ linux/include/asm-i386/pgalloc.hSun Mar 25 23:11:23 2001
@@ -11,37 +11,56 @@
 #define pte_quicklist (current_cpu_data.pte_quick)
 #define pgtable_cache_size (current_cpu_data.pgtable_cache_sz)
 
-#define pmd_populate(pmd, pte) set_pmd(pmd, __pmd(_PAGE_TABLE + __pa(pte)))
-
-#if CONFIG_X86_PAE
-# include 
-#else
-# include 
-#endif
+#define pmd_populate(pmd, pte) \
+   set_pmd(pmd, __pmd(_PAGE_TABLE + __pa(pte)))
 
 /*
- * Allocate and free page tables. The xxx_kernel() versions are
- * used to allocate a kernel page table - this turns on ASN bits
- * if any.
+ * Allocate and free page tables.
  */
 
+#if CONFIG_X86_PAE
+
+extern void *kmalloc(size_t, int);
+extern void kfree(const void *);
+
 extern __inline__ pgd_t *get_pgd_slow(void)
 {
-   pgd_t *ret = (pgd_t *)__get_free_page(GFP_KERNEL);
+   int i;
+   pgd_t *pgd = kmalloc(PTRS_PER_PGD * sizeof(pgd_t), GFP_KERNEL);
+
+   if (pgd) {
+   for (i = 0; i < USER_PTRS_PER_PGD; i++) {
+   unsigned long pmd = __get_free_page(GFP_KERNEL);
+   if (!pmd)
+   goto out_oom;
+   clear_page(pmd);
+   set_pgd(pgd + i, __pgd(1 + __pa(pmd)));
+   }
+   memcpy(pgd + USER_PTRS_PER_PGD, swapper_pg_dir + USER_PTRS_PER_PGD, 
+(PTRS_PER_PGD - USER_PTRS_PER_PGD) * sizeof(pgd_t));
+   }
+   return pgd;
+out_oom:
+   for (i--; i >= 0; i--)
+   free_page((unsigned long)__va(pgd_val(pgd[i])-1));
+   kfree(pgd);
+   return NULL;
+}
 
-   if (ret) {
-#if CONFIG_X86_PAE
-   int i;
-   for (i = 0; i < USER_PTRS_PER_PGD; i+

oops in 2.4.2-23 in pipe_write

[Eric Buddington]

These oopsen were invoked by a normal shell script. Hope you can make
some use of it. Processor is a K6/2.

-Eric

--

ksymoops 2.4.1 on i586 2.4.2-ac23.  Options used
 -V (default)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.4.2-ac23/ (default)
 -m /boot/System.map-2.4.2-ac23-k6 (specified)

Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(shmem_file_setup) not 
found in System.map.  Ignoring ksyms_base entry
Unable to handle kernel NULL pointer dereference at virtual address 0014
c013880e
*pde = 
Oops: 
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010246
eax:    ebx: c034c440   ecx: c2efd460   edx: c034c440
esi: c2efd400   edi:    ebp: 0015   esp: c7489f7c
ds: 0018   es: 0018   ss: 0018
Process sed (pid: 5898, stackpage=c7489000)
Stack: c034c440 ffea  0015 c2efd460 fe00  400f7000 
   c012fd5a c034c440 400f7000 0015 c034c460 c7488000 0015 400f7000 
   bba4 c0108d33 0001 400f7000 0015 0015 400f7000 bba4 
Call Trace: [] [] 
Code: 83 7f 14 00 0f 84 08 02 00 00 c7 44 24 1c 01 00 00 00 81 fd 

>>EIP; c013880e<=
Trace; c012fd5a 
Trace; c0108d33 
Code;  c013880e 
 <_EIP>:
Code;  c013880e<=
   0:   83 7f 14 00   cmpl   $0x0,0x14(%edi)   <=
Code;  c0138812 
   4:   0f 84 08 02 00 00 je 212 <_EIP+0x212> c0138a20 
Code;  c0138818 
   a:   c7 44 24 1c 01 00 00  movl   $0x1,0x1c(%esp,1)
Code;  c013881f 
  11:   00 
Code;  c0138820 
  12:   81 fd 00 00 00 00 cmp$0x0,%ebp

 <1>Unable to handle kernel NULL pointer dereference at virtual address 0014
c013880e
*pde = 
Oops: 
CPU:0
EIP:0010:[]
EFLAGS: 00010246
eax:    ebx: c3621120   ecx: c36aa2c0   edx: c3621120
esi: c36aa260   edi:    ebp: 0015   esp: c0e69f7c
ds: 0018   es: 0018   ss: 0018
Process sed (pid: 5945, stackpage=c0e69000)
Stack: c3621120 ffea  0015 c36aa2c0 fe00  400f7000 
   c012fd5a c3621120 400f7000 0015 c3621140 c0e68000 0015 400f7000 
   bba4 c0108d33 0001 400f7000 0015 0015 400f7000 bba4 
Call Trace: [] [] 
Code: 83 7f 14 00 0f 84 08 02 00 00 c7 44 24 1c 01 00 00 00 81 fd 

>>EIP; c013880e<=
Trace; c012fd5a 
Trace; c0108d33 
Code;  c013880e 
 <_EIP>:
Code;  c013880e<=
   0:   83 7f 14 00   cmpl   $0x0,0x14(%edi)   <=
Code;  c0138812 
   4:   0f 84 08 02 00 00 je 212 <_EIP+0x212> c0138a20 
Code;  c0138818 
   a:   c7 44 24 1c 01 00 00  movl   $0x1,0x1c(%esp,1)
Code;  c013881f 
  11:   00 
Code;  c0138820 
  12:   81 fd 00 00 00 00 cmp$0x0,%ebp


1 warning issued.  Results may not be reliable.

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

Re: [PATCH] Prevent OOM from killing init

[Jonathan Morton]

>> 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.
>
>Great.  I haven't seen your patch yet as my gateway ate it's very last
>disk.  I look forward to reading it.

I'm currently investigating the old non-overcommit patch, which (apart from
needing manual applying to recent kernels) appears to be rather broken in a
trivial way.  It prevents allocation if total reserved memory is greater
than the total unallocated memory.  Let me say that again, a different way
- it prevents memory usage from exceeding 50%...

Is there a fast way of getting total VM size?  Eg. equivalent to the
following code:

si_meminfo(&i);
si_swapinfo(&i);
free = i.totalram + i.totalswap;

If not, I have to do some jiggery to keep good performance along with true
non-overcommittance.

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

[Guest section DW]

On Sun, Mar 25, 2001 at 05:35:01PM +0200, Wichert Akkerman wrote:
> In article <[EMAIL PROTECTED]>,
>  <[EMAIL PROTECTED]> wrote:
> >a large name space allows one to omit checking what part can be
> >reused - reuse is unnecessary.
> 
> You are just delaying the problem then, at some point your uptime will
> be large enough that you have run through all 64bit pids for example.
> 
> Wichert.

Yes indeed. If my box, after continually spawning 10 processes
per second for 500 years crashes because pid_t overflows, I'll think
about whether I should put the test back in, or should upgrade to a
128-bit machine.

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

[Guest section DW]

On Sun, Mar 25, 2001 at 01:32:42AM +0100, Kurt Garloff wrote:
> 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 ...

Yes. I investigated and found rpm's data base corrupted, and rpm cannot handle
that. Since I have several occurrences of rpm being killed by the oom killer
in my logs it is entirely possible that the data base got corrupted because
rpm was killed while in the process of updating 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] pae-2.4.3-A4

[Linus Torvalds]

On Sun, 25 Mar 2001, Ingo Molnar wrote:
>
> one nontrivial issue was that on PAE the pgd has to be installed with
> 'present' pgd entries, due to a CPU erratum. This means that the
> pgd_present() code in mm/memory.c, while correct theoretically, doesnt
> work with PAE. An equivalent solution is to use !pgd_none(), which also
> works with the PAE workaround.

Note that due to the very same erratum, we really should populate the PGD
from the very beginning. See the other thread about how we currently
fail to properly invalidate the TLB on other CPU's when we add a new PGD
entry, exactly because the other CPU's are caching the "nonexistent" PGD
entry that we just replaced.

So my suggestion for PAE is:

 - populate in gdb_alloc() (ie just do the three "alloc_page()" calls to
   allocate the PMD's immediately)

   NOTE: This makes the race go away, and will actually speed things up as
   we will pretty much in practice always populate the PGD _anyway_, the
   way the VM areas are laid out.

 - make "pgd_present()" always return 1.

   NOTE: This will speed up the page table walkers anyway. It will also
   avoid the problem above.

 - make "free_pmd()" a no-op.

All of the above will (a) simplify things (b) remove special cases and (c)
remove actual and existing bugs.

(In fact, the reason why the PGD populate missing TLB invalidate probably
never happens in practice is exactly the fact that the PGD is always
populated so fast that it's hard to make a test-case that shows this. But
it's still a bug - probably fairly easily triggered by a threaded program
that is statically linked (so that the code loads at 0x4000 and
doesn't have the loader linked low - so the lowest PGD entry is not
allocated until later).

Does anybody see any problems with the above? It looks like the obvious
fix.

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/

new aic7xxx driver needs berkeley db?

[Todd M. Roy]

Hi All,
  I notice that the new aic7xxx driver in 2.4.3-pre7 needs some version
of the berkeley db.  (the make file has -ldb1 in it).  It blew
up on my because I apparently don't have it installed.  


  .~.  Todd Roy, Senior Database Administrator  .~.
  /V\ Holstein Association, U.S.A. Inc. /V\ 
 // \\   [EMAIL PROTECTED] // \\  
/(   )\ 1-802-254-4551x4230   /(   )\
 ^^-^^ ^^-^^
-
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/

new aic7xxx needs berkeley db?

[Todd M. Roy]

Hi All,
  I notice that the new aic7xxx driver needs some version
of the berkekey db.  (the make file has -ldb1 in it).  It blew
up on my because I apparently don't have it installed.  
-- 
  .~.  Todd Roy, Senior Database Administrator  .~.
  /V\ Holstein Association, U.S.A. Inc. /V\ 
 // \\   [EMAIL PROTECTED] // \\  
/(   )\ 1-802-254-4551x4230   /(   )\
 ^^-^^ ^^-^^
-
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

[Gerry]

Ok, i don't really know much about the kernel at all, but here's my opinion 
anyway..

To use 64bit pids when 32bit is enough just to "make things easier" doesn't 
sound like a good idea to me. Eventually it might wrap around (fx. as on that 
supercomputer Jamie Lokier talked about) to overwrite running processes, and 
cause death and destruction. Bye bye stability.

Even if it doesn't wrap, using double the space necessarry for something 
every single process has is a waste of space. Linux is supposed to be able to 
run on a large range of systems, and some of them don't have that kind of 
luxury. Sure, the kernel can be modified for those (rare) cases, but still, 
using something that's not necessary just sounds like bad practice to me.. 

Never assume luxury..

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/

Re: [PATCH] OOM handling

[Rik van Riel]

On Sun, 25 Mar 2001, Martin Dalecki wrote:
> Rik van Riel wrote:

> > - the AGE_FACTOR calculation will overflow after the system has
> >   an uptime of just _3_ days
> 
> I esp. the behaviour will be predictable.

U ?

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

[Michel Wilson]

> Ever heard of cut-and-paste? Surely you can afford a mouse... And 
> for when 
> you you are not inputting manually but running a script/whatever, 
> who cares 
> what the numbers are...
> 
> Cheers,
> 
>  Anton
Oops. Okay, you're right.

-
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

[Jeff Garzik]

Michel Wilson wrote:
> Ever thought about how you would kill a process: kill -9 127892752 doesn't
> sound very appealing to me.

man killall(1).  Kill processes by name.

> So you'd also need to implement a mechanism that allows for 'easy' selection
> of processes to kill, for example giving every process with the same name
> a unique identifier (like httpd_0, httpd_1, httpd_2 and so on).

huh?

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

Re: Larger dev_t

[Jamie Lokier]

Mitchell Blank Jr wrote:
> Wichert Akkerman wrote:
> > You are just delaying the problem then, at some point your uptime will
> > be large enough that you have run through all 64bit pids for example.
> 
> 64 bits is enough to fork 1 million processes per second for over
> 500,000 years.  I think that's putting the problem off far enough.

The year is 2006.  IBM's latest supercluster has 1000 boxes, each with 4
x 8-way SMT processors running at 1THz.  Dense optical interconnect
provides NUMA-style cache coherency, and the entire system runs like a
giant SMP box (using kernel data structure replication).  Each active
thread is able to clone() 500,000,000 threads per second, in a pid space
shared throughout the cluster.

A virus arrives containing while(1){clone();}

Engineers observe pid wraparound approximately 2 weeks later :-)

-- Jamie
-
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: ACPI power-off doesn't work on Asus CUV4X (VIA Apollo 133)

[Ingo Oeser]

On Sat, Mar 24, 2001 at 10:53:08PM +0100, Ingo Oeser wrote:
> 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.
> > 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?
 
Just left it in FYI, Andrew.

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

Ok, that worked. Backing out all the changes made it shutdown
again.

Since this shouldn't by the right way to fix this problem, what
else can I do Andrew?

The BIG Problem is: This is an embedded machine, so I cannot
attach all the funny debug tools. The most thing I can do is
printk and evtl. ikdb. I have only 16MB flash disk on this
machine and it is full already :-(

Regards

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

Re: [PATCH] Prevent OOM from killing init

[Mike Galbraith]

On Sat, 24 Mar 2001, Jonathan Morton wrote:

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

Great.  I haven't seen your patch yet as my gateway ate it's very last
disk.  I look forward to reading it.

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

[Anton Altaparmakov]

At 17:54 25/03/2001, Michel Wilson wrote:
> > Wichert Akkerman wrote:
> > > You are just delaying the problem then, at some point your uptime will
> > > be large enough that you have run through all 64bit pids for example.
> >
> > 64 bits is enough to fork 1 million processes per second for over
> > 500,000 years.  I think that's putting the problem off far enough.
> >
> > -Mitch
> > -
>Ever thought about how you would kill a process: kill -9 127892752 doesn't
>sound very appealing to me.
>So you'd also need to implement a mechanism that allows for 'easy' selection
>of processes to kill, for example giving every process with the same name
>a unique identifier (like httpd_0, httpd_1, httpd_2 and so on).

Ever heard of cut-and-paste? Surely you can afford a mouse... And for when 
you you are not inputting manually but running a script/whatever, who cares 
what the numbers are...

Cheers,

 Anton


-- 
Anton Altaparmakov  (replace at with @)
Linux NTFS Maintainer / WWW: http://sourceforge.net/projects/linux-ntfs/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

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

[Jamie Lokier]

Jakob Østergaard wrote:
> 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 ?

On this theme, some garbage collectors like to write-protect individual
pages, to detect which pages are modified between generations.  The
kernel has never handled this especially well.  It could be argued that
mprotect() and signal() aren't the right way to get this information
though, and it would be better to add a different mechanism.

-- Jamie
-
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 Sat, Mar 24, 2001 at 10:05:18PM -0300, Rik van Riel wrote:
> 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.

But it doesn't --- page_launder can try to lock the page after it
checks the refcount, without taking any locks which protect us against
running lookup_swap_cache in parallel.  If we get our reference after
page_launder checks the count, we can find the page getting locked out
from underneath our feet.

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

Exactly.  We're not in danger of _losing_ the page, because
reclaim_page is locked more aggressively than page_launder.  We still
risk having the page locked against us after lookup_swap_cache does
its own UnlockPage.

So, if lookup_swap_cache doesn't actually ensure that the page is
unlocked, are there any callers which implicitly rely on
lookup_swap_cache() doing a wait_on_page?

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

[Michel Wilson]

> Wichert Akkerman wrote:
> > You are just delaying the problem then, at some point your uptime will
> > be large enough that you have run through all 64bit pids for example.
>
> 64 bits is enough to fork 1 million processes per second for over
> 500,000 years.  I think that's putting the problem off far enough.
>
> -Mitch
> -
Ever thought about how you would kill a process: kill -9 127892752 doesn't
sound very appealing to me.
So you'd also need to implement a mechanism that allows for 'easy' selection
of processes to kill, for example giving every process with the same name
a unique identifier (like httpd_0, httpd_1, httpd_2 and so on).

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

>[  about non-overcommit  ]
>> > Nobody feels its very important because nobody has implemented it.
>
>Enterprises use other systems because they have much better resource
>management than Linux -- adding non-overcommit wouldn't help them much.
>Desktop users, Linux newbies don't understand what's
>eager/early/non-overcommit vs lazy/late/overcommit memory management
>[just see these threads here if you aren't bored already enough ;)] and
>even if they do at last they don't have the ability to implement it. And
>between them, people are mostly fine with ulimit.
>
>> Small correction - It was implemented, just not included in the standard
>> kernel.
>
>Please note, adding optional non-overcommit also wouldn't help much
>without guaranteed/reserved resources [e.g. you are OOM -> appps, users
>complain, admin login in and BANG OOM killer just killed one of the
>jobs]. This was one of the reasons I made the reserved root memory
>patch [this is also the way other OS'es do]. Now just the different
>patches should be merged and write an OOM FAQ for users how to avoid,
>control, etc it].

I'm currently trying to apply the 2.3.99.whatever non-overcommit patch to
2.4.1 - decidedly nontrivial, lots of failed hunks, parts of the kernel
have changed significantly even in this (fairly short) time.

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

[Guest section DW]

On Sat, Mar 24, 2001 at 02:57:27AM -0300, Rik van Riel wrote:
> On Fri, 23 Mar 2001, Guest section DW wrote:
> > On Fri, Mar 23, 2001 at 11:56:23AM -0300, Rik van Riel wrote:
> > > On Fri, 23 Mar 2001, Martin Dalecki wrote:
> > 
> > > > > Feel free to write better-working code.
> > > > 
> > > > I don't get paid for it and I'm not idling through my days...
> > > 
> > >   
> > 
> > No lies please.
> 
> You mean that you ARE willing to implement what you've been
> arguing for?

There had not been any such response by me -
thus you should not ascribe to me such a response.

Concerning overcommit: people tell me that Eduardo Horvath
in his patch submitted to l-k on 2000-03-31 already solved
the problem (entirely or to a large extent).

: This patch will prevent the linux kernel from allowing VM overcommit.

I have not yet read the code.

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: [patch] pae-2.4.3-A4

[Russell King]

On Sun, Mar 25, 2001 at 04:53:37PM +0200, Ingo Molnar wrote:
> one nontrivial issue was that on PAE the pgd has to be installed with
> 'present' pgd entries, due to a CPU erratum. This means that the
> pgd_present() code in mm/memory.c, while correct theoretically, doesnt
> work with PAE. An equivalent solution is to use !pgd_none(), which also
> works with the PAE workaround.

Certainly that's the way the original *_alloc routines used to work.
In fact, ARM never had need to implement the pmd_present() macros, since
they were never referenced - only the pmd_none() macros were.

However, I'm currently struggling with this change on ARM - so far after
a number of hours trying to kick something into shape, I've not managed
to even get to the stange where I get a kernel image to link, let alone
the compilation to finish.

One of my many dilemas at the moment is how to allocate the page 0 PMD
in pgd_alloc(), where we don't have a mm_struct to do the locking against.

--
Russell King ([EMAIL PROTECTED])The developer of ARM Linux
 http://www.arm.linux.org.uk/personal/aboutme.html

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

Re: [PATCH] OOM handling

[Jonathan Morton]

>> I didn't quite understand Martin's comments about "not normalised" -
>> presumably this is some mathematical argument, but what does this actually
>> mean?
>
>Not mathematics. It's from physics. Very trivial physics, basic scool
>indeed.
>If you try to calculate some weightning
>factors which involve different units (in this case mostly seconds and
>bits)
>then you will have to make sure tha those units get factorized out.
>Rik is just throwing the absolute values together...

Understood - my Physics courses covered this as well, but not using the
word "normalise".

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

console.c unblank_screen problem

[Benjamin Herrenschmidt]

There is a problem with the power management code for console.c

The current code calls do_blank_screen(0); on PM_SUSPEND, and
unblank_screen() on PM_RESUME.

The problem happens when X is the current display while putting the
machine to sleep. The do_blank_screen(0) code will do nothing as
the console is not in KD_TEXT mode.
However, unblank_screen has no such protection. That means that
on wakeup, the cursor timer & console blank timers will be re-enabled
while X is frontmost, causing the blinking cursor to be displayed on
top of X, and other possible issues.

I hacked the following pacth to work around this. It appear to work
fine, but since the console code is pretty complex, I'm not sure about
possible side effects and I'd like some comments before submiting it
to Linus:

(Don't worry about the {} I added, I just noticed them and will remove
them before submitting ;)

--- 1.2/drivers/char/console.c  Sat Feb 10 18:54:15 2001
+++ edited/drivers/char/console.c   Sun Mar 25 17:57:46 2001
@@ -2595,8 +2595,9 @@
int currcons = fg_console;
int i;
 
-   if (console_blanked)
+   if (console_blanked) {
return;
+   }
 
/* entering graphics mode? */
if (entering_gfx) {
@@ -2660,12 +2661,16 @@
printk("unblank_screen: tty %d not allocated ??\n", fg_console+1);
return;
}
+   currcons = fg_console;
+   if (vcmode != KD_TEXT) {
+   console_blanked = 0;
+   return;
+   }
console_timer.function = blank_screen;
if (blankinterval) {
mod_timer(&console_timer, jiffies + blankinterval);
}
 
-   currcons = fg_console;
console_blanked = 0;
if (console_blank_hook)
console_blank_hook(0);


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

Re: Larger dev_t

[Mitchell Blank Jr]

Wichert Akkerman wrote:
> You are just delaying the problem then, at some point your uptime will
> be large enough that you have run through all 64bit pids for example.

64 bits is enough to fork 1 million processes per second for over
500,000 years.  I think that's putting the problem off far enough.

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

Non keyboard trigger of Alt-SysRQ-S-U-B

[Nathan Neulinger]

Is there any way that this can be triggered remotely? I frequently get
into situations with a particular machine where 'reboot' or 'reboot -f'
just plain won't work, and would like to be able do a 'filesystem clean'
forcible reboot, but don't particularly care about services being shut
down cleanly. Of course, the key is, I'm not at the keyboard of the
server in question.

I figured there may be some way to have a module do this, but if anyone
has any ideas, I'd appreciate it. I did see the example sent not too
long ago about triggering a panic, but that won't cleanly unmount the
filesystems. 

-- Nathan


Nathan Neulinger   EMail:  [EMAIL PROTECTED]
University of Missouri - Rolla Phone: (573) 341-4841
CIS - Systems ProgrammingFax: (573) 341-4216
-
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] pae-2.4.3-A4

[Ingo Molnar]

On Mon, 19 Mar 2001, Linus Torvalds wrote:

> The complete changelog is appended, but the biggest recent change is
> the mmap_sem change, which I updated with new locking rules for
> pte/pmd_alloc to avoid the race on the actual page table build.
>
> This has only been tested on i386 without PAE, and is known to break
> other architectures. Ingo, mind checking what PAE needs? [...]

one nontrivial issue was that on PAE the pgd has to be installed with
'present' pgd entries, due to a CPU erratum. This means that the
pgd_present() code in mm/memory.c, while correct theoretically, doesnt
work with PAE. An equivalent solution is to use !pgd_none(), which also
works with the PAE workaround.

PAE mode could re-define pgd_present() to filter out the workaround - do
you prefer this to the !pgd_none() solution?

the rest was pretty straightforward.

in any case, with the attached pae-2.4.3-A4 patch (against 2.4.3-pre7,
applies to 2.4.2-ac24 cleanly as well) applied, 2.4.3-pre7 boots & works
just fine on PAE 64GB-HIGHMEM and non-PAE kernels.

- the patch also does another cleanup: removes various bad_pagetable code
  snippets all around the x86 tree, it's not needed anymore. This saves 8
  KB RAM on x86 systems.

- removed the last remaining *_kernel() macro.

- fixed a minor clear_page() bug in pgalloc.h, gfp() could fail in the
  future.

Ingo


--- linux/mm/memory.c.orig  Sun Mar 25 18:55:05 2001
+++ linux/mm/memory.c   Sun Mar 25 18:55:07 2001
@@ -1295,7 +1295,7 @@
 * Because we dropped the lock, we should re-check the
 * entry, as somebody else could have populated it..
 */
-   if (pgd_present(*pgd)) {
+   if (!pgd_none(*pgd)) {
pmd_free(new);
goto out;
}
@@ -1313,7 +1313,7 @@
  */
 pte_t *pte_alloc(struct mm_struct *mm, pmd_t *pmd, unsigned long address)
 {
-   if (!pmd_present(*pmd)) {
+   if (pmd_none(*pmd)) {
pte_t *new;
 
/* "fast" allocation can happen without dropping the lock.. */
@@ -1329,7 +1329,7 @@
 * Because we dropped the lock, we should re-check the
 * entry, as somebody else could have populated it..
 */
-   if (pmd_present(*pmd)) {
+   if (!pmd_none(*pmd)) {
pte_free(new);
goto out;
}
--- linux/include/asm-i386/pgalloc-3level.h.origSun Mar 25 18:55:05 2001
+++ linux/include/asm-i386/pgalloc-3level.h Sun Mar 25 19:23:02 2001
@@ -21,12 +21,12 @@
 {
unsigned long *ret;
 
-   if ((ret = pmd_quicklist) != NULL) {
+   ret = pmd_quicklist;
+   if (ret != NULL) {
pmd_quicklist = (unsigned long *)(*ret);
ret[0] = 0;
pgtable_cache_size--;
-   } else
-   ret = (unsigned long *)get_pmd_slow();
+   }
return (pmd_t *)ret;
 }
 
@@ -41,5 +41,10 @@
 {
free_page((unsigned long)pmd);
 }
+
+#define pmd_free(pmd) pmd_free_fast(pmd)
+
+#define pgd_populate(pgd, pmd) \
+   do { set_pgd(pgd, __pgd(1 + __pa(pmd))); __flush_tlb(); } while(0)
 
 #endif /* _I386_PGALLOC_3LEVEL_H */
--- linux/include/asm-i386/pgalloc.h.orig   Sun Mar 25 18:56:25 2001
+++ linux/include/asm-i386/pgalloc.hSun Mar 25 19:35:59 2001
@@ -11,7 +11,8 @@
 #define pte_quicklist (current_cpu_data.pte_quick)
 #define pgtable_cache_size (current_cpu_data.pgtable_cache_sz)
 
-#define pmd_populate(pmd, pte) set_pmd(pmd, __pmd(_PAGE_TABLE + __pa(pte)))
+#define pmd_populate(pmd, pte) \
+   set_pmd(pmd, __pmd(_PAGE_TABLE + __pa(pte)))
 
 #if CONFIG_X86_PAE
 # include 
@@ -72,7 +73,8 @@
pte_t *pte;
 
pte = (pte_t *) __get_free_page(GFP_KERNEL);
-   clear_page(pte);
+   if (pte)
+   clear_page(pte);
return pte;
 }
 
@@ -100,7 +102,6 @@
free_page((unsigned long)pte);
 }
 
-#define pte_free_kernel(pte)   pte_free_slow(pte)
 #define pte_free(pte)  pte_free_slow(pte)
 #define pgd_free(pgd)  free_pgd_slow(pgd)
 #define pgd_alloc()get_pgd_fast()
--- linux/include/asm-i386/pgtable.h.orig   Sun Mar 25 19:03:58 2001
+++ linux/include/asm-i386/pgtable.hSun Mar 25 19:04:06 2001
@@ -243,12 +243,6 @@
 /* page table for 0-4MB for everybody */
 extern unsigned long pg0[1024];
 
-/*
- * Handling allocation failures during page table setup.
- */
-extern void __handle_bad_pmd(pmd_t * pmd);
-extern void __handle_bad_pmd_kernel(pmd_t * pmd);
-
 #define pte_present(x) ((x).pte_low & (_PAGE_PRESENT | _PAGE_PROTNONE))
 #define pte_clear(xp)  do { set_pte(xp, __pte(0)); } while (0)
 
--- linux/arch/i386/mm/init.c.orig  Sun Mar 25 19:02:05 2001
+++ linux/arch/i386

Re: [PATCH] Prevent OOM from killing init

[Szabolcs Szakacsits]

On Sat, 24 Mar 2001, Jesse Pollard wrote:
> On Fri, 23 Mar 2001, Alan Cox wrote:
[  about non-overcommit  ]
> > Nobody feels its very important because nobody has implemented it.

Enterprises use other systems because they have much better resource
management than Linux -- adding non-overcommit wouldn't help them much.
Desktop users, Linux newbies don't understand what's
eager/early/non-overcommit vs lazy/late/overcommit memory management
[just see these threads here if you aren't bored already enough ;)] and
even if they do at last they don't have the ability to implement it. And
between them, people are mostly fine with ulimit.

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

Please note, adding optional non-overcommit also wouldn't help much
without guaranteed/reserved resources [e.g. you are OOM -> appps, users
complain, admin login in and BANG OOM killer just killed one of the
jobs]. This was one of the reasons I made the reserved root memory
patch [this is also the way other OS'es do]. Now just the different
patches should be merged and write an OOM FAQ for users how to avoid,
control, etc it].

Szaka

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

Re: [PATCH] OOM handling

[Martin Dalecki]

Jonathan Morton wrote:
> 
> >- the AGE_FACTOR calculation will overflow after the system has
> >  an uptime of just _3_ days
> 
> Tsk tsk tsk...
> 
> >Now if you can make something which preserves the heuristics which
> >serve us so well on desktop boxes and add something that makes it
> >also work on your Oracle servers, then I'd be interested.
> 
> What do people think of my "adjustments" to the existing algorithm?  Mostly
> it gives extra longevity to low-UID and long-running processes, which to my
> mind makes sense for both server and desktop boxen.
> 
> Taking for example an 80Mb process under my adjustments, it is reduced to
> under the badness of a new shell process after less than a week's uptime
> (compared to several months), especially if it is run as low-UID.  Small,
> short-lived interactive processes still don't get *too* adversely affected,
> but a memory hog with only a few hours' uptime will still get killed with
> high probability (pretty much what we want).
> 
> I didn't quite understand Martin's comments about "not normalised" -
> presumably this is some mathematical argument, but what does this actually
> mean?

Not mathematics. It's from physics. Very trivial physics, basic scool
indeed.
If you try to calculate some weightning
factors which involve different units (in this case mostly seconds and
bits)
then you will have to make sure tha those units get factorized out.
Rik is just throwing the absolute values together...

Trivial example:
"How long does it take to travel from A to B?"
"It takes about 1000sec."
"How long does it take to travel from C to D?"
"It takes about  100sec."
"Ah, so it's 10 times longer from A to B then from C to D".

Write it down - you just divide the seconds out.

In case of varying intervalls you have to normalize
measures by max/min values. Since for example the
amount of RAM in a box can vary as well. Otherwise
your algorithms will behave very differently on boxes
with low RAM in comparision to boxes with huge amounts of
it. That's what one says if he talks about an
algorithm "scalling well".
-
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]

>> >start your app, wait for malloc to fail, hit enter for the other app and
>> >watch you app to be OOM killed ;)
>>
>> That would only happen if memory_overcommit was turned on, in which case my
>> modification would have zero effect anyway (the overcommit test happens
>> before my code).
>
>Thanks for listening and trying out the above trivial code instead of
>wrong theoretical arguments ;)
>
>So again, Linux *always* overcommit memory, the
>/proc/sys/vm/overcommit_memory controls total overcommit or
>quasi-overcommit [ehen you make your check in vm_enough() the memory is
>already overcommitted].

OK, looks like I got mixed up between *reservation* (malloc) and
*allocation* (access), and we're checking allocated memory when we should
really be checking reserved.  Be patient - I haven't done much of this type
of thing...  but your argument turns out to be correct, and I eventually
figured it out for myself.  I certainly agree that the default should be to
assume that all reserved memory will be used.  Maybe even do little nasty
things like printk(KERN_WARN "root is overcommitting memory!\n"); in
appropriate places, to discourage overcommitting.

>The solution is something like,
>add optional non-overcommit support,
>   http://lwn.net/2000/0406/a/no-overcommit.html

This sounds like a good solution.  Saw the size of the patch, it's big and
touches lots of bits of VM code, but it looks as though parts of my ideas
will also fit in there and be helpful.

Hmm... so we get an adjusted or replaced OOM-kill-selection algorithm, my
out_of_memory() fix and runaway process clamp, and this big(ish)
memory-accounting patch.  Sounds like a good combination to me, fixing all
the problems I've heard about recently.

There are some unrelated performance problems I've encountered during my
testing (eg. kswapd gets incredibly inefficient when swap usage grows
beyond about 500Mb on my 256Mb physical machine, causing swap bandwidth to
fall way below the HDs' capabilities), which I'm going to ignore for now.
Probably whoever takes on the VM balancing problem can look into that, as
it's probably related to that rather than this...

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

[Jeff Garzik]

Martin Dalecki wrote:
> Rik van Riel wrote:
> > - the comments are just too rude  ;)
> >   (though fun)
> 
> That's only a matter for the "smooth" anglosaxons. Different
> cultures have different measures on this. I don't feel the need
> to adjust myself to the american cultural obstructivity.
> I esp. to the habit of don't saying clearly what one means if one
> want's to criticize something.

Rik should know that lkml and the kernel sources are in no way
politically correct...  Fuck 'em... :)

Jeff


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

Re: [PATCH] Prevent OOM from killing init

[Martin Dalecki]

Alan Cox wrote:
> 
> > That depends what you mean by "must not". If it's your missile guidance
> > system, aircraft autopilot or life support system, the system must not run
> > out of memory in the first place. If the system breaks down badly, killing
> > init and thus panicking (hence rebooting, if the system is set up that
> > way) seems the best approach.
> 
> Ultra reliable systems dont contain memory allocators. There are good reasons
> for this but the design trade offs are rather hard to make in a real world
> environment

I esp. they run on CPU's without a stack or what?
-
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] OOM handling

[Jonathan Morton]

>- the AGE_FACTOR calculation will overflow after the system has
>  an uptime of just _3_ days

Tsk tsk tsk...

>Now if you can make something which preserves the heuristics which
>serve us so well on desktop boxes and add something that makes it
>also work on your Oracle servers, then I'd be interested.

What do people think of my "adjustments" to the existing algorithm?  Mostly
it gives extra longevity to low-UID and long-running processes, which to my
mind makes sense for both server and desktop boxen.

Taking for example an 80Mb process under my adjustments, it is reduced to
under the badness of a new shell process after less than a week's uptime
(compared to several months), especially if it is run as low-UID.  Small,
short-lived interactive processes still don't get *too* adversely affected,
but a memory hog with only a few hours' uptime will still get killed with
high probability (pretty much what we want).

I didn't quite understand Martin's comments about "not normalised" -
presumably this is some mathematical argument, but what does this actually
mean?

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

[Wichert Akkerman]

In article <[EMAIL PROTECTED]>,
 <[EMAIL PROTECTED]> wrote:
>a large name space allows one to omit checking what part can be
>reused - reuse is unnecessary.

You are just delaying the problem then, at some point your uptime will
be large enough that you have run through all 64bit pids for example.

Wichert.


-- 
   
 / Generally uninteresting signature - ignore at your convenience  \
| [EMAIL PROTECTED]  http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

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

[Martin Dalecki]

Rik van Riel wrote:
> 
> On Sun, 25 Mar 2001, Martin Dalecki wrote:
> 
> > Ah... and of course I think this patch can already go directly
> > into the official kernel. The quality of code should permit
> > it. I would esp. request Rik van Riel to have a closer look
> > at it...
> 
> - the algorithms are just as much black magic as the old ones
> - it hasn't been tested in any other workload than your Oracle
>   server (at least, not that I've heard of)

No that's not true! Read the code please. The result is a simple
wighted sum without artificial unit.

> - the comments are just too rude  ;)
>   (though fun)

That's only a matter for the "smooth" anglosaxons. Different
cultures have different measures on this. I don't feel the need
to adjust myself to the american cultural obstructivity.
I esp. to the habit of don't saying clearly what one means if one
want's to criticize something.

> - the AGE_FACTOR calculation will overflow after the system has
>   an uptime of just _3_ days
> - your code might be good for server loads, but for normal
>   users it will kill what amounts to a random process ... this
>   is horribly wrong for desktop systems

No that isn't true.  I esp. the behaviour will be predictable.

> In short, I like some of your ideas, but I really fail to see why
> this version of the code would be any better than what we're having
> now. In fact, since there seem to be about 1000x more desktop boxes
> than Oracle boxes (probably even more), I'd say that the current
> algorithm in the kernel is better (since it's right for more systems).

You misunderstood me compleatly. I wasn't using an running oracle
db as a test case. I was using the INSTALLATION process.
Since you apparently don't know about oracle I will tell you:
It involves a lot of different applications. Infact TONS of:
Java, shell, compiler, linker, apache, perl and whatanot.

> Now if you can make something which preserves the heuristics which
> serve us so well on desktop boxes and add something that makes it
> also work on your Oracle servers, then I'd be interested.

I would like to state: The current heuristics DON'T serve us well 
on desktop boxes...

> Alternatively, I also wouldn't mind a completely new algorithm, as
> long as it turns out to work well on desktop boxes too. But remember

I was testing on a NOTEBOOK.

> that we cannot tell this without first testing the thing on a few
> dozen (hundreds?) of machines with different workloads...

That's true for sure.
-
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/

UDMA 5 on Promise ULTRA 100

[Otto Meier]

I run linux 2.4.2-ac24 on the ULTRA 100 card with pdc 20267 Chip.

Drives are MAXTOR 53073H4 UDMA100.

Everything runs fine so far. The only thing which iritates me is
that :

/proc/ide/pdc202xx reports that the drives run in UDMA4 mode.

I have the above mentioned drives running as master each as a single
drive on its interface. 

How can I achive that the drives run in UDMA5 ?

Otto



-
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

[Sandy Harris]

Kurt Garloff wrote:

> Kernel related questions IMHO are:
> (1) Why do we get into OOM?

There was a long thread about this a few months back. We get into OOM because
malloc(), calloc() etc. can allocate more memory than is actually available.

e.g. Say you have machine with 64 RAM + 64 swap = 128 megs with 40 megs in use,
so 88 free. Now two processes each malloc() 80 megs. Both succeed. If both
processes then use that memory, someone is likely to fail later.

> Can we avoid it?

The obvious solution is to consider the above behaviour a bug and fix it.
The second malloc() should fail. The process making that call can then look
at the return value and decide what to do about the failure.

However, this was extensively discussed here last year, and that solution was
quite firmly rejected. I never understood the reasons. See the archives.

Someone did announce they were working on patches implementing a sane malloc().
What happened to that project?
-
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] OOM handling

[Rik van Riel]

On Sun, 25 Mar 2001, Martin Dalecki wrote:

> Ah... and of course I think this patch can already go directly 
> into the official kernel. The quality of code should permit 
> it. I would esp. request Rik van Riel to have a closer look
> at it...

- the algorithms are just as much black magic as the old ones
- it hasn't been tested in any other workload than your Oracle
  server (at least, not that I've heard of)
- the comments are just too rude  ;)
  (though fun)
- the AGE_FACTOR calculation will overflow after the system has
  an uptime of just _3_ days 
- your code might be good for server loads, but for normal
  users it will kill what amounts to a random process ... this
  is horribly wrong for desktop systems

In short, I like some of your ideas, but I really fail to see why
this version of the code would be any better than what we're having
now. In fact, since there seem to be about 1000x more desktop boxes
than Oracle boxes (probably even more), I'd say that the current
algorithm in the kernel is better (since it's right for more systems).

Now if you can make something which preserves the heuristics which
serve us so well on desktop boxes and add something that makes it
also work on your Oracle servers, then I'd be interested.

Alternatively, I also wouldn't mind a completely new algorithm, as
long as it turns out to work well on desktop boxes too. But remember
that we cannot tell this without first testing the thing on a few
dozen (hundreds?) of machines with different workloads...

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

[Marco Colombo]

On Fri, 23 Mar 2001, Jonathan Morton wrote:

> >The main point is letting malloc fail when the memory cannot be
> >guaranteed.
> 
> If I read various things correctly, malloc() is supposed to fail as you
> would expect if /proc/sys/vm/overcommit_memory is 0.  This is the case on
> my RH 6.2 box, dunno about yours.  I can write a simple test program which
> simply allocates tons of memory if you like...
> 
> ...and I did.  It filled up my physical and swap memory, and got killed by
> the OOM handler before malloc() failed, even though overcommit_memory was
> set to 0.
> 
> *BAD!*

Please search list archives, there are plenty of threads about
overcommitment.

Have a look at the sources, that part is easy to read and you'll
realize that /proc/sys/vm/overcommit_memory does not really enable
/ disable memory overcommitment: its closer to a sanity check to
disallow absurdly sized requests, IIRC.

.TM.
-- 
  /  /   /
 /  /   /   Marco Colombo
___/  ___  /   /  Technical Manager
   /  /   /  ESI s.r.l.
 _/ _/  _/ [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: Larger dev_t

[Martin Dalecki]

Linus Torvalds wrote:
> 
> 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.

Amen. It's entierly sufficent to take a size similiar to the one
on systems which don't have the problems linux has in this area.
Our daily motto should be: "Maybe we don't know a shit about
OS design - but we known very well up to the ground how Solaris works."

Please forgive me If I stressed your sense of humour a bit too much :-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Prevent OOM from killing init

[Martin Dalecki]

Stephen Satchell wrote:
> 
> 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.

That makes me actually rolling on by back... Just try to add oracle to
inittab
crash it and watch it grabefully restarting by repawn!

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

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

Re: [PATCH] Prevent OOM from killing init

[Martin Dalecki]

Jonathan Morton wrote:
> 
> >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;

Ahh this will make the oom killer robust against misbalanced
MM. I will assimiliate this idea.
-
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

[Martin Dalecki]

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

Please se the patches I have send roughly a year to the list as well.
It's actually NOT easy. In esp the SCSI and IDE-CD usage of minor arrays
is
a huge obstacle.

-- 
- phone: +49 214 8656 283
- job:   eVision-Ventures AG, LEV .de (MY OPINIONS ARE MY OWN!)
- langs: de_DE.ISO8859-1, en_US, pl_PL.ISO8859-2, last ressort:
ru_RU.KOI8-R
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/