Messages in this thread Patch in this message | | | Date | Sun, 06 Dec 1998 07:43:30 +0800 | From | Foong Wai Ho <> | Subject | Re:linux-kernel-digest V1 #2946 |
| |
I am on leave from 7/12/98 till 9/12/98. For urgent matters you may resend the mail to :
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/
| |