Soo Heng (AUDTQSH) on Network Security related matters
Jenny (AUDTJCG) on PC and LAN matters.
Thank you.
>>> "linux-kernel@vger.rutgers.edu" 12/06/98 00:16 >>>
linux-kernel-digest Saturday, 5 December 1998 Volume 01 : Number 2946
In this issue:
Re: [patch] morethan900MB-2.0.36
Re: [OT] gravity, who cares anymore, really? Feel free to send your hate mail.
Re: freebsd's dummynet or selectable traffic shaping
Subj. TCP_CLOSING states lasting for 20 minutes :-(
Re: NTFS partitions show up as OS/2 partitions.
2.1.131 breaks xosview?
Re: ftape_timestamp and do_gettimeofday?
devfs patch v80 available
Re: Absolutely horrid IDE performance...
Re: NO ROM BASIC
2.1.131 compile problem fixed
Oops in 2.1.131 accessing IDE CD-ROM
smc-ultra irq? problems in 2.1.13[01]
Apology to all.
Re: MegaRAID patch with SMP
Re: aic7xxx Driver support faster than 20MB/sec?
Are people still having fun with psaux and 2.1.12/3x ?
adaptec ava-1505 card
SMP config option
Re: Y2k compliance
Re: Problem with 1G RAM
[OFFTOPIC] Re: Y2k compliance
atomicity
Re: Linux timekeeping plans
Re: SAR (was Re: disks stats through /proc)
Re: limitations on sysv ipc message queues on Linux
memory management
2.1.131 notes.
See the end of the digest for information on subscribing to the linux-kernel
or linux-kernel-digest mailing lists.
----------------------------------------------------------------------
From: MOLNAR Ingo <mingo@chiara.csoma.elte.hu>
Date: Sat, 5 Dec 1998 00:17:06 +0100 (CET)
Subject: Re: [patch] morethan900MB-2.0.36
On Fri, 4 Dec 1998, Leonard N. Zubkoff wrote:
> we _definitely_ need support for more than 2G physical RAM. (eg. the
> Torrent system demo on OracleWorld was run on a box with 2.5G RAM.) Also,
> a 2G+2G split has performance disadvantages if the box in question has
> less memory (eg. 1G RAM).
>
> While allowing for more than 2GB physical memory makes sense in some
> cases, the resulting limitation on the virtual address space size is
> going to be highly problematic for many applications. For example,
> Oracle wants to use as much memory as possible for its database block
> buffer cache which is mapped by all Oracle processes as shared memory.
> [...]
Oracle has a problem with their process architecture being limited to
32-bit virtual memory on x86. They have to and will solve this anyway, to
support NT's (and other OS's) 4M-pages 36-bit RAM extensions. There are
ways around this even with the current model: multiple instances of the
server can be used, this is perfectly possible and many bigger Oracle
sites run this way. (several departmental isolated servers on the same
box, casual communication between them via SQL*Net over local IPC)
but having one big application limited to 32-bits doesnt mean we should
forget about other applications ...
> Similarly, large scientific applications probably need large individual
> data segments. [...]
yes. One of the early testers of the original patch had a simulation
system on a 4-ways PPro box, each process had it's own ~600-700M segment
which it did number crunching on. This simulation setup, with it's current
architecture could use up to ~3.2G physical memory. (3.2G RAM, 4x800M
processes, one per CPU)
> [...] It looks to me like the only systems that can make use of
> more than 2GB physical memory will have a number of smaller processes
> that don't share memory.
there are lots of such applications! a typical multiuser box is such an
application. a typical fileserver/webserver/newsserver/proxy is such an
application.
> What's the performance disadvantage with a 2GB+2GB split?
we are now considering the case when someone has 1G physical memory, but
is not using a 1.1G/2.9G split, but a 2.0G/2.0G split.
we want to 'spread out' mapped memory out for several reasons, but the
single most important is:
- near the 'saturation point' the system slows down if it wants to
find a given-size virtual memory chunk. This is basically a
'fragmentation issue' for virtual memory, and the basic defense
against fragmentation is having more free space :) We have to walk
lots of vmas before we find some 'free space'.
(i suspect this was one of the reasons why NT went from a 2:2 split to a
3:1 split ... not only marketing reasons.)
there are some other (non-performance) arguments too:
- a.out compatibility libraries are pretty much hosed if we map
those low addresses. (not an issue for most people)
- the likelihood of 'silent data corruption' vs. 'segmentation
fault' is smaller if you have more virtual memory for the same
amount of mapped memory, obviously. We want to see a clear
segmentation fault if a bug happens, not some silent data
corruption.
- a related issue: any kind of mmap() trick to build a safer
memory architecture (like putting a 4K 'hole' between each
allocated block) becomes harder and harder if virtual memory gets
saturated. (maybe Checker or Electric Fence is affected, not
sure)
basically, 'free virtual memory estate' is a system resource, which we
should not arbitrarily waste, thats the main concept.
- -- mingo
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: "Brandon S. Allbery KF8NH" <allbery@kf8nh.apk.net>
Date: Fri, 04 Dec 1998 18:34:22 -0500
Subject: Re: [OT] gravity, who cares anymore, really? Feel free to send your hate mail.
In message <3667B156.62983DA2@ionet.net>, pleXus writes:
+-----
| Centripetal force is the force applied to something that would mimick gravity
| ,
| and, any physicist should know that centripetal force cannot be created using
| a a
| simple spin (not really). Maybe quantum mechanics (theoretical physics? huh?
+--->8
What planet are you from?
Centripetal force is the force which keeps an object in motion about a
center from doing what it would otherwise do, which is continue moving at a
tangent away from the center due to its momentum. In the case of an object
held by a string, the force is exerted by the string; for someone standing
on the "floor" of a space station which rotates to produce "artificial
gravity", it's the force exerted on the person's feet by the "floor" of the
station.
"Centrifugal force" doesn't exist. It's the apparent "force" directed away
from the center of rotation which appears to be pulling the rotating object
directly outward from the center; in fact, it's actually the object's
momentum trying to carry it in a straight line (at a tangent to the circle,
not normal to it). Since for short distances the tangent is fairly close to
the circular path resulting from the application of centripetal force to the
object, it "feels" like a force directly away from the center.
- --
brandon s. allbery [os/2][linux][solaris][japh] allbery@kf8nh.apk.net
system administrator [WAY too many hats] allbery@ece.cmu.edu
carnegie mellon / electrical and computer engineering KF8NH
Kiss my bits, Billy-boy.
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Carlos Morgado <l39801@alfa.ist.utl.pt>
Date: Fri, 4 Dec 1998 23:45:27 +0000
Subject: Re: freebsd's dummynet or selectable traffic shaping
- -----BEGIN PGP SIGNED MESSAGE-----
On Fri, Dec 04, 1998 at 03:59:51PM +0200, Roman Maschak wrote:
> Hi, All
>
> Under FreeBSD there are is some firewall extension such as dummynet
>
> That program allow you creat "pipes" with some bandwidth, packet queue
> delay and size and route some traffic trough that "pipes"
>
> In other word this is something like shaping via ip aliasing under
> cisco
>
> More info at http://www.iet.unipi.it/~luigi/ip_dummynet/
>
> So question - is there are any possiblity to do this under linux ?
>
Can't this be done via sensible routing, shaping and QoS ?
- - --
Carlos Morgado - l39801@alfa.ist.utl.pt - http://alfa.ist.utl.pt/~c39801
PGP Key fingerprint = 43 BF 53 98 EB 32 F5 17 9E EB 77 1F 57 8C C6 83
"Some people have told me they don't think a fat penguin really embodies the
grace of Linux, which just tells me they have never seen a angry penguin
charging at them in excess of 100mph. They'd be a lot more careful about
what they say if they had." -- Linus Torvalds
- -----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
iQCVAwUBNmh0GoewijNBLgpJAQGYugQAtLVUrwT0xp9GJG36Yjp9kOdxqOdiOl28
lLqvnTixq8ko1O+onO8HYU1U8X16Rh0HrY0tstddJaZin6a1JWOZpUU4TGPOmA5r
gm+SjzQzMLKOGQM6BF3u6D9WHjdAn0yn0xBZGtoSQRbBhaIV0C0fkwcNH7N7haHb
GKwDPB/Vtg0=
=BETp
- -----END PGP SIGNATURE-----
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: torben fjerdingstad <unitfj-lk@tfj.rnd.uni-c.dk>
Date: Sat, 5 Dec 1998 00:55:08 +0100
Subject: Subj. TCP_CLOSING states lasting for 20 minutes :-(
I have trouble using Linux through a Cisco PIX firewall.
This is Linux specific!
With secure shell I get random "Read failed, connection
closed". That is now fixed by disabling random tcp
sequence numbers on the cisco.
The Cisco PIX only allows connections initiated from "inside".
Now to the other problem.
Most of the time tcp connections from Linux do not close
properly.
netstat shows usually CLOSING for 20 minutes, while the
Linux box at "inside" retransmits a FIN every two minutes.
With some sessions netstat has shown LAST_ACK instead.
I have made simultateous tcpdumps at both ends. It seems
they have opposite idea of who sent a FIN first. Until
then, they completely agree. I have cut out the domain
names to make the lines shorter.:
View from sslug at "outside":
23:40:28.542802 olivia.4718 > sslug.nntp: P 402:408(6) ack 675 win 16060 (DF)
23:40:28.542802 sslug.nntp > olivia.4718: P 675:682(7) ack 408 win 32736 (DF)
23:40:28.542802 sslug.nntp > olivia.4718: F 682:682(0) ack 408 win 32736
23:40:28.682802 olivia.4718 > sslug.nntp: F 408:408(0) ack 682 win 16060
23:40:28.682802 sslug.nntp > olivia.4718: . ack 409 win 32735 (DF)
23:40:28.682802 olivia.4718 > sslug.nntp: . ack 683 win 16060 (DF)
View from olivia at "inside":
23:40:29.205469 olivia.4718 > sslug.nntp: P 402:408(6) ack 675 win 16060 (DF)
23:40:29.345469 sslug.nntp > olivia.4718: P 675:682(7) ack 408 win 32736 (DF)
23:40:29.345469 olivia.4718 > sslug.nntp: F 408:408(0) ack 682 win 16060
23:40:29.355469 sslug.nntp > olivia.4718: F 682:682(0) ack 408 win 32736
23:40:29.355469 olivia.4718 > sslug.nntp: . ack 683 win 16060 (DF)
23:40:29.595469 olivia.4718 > sslug.nntp: F 408:408(0) ack 683 win 16060
23:40:30.095469 olivia.4718 > sslug.nntp: F 408:408(0) ack 683 win 16060
23:40:31.095469 olivia.4718 > sslug.nntp: F 408:408(0) ack 683 win 16060
23:40:33.095469 olivia.4718 > sslug.nntp: F 408:408(0) ack 683 win 16060
23:40:37.095469 olivia.4718 > sslug.nntp: F 408:408(0) ack 683 win 16060
23:40:45.095469 olivia.4718 > sslug.nntp: F 408:408(0) ack 683 win 16060
23:41:01.095469 olivia.4718 > sslug.nntp: F 408:408(0) ack 683 win 16060
23:41:33.095469 olivia.4718 > sslug.nntp: F 408:408(0) ack 683 win 16060
23:42:37.095469 olivia.4718 > sslug.nntp: F 408:408(0) ack 683 win 16060
23:44:37.095469 olivia.4718 > sslug.nntp: F 408:408(0) ack 683 win 16060
The state on olivia during retransmit of the FIN(408) was CLOSING
More details:
olivia is running linux-2.0.35. Changing to other versions did not
solve the tcp close problem. I tried 2.0.24, 2.1.105 and 2.1.125 too.
I tried many times with a Window(do)s95 box at "inside". No problem.
sslug is running redhat-5.x (I don't remember what x is). The result
is the same with our AIX news server. A remote server that almost
always gives the problem is http://www.theregister.co.uk
The problem loads the phone bill because some of the
"inside" hosts are in private homes, connected by ISDN.
I don't know the details of tcp or C programming, I'm just
a unix system manager.
- --
Med venlig hilsen / Regards
Netdriftgruppen / Network Management Group
UNI-C
Tlf./Phone +45 35 87 89 41 Mail: UNI-C
Fax. +45 35 87 89 90 Bygning 304
E-mail: torben.fjerdingstad@uni-c.dk DK-2800 Lyngby
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: "Brandon S. Allbery KF8NH" <allbery@kf8nh.apk.net>
Date: Fri, 04 Dec 1998 18:50:24 -0500
Subject: Re: NTFS partitions show up as OS/2 partitions.
In message <Pine.LNX.3.96.981204020105.30024G-100000@52-a-usw.rb1.blv.nwnexus
.n
et>, Tim Smith writes:
+-----
| > > ext2flt.sys) for NTFS. Probably for the same reason that OS/2 does;
| > > despite the hype, the innards of NT are still recognizeably based on OS/2
| > > 2.0.
|
| That's a common usenet myth, but its completely wrong. The only thing from
+--->8
*That's* a common myth encouraged by Microsoft. Little code is left, I'll
grant, but the basic behavior is much the same; any experienced OS/2 user
can recognize BASEDEVs in NT's refusal to deal with changing devices at
runtime, for example. Likewise, its handling of IFSes is quite familiart
once you get past the use of the registry instead of CONFIG.SYS. And Win32
is the OS/2 API with functions and structures renamed, structure contents
slightly rearranged, and the not-so-occasional flag with an inverted sense
(often for no discernable reason IMHO).
Someone who hasn't had significant experience with both would likely believe
the tale that NT has no relationship to OS/2. Someone who has experience
with both knows differently; if you can see past the glitz, the behavior
tells the story. (I discount Microsoft's claims that NT is not related to
OS/2, for the simple reason that they felt they had more to lose by
acknowledging it than by trying to claim that OS/2 was entirely IBM's fault
and that they had the "real" OS.)
- --
brandon s. allbery [os/2][linux][solaris][japh] allbery@kf8nh.apk.net
system administrator [WAY too many hats] allbery@ece.cmu.edu
carnegie mellon / electrical and computer engineering KF8NH
Kiss my bits, Billy-boy.
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: getlkl@terrorist.math.ntu.edu.tw
Date: Sat, 5 Dec 1998 08:02:03 +0800
Subject: 2.1.131 breaks xosview?
Did something happen? xosview croaks, claiming that /proc/net/ip_acct
does not exist. Can someone tell me what happened in between 2.1.129
and 2.1.131? Thanks ... I was using make oldconfig, same settings.
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Claus-Justus Heine <heine@math1.rwth-aachen.de>
Date: 05 Dec 1998 00:29:03 +0100
Subject: Re: ftape_timestamp and do_gettimeofday?
Robert Hamilton <hamilton@users.kdi.com> writes:
> Hi all. Browsing the source I came across what
> I hope is a helpful question: is there any reason
> now why ftape_timestamp() reads the 8254 directly
> instead of calling do_gettimeofday()?
>
> It seems to be used only to compute time differences
> in microsec and for stamping debugging traces, so I
> can't see where there would be any ill effects.
>
> Doing the latter could simplify the routines in
> ftape-calibr.c, put paid to the possible jiffy-
> crossing bugs, and take advantage of the careful
> coding and bugfixes in arch/i386/kernel/time.c,
> so it looks like a win all around to me.
>
> Apologies for not submitting a patch suggestion, but
> without a floppy tape myself, I have no way to test it.
You can't know, but more up-to-date versions of ftape don't use it any
more.
I tried to push ftape-4.02 into recent v2.1 kernel some weeks ago, but
had no time to resent the thing a third of fourth time.
ftape-4.x supports certain kinds of parallel port tape drives, so it
would be nice to have in the v2.2 kernel. It also gets rid of kernel
level software compression which was a bad idea anyway and has
improved write error recovery, compared to all previous versions of
ftape.
I hope to be able to release a new version next week and thereby will
produce a new patch and send it to Linus.
Thanks for taking care
Claus
- --
Claus-Justus Heine
heine@math1.rwth-aachen.de
http://www.math1.rwth-aachen.de/~heine/
Ftape - the Linux Floppy Tape Project
Home Page : http://www.math1.rwth-aachen.de/~heine/ftape/
CVS Repos. : http://iris3.math1.rwth-aachen.de:8000/cvsweb/
Bug Reports : http://iris3.math1.rwth-aachen.de:8080/gnats/
ftape-bugs@iris3.math1.rwth-aachen.de
Mailing-list: linux-tape@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Richard Gooch <rgooch@atnf.csiro.au>
Date: Sat, 5 Dec 1998 11:02:30 +1100
Subject: devfs patch v80 available
Hi, all. Version 80 of my devfs patch is now available from:
http://www.atnf.csiro.au/~rgooch/linux/kernel-patches.html
The devfs FAQ is also available here.
This is against 2.1.131. Highlights of this release:
- - Ported to kernel 2.1.131
- - Updated <devfs_rmdir> for VFS change in 2.1.131
Regards,
Richard....
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Gerard Roudier <groudier@club-internet.fr>
Date: Sat, 5 Dec 1998 01:13:57 +0100 (MET)
Subject: Re: Absolutely horrid IDE performance...
On Wed, 2 Dec 1998, Mark Lord wrote:
> > -------Sequential Output-------- ---Sequential Input-- --Random--
> > -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
> >Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec
> >%CPU
> > 256 17374 95.5 32681 33.2 10706 24.3 15683 68.4 23710 24.3 214.6 1.8
Just my comments on this benchmark results:
1) Block write = 32681 KB/second
Comment: Not relevant, if as I guess the machine has probably 128 MB
memory.
2) Block read 23710 KB/second against Character Read 15683 KB/s
and only 68.4 % CPU.
Comment: You should get at least 90 %. Something is behaving not well
somewhere.
For your information, here is a benchmark result with Linux 2.1.30 and the
stock driver I got a couple of days ago using a single Cheatah2.
(PII 233 / 66MHz SDRAM + 64MB + SYM53C895)
-------Sequential Output-------- ---Sequential Input-- --Random--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
4K ext2 300 10656 97.7 19235 23.7 8346 26.5 13097 91.8 18602 21.0 229.2 4.7
Even if the number are lower, I bet you that a single Cheatah2 is
significantly faster for RL than you pair of IDE things. Just looking at
the results shows that the Cheatah2 is working in optimal conditions. On
the other hand the IDE things seem to perform chaotically due to the
poorness of the IDE interface and protocol.
(BTW, results seem slightly better using the 896 board I have received
yesterday using the new 896 driver (less CPU load and a bit faster).
Regards,
Gerard.
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: "J. S. Connell" <ankh@canuck.gen.nz>
Date: Fri, 4 Dec 1998 19:03:56 -0500 (EST)
Subject: Re: NO ROM BASIC
> > > Then I rebooted. When it starts, it goes to 40 column mode and
> > > says "NO ROM BASIC"
Even the most recent BIOSes fall through into the ancient NO ROM BASIC
screen if they can't boot from a hard drive. It's not a virus, just one of
those lovable "features" of the Intel platform.
- --Jeff
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: "Mr. Joshua Lambert" <Daedalas@concentric.net>
Date: Fri, 4 Dec 1998 19:22:49 -0500 (EST)
Subject: 2.1.131 compile problem fixed
2.1.131 is up and running, thanks to some helpful tips and pointers
towards the discovery of a mis-placed uio.h. It seems as though, after
installing glibc, its uio.h was copied over linux's uio.h; not good. All
fixed and running like a charm; my thanks to everyone who helped out.
Cheers,
JL
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Richard Gooch <rgooch@atnf.csiro.au>
Date: Sat, 5 Dec 1998 12:53:59 +1100
Subject: Oops in 2.1.131 accessing IDE CD-ROM
Hi, all. I've been getting Oopses on a new laptop (Dell Inspiron
3200) when I attempt to mount the CD-ROM drive. I noticed the problem
with 2.1.129, 2.1.130 and now 2.1.131. At first, I had the ide-cd and
isofs code compiled as modules, and just now I've tried with them
built in. Still no good. Kernel log and trace follows.
Test patches will be gratefully accepted :-)
Linux version 2.1.131 (rgooch@mobilix) (gcc version 2.7.2.f.1) #3 Sat Dec 5 12:30:24 EST 1998
Detected 232530658 Hz processor.
Console: colour VGA+ 80x50
Calibrating delay loop... 231.83 BogoMIPS
Memory: 79376k/81920k available (876k kernel code, 404k reserved, 1188k data, 76k init)
CPU: Intel Pentium II (Deschutes) stepping 02
Checking 386/387 coupling... OK, FPU using exception 16 error reporting.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.26 (19981001) Richard Gooch (rgooch@atnf.csiro.au)
PCI: PCI BIOS revision 2.10 entry at 0xfda13
PCI: Probing PCI hardware
PCI: Enabling I/O for device 00:3a
Swansea University Computer Society NET3.039 for Linux 2.1
NET3: Unix domain sockets 0.16 for Linux NET3.038.
Swansea University Computer Society TCP/IP for NET3.037
IP Protocols: ICMP, UDP, TCP
Starting kswapd v 1.5
Serial driver version 4.26 with SHARE_IRQ enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
apm: BIOS version 1.2 Flags 0x03 (Driver version 1.7)
Real Time Clock Driver v1.09
RAM disk driver initialized: 16 RAM disks of 8192K size
PIIX4: IDE controller on PCI bus 00 dev 39
PIIX4: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xfcf0-0xfcf7, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xfcf8-0xfcff, BIOS settings: hdc:pio, hdd:pio
hda: FUJITSU MHD2032AT, ATA DISK drive
hdc: TOSHIBA CD-ROM XM-1702BC, ATAPI CDROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: FUJITSU MHD2032AT, 3102MB w/0kB Cache, CHS=788/128/63, UDMA
hdc: ATAPI 24X CDROM drive, 128kB Cache
Uniform CDROM driver Revision: 2.50
scsi : 0 hosts.
scsi : detected total.
Partition check:
/dev/ide/hd/c0b0t0u0: p1 p2 p3 p4 < p5 p6 p7 p8 p9 >
devfs: v0.55 (19981205) Richard Gooch (rgooch@atnf.csiro.au)
devfs: devfs_debug: 0x0
devfs: boot_options: 0xc
VFS: Mounted root (ext2 filesystem) readonly.
Mounted devfs on /dev
Freeing unused kernel memory: 76k freed
inserting floppy driver for 2.1.131
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
ad1848/cs4248 codec driver Copyright (C) by Hannu Savolainen 1993-1996
YM3812 and OPL-3 driver Copyright (C) by Hannu Savolainen, Rob Hooft 1993-1996
Linux PCMCIA Card Services 3.0.6
kernel build: 2.1.131 #2 Sat Dec 5 12:01:19 EST 1998
options: [pci] [cardbus] [apm]
Intel PCIC probe:
TI 1131 PCI-to-CardBus at bus 0 slot 4, mem 0x68000000, 2 sockets
host opts [0]: [pci + serial irq] [no pci irq] [lat 168/176] [bus 32/34]
host opts [1]: [pci + serial irq] [no pci irq] [lat 168/176] [bus 35/37]
ISA irqs (scanned) = 3,4,7,9,10,11 status change on irq 11
cs: IO port probe 0x0100-0x03ff: excluding 0x220-0x22f 0x378-0x37f
cs: memory probe 0xa0000000-0xa0ffffff: clean.
eth0: NE2000 Compatible: port 0x300, irq 3, hw_addr 00:40:33:9A:22:26
Unable to handle kernel NULL pointer dereference at virtual address 00000014
current->tss.cr3 = 04a32000, %cr3 = 04a32000
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[<c0143efb>]
EFLAGS: 00010296
eax: 00000000 ebx: 00001600 ecx: c01e1fcc edx: 00000016
esi: c4643800 edi: c4641600 ebp: 00000016 esp: c495dd68
ds: 0018 es: 0018 ss: 0018
Process mount (pid: 199, process nr: 16, stackpage=c495d000)
Stack: c4643800 00001600 00000000 c01f2000 c0110ae7 c495dd9c fffffc18 c495c000
c01f2000 c495c000 c495dde4 c495ddb0 ffff7f16 c495ddb8 00000202 c495dde4
c495de14 00000000 c495c000 c495dde8 c0006c20 c01bbec8 c495dde4 c0006c20
Call Trace: [<c0110ae7>] [<c01bbec8>] [<c0177b67>] [<c0124fb6>] [<c0144038>] [<c0144051>] [<c0120000>]
[<c01279ea>] [<c0127e9f>] [<c01c4fa4>] [<c0128401>] [<c01c4fa4>] [<c0109864>]
Code: 83 78 14 00 74 5e bb 00 e0 ff ff 21 e3 8b 73 0c 66 89 7c 24
Using `../System.map' to map addresses to symbols.
>>EIP: c0143efb <isofs_get_last_session+2b/a0>
Trace: c0110ae7 <schedule+1e3/20c>
Trace: c01bbec8 <__down_failed+8/10>
Trace: c0177b67 <cdrom_queue_packet_command+47/e8>
Trace: c0124fb6 <set_blocksize+a6/178>
Trace: c0144038 <isofs_read_super+c8/648>
Trace: c0144051 <isofs_read_super+e1/648>
Trace: c0120000 <swap_out_vma+28c/490>
Trace: c01279ea <read_super+86/ac>
Trace: c0127e9f <do_mount+9b/108>
Trace: c01c4fa4 <tvecs+4e20/4ffc>
Trace: c0128401 <sys_mount+2f9/35c>
Trace: c01c4fa4 <tvecs+4e20/4ffc>
Trace: c0109864 <system_call+34/40>
Code: c0143efb <isofs_get_last_session+2b/a0>
Code: c0143efb <isofs_get_last_session+2b/a0> 83 78 14 00 cmpl $0x0,0x14(%eax)
Code: c0143eff <isofs_get_last_session+2f/a0> 74 5e je c0143f5f <isofs_get_last_session+8f/a0>
Code: c0143f01 <isofs_get_last_session+31/a0> bb 00 e0 ff ff movl $0xffffe000,%ebx
Code: c0143f06 <isofs_get_last_session+36/a0> 21 e3 andl %esp,%ebx
Code: c0143f08 <isofs_get_last_session+38/a0> 8b 73 0c movl 0xc(%ebx),%esi
Code: c0143f0b <isofs_get_last_session+3b/a0> 66 89 7c 24 00 movw %di,0x0(%esp,1)
Code: c0143f10 <isofs_get_last_session+40/a0> 90 nop
Code: c0143f11 <isofs_get_last_session+41/a0> 90 nop
Code: c0143f12 <isofs_get_last_session+42/a0> 90 nop
Regards,
Richard....
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: collins benjamin m <bcollins@it.larc.nasa.gov>
Date: Fri, 4 Dec 1998 20:56:49 -0500 (EST)
Subject: smc-ultra irq? problems in 2.1.13[01]
My smc ultra which has been working for over a year now has now seemed to
have died all of the sudden. The only thing that changed was going to
2.1.130, when i rebooted it wouldn't work any more and subsequently
upgrading to 2.1.131 didn't help either. I'm not so sure it is a kernel
problem, but figured I would start here.
Originally I had the smc-ultra being built into the kernel, but after the
problems started I made it a module to do some testing with other irq's.
Basically the modules for the smc load and ifconfig eth0 works without any
errors. Here is what I get after trying to use the interface however:
[root@goodguy(4:30pm)-~]%dmesg
<snipped>
smc-ultra.c: Presently autoprobing (not recommended) for a single card.
smc-ultra.c:v2.00 6/6/96 Donald Becker (becker@cesdis.gsfc.nasa.gov)
eth0: SMC EtherEZ at 0x240, 00 00 C0 AB AC CA, IRQ 11 memory
0xc8000-0xc9fff.
Socket destroy delayed (r=0 w=160)
Socket destroy delayed (r=0 w=160)
Socket destroy delayed (r=0 w=160)
eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=679.
eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x43, t=2500.
eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x43, t=1000.
Socket destroy delayed (r=0 w=128)
eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x43, t=1000.
eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x43, t=1000.
smc-ultra.c: Presently autoprobing (not recommended) for a single card.
smc-ultra.c:v2.00 6/6/96 Donald Becker (becker@cesdis.gsfc.nasa.gov)
eth0: SMC EtherEZ at 0x240, 00 00 C0 AB AC CA,assigned IRQ 12 memory
0xc8000-0xc9fff.
eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=770.
eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x43, t=1000.
eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x43, t=1000.
Socket destroy delayed (r=0 w=128)
eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x43, t=1000.
eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x43, t=1000.
eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x43, t=1000.
eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x43, t=1000.
eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x43, t=1000.
eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x43, t=1000.
You can see where I unloaded the module and changed the irq, I have tried
irq 5,7,9,11,12 but none work. I was originally using irq 11 which had
always worked. Here is an output of ifconfig after trying to use the
interface:
[root@goodguy(4:30pm)-~]%ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:00:C0:AB:AC:CA
inet addr:10.0.0.1 Bcast:10.255.255.255 Mask:255.0.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:15 dropped:0 overruns:0 carrier:0
Collisions:0
Interrupt:12 Base address:0x250 Memory:c8000-ca000
Any one have any ideas as to what may have happened? NOTE: my wife tried
to install some dos game under windows just before this as well which had
trouble auto-detecting the PnP sound card, sound still works, but smc
doesn't.
thanks
- --
- ----- -- - -------- --------- ---- ------- ----- - - --- --------
Ben Collins <b.m.collins@larc.nasa.gov> Debian GNU/Linux
UnixGroup Admin - Jordan Systems Inc. bcollins@debian.org
- ------ -- ----- - - ------- ------- -- The Choice of the GNU Generation
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Alex Buell <alex.buell@tahallah.demon.co.uk>
Date: Fri, 4 Dec 1998 21:27:01 -0500 (EST)
Subject: Apology to all.
Guys,
First off, I'm geninuely horrified at what I've done lately. One innocent
(but completely wrong) comment about spinning down the planet has turned
into a HUGE off-topic thread. :o( Can we kill that thread now? Pretty
please?
Secondly, I misread the spam I recieved the other day - I'd thought it
came through the l-kernel list instead of the l-ppp list. The proper
authorities have been notified and the offender duly dealt with
(presumably they've reinstalled his machine with Windows 95 by now and
slapped a firewall on it that ensures that nothing gets out onto the net).
If you are going to reply, send it privately. I don't want another
monster thread again.
Cheers,
Alex
- --
/\_/\ Legalise cannabis now!
( o.o ) Grow some cannabis today!
> ^ < Peace, Love, Unity and Respect to all.
http://www.tahallah.demon.co.uk - *new* - rewritten for text browser users!
Linux tahallah 2.1.131 #65 SMP Thu Dec 3 18:36:23 EST 1998
Two Intel Pentium Pro 166MHz processors, 331.78 total bogomips, 48M RAM
System library 2.0.105
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Mark Plaksin <happy@arches.uga.edu>
Date: 04 Dec 1998 21:41:13 -0500
Subject: Re: MegaRAID patch with SMP
Pavel.Janik@inet.cz (Pavel Janik ml.) writes:
> When running on 2.0.29 (latest versions are "SMP updated", so no go
> for our configuration) no problems arrive (cd /usr/src/linux; make -j
> 5 bzImage is OK, -j 50 too ;-). 2.1.130 is bad - it stays about 30s of
> compilation, then locks, no messages in log file. Some messages on the
> console, but we did not write them down, but it is repoducible.
Hi,
We recently got a patch from somebody at AMI that fixed our 2.1.x +
MegaRAID + SMP problems. We've been banging on it for a day and it looks
good so far. The mail message we got included megaraid.c and megaraid.h
along with the smp patch. I haven't checked to see if the .c and .h are
different from what you get from ftp.ami.com. Anyhow, here's a link to the
email message:
http://www.arches.uga.edu/~happy/megaraid.smp.txt
I suspect AMI will come out with a new version of the driver soon.
- --
Mark Plaksin http://www.arches.uga.edu/~happy/
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: "Albert D. Cahalan" <acahalan@cs.uml.edu>
Date: Fri, 4 Dec 1998 21:40:33 -0500 (EST)
Subject: Re: aic7xxx Driver support faster than 20MB/sec?
Matthias Andree writes:
> On Thu, Dec 03, 1998 at 04:42:25PM -0800, Timm Gleason wrote:
>> Does anyone know if the current version of the aic7xxx driver(5.1.4)
>> support faster than 20MB/sec maximum transfer rate?
...
>> aic7xxx driver 5.1.4 and does not seem to accept negotiation higher
>> than 20MB/sec. Yes, I have checked the SCSI BIOS for the controller
>> and all ID's are set to 80MB/sec rate.
>
> You're not stating if you have U2SCSI, but I assume you don't. So I can
> assume you are messing up MB/s and MXfers/s: The MB/s are derived from
> MXfers/s and the actual transfer width. So, 20 MXfers/s on a narror bus
> are 20 MB/s, 20 MXfers/s with a 16bit wide transfer gives 40 MB/s (which
> is what you can probably achieve with the 20 MHz setting), a 32 bit wide
> transfer would offer 80 MB/s, but I doubt your equipment actually does
> 32 Bit transfers.
This is a FAQ I think. Perhaps it would be better to print something
like 1*20 MHz, 2*20 MHz, or 4*20MHz.
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Mike McEwan <mike@lotusland.demon.co.uk>
Date: Sat, 05 Dec 1998 03:09:52 GMT
Subject: Are people still having fun with psaux and 2.1.12/3x ?
Sorry to raise this again, but are people out there still having
problems with PS/2 mice suddenly shooting up the right hand-corner
under X. It would appear this has been happening to some of us since
2.1.124 , or there abouts, since the PS/2 code was moved into the
keyboard stuff.
I've read a few posts pertaining to the 'ol gpm co-existance
problems etc., but even with gpm absent altogether I'm still getting
this. I have a 3 button MS intellimouse, everything worked fine 'til
2.1.124ac?, when the PS/2 mouse code was incorporated with the
keyboard stuff.
To clarify a little further, the problem only occurs when I'm online
to my ISP and my modem's lights are flashing, which leads one to feel
it's something to do with interrupts or the like.
# cat /proc/interrupts
CPU0
0: 4451952 XT-PIC timer
1: 40386 XT-PIC keyboard
2: 0 XT-PIC cascade
4: 357526 XT-PIC serial
8: 4 XT-PIC rtc
12: 33187 XT-PIC PS/2 Mouse
13: 1 XT-PIC fpu
14: 108003 XT-PIC ide0
15: 5 XT-PIC ide1
NMI: 0
IPI: 0
That's my modem on IRQ 4. I'm running `imwheel' and conduct an
`irqtune' at boot time, but the elimination of either of these factors
has, thus far, delivered no relief.
I know there's a few others suffering the same plight from earlier
mailings on this list. Has anyone sussed this out yet, it's a real
pain as, depending on when the bugger strikes, I have to CTRL-ALT-BS
out of X altogether to recover the situation, core dumping as I go.
If this is rather old hat now, please could someone mail this list
or myself as to how the problem can be resolved.
TIA
- --
Mike.
.
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Richard A Nelson <kenpocowboy@mindspring.com>
Date: Fri, 4 Dec 1998 23:26:21 -0500 (EST)
Subject: adaptec ava-1505 card
I couldn't find anything in Documentation/scsi, or drivers/scsi
regarding this card...
Has anyone seen it, and does one of the extant drivers work for it?
Thanks,
- --
Rick Nelson
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Keith Duthie <psycho@stonebow.otago.ac.nz>
Date: Sat, 5 Dec 1998 17:33:22 +1300 (NZDT)
Subject: SMP config option
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to mime@docserver.cac.washington.edu for more info.
- --185212428-1848659583-912832402=:10247
Content-Type: TEXT/PLAIN; charset=US-ASCII
Hi, heres a trivial (ie probably broken) diff to add an SMP option to make
*config. It should (emphasis on should) patch cleanly from /usr/src/linux.
--
| Keith Duthie O- |
+ Don't call me, I'll call you. Maybe. +
| keith.duthie@stonebow.otago.ac.nz |
__ _
/ / (_)__ __ ____ __
/ /__/ / _ \/ // /\ \/ / . . . t h e c h o i c e o f a
/____/_/_//_/\_,_/ /_/\_\ G N U g e n e r a t i o n . . .
- --185212428-1848659583-912832402=:10247
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="smpoption.diff"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.3.96.981205173322.10247F@loki.wibble.prv>
Content-Description:
LS0tIGFyY2gvaTM4Ni9jb25maWcuaW4ub3JpZwlTYXQgRGVjICA1IDE3OjE4
OjI0IDE5OTgNCisrKyBhcmNoL2kzODYvY29uZmlnLmluCVNhdCBEZWMgIDUg
MTc6MTk6MTUgMTk5OA0KQEAgLTIwLDYgKzIwLDcgQEANCiBpZiBbICIkQ09O
RklHX0VYUEVSSU1FTlRBTCIgPSAieSIgXTsgdGhlbg0KICAgYm9vbCAnTVRS
UiAoTWVtb3J5IFR5cGUgUmFuZ2UgUmVnaXN0ZXIpIHN1cHBvcnQnIENPTkZJ
R19NVFJSDQogZmkNCitib29sICdTTVA/JyBDT05GSUdfVVNFU01QDQogZW5k
bWVudQ0KIA0KIG1haW5tZW51X29wdGlvbiBuZXh0X2NvbW1lbnQNCi0tLSBN
YWtlZmlsZS5vcmlnCVNhdCBEZWMgIDUgMTc6MTY6NDMgMTk5OA0KKysrIE1h
a2VmaWxlCVNhdCBEZWMgIDUgMTc6MTc6MDYgMTk5OA0KQEAgLTExLDcgKzEx
LDkgQEANCiAjDQogIyBGb3IgVVAgb3BlcmF0aW9ucyBDT01NRU5UIFRISVMg
T1VULCBzaW1wbHkgc2V0dGluZyBTTVAgPSAwIHdvbid0IHdvcmsNCiAjDQor
aWZlcSAoJChDT05GSUdfVVNFU01QKSx5KQ0KIFNNUCA9IDENCitlbmRpZg0K
IA0KIC5FWFBPUlRfQUxMX1ZBUklBQkxFUzoNCiANCg==
- --185212428-1848659583-912832402=:10247--
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: ralf@uni-koblenz.de
Date: Sat, 5 Dec 1998 05:34:35 +0100
Subject: Re: Y2k compliance
On Fri, Dec 04, 1998 at 09:12:47AM -0600, S. Shore wrote:
> In fact, the year 2000 isn't a leap year. A little-known rule of leapyears
> (iirc) is that any year divisible by 100 (i think) can't be a leapyear.
A lesser known rule is that years divisble by 400 are leapyears, though ...
Ralf
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Tymm Twillman <tymm@coe.missouri.edu>
Date: Fri, 4 Dec 1998 22:54:10 -0600
Subject: Re: Problem with 1G RAM
<stuff deleted to preserve bandwidth>
>
> I will set up a Linux MM documentation section in the Linux
> MM site. Then I'll also put a pointer file ("More.Info" or
> something like that) in the Documentation directory.
>
> Then every kernel subsystem is free to setup a web page/site
> to document problems, internal structure, hacking info, todo
> lists and tips&tricks themselves.
>
> Including all possible info with the kernel would be far too
> much and restricting the available info would be a bad thing.
>
> Once each subsystem has it's own site there could even be a
> bit of competition over who's got the best site -- this will
> undoubtedly annihalate the "no support" FUD we've all been
> hearing.
>
> comments?,
<ramble>
I certainly think this is a good idea, but it would also be really nice to
document the really obvious problems that people are going to run into in
the Documentation directory, if only as a list that says "you have this
problem? go see http://fix.the.problem.org"... All too often people (and
I've made the mistake myself) will run into something like this, quickly
look over the docs, see that there's nothing specifically covering
the problem, and immediately complain to a list or just abort the whole
thing. And while it's fairly obvious that this case is an MM issue, I
expect that many people would skip checking the site, because a) they're
not *sure* this is where to look, and b) it's an extra step with no
guaranteed results. We want to keep things as obvious as possible,
even for the people with big machines and no hacking prowess that are so
easy to FUD...
</ramble>
just my $.0002
- -Tymm
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: "J. S. Connell" <ankh@canuck.gen.nz>
Date: Sat, 5 Dec 1998 00:25:31 -0500 (EST)
Subject: [OFFTOPIC] Re: Y2k compliance
On Fri, 4 Dec 1998, S. Shore wrote:
> In fact, the year 2000 isn't a leap year. A little-known rule of
> leapyears (iirc) is that any year divisible by 100 (i think) can't be a
> leapyear.
And an even less-well-known rule, obviously, is that years divisible by 400
*are* leap years. See http://www.amherst.edu/~atstarr/leapday.html, among
other calendrically-oriented sites.
Mr. Myréen asked whether 2000 being a leap year is a problem, since people
who know the /100 rule probably know the /400 rule as well. I neither wish
to single out Mr. Shore nor make an example out of him, but it appears that
Mr. Myréen's optimism is ill-founded.
(Another rarely-known fact is that the leap day is not the 29th of
February. It's actually the 24th. Inter Gravissimus (-mas?) can make for
interesting reading, when you're bored.)
- --
Jeffrey Sean Connell | Networking/Telecommunications Engineer, GXC
ankh@canuck.gen.nz | PGP key at http://www.canuck.gen.nz/~ankh/pgpkey.html
- ---------------------+-------------------------------------------------------
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: David Feuer <feuer@his.com>
Date: Sat, 05 Dec 1998 00:24:10 -0500
Subject: atomicity
Is there a way for a program to make a section of code atomic? I think
it would be useful to allow root programs (or, for added security, root
programs with special permissions or listed in a certain file) to
protect a certain section of their code so thoroughly that while in that
section
a) the scheduler will not interrupt them
b) they cannot receive _any_ signals, including SIGKILL
If this feature does not exist, I am guessing that writing it will make
it more possible to write such things as background defragmenters,
though additional kernel interfaces would probably be needed to keep the
FS from confusing itself..... e.g.
defragmenter enters protected block
defragger moves a disk block
defragger modifies inode to reflect change
defragger tells FS about change
defragger exits protected block
(note: some changes would be needed for safety: maybe tell FS about
change, then implement, then tell FS complete..., have various dirtiness
flags......)
So the defragmenter flipped around parts of the disk without anybody
else caring. With the defragger running as an idle-process only when
the system load is low, it can effectively keep the disk at near-zero
fragmentation without serious slow-down.
- --
______________________________
/ David Feuer \
| dfeuer@binx.mbhs.edu |
| feuer@his.com |
\ david@feuer.his.com /
-----------------------------
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Andi Kleen <ak@muc.de>
Date: Sat, 5 Dec 1998 06:37:28 +0100
Subject: Re: Linux timekeeping plans
In linux-kernel, you wrote:
> volatile master_lock = 1, slave_lock = 0;
>
>master:
> tell_slave_to_start_calibration();
>
> for (i = 0; i < 100; i++) {
> /* Send to slave */
> while (slave_lock) /* Wait for slave to start spinning */
> ;
> nop(); /* Wait a moment for slave to really start spinning */
> master_time[2*i] = rdtsc();
> master_lock = 1;
>
> /* Receive from slave */
> master_lock = 0; /* Announce that we're spinning */
> while (!slave_lock)
> ;
I think you need mb() after the setting of master/slave_lock to make sure
that the other CPU sees it as early as possible.
- -Andi
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Andi Kleen <ak@muc.de>
Date: Sat, 5 Dec 1998 06:42:11 +0100
Subject: Re: SAR (was Re: disks stats through /proc)
In muc.lists.linux-kernel, you wrote:
>Sorry, Stephen, I wrote my previous message before I read yours so I didn't know
>it's already a fixed thing to go to 2.3 in its current form.
>
>I will try to find something that you haven't done yet :)
Try IO statistics for generic scsi and scsi/other tape devices - Stephen's
sard patch so far only covers block devices and I'm sure a lot of people
would like to measure their backup or cd writing speeds.
A lot of the information that sard uses is not available there, but
you could start with a simple byte counter and get some other things too.
- -Andi
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: <peeter_joot@VNET.IBM.COM> (peeter joot)
Date: Sat, 5 Dec 1998 00:42:04 -0500 (EST)
Subject: Re: limitations on sysv ipc message queues on Linux
Hi Alan,
Splitting msqid_ds like you suggested did the trick nicely -- I am
attaching the new patch below.
I have tested this with a variety of different msgmax/msgmnb values
( MSGMAX/MSGMNB, 5000/MSGMNB, 32K/64K, 64K/192K, 1M/4M, 1M/8M ), and
everything seems to work fine. I also verified that the allocated memory
was being reclaimed.
I think the only thing left to do is implement sysctls for system wide limits
and per process limits. As it stands now if one sets msgmax to 64K then
there is nothing stopping a user from creating 64K*128=8M of unswappable
message buffers.
Since msgmax and msgmnb do retain their defaults (MSGMAX/MSGMNB) unless
they are explictly raised by root, this could be viewed as working as
designed, but 64K is not a particularily unreasonable value (it is the
default on at least a couple other UNIXes), so it would be good to allow
the system administrator to have more selective resource allocation control.
The system wide limits should be easy enough to handle -- msgbytes already
keeps track of that info, but I don't know where the user limits should go.
struct rusage looks like it is the right place, but can this be modified
without breaking apps?
Peeter
- --
Peeter Joot peeterj@ca.ibm.com
IBM DB2 Operating System Services 416-448-3359 (tie line 778)
[This patch is against 2.1.128, because I have been unsuccessful getting
newer kernels from kernel.org for a while.]
- --- include/linux/sysctl.h 1998/11/14 18:20:06 1.1
+++ include/linux/sysctl.h 1998/12/03 04:27:36
@@ -89,6 +89,9 @@
KERN_SG_BIG_BUFF=29,
KERN_ACCT=30, /* BSD process accounting parameters */
KERN_PPC_L2CR=31, /* l2cr register on PPC */
+ KERN_SHMMAX=32, /* int: Maximum shared memory segment */
+ KERN_MSGMAX=33, /* int: Maximum size of a messege */
+ KERN_MSGMNB=34, /* int: Default maximum message queue size */
};
- --- include/linux/msg.h 1998/12/05 01:01:38 1.1
+++ include/linux/msg.h 1998/12/05 01:43:54
@@ -12,18 +12,38 @@
#define MSG_EXCEPT 020000 /* recv any msg except of specified type.*/
/* one msqid structure for each queue on the system */
- -struct msqid_ds {
+struct msqid_ds_base {
struct ipc_perm msg_perm;
struct msg *msg_first; /* first message on queue */
struct msg *msg_last; /* last message in queue */
__kernel_time_t msg_stime; /* last msgsnd time */
__kernel_time_t msg_rtime; /* last msgrcv time */
__kernel_time_t msg_ctime; /* last change time */
+};
+
+#ifdef __KERNEL__
+
+struct msqid_ds_kernel {
+ struct msqid_ds_base u;
struct wait_queue *wwait;
struct wait_queue *rwait;
- - unsigned short msg_cbytes; /* current number of bytes on queue */
+ unsigned int msg_cbytes; /* current number of bytes on queue */
+ unsigned short msg_qnum; /* number of messages in queue */
+ unsigned int msg_qbytes; /* max number of bytes on queue */
+ __kernel_ipc_pid_t msg_lspid; /* pid of last msgsnd */
+ __kernel_ipc_pid_t msg_lrpid; /* last receive pid */
+};
+
+#endif
+
+struct msqid_ds {
+ struct msqid_ds_base u;
+ /* unions used to maintain size on 64 bit platforms */
+ union { void * __wwait ; unsigned int msg_cbytes; } c;
+ union { void * __rwait ; unsigned int msg_qbytes; } q;
+ unsigned short old_msg_cbytes; /* current number of bytes on queue */
unsigned short msg_qnum; /* number of messages in queue */
- - unsigned short msg_qbytes; /* max number of bytes on queue */
+ unsigned short old_msg_qbytes; /* max number of bytes on queue */
__kernel_ipc_pid_t msg_lspid; /* pid of last msgsnd */
__kernel_ipc_pid_t msg_lrpid; /* last receive pid */
};
@@ -66,7 +86,7 @@
long msg_type;
char *msg_spot; /* message text address */
time_t msg_stime; /* msgsnd time */
- - short msg_ts; /* message text size */
+ int msg_ts; /* message text size */
};
asmlinkage int sys_msgget (key_t key, int msgflg);
- --- ipc/msg.c 1998/12/03 04:20:52 1.1
+++ ipc/msg.c 1998/12/05 04:31:03
@@ -2,11 +2,12 @@
* linux/ipc/msg.c
* Copyright (C) 1992 Krishna Balasubramanian
*
+ * Remove 4056 byte MSGMAX restriction and 64K restrictions, limits made dynamic
* Removed all the remaining kerneld mess
* Catch the -EFAULT stuff properly
* Use GFP_KERNEL for messages as in 1.2
* Fixed up the unchecked user space derefs
- - * Copyright (C) 1998 Alan Cox & Andi Kleen
+ * Copyright (C) 1998 Alan Cox, Andi Kleen & Peeter Joot
*
*/
@@ -19,6 +20,7 @@
#include <linux/smp.h>
#include <linux/smp_lock.h>
#include <linux/init.h>
+#include <linux/vmalloc.h>
#include <asm/uaccess.h>
@@ -28,7 +30,7 @@
static int newque (key_t key, int msgflg);
static int findkey (key_t key);
- -static struct msqid_ds *msgque[MSGMNI];
+static struct msqid_ds_kernel *msgque[MSGMNI];
static int msgbytes = 0;
static int msghdrs = 0;
static unsigned short msg_seq = 0;
@@ -36,12 +38,15 @@
static int max_msqid = 0;
static struct wait_queue *msg_lock = NULL;
+int msgmax = MSGMAX;
+int msgmnb = MSGMNB;
+
void __init msg_init (void)
{
int id;
for (id = 0; id < MSGMNI; id++)
- - msgque[id] = (struct msqid_ds *) IPC_UNUSED;
+ msgque[id] = (struct msqid_ds_kernel *) IPC_UNUSED;
msgbytes = msghdrs = msg_seq = max_msqid = used_queues = 0;
msg_lock = NULL;
return;
@@ -49,13 +54,13 @@
static int real_msgsnd (int msqid, struct msgbuf *msgp, size_t msgsz, int msgflg)
{
- - int id;
- - struct msqid_ds *msq;
+ int id, error;
+ struct msqid_ds_kernel *msq;
struct ipc_perm *ipcp;
struct msg *msgh;
long mtype;
- - if (msgsz > MSGMAX || (long) msgsz < 0 || msqid < 0)
+ if (msgsz > msgmax || (long) msgsz < 0 || msqid < 0)
return -EINVAL;
if (get_user(mtype, &msgp->mtype))
return -EFAULT;
@@ -65,43 +70,53 @@
msq = msgque [id];
if (msq == IPC_UNUSED || msq == IPC_NOID)
return -EINVAL;
- - ipcp = &msq->msg_perm;
+ ipcp = &msq->u.msg_perm;
slept:
- - if (msq->msg_perm.seq != (unsigned int) msqid / MSGMNI)
+ if (msq->u.msg_perm.seq != (unsigned int) msqid / MSGMNI)
return -EIDRM;
if (ipcperms(ipcp, S_IWUGO))
return -EACCES;
- -
+
+ /* There were two identical if statements here? */
if (msgsz + msq->msg_cbytes > msq->msg_qbytes) {
- - if (msgsz + msq->msg_cbytes > msq->msg_qbytes) {
- - /* still no space in queue */
- - if (msgflg & IPC_NOWAIT)
- - return -EAGAIN;
- - if (signal_pending(current))
- - return -EINTR;
- - interruptible_sleep_on (&msq->wwait);
- - goto slept;
- - }
+ /* still no space in queue */
+ if (msgflg & IPC_NOWAIT)
+ return -EAGAIN;
+ if (signal_pending(current))
+ return -EINTR;
+ interruptible_sleep_on (&msq->wwait);
+ goto slept;
}
- -
+
/* allocate message header and text space*/
- - msgh = (struct msg *) kmalloc (sizeof(*msgh) + msgsz, GFP_KERNEL);
- - if (!msgh)
- - return -ENOMEM;
- - msgh->msg_spot = (char *) (msgh + 1);
+ if (msgsz < MSGMAX) {
+ /* Standard small message: */
+ msgh = (struct msg *) kmalloc (sizeof(*msgh) + msgsz,
+ GFP_KERNEL);
+ if (!msgh)
+ return -ENOMEM;
+ msgh->msg_spot = (char *) (msgh + 1);
+ } else {
+ msgh = (struct msg *) kmalloc (sizeof(*msgh), GFP_KERNEL);
+ if (!msgh)
+ return -ENOMEM;
+ msgh->msg_spot = (char *) vmalloc(msgsz);
+ if (!msgh->msg_spot)
+ kfree(msgh);
+ }
if (copy_from_user(msgh->msg_spot, msgp->mtext, msgsz))
{
- - kfree(msgh);
- - return -EFAULT;
+ error = -EFAULT;
+ goto free_buf;
}
if (msgque[id] == IPC_UNUSED || msgque[id] == IPC_NOID
- - || msq->msg_perm.seq != (unsigned int) msqid / MSGMNI) {
- - kfree(msgh);
- - return -EIDRM;
+ || msq->u.msg_perm.seq != (unsigned int) msqid / MSGMNI) {
+ error = -EIDRM;
+ goto free_buf;
}
msgh->msg_next = NULL;
@@ -109,25 +124,31 @@
msgh->msg_type = mtype;
msgh->msg_stime = CURRENT_TIME;
- - if (!msq->msg_first)
- - msq->msg_first = msq->msg_last = msgh;
+ if (!msq->u.msg_first)
+ msq->u.msg_first = msq->u.msg_last = msgh;
else {
- - msq->msg_last->msg_next = msgh;
- - msq->msg_last = msgh;
+ msq->u.msg_last->msg_next = msgh;
+ msq->u.msg_last = msgh;
}
msq->msg_cbytes += msgsz;
msgbytes += msgsz;
msghdrs++;
msq->msg_qnum++;
msq->msg_lspid = current->pid;
- - msq->msg_stime = CURRENT_TIME;
+ msq->u.msg_stime = CURRENT_TIME;
wake_up (&msq->rwait);
return 0;
+
+free_buf:
+ if (msgsz >= MSGMAX)
+ vfree(msgh->msg_spot);
+ kfree(msgh);
+ return error;
}
static int real_msgrcv (int msqid, struct msgbuf *msgp, size_t msgsz, long msgtyp, int msgflg)
{
- - struct msqid_ds *msq;
+ struct msqid_ds_kernel *msq;
struct ipc_perm *ipcp;
struct msg *tmsg, *leastp = NULL;
struct msg *nmsg = NULL;
@@ -140,7 +161,7 @@
msq = msgque [id];
if (msq == IPC_NOID || msq == IPC_UNUSED)
return -EINVAL;
- - ipcp = &msq->msg_perm;
+ ipcp = &msq->u.msg_perm;
/*
* find message of correct type.
@@ -149,7 +170,7 @@
* msgtyp < 0 => get message with least type must be < abs(msgtype).
*/
while (!nmsg) {
- - if (msq->msg_perm.seq != (unsigned int) msqid / MSGMNI) {
+ if (msq->u.msg_perm.seq != (unsigned int) msqid / MSGMNI) {
return -EIDRM;
}
if (ipcperms (ipcp, S_IRUGO)) {
@@ -157,23 +178,23 @@
}
if (msgtyp == 0)
- - nmsg = msq->msg_first;
+ nmsg = msq->u.msg_first;
else if (msgtyp > 0) {
if (msgflg & MSG_EXCEPT) {
- - for (tmsg = msq->msg_first; tmsg;
+ for (tmsg = msq->u.msg_first; tmsg;
tmsg = tmsg->msg_next)
if (tmsg->msg_type != msgtyp)
break;
nmsg = tmsg;
} else {
- - for (tmsg = msq->msg_first; tmsg;
+ for (tmsg = msq->u.msg_first; tmsg;
tmsg = tmsg->msg_next)
if (tmsg->msg_type == msgtyp)
break;
nmsg = tmsg;
}
} else {
- - for (leastp = tmsg = msq->msg_first; tmsg;
+ for (leastp = tmsg = msq->u.msg_first; tmsg;
tmsg = tmsg->msg_next)
if (tmsg->msg_type < leastp->msg_type)
leastp = tmsg;
@@ -186,21 +207,21 @@
return -E2BIG;
}
msgsz = (msgsz > nmsg->msg_ts)? nmsg->msg_ts : msgsz;
- - if (nmsg == msq->msg_first)
- - msq->msg_first = nmsg->msg_next;
+ if (nmsg == msq->u.msg_first)
+ msq->u.msg_first = nmsg->msg_next;
else {
- - for (tmsg = msq->msg_first; tmsg;
+ for (tmsg = msq->u.msg_first; tmsg;
tmsg = tmsg->msg_next)
if (tmsg->msg_next == nmsg)
break;
tmsg->msg_next = nmsg->msg_next;
- - if (nmsg == msq->msg_last)
- - msq->msg_last = tmsg;
+ if (nmsg == msq->u.msg_last)
+ msq->u.msg_last = tmsg;
}
if (!(--msq->msg_qnum))
- - msq->msg_last = msq->msg_first = NULL;
+ msq->u.msg_last = msq->u.msg_first = NULL;
- - msq->msg_rtime = CURRENT_TIME;
+ msq->u.msg_rtime = CURRENT_TIME;
msq->msg_lrpid = current->pid;
msgbytes -= nmsg->msg_ts;
msghdrs--;
@@ -209,6 +230,8 @@
if (put_user (nmsg->msg_type, &msgp->mtype) ||
copy_to_user (msgp->mtext, nmsg->msg_spot, msgsz))
msgsz = -EFAULT;
+ if (nmsg->msg_ts >= MSGMAX)
+ vfree(nmsg->msg_spot);
kfree(nmsg);
return msgsz;
} else { /* did not find a message */
@@ -248,14 +271,14 @@
static int findkey (key_t key)
{
int id;
- - struct msqid_ds *msq;
+ struct msqid_ds_kernel *msq;
for (id = 0; id <= max_msqid; id++) {
while ((msq = msgque[id]) == IPC_NOID)
interruptible_sleep_on (&msg_lock);
if (msq == IPC_UNUSED)
continue;
- - if (key == msq->msg_perm.key)
+ if (key == msq->u.msg_perm.key)
return id;
}
return -1;
@@ -264,48 +287,48 @@
static int newque (key_t key, int msgflg)
{
int id;
- - struct msqid_ds *msq;
+ struct msqid_ds_kernel *msq;
struct ipc_perm *ipcp;
for (id = 0; id < MSGMNI; id++)
if (msgque[id] == IPC_UNUSED) {
- - msgque[id] = (struct msqid_ds *) IPC_NOID;
+ msgque[id] = (struct msqid_ds_kernel *) IPC_NOID;
goto found;
}
return -ENOSPC;
found:
- - msq = (struct msqid_ds *) kmalloc (sizeof (*msq), GFP_KERNEL);
+ msq = (struct msqid_ds_kernel *) kmalloc (sizeof (*msq), GFP_KERNEL);
if (!msq) {
- - msgque[id] = (struct msqid_ds *) IPC_UNUSED;
+ msgque[id] = (struct msqid_ds_kernel *) IPC_UNUSED;
wake_up (&msg_lock);
return -ENOMEM;
}
- - ipcp = &msq->msg_perm;
+ ipcp = &msq->u.msg_perm;
ipcp->mode = (msgflg & S_IRWXUGO);
ipcp->key = key;
ipcp->cuid = ipcp->uid = current->euid;
ipcp->gid = ipcp->cgid = current->egid;
- - msq->msg_perm.seq = msg_seq;
- - msq->msg_first = msq->msg_last = NULL;
+ msq->u.msg_perm.seq = msg_seq;
+ msq->u.msg_first = msq->u.msg_last = NULL;
msq->rwait = msq->wwait = NULL;
msq->msg_cbytes = msq->msg_qnum = 0;
msq->msg_lspid = msq->msg_lrpid = 0;
- - msq->msg_stime = msq->msg_rtime = 0;
- - msq->msg_qbytes = MSGMNB;
- - msq->msg_ctime = CURRENT_TIME;
+ msq->u.msg_stime = msq->u.msg_rtime = 0;
+ msq->msg_qbytes = msgmnb;
+ msq->u.msg_ctime = CURRENT_TIME;
if (id > max_msqid)
max_msqid = id;
msgque[id] = msq;
used_queues++;
wake_up (&msg_lock);
- - return (unsigned int) msq->msg_perm.seq * MSGMNI + id;
+ return (unsigned int) msq->u.msg_perm.seq * MSGMNI + id;
}
asmlinkage int sys_msgget (key_t key, int msgflg)
{
int id, ret = -EPERM;
- - struct msqid_ds *msq;
+ struct msqid_ds_kernel *msq;
lock_kernel();
if (key == IPC_PRIVATE)
@@ -321,10 +344,10 @@
msq = msgque[id];
if (msq == IPC_UNUSED || msq == IPC_NOID)
ret = -EIDRM;
- - else if (ipcperms(&msq->msg_perm, msgflg))
+ else if (ipcperms(&msq->u.msg_perm, msgflg))
ret = -EACCES;
else
- - ret = (unsigned int) msq->msg_perm.seq * MSGMNI + id;
+ ret = (unsigned int) msq->u.msg_perm.seq * MSGMNI + id;
}
unlock_kernel();
return ret;
@@ -332,24 +355,26 @@
static void freeque (int id)
{
- - struct msqid_ds *msq = msgque[id];
+ struct msqid_ds_kernel *msq = msgque[id];
struct msg *msgp, *msgh;
- - msq->msg_perm.seq++;
+ msq->u.msg_perm.seq++;
msg_seq = (msg_seq+1) % ((unsigned)(1<<31)/MSGMNI); /* increment, but avoid overflow */
msgbytes -= msq->msg_cbytes;
if (id == max_msqid)
while (max_msqid && (msgque[--max_msqid] == IPC_UNUSED));
- - msgque[id] = (struct msqid_ds *) IPC_UNUSED;
+ msgque[id] = (struct msqid_ds_kernel *) IPC_UNUSED;
used_queues--;
while (waitqueue_active(&msq->rwait) || waitqueue_active(&msq->wwait)) {
wake_up (&msq->rwait);
wake_up (&msq->wwait);
schedule();
}
- - for (msgp = msq->msg_first; msgp; msgp = msgh ) {
+ for (msgp = msq->u.msg_first; msgp; msgp = msgh ) {
msgh = msgp->msg_next;
msghdrs--;
+ if (msgp->msg_ts >= MSGMAX)
+ vfree(msgp->msg_spot);
kfree(msgp);
}
kfree(msq);
@@ -358,9 +383,10 @@
asmlinkage int sys_msgctl (int msqid, int cmd, struct msqid_ds *buf)
{
int id, err = -EINVAL;
- - struct msqid_ds *msq;
+ struct msqid_ds_kernel *msq;
struct msqid_ds tbuf;
struct ipc_perm *ipcp;
+ unsigned int msg_qbytes;
lock_kernel();
if (msqid < 0 || cmd < 0)
@@ -374,8 +400,8 @@
{
struct msginfo msginfo;
msginfo.msgmni = MSGMNI;
- - msginfo.msgmax = MSGMAX;
- - msginfo.msgmnb = MSGMNB;
+ msginfo.msgmax = msgmax;
+ msginfo.msgmnb = msgmnb;
msginfo.msgmap = MSGMAP;
msginfo.msgpool = MSGPOOL;
msginfo.msgtql = MSGTQL;
@@ -403,16 +429,18 @@
if (msq == IPC_UNUSED || msq == IPC_NOID)
goto out;
err = -EACCES;
- - if (ipcperms (&msq->msg_perm, S_IRUGO))
+ if (ipcperms (&msq->u.msg_perm, S_IRUGO))
goto out;
- - id = (unsigned int) msq->msg_perm.seq * MSGMNI + msqid;
- - tbuf.msg_perm = msq->msg_perm;
- - tbuf.msg_stime = msq->msg_stime;
- - tbuf.msg_rtime = msq->msg_rtime;
- - tbuf.msg_ctime = msq->msg_ctime;
- - tbuf.msg_cbytes = msq->msg_cbytes;
+ id = (unsigned int) msq->u.msg_perm.seq * MSGMNI + msqid;
+ tbuf.u.msg_perm = msq->u.msg_perm;
+ tbuf.u.msg_stime = msq->u.msg_stime;
+ tbuf.u.msg_rtime = msq->u.msg_rtime;
+ tbuf.u.msg_ctime = msq->u.msg_ctime;
+ tbuf.c.msg_cbytes = msq->msg_cbytes;
+ tbuf.q.msg_qbytes = msq->msg_qbytes;
+ tbuf.old_msg_cbytes = (unsigned short)msq->msg_cbytes;
tbuf.msg_qnum = msq->msg_qnum;
- - tbuf.msg_qbytes = msq->msg_qbytes;
+ tbuf.old_msg_qbytes = (unsigned short)msq->msg_qbytes;
tbuf.msg_lspid = msq->msg_lspid;
tbuf.msg_lrpid = msq->msg_lrpid;
err = -EFAULT;
@@ -439,22 +467,24 @@
if (msq == IPC_UNUSED || msq == IPC_NOID)
goto out;
err = -EIDRM;
- - if (msq->msg_perm.seq != (unsigned int) msqid / MSGMNI)
+ if (msq->u.msg_perm.seq != (unsigned int) msqid / MSGMNI)
goto out;
- - ipcp = &msq->msg_perm;
+ ipcp = &msq->u.msg_perm;
switch (cmd) {
case IPC_STAT:
err = -EACCES;
if (ipcperms (ipcp, S_IRUGO))
goto out;
- - tbuf.msg_perm = msq->msg_perm;
- - tbuf.msg_stime = msq->msg_stime;
- - tbuf.msg_rtime = msq->msg_rtime;
- - tbuf.msg_ctime = msq->msg_ctime;
- - tbuf.msg_cbytes = msq->msg_cbytes;
+ tbuf.u.msg_perm = msq->u.msg_perm;
+ tbuf.u.msg_stime = msq->u.msg_stime;
+ tbuf.u.msg_rtime = msq->u.msg_rtime;
+ tbuf.u.msg_ctime = msq->u.msg_ctime;
+ tbuf.c.msg_cbytes = msq->msg_cbytes;
+ tbuf.q.msg_qbytes = msq->msg_qbytes;
+ tbuf.old_msg_cbytes = (unsigned short)msq->msg_cbytes;
tbuf.msg_qnum = msq->msg_qnum;
- - tbuf.msg_qbytes = msq->msg_qbytes;
+ tbuf.old_msg_qbytes = (unsigned short)msq->msg_qbytes;
tbuf.msg_lspid = msq->msg_lspid;
tbuf.msg_lrpid = msq->msg_lrpid;
err = -EFAULT;
@@ -467,14 +497,18 @@
current->euid != ipcp->uid && !capable(CAP_SYS_ADMIN))
/* We _could_ check for CAP_CHOWN above, but we don't */
goto out;
- - if (tbuf.msg_qbytes > MSGMNB && !capable(CAP_SYS_RESOURCE))
+ if (tbuf.old_msg_qbytes == 0)
+ msg_qbytes = tbuf.q.msg_qbytes;
+ else
+ msg_qbytes = tbuf.old_msg_qbytes;
+ if (msg_qbytes > msgmnb && !capable(CAP_SYS_RESOURCE))
goto out;
- - msq->msg_qbytes = tbuf.msg_qbytes;
- - ipcp->uid = tbuf.msg_perm.uid;
- - ipcp->gid = tbuf.msg_perm.gid;
+ msq->msg_qbytes = msg_qbytes;
+ ipcp->uid = tbuf.u.msg_perm.uid;
+ ipcp->gid = tbuf.u.msg_perm.gid;
ipcp->mode = (ipcp->mode & ~S_IRWXUGO) |
- - (S_IRWXUGO & tbuf.msg_perm.mode);
- - msq->msg_ctime = CURRENT_TIME;
+ (S_IRWXUGO & tbuf.u.msg_perm.mode);
+ msq->u.msg_ctime = CURRENT_TIME;
err = 0;
goto out;
case IPC_RMID:
- --- ipc/shm.c 1998/11/14 18:20:06 1.1
+++ ipc/shm.c 1998/11/14 18:21:41
@@ -133,6 +133,8 @@
return (unsigned int) shp->u.shm_perm.seq * SHMMNI + id;
}
+int shmmax = SHMMAX;
+
asmlinkage int sys_shmget (key_t key, int size, int shmflg)
{
struct shmid_kernel *shp;
@@ -140,7 +142,7 @@
down(¤t->mm->mmap_sem);
lock_kernel();
- - if (size < 0 || size > SHMMAX) {
+ if (size < 0 || size > shmmax) {
err = -EINVAL;
} else if (key == IPC_PRIVATE) {
err = newseg(key, shmflg, size);
@@ -235,7 +237,7 @@
if (!buf)
goto out;
shminfo.shmmni = SHMMNI;
- - shminfo.shmmax = SHMMAX;
+ shminfo.shmmax = shmmax;
shminfo.shmmin = SHMMIN;
shminfo.shmall = SHMALL;
shminfo.shmseg = SHMSEG;
- --- kernel/sysctl.c 1998/11/14 18:20:06 1.1
+++ kernel/sysctl.c 1998/12/03 04:42:29
@@ -46,6 +46,11 @@
#ifdef CONFIG_CHR_DEV_SG
extern int sg_big_buff;
#endif
+#ifdef CONFIG_SYSVIPC
+extern int shmmax;
+extern int msgmax;
+extern int msgmnb;
+#endif
#ifdef __sparc__
extern char reboot_command [];
@@ -198,6 +203,14 @@
#ifdef CONFIG_BSD_PROCESS_ACCT
{KERN_ACCT, "acct", &acct_parm, 3*sizeof(int),
0644, NULL, &proc_dointvec},
+#endif
+#ifdef CONFIG_SYSVIPC
+ {KERN_SHMMAX, "shmmax", &shmmax, sizeof (int),
+ 0644, NULL, &proc_dointvec},
+ {KERN_MSGMAX, "msgmax", &msgmax, sizeof (int),
+ 0644, NULL, &proc_dointvec},
+ {KERN_MSGMNB, "msgmnb", &msgmnb, sizeof (int),
+ 0644, NULL, &proc_dointvec},
#endif
{0}
};
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: David Feuer <feuer@his.com>
Date: Sat, 05 Dec 1998 00:42:42 -0500
Subject: memory management
It seems from what I've seen on this list that there may not be one
(finitely described) set of memory management algorithms that are
optimal for all systems. I think it might be a good idea to provide
several separate algorithms, each optimized for certain amounts of
physical RAM and certain system conditions (e.g. lots of little
processes vs. a few big ones, lots of CPU-intensive processes vs. mostly
disk-bound, huge hard-drive vs. embedded system.....). The memory
management could be selected by
(in increasing order of flexibility and decreasing order of ease of
implementation)
a) configuration options, with well-written help pages so users can
figure out what is likely best for their system.
b) lilo/loadlin/rdev boot parameters with docs
c) loadable modules with docs
I think this could help everybody.
- --
______________________________
/ David Feuer \
| dfeuer@binx.mbhs.edu |
| feuer@his.com |
\ david@feuer.his.com /
-----------------------------
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Vladimir Dergachev <vdergach@sas.upenn.edu>
Date: Sat, 5 Dec 1998 00:49:32 -0500 (EST)
Subject: 2.1.131 notes.
I have tried 2.1.131. Works ok, with a few bugs :
1. I have a cd-rom that sometimes doesn't work well (i.e. it locks up,
opening and closing door makes it work) 2.1.130 and 2.1.131 make an oops
in mount when they try to mount /dev/hdc at boot.
(I can send an appropriate oops/ksym/ksymoops files upon request)
2. atyfb still doesn't work for me (in spite of ioremap changes)
3. The following is the output of cat /proc/partitiions:
3 0 7034328 hda
3 1 1638598 hda1
3 2 1 hda2
3 5 1638598 hda5
3 6 72261 hda6
3 7 409626 hda7
3 8 3253131 hda8
3 64 9772560 hdb
3 65 128488 hdb1
3 66 128520 hdb2
22 0 1073741823 hdc
You can see that /dev/hdc has some strange value (it's cdrom) and it's
mounted. (i.e. it is ok at the moment).
4. Not a bug... Maybe it would make sense if modules that are compiled in
would also be displayed in /proc/modules with (compiled in) note ?
This way /proc/modules will tell the current configuration of the kernel.
thanks
Vladimir Dergachev
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
End of linux-kernel-digest V1 #2946
***********************************
To subscribe to linux-kernel-digest, send the command:
subscribe linux-kernel-digest
in the body of a message to "Majordomo@vger.rutgers.edu". If you want
to subscribe something other than the account the mail is coming from,
such as a local redistribution list, then append that address to the
"subscribe" command; for example, to subscribe "local-linux-kernel":
subscribe linux-kernel-digest local-linux-kernel@your.domain.net
A non-digest (direct mail) version of this list is also available; to
subscribe to that instead, replace all instances of "linux-kernel-digest"
in the commands above with "linux-kernel".
!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/