Messages in this thread Patches in this message | | | Date | Sun, 06 Dec 1998 02:27:09 +0800 | From | Foong Wai Ho <> | Subject | Re:linux-kernel-digest V1 #2944 |
| |
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/05/98 17:41 >>>
linux-kernel-digest Saturday, 5 December 1998 Volume 01 : Number 2944
In this issue:
Re: NO ROM BASIC Absolutely Horride UDMA performace... resolved more or less ext2 fs corruption in 2.1.131+DAC960-2.1-beta3+knfsd-981122 Re: /dev/temperature 2.1.131 modules_install---fs twice Re: cua* on kernel 2.1 and beyond scripts/Configure bug, perhaps? Re: [patch] morethan900MB-2.0.36 Re: Dead Machine & 2.1.131 Re: /proc and /kern Re: [OFFTOPIC] Re: linux kernel hackers discover new theory of relativity! Please try knfsd-981204 Re: Dumb question: Which is "better" SCSI or IDE disks? Re: Linux timekeeping plans Re: Machine Dead on 2.1.131 Re: Linux timekeeping plans Re: NO ROM BASIC Re: UDP bad checksum :) Re: [PATCH] swapin readahead and fixes [PATCH] Fix to truncate memory_end if > possible maximum Re: /proc and /kern Re: 2.1.131 compile; crash and burn Re: Problem with 1G RAM Re: IDE disk geometry + patch 2.1.131 Kernel panic while booting Re: suspendd-v0.1.0 released Re: Problem with 1G RAM Re: IDE disk geometry + patch Re: [PATCH] swapin readahead and fixes Re: /proc and /kern Re: Synchronous protocols on Linux [PATCH] More rmdir fixes (was: Linux-2.1.131..)
See the end of the digest for information on subscribing to the linux-kernel or linux-kernel-digest mailing lists.
----------------------------------------------------------------------
From: Mark Szlaga <mszlaga@engin.umd.umich.edu> Date: Fri, 4 Dec 1998 12:48:43 -0500 (EST) Subject: Re: NO ROM BASIC
Greetings, I have actually had this occur due to a software malfunction before... The cause was actually the fact that my MBR got fried AND I had no active boot partition. All that was necessary to fix this was booting off a floppy and making that partition active. For a linux only system this can be complex, but if DOS is your first partition just get the stock DOS disk, fdisk to enable an active partition, then fdisk /mbr to be safe. this may toast Lilo, but it will be a bootable system. But one way or another, it is a BIOS problem, and maybe further a Hardware problem. I agree.
Mark
On Thu, 3 Dec 1998, Kenneth D'Ambrosio wrote:
> That's not a kernel issue -- that's what a non-IBM(tm) machine says when > it can't find a boot device. In other words, your hard drive is, somehow, > not communicating with the system. Watch your power-up stuff, and you'll > most likely see that the hard drive isn't being mentioned. Check your > cables, make sure the BIOS is configured properly, make sure your ID > jumpers are correct, and, lastly, listen to see if the drive itself is > spinning up -- it may have died. NOTE: this is a HARDWARE issue; merely > blowing away your MBR wouldn't give you this error; then you'd get a > "Can't find OS" or some such error. > > Ken D'Ambrosio > SysAdmin, > Cisco Systems, Inc. > kend@cisco.com > > P.S. A True Blue IBM machine actually *would* load up basica, which is > stored (or, at least, used to be) in ROM. Pretty damn useless, but fun. > Also true for Compaq, when they used to license the IBM BIOS. > > > On Thu, 3 Dec 1998, Konstantyn Prokopenko wrote: > > > Date: Thu, 3 Dec 1998 10:29:57 -0500 (EST) > > From: Konstantyn Prokopenko <kproko@analogic.com> > > To: linux-kernel@vger.rutgers.edu > > Subject: NO ROM BASIC > > > > Hi! > > > > I'm new in Linux and I've got a problem compiling a kernel. > > I have dual PENTIUM II motherboard with 128 Mb memory runing Red Hat > > Linux. I compiled the 2.1.128 Linux kernel using: > > > > make config > > make dep > > make bzImage > > make install > > > > > > Then I rebooted. When it starts, it goes to 40 column mode and > > says "NO ROM BASIC" > > > > > > Sincerely, > > > > K.V.P > > > > > > - > > 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/ > > > > > - > 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/ >
- -- Mark Szlaga mszlaga@umd.umich.edu http://www.umd.umich.edu/~mszlaga/ /dev/hdb5 - 0.5Gb of spinning metal, all alone in the night... - - unknown - alt.sysadmin.recovery /dev/hdb5 - our last best hope for free space... - - Chip Salzenberg - <chip@pobox.com>
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: "Brian Macy" <bmacy@sunshinecomputing.com> Date: Fri, 4 Dec 1998 09:52:22 -0800 Subject: Absolutely Horride UDMA performace... resolved more or less
Just thought I'd let those interesting know that upgrading to the 2.1.131 kernel from 2.0.35 fixed my UDMA performance problems. I now get 12.5meg/sec in both dd and hdparm. I still don't know why it didn't work in 2.0.35 but it works now :)
I would have upgraded soon except I haven't gotten modules to work in the 2.1.128-2.1.131 kernels so my eth0 and eth1 got swapped. I had to change my network/firewall scripts to match.
Brian Macy
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: David Mansfield <david@cobite.com> Date: Fri, 4 Dec 1998 12:54:17 -0500 (EST) Subject: ext2 fs corruption in 2.1.131+DAC960-2.1-beta3+knfsd-981122
This is not a success story :-(
I am running the above kernel compiled UP w/gcc 2.7.2.3 on a PII 450, 256MB ram, basically RedHat 5.1 (actually it's a VAResearch box). I have been trying to determine the stability of the current kernel dev. for being an NFS server. I have managed to get these errors:
EXT2-fs error (device 30:04): ext2_check_blocks_bitmap: Wrong free blocks count for group 83, stored = 1551, counted = 1036 EXT2-fs error (device 30:04): ext2_new_block: Free blocks count corrupted for block group 83
The fs in question is on a RAID-5 logical volume on the DAC960PG, and is basically empty, and about 20GB. Nothing has touched this fs (since I got the machine) except bonnie, and bonnie from a remote NFS client.
See also a previous post about 'knfsd strangeness' from yesterday. Here are the things I have been doing (not all simultaneous, but some :-):
bonnie -s 1000m on the ext2 fs in question bonnie -s 500m x5 simultaneous Mount fs from linux 2.0.35 client and bonnie -s 100m Mount fs from solaris 2.5 client and bonnie -s 100m Mount fs from solaris 2.6 client and bonnie -s 100m Mount fs using NFS from local machine (loopback NFS?) and bonnie -s 500m make -j 100 zImage (not on this fs but simultaneous to bonnie x5)
Other errors in syslog include:
<cut> nfs: server spike not responding, still trying nfs: server spike not responding, still trying nfs: task 1078 can't get a request slot nfs: task 1079 can't get a request slot nfs: server spike OK </cut>
same as above with lots of different task #'s
<cut> mountd[624]: authenticated mount request from marvin.cobite.com:884 kernel: nfsd: connect from unprivileged port: cf8e8816:36381<4>nfsd: accept failed (err 11)! kernel: nfsd: accept failed (err 11)! kernel: svc: unknown program 100227 (me 100003) </cut>
(marvin is solaris 2.6)
After unmounting, fsck went through cleanly until 'fix summary info' then:
IMMENSE #'s of messages like '-754395 -754396 -754397 -754398 -754399'. Tens of thousands. And then stuff like:
Free blocks count wrong for group 115 (0, counted=7854). FIXED Free blocks count wrong for group 116 (0, counted=7854). FIXED Free blocks count wrong for group 117 (0, counted=7854). FIXED Free blocks count wrong for group 118 (0, counted=7854). FIXED
Free blocks count wrong (19069902, counted=19562827). FIXED Inode bitmap differences: -30723. FIXED Free inodes count wrong for group #15 (2045, counted=2046). FIXED Free inodes count wrong (5119769, counted=5119770). FIXED
Thanks for listening. David
- -- /==============================\ | David Mansfield | | david@cobite.com | \==============================/
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Riley Williams <rhw@bigfoot.com> Date: Fri, 4 Dec 1998 18:04:38 +0000 (GMT) Subject: Re: /dev/temperature
Hi Kurt.
>> Could someone please point me to the patch set that makes the >> current CPU temperature and fan speed on newer P-II boards >> available through /dev/temperature?
> Use the lm-sensors package: http://www.netroedge.com/~lm78/
Maybe I've got the wrong end of the stick, but I thought that /dev/temperature was used by one of the hardware watchdogs?
Best wishes from Riley.
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: =?iso-8859-1?Q?Johnny_Teve=DFen?= <j.tevessen@gmx.net> Date: Fri, 4 Dec 1998 18:55:04 +0100 Subject: 2.1.131 modules_install---fs twice
Quoting Nick Holloway (Nick.Holloway@alfie.demon.co.uk):
[I retried it with 2.1.131 and the problem persists]
> Because FS and NLS modules are installed into the fs directory: > > [Taken from Makefile] > if [ -f FS_MODULES ]; then inst_mod FS_MODULES fs; fi; \ > if [ -f NLS_MODULES ]; then inst_mod NLS_MODULES fs; fi; \
This should be changed, since it is confusing.
What about saying "Installing *NLS* modules under /lib/modules/current/fs"?
johnny - -- Trust no-one.
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Riley Williams <rhw@bigfoot.com> Date: Fri, 4 Dec 1998 18:21:44 +0000 (GMT) Subject: Re: cua* on kernel 2.1 and beyond
Hi there.
>> I think i read somewhere, that the cua* devices for serial >> were going to be made obselite..
>> Im just wondering about this as far as compatability with other >> sources built on FreeBSD or such that, by default may use cua*.
> Tis true. ;-) cua is out, ttys is in, why I'm not sure, although > I'd be interested to know myself for curiosity.
There's not exactly a great deal of compatibility problem there: run the following script and fix it for good...
Q> #!/bin/bash Q> cd /dev Q> rm -f cua? Q> for Z in 0 1 2 3 ; do Q> mknod cua$Z c 4 6$Z Q> done
Best wishes from Riley.
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Jamie Lokier <lkd@tantalophile.demon.co.uk> Date: Fri, 4 Dec 1998 18:28:42 +0000 Subject: scripts/Configure bug, perhaps?
I did `make oldconfig' today on a 2.1.131 tree, running on a 2.1.129ac3 kernel.
I got an error message (see below, look for the line starting "scripts/Configure:"). Is the message anything to be worried about? I.e., is it a kernel problem or a problem with the script?
Sorry I don't have more details.
- -- Jamie
Amateur Radio support (CONFIG_HAMRADIO) [N/y/?] * * ISDN subsystem * ISDN support (CONFIG_ISDN) [N/y/m/?] * * CD-ROM drivers (not for SCSI or IDE/ATAPI drives) * scripts/Configure: Can't reopen pipe to command substitution (fd 5): No child processes Support non-SCSI/IDE/ATAPI CDROM drives (CONFIG_CD_NO_IDESCSI) [N/y/?] (NEW)
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: "Leonard N. Zubkoff" <lnz@dandelion.com> Date: Fri, 4 Dec 1998 10:32:50 -0800 Subject: Re: [patch] morethan900MB-2.0.36
Date: Fri, 4 Dec 1998 16:50:53 +0100 (CET) From: MOLNAR Ingo <mingo@chiara.csoma.elte.hu>
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. Similarly, large scientific applications probably need large individual data segments. 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.
What's the performance disadvantage with a 2GB+2GB split?
Leonard
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Michael K Vance <mkv102@psu.edu> Date: Fri, 04 Dec 1998 13:28:38 -0500 Subject: Re: Dead Machine & 2.1.131
Rik van Riel wrote:
> What exactly is xfstt and what is it doing to your machine?
It is a True Type font server for X. I installed it. > OTOH, if xfstt runs as root and directly accesses I/O ports, > then there isn't much we can do... (a usermode device driver
It doesn't run as root, it runs from a user account. It uses the inet interface to do port communication, I believe.
m.
- -- "Up above aliens hover making home movies for the folks back home, of all these weird creatures who lock up their spirits, drill holes in themselves and live for their secrets. They're all uptight." -Thom Yorke, Radiohead
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Mirian Crzig Lennox <mirian@xensei.com> Date: 04 Dec 1998 13:38:03 -0500 Subject: Re: /proc and /kern
o.r.c@p.e.l.l.p.o.r.t.l.a.n.d.o.r.u.s (david parsons) writes:
> >Anyway, the question I have is this: I would like to work on splitting > >/proc into /proc and /kern, such that /proc is only for process > >information and /kern is for kernel structures. > > Unless you also write a union filesystem so that those of us who > are anal about backwards compatability won't be royally bitten in > the ass, it's a really really really dumb idea.
I thought making the change configurable would take care of that. What do you think about Alain Williams' symlink suggestion?
> (On the other > hand, I'd probably _pay_ you if you also wrote a union filesystem, > because that's an all purpose tool that could be used all over the > place.)
Linux doesn't have one? Hmm....
> >Another thought I had is to make the pseudo files in /proc and /kern > >display real size information instead of 0, as they do under BSD, > That would be really nice, if you could have come guarantee that > the size wouldn't change between stat time and access time.
Technically, you never have this guarantee ever in unix. But I agree with pretty much everyone that it's probably impractical because it would involve generating the data for all the files in a file listing.
I still think it would be nice if the fs could some how indicate that file's size was undefined, as opposed to simply zero, but I'm unsure of how best to do that.
- -- Mirian Crzig Lennox Systems Anarchist "There's a New World Order coming every minute. Make mine extra cheese."
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Steve VanDevender <stevev@efn.org> Date: Fri, 4 Dec 1998 10:40:12 -0800 (PST) Subject: Re: [OFFTOPIC] Re: linux kernel hackers discover new theory of relativity!
H. Peter Anvin writes: > > Babylon 5 is closer to the reality of physics - the spinning station > > creates artificial gravity, but only for people standing on the > > inside walls of the cylinder. Those who are near of rotation axis > > are in zero-gravity. This is not gravity guys, it's centrifugal > > force, the same that pushes you against your car's window when you > > take a sharp turn. -- > > > > Actually, it *is* gravity. Read up on general relativity if you don't > believe me.
I have, and I don't.
Following a curved path through spacetime (as in sitting on the inside of a spinning cylinder) is not the same as being in a region of curved spacetime (as in sitting on a massive object). If you didn't get that from your reading of general relativity you weren't paying proper attention.
It's a good thing we're not building LinUniverse. Given the level of physics knowledge most people are displaying it would have collapsed irretrievably into an unusable singularity as soon as it was put together.
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: hjl@lucon.org (H.J. Lu) Date: Fri, 4 Dec 1998 10:43:00 -0800 (PST) Subject: Please try knfsd-981204
Hi,
I cleaned up mountd a little bit. Please double check it doesn't break anything.
Thanks.
H.J. - --- This is the Linux kernel NFS daemon. It is based on linux-nfs 0.4.22. It is tested on Linux/alpha and Linux/x86 running glibc 2.0.7.
WARNING: Linux 2.1.126-2.1.129 are seriously broken. Please use Linux 2.1.130 or above.
I made my knfsd package available only because I use it and noone else seems to maintain it. But I don't have much time to really work on it. I will only fix bugs in the NFS utilities and serious kernel NFS bugs which I can duplcate easily. If you have any kernel NFS server problem, please report it to the Linux kernel mailing list. If it can be reproduced with Linux NFS server and client in less than 5 minutes, you can also send me a copy in addition to sending it to the Linux kernel mailing list. I may take a look when I have time. However I will collect kernel NFS related patches. Contributions are more than welcome.
The NFS lock only works with lockd. Please make sure the portmapper, portmap, should be started before mounting NFS.
Changes from knfsd-981122:
1. Modify etc/rc.nfsd and etc/rc.nfsfs to handle statd during shutdown. 2. Remove maximum knfsd count checking. 3. Clean up mountd. 4. cache-2.1.131-1.patch from G. Allen Morris III (gam3@acm.org). 5. lock-2.1.131.diff. A nfsd lock patch for Linux 2.1.131.
Changes from knfsd-981113:
1. procfs-2.1.127.patch from G. Allen Morris III (gam3@acm.org). 2. Modify etc/rc.nfsd and etc/rc.nfsfs to better handle statd. 3. Fix the sub-mounted directories.
Changes from knfsd-981022:
1. Fix buffer overruns from Peter Benie <pjb1008@cus.cam.ac.uk>. 2. Fix hostname matching. 3. Correctly handle dupilcations in /etc/exports. 4. Add -F flag to statd. 5. nfsd-2.1.127-5.patch from G. Allen Morris III (gam3@acm.org).
Changes from knfsd-981014:
1. lock-2.1.1xx.diff. A nfsd lock patch. 2. nullproc-2.1.1xx.diff. Allow any clients to call the nfsd NULL proc. 3. Add etc/rc.nfsfs to handle statd. 3. Update etc/rc.nfsd to handle statd. 4. nfsd-2.1.125-2.patch from G. Allen Morris III (gam3@acm.org). 5. Fix inet_ntoa usage in statd.
Changes from knfsd-981010:
1. Check client aliases when matching for wildcard client hostnames. 2. Fix memory leak in mountd. 3. Fix filename in nfsd-2.1.125-1.patch.
Changes from knfsd-980930:
1. nfsd-2.1.125-1.patch from G. Allen Morris III (gam3@acm.org) and me. 2. Fix the hostent bugs in mountd and statd. 3. Remove "kexportfs -au" for "rc.nfsd stop".
Changes from knfsd-980925:
1. socket-2.1.1xx.diff for creating socket on NFS client. 2. There is a knsfd root_squash patch for Linux 2.1.1xx, root-2.1.1xx.diff. It is only tested on linux 2.1.123. It also fixes the server side 0711 mode bug. 3. sunrpc-2.1.123-1.patch from Bill Hawes <whawes@transmeta.com>. 4. nfsd-2.1.122-3.patch from G. Allen Morris III (gam3@acm.org). 5. Various buffer overrun changes. 6. Fix mountd to check the duplicated entry in rmtab. 7. Change exportfs to ignore warnings for "-r". 8. Fix showmount -e.
Changes from knfsd-980922:
1. nfsd-2.1.121-4.patch from G. Allen Morris III (gam3@acm.org). 2. Make async as default for export. It matches the user space NFS server.
Changes from knfsd-980920:
1. Add NFS mount version flags to mountd. Change rc.nfsd to disable NFS V3 for mountd. 2. Fix client hostname. 3. rc.nfsd runs kexportfs with -r instead of -a for restart and reload.
Changes from knfsd-980915:
1. There is a knsfd quota patch for Linux 2.1.1xx, quota-2.1.1xx.diff. It is only tested on linux 2.1.122. 2. The submount pathname is removed from the xtab file. 3. rc.nfsd runs kexportfs with -r instead of -a for start. 4. Fix kshowmount -e. 5. Fix hostname matching. 6. Fix compiling on libc 5.
Changes from knfsd-980910:
1. nfsd-2.1.121-3.patch from G. Allen Morris III (gam3@acm.org). 2. A new flag, -r, for exportfs. 3. Don't put an entry in xtab if kernel rejects it. 4. Use the official hostname when checking if 2 hostnames are the same. 5. Allow submounts.
It is available at
ftp://ftp.yggdrasil.com/private/hjl/knfsd-981204.tar.gz ftp://ftp.yggdrasil.com/private/hjl/knfsd-981122-981204.diff.gz ftp://ftp.kernel.org/pub/linux/devel/gcc/knfsd-981204.tar.gz ftp://ftp.kernel.org/pub/linux/devel/gcc/knfsd-981122-981204.diff.gz
You have to apply the patch, linux-2.1.1xx.diff, to the Linux kernel first. It fixes quite a few nfs bugs. That patch is against Linux 2.1.111. If your kernel is different, you have to apply it by hand.
If you want quota to work for knfsd, you also need to apply the patch, quota-2.1.1xx.diff, to the Linux kernel. This patch is against Linux 2.1.122. If your kernel is different, you have to apply it by hand.
If you want root_squash to work for knfsd, you also need to apply the patch, root-2.1.1xx.diff, to the Linux kernel. This patch is against Linux 2.1.123. If your kernel is different, you have to apply it by hand.
If you want unix socket to work for knfsd, you also need to apply the patch, socket-2.1.1xx.diff, to the Linux kernel. This patch is against Linux 2.1.122. If your kernel is different, you have to apply it by hand.
sunrpc-2.1.123-1.patch is a knfsd patch against linux 2.1.123 by Bill Hawes <whawes@transmeta.com>. It fixes some sunrpc bugs.
cache-2.1.131-1.patch is another knfsd patch from "G. Allen Morris III" (gam3@acm.org). It implements the dynamic nfsd read-ahead cache allocation.
procfs-2.1.127.patch is a knfsd patch from "G. Allen Morris III" (gam3@acm.org). It adds /proc/fs/nfsd/exports.
nfsd-2.1.127-5.patch is a new knfsd patch against linux 2.1.127 from "G. Allen Morris III" (gam3@acm.org). It works for me on x86 and alpha. You can get Allen's current patch from
http://www.CSUA.Berkeley.EDU/~gam3/knfsd/
To compile, just do
# make
Makefile will try to determine which C library you are using and compile this package accordingly.
# make install
will install the knfsd binaries. You have to install a knfs start up script by hand. There is a new rc.nfsd in etc. I use it for both the user-space nfsd and the kernel nfsd.
Thanks.
H.J. hjl@lucon.org 12/04/98
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Richard Fish <rjf@estinc.com> Date: Fri, 04 Dec 1998 11:47:40 -0700 Subject: Re: Dumb question: Which is "better" SCSI or IDE disks?
Harvey Fishman wrote: > In general, you will get less performance from a capable > O/S using ATA interfaced devices than with SCSI. Of course, the ATA > devices can cost a lot less, so it is a situation where you must determine > how much performance you are willing to pay for.
I agree with you, but I'm gonna throw my $.02 in just to confuse things some more... ;>
I recently got to test SCSI vs IDE drives in the same system. My tests involved raw disk read (with hdparm), filesystem access (by making a backup), and loaded filesystem access(by dd'ing from the raw drive to /dev/null, while performing a filesystem backup). Both drives were 7200rpm, with UDMA enabled on the IDE drive. The SCSI drive was a 9GB Quantum Atlas UW, which cost $370, and was attached to a Mylex BT950 UW controller (~$250). The 6.5 GB Seagate Medalist PRO drive cost $225.
My tests had the following results (in K/sec):
IDE SCSI Raw Read: 13358 9423 Filsystem: 5174 4780 Loaded: 478 1511
As you can see, the first 2 cases the IDE drive won, but severly lost on the 3rd.
Now, before I get flamed, I will admit that it is certainly possible to put together a SCSI system that beats IDE for all cases. With unlimited funds, ANYTHING is possible... :>
And for the 3rd case, my test is probably not really indicative of a real-world situation. But it does show that at some level of high IO, multi-user, multi-process environments, SCSI will have a clear ad It would be very interesting to repeat the above with 2 UDMA drives using an md/raid0 configuration.
- -- Richard Fish Enhanced Software Technologies, Inc. Software Developer 4014 E Broadway Rd Suite 405 rjf@estinc.com Phoenix, AZ 85040 (602) 470-1115 http://www.estinc.com
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Kris Karas <ktk@ktk.bidmc.harvard.edu> Date: Fri, 04 Dec 1998 14:02:42 -0500 Subject: Re: Linux timekeeping plans
Stefan Monnier wrote:
> I must say (as an NTP user) that I don't understand: why don't you just > allow xntpd to use the RTC as a local clock and let xntpd slave ths system > clock with it ?
The RTC has a precision of 1 second, if memory serves, even though it can generate interrupts more rapidly. In order for the system to derive more precision, it must do what hwclock(8) does - watch carefully for the transition of the seconds digit, and set the kernel's fractional-seconds portion of the time to zero. This is inherently costly to do. If memory also serves, the RTC is a slow device - reading it may take a microsecond or more more per byte.
- -- Kristofer Karas * kXtXk@bigfoot.com (delete X's) AMA/CCS DoD RF900RR HawkGT !car * Senior systems engineer/SysAdmin "Build a system that even a fool can use, * BI Deaconess Medical Center, Boston and only a fool will want to use it." * Will design LISP machines for food
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Rik van Riel <H.H.vanRiel@phys.uu.nl> Date: Fri, 4 Dec 1998 20:01:48 +0100 (CET) Subject: Re: Machine Dead on 2.1.131
On Thu, 3 Dec 1998, Michael K Vance wrote:
> I'm starting to reconsider the causes of my previously reported > crash. I've started to run xfstt to serve TrueType fonts under X, > and have noticed it's pegged the CPU meter a few times now. I wonder > if it's breaking X in bad ways, especially since I manually killed > the runaway process...
This is strange, a _font_ server killing the X and subsequently the machine. I suspect that X is at fault since that's the only part of the system (apart from the kernel) that has direct hardware access. You're not using XFree 3.3.3 are you?
cheers,
Rik -- the flu hits, the flu hits, the flu hits -- MORE +-------------------------------------------------------------------+ | Linux memory management tour guide. H.H.vanRiel@phys.uu.nl | | Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ | +-------------------------------------------------------------------+
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: "Stefan Monnier" <monnier+lists/linux/kernel@tequila.cs.yale.edu> Date: Fri, 04 Dec 1998 14:15:25 -0500 Subject: Re: Linux timekeeping plans
Kris Karas wrote: > Stefan Monnier wrote: > > I must say (as an NTP user) that I don't understand: why don't you just > > allow xntpd to use the RTC as a local clock and let xntpd slave ths system > > clock with it ? > The RTC has a precision of 1 second, if memory serves, even though it can > generate interrupts more rapidly. In order for the system to derive more > precision, it must do what hwclock(8) does - watch carefully for the transition > of the seconds digit, and set the kernel's fractional-seconds portion of the > time to zero. This is inherently costly to do. If memory also serves, the RTC > is a slow device - reading it may take a microsecond or more more per byte.
Indeed, which is why I want to keep the RTC support separate (exporting it for xntpd's use) so that I can run with a sane system (not using the RTC but a remote time server). To make "good" use of the RTC, you'd probably be better off to use it as a PPS source.
Stefan
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Chris Cheney <chris@lcc.net> Date: Fri, 04 Dec 1998 13:16:54 -0600 Subject: Re: NO ROM BASIC
I have seen the NO ROM BASIC error message on machines in which the hard drive did not have a partition marked as active. If you check your drive and that isn't the problem it could be a hardware problem as Kenneth suggests.
Chris Cheney
PS - I am only on the kernel-digest list so if you have any questions please email me directly
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: carguin@iname.com Date: Fri, 4 Dec 1998 14:21:02 -0500 (EST) Subject: Re: UDP bad checksum :)
On Fri, 4 Dec 1998, Joseph W. Breu wrote:
> On Thu, 3 Dec 1998, Lenart Gabor wrote: > > > I've just get this 'UDP: bad checksum' messaga again : > > > > Dec 3 18:36:16 oxygene kernel: UDP: bad checksum. From 193.6.41.136:138 to 193.6.41.255:138 ulen 228 > > > > It's strange that I get this message when somebody boot Windows98 on > > 193.6.41.136. Nice :) > > I think that this is from a BOOTP or DHCP request. Should these > kinds of messages still be printing out?
More to the point, why is the kernel evaluating these as bad checksums? Is there anyway to recognize these sorts of messages beforehand, so the kernel knows the checksum is invalid/special. I'm not all the familiar with the protocols in question, but it seems to me that this is really an erroneous error message (from the department of redundancy department).
OTOH, it may not be worth the extra code, and there is something interesting about knowing when all machines on your LAN boot up. Thank goodness UNH did a decent job sub-netting though, or I would *really* be inundated with these messages. Windows boxes make a lot of DHCP request, presumably because they are always rebooting.
- -- Chris Arguin | "...All we had were Zeros and Ones -- And CArguin@iname.com | sometimes we didn't even have Ones." +--------------+ - Dilbert, by Scott Adams http://leonardo.sr.unh.edu/arguin/home.html |
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Chris Evans <chris@ferret.lmh.ox.ac.uk> Date: Fri, 4 Dec 1998 19:25:31 +0000 (GMT) Subject: Re: [PATCH] swapin readahead and fixes
On Thu, 3 Dec 1998, Rik van Riel wrote:
> Hi, > > here is a patch (against 2.1.130, but vs. 2.1.131 should > be trivial) that improves the swapping performance both > during swapout and swapin and contains a few minor fixes.
Hi Rik,
I'm very interested in performance for sequential swapping. This occurs in for example scientific applications which much sweep through vast arrays much larger than physical RAM.
Have you benchmarked booting with low physical RAM, lots of swap and writing a simple program that allocates 100's of Mb of memory and then sequentially accesses every page in a big loop?
This is one area in which FreeBSD stomps on us. Theoretically it should be possible to get swap with readahead pulling pages into RAM at disk speed.
Cheers Chris
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Perry Harrington <pedward@sun4.apsoft.com> Date: Fri, 4 Dec 1998 11:37:29 -0800 (PST) Subject: [PATCH] Fix to truncate memory_end if > possible maximum
Here's a patch to setup.c in the i386 architecture to fix the problems with people specifying > 960MB of RAM on 2.1 kernels.
I haven't compiled it, but it passes my sanity checking of the code.
- --Perry
PS: This is sent to Linus and Alan, so you both have it.
- -------------------------------------------------8<-------------------------- - --- setup.c.old Fri Dec 4 11:36:41 1998 +++ setup.c Fri Dec 4 11:36:43 1998 @@ -146,13 +146,6 @@ } #endif
- -#define VMALLOC_RESERVE (64 << 20) /* 64MB for vmalloc */ - -#define MAXMEM ((unsigned long)(-PAGE_OFFSET-VMALLOC_RESERVE)) - - - - if (memory_end > MAXMEM) - - memory_end = MAXMEM; - - - - memory_end &= PAGE_MASK; #ifdef CONFIG_BLK_DEV_RAM rd_image_start = RAMDISK_FLAGS & RAMDISK_IMAGE_START_MASK; rd_prompt = ((RAMDISK_FLAGS & RAMDISK_PROMPT_FLAG) != 0); @@ -199,6 +192,16 @@ break; *(to++) = c; } + +/* truncate memory_end to the maximum possible value if it's greater 12/04/98 pedward */ +#define VMALLOC_RESERVE (64 << 20) /* 64MB for vmalloc */ +#define MAXMEM ((unsigned long)(-PAGE_OFFSET-VMALLOC_RESERVE)) + + if (memory_end > MAXMEM) + memory_end = MAXMEM; + + memory_end &= PAGE_MASK; + *to = '\0'; *cmdline_p = command_line; memory_end += PAGE_OFFSET; - -------------------------------------------------8<-------------------------- - -- Perry Harrington Linux rules all OSes. APSoft () email: perry@apsoft.com Think Blue. /\
Please read the FAQ at http://www.tux.org/lkml/
------------------------------ From: Glynn Clements <glynn@sensei.co.uk> Date: Fri, 4 Dec 1998 19:36:30 +0000 (GMT) Subject: Re: /proc and /kern david parsons wrote:
> > Another thought I had is to make the pseudo files in /proc and /kern > > display real size information instead of 0, as they do under BSD, > > That would be really nice, if you could have come guarantee that > the size wouldn't change between stat time and access time.
Two questions:
1. Why? Given that you don't have this guarantee for regular files, nothing is going to care whether the result of stat() matches the amount of data that can actually be read from the file (or at least nothing written by anyone with the slightest clue about Unix).
2. Clearly such a guarantee would be impossible to provide, unless you're going to somehow freeze the contents of these files as soon a some process performs a stat() on them.
- -- Glynn Clements <glynn@sensei.co.uk>
Please read the FAQ at http://www.tux.org/lkml/
------------------------------ From: Glynn Clements <glynn@sensei.co.uk> Date: Fri, 4 Dec 1998 19:29:37 +0000 (GMT) Subject: Re: 2.1.131 compile; crash and burn Mr. Joshua Lambert wrote:
> Attempted compilation with both gcc-2.7.2.3 and egcs-1.1.1, with > glibc-2.0.7pre6 compiled with 2.1.130 headers, and both times around, the > following shriekery occured. ;-) > gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -D__SMP__ -pipe -fno-strength-reduce -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=586 -c -o init/main.o init/main.c > In file included from /usr/include/sys/types.h:30, > from /usr/src/linux/include/linux/uio.h:24,
What does your linux/uio.h look like? Mine certainly doesn't include sys/types.h at line 24 (or anywhere else for that matter). OTOH, my sys/uio.h *does* include sys/types.h at line 24.
Is your linux/uio.h a symlink to sys/uio.h instead of a file?
- -- Glynn Clements <glynn@sensei.co.uk>
Please read the FAQ at http://www.tux.org/lkml/
------------------------------ From: hpa@transmeta.com (H. Peter Anvin) Date: 4 Dec 1998 19:59:20 GMT Subject: Re: Problem with 1G RAM
Followup to: <E0zlshT-0002u3-00@devel2.axiom.internal> By author: David Woodhouse <David.Woodhouse@mvhi.com> In newsgroup: linux.dev.kernel > > > tymm@coe.missouri.edu said: > > include/asm/page.h isn't the most intuitive place to look :) ) > > Indeed. I knew it was somewhere, but couldn't find it. No wonder the author of > the original question couldn't! > > > > ... Or > > even have it as a configuration option (with appropriate warnings, of > > course) > > We did once, but it was taken out because so many people set it to 64Mb and > wondered why it stopped working. However, if we do something like... > > bool 'Support for over 1Gb of physical memory' CONFIG_BIGRAM > if [ "$CONFIG_BIGRAM" != n ]; then > int 'Maximum memory size (read Documentation/i386/bigram.txt)' CONFIG_MEMSIZE > fi > > > then that's much less likely to happen. >
Or just make it a selection box... there aren't really that many useful levels; say 1 GB, 1.5 GB, 2 GB.
-hpa - -- PGP: 2047/2A960705 BA 03 D3 2C 14 A8 A8 BD 1E DF FE 69 EE 35 BD 74 See http://www.zytor.com/~hpa/ for web page and full PGP public key I am Bahá'í -- ask me about it or see http://www.bahai.org/ "To love another person is to see the face of God." -- Les Misérables
Please read the FAQ at http://www.tux.org/lkml/
------------------------------ From: Gerhard Mack <gmack@imag.net> Date: Fri, 4 Dec 1998 12:12:24 -0800 (PST) Subject: Re: IDE disk geometry + patch
Please be carefull, last time changes like that were made it killed my setup:
This is a WD Caviar 2100 with no translation enabled. hda1 is mounted as /boot this way I can avoid translation since on as some of the setups I've installed on have buggy translation that is noticably slower (IPC notebooks)
I've had had to haul out bootdisks twice, in the deval series over changes such as the one being discussed.
output from cfdisk:
Heads: 16 Sectors per Track: 63 Cylinders: 2100
Name Flags Part Type FS Type Size (MB)
- ------------------------------------------------------------------------------ /dev/hda1 Primary Linux 5.42 /dev/hda2 Primary Linux Swap 20.18 /dev/hda3 Primary Linux 1008.00
On Fri, 4 Dec 1998 Andries.Brouwer@cwi.nl wrote:
> From mlord@pobox.com Fri Dec 4 06:19:55 1998 > > The reason the IDE driver does NOT do what you suggest > is to ensure 100% compatibility with the BIOS view when > using programs (like LILO and fdisk) which interact with > the BIOS. > > The code is very careful to correctly use the BIOS view > of the drive under such circumstances, and it is a little > too risky to try changing it at this stage of 2.1.xxx > (it could break many systems through some unforeseen interaction). > > Hmm. It sounds like you react without thinking. > Look at the code I want to replace. It corrects bios_cyl > under certain circumstances. I want to correct bios_cyl > under a wider set of circumstances. > It is not at all the case today that the Linux kernel > preserves the BIOS view on the number of cylinders. > > Now think about the fdisk and LILO interaction. > What is the effect of a too small number of cylinders? > That part of the disk is inaccessible. > For LILO one may live with that - there have always > been restrictions on the place of the kernel on disk. > But for fdisk that is inacceptable - people struggle > with this, and - as far as I can see - there is no > reason at all to inflict these problems unto them. > > The number of people with 8+ GB disks increases quickly. > The handling of large IDE disks has always been broken, > but in 2.0.35 and 2.1.90 this problem was partially > corrected by inserting the test for C/H/S=16383/16/63. > However, this only solves the problem if the BIOS is > not using a translation (`LBA' or `Large' or so). > People with a large IDE disk and translating BIOS > still cannot use the entire disk (without overriding > the kernel view by giving LILO additional hda=C,H,S > parameters, or going into expert mode of fdisk, etc.). > > The sooner this is corrected, the better. > > Andries > > - > 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/ >
- -- Gerhard Mack
gmack@imag.net InnerFIRE@starchat.net
As a computer I find your faith in technology amusing.
Please read the FAQ at http://www.tux.org/lkml/
------------------------------ From: Radim Literak <literakr@alpha.inf.upol.cz> Date: Fri, 4 Dec 1998 21:18:59 +0100 (MET) Subject: 2.1.131 Kernel panic while booting
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.
- ---1029770296-1850802630-912777522=:179 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: <Pine.OSF.4.05.9812041417582.1143@alpha.inf.upol.cz>
Hello,
I still have the same problem with experimental kernels. When I booting, folowing errors occures:
Partition check: hda: hda1 hda2 hda3 hda4 < hda5 hda6 > hdb: hdb1 hdb2 < hdb5 hdb6 > EXT2-fs error (device 03:01): ext2_check_descriptors: Block bitmap for group 27 not in group (block 0)! EXT2-fs: group descriptors corrupted! Kernel panic: VFS: Unable to mount root fs on 03:01
Another interesting thing is that sometimes partition check froze and computer doesn't work (only HDD LED on my case is lighting). And when is not frozen, then there is error described upper, but every time is here different number in this error, like group 27 group 19 group 23 group 40 group 17
etc. But 2.0.36 is going correctly.
Maybe is important physical description of partitions on my HDD, because partitions are not normaly sorted:
hda3 hda1 hda4 <hda5 hda6> hda2
hda3.............FAT16 (first on hda) hda1.............EXT2 (after hda3) hda4.............DOS EXTENDED (after hda1) hda5...........NTFS (first on hda4) hda6...........NTFS (second on hda4) hda2.............LINUX SWAP (after hda4)
I attach my configuration file, too.
Thank you for help me.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Radim Literak, Olomouc, Czech Republic Student of Palacky University at Computer Science Department http://www.inf.upol.cz/~literakr
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - ---1029770296-1850802630-912777522=:179 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=".config" Content-Transfer-Encoding: BASE64 Content-ID: <Pine.OSF.4.05.9812042118580.30679@alpha.inf.upol.cz> Content-Description: Configuration file Content-Disposition: attachment; filename=".config"
Iw0KIyBBdXRvbWF0aWNhbGx5IGdlbmVyYXRlZCBieSBtYWtlIG1lbnVjb25m aWc6IGRvbid0IGVkaXQNCiMNCg0KIw0KIyBDb2RlIG1hdHVyaXR5IGxldmVs IG9wdGlvbnMNCiMNCiMgQ09ORklHX0VYUEVSSU1FTlRBTCBpcyBub3Qgc2V0 DQoNCiMNCiMgUHJvY2Vzc29yIHR5cGUgYW5kIGZlYXR1cmVzDQojDQojIENP TkZJR19NMzg2IGlzIG5vdCBzZXQNCiMgQ09ORklHX000ODYgaXMgbm90IHNl dA0KQ09ORklHX001ODY9eQ0KIyBDT05GSUdfTTY4NiBpcyBub3Qgc2V0DQoj IENPTkZJR19NQVRIX0VNVUxBVElPTiBpcyBub3Qgc2V0DQoNCiMNCiMgTG9h ZGFibGUgbW9kdWxlIHN1cHBvcnQNCiMNCkNPTkZJR19NT0RVTEVTPXkNCkNP TkZJR19NT0RWRVJTSU9OUz15DQpDT05GSUdfS01PRD15DQoNCiMNCiMgR2Vu ZXJhbCBzZXR1cA0KIw0KQ09ORklHX05FVD15DQpDT05GSUdfUENJPXkNCiMg Q09ORklHX1BDSV9CSU9TIGlzIG5vdCBzZXQNCkNPTkZJR19QQ0lfRElSRUNU PXkNCiMgQ09ORklHX1BDSV9RVUlSS1MgaXMgbm90IHNldA0KQ09ORklHX1BD SV9PTERfUFJPQz15DQojIENPTkZJR19NQ0EgaXMgbm90IHNldA0KQ09ORklH X1NZU1ZJUEM9eQ0KIyBDT05GSUdfQlNEX1BST0NFU1NfQUNDVCBpcyBub3Qg c2V0DQpDT05GSUdfU1lTQ1RMPXkNCkNPTkZJR19CSU5GTVRfQU9VVD1tDQpD T05GSUdfQklORk1UX0VMRj15DQpDT05GSUdfQklORk1UX01JU0M9eQ0KIyBD T05GSUdfUEFSUE9SVCBpcyBub3Qgc2V0DQojIENPTkZJR19BUE0gaXMgbm90 IHNldA0KDQojDQojIFBsdWcgYW5kIFBsYXkgc3VwcG9ydA0KIw0KIyBDT05G SUdfUE5QIGlzIG5vdCBzZXQNCg0KIw0KIyBCbG9jayBkZXZpY2VzDQojDQpD T05GSUdfQkxLX0RFVl9GRD1tDQpDT05GSUdfQkxLX0RFVl9JREU9eQ0KIyBD T05GSUdfQkxLX0RFVl9IRF9JREUgaXMgbm90IHNldA0KQ09ORklHX0JMS19E RVZfSURFRElTSz15DQpDT05GSUdfQkxLX0RFVl9JREVDRD1tDQojIENPTkZJ R19CTEtfREVWX0lERVRBUEUgaXMgbm90IHNldA0KIyBDT05GSUdfQkxLX0RF Vl9JREVGTE9QUFkgaXMgbm90IHNldA0KIyBDT05GSUdfQkxLX0RFVl9JREVT Q1NJIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZfQ01ENjQwIGlzIG5v dCBzZXQNCiMgQ09ORklHX0JMS19ERVZfUloxMDAwIGlzIG5vdCBzZXQNCkNP TkZJR19CTEtfREVWX0lERVBDST15DQpDT05GSUdfQkxLX0RFVl9JREVETUE9 eQ0KIyBDT05GSUdfQkxLX0RFVl9PRkZCT0FSRCBpcyBub3Qgc2V0DQpDT05G SUdfSURFRE1BX0FVVE89eQ0KIyBDT05GSUdfSURFX0NISVBTRVRTIGlzIG5v dCBzZXQNCiMgQ09ORklHX0JMS19ERVZfTE9PUCBpcyBub3Qgc2V0DQojIENP TkZJR19CTEtfREVWX05CRCBpcyBub3Qgc2V0DQojIENPTkZJR19CTEtfREVW X01EIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZfUkFNIGlzIG5vdCBz ZXQNCiMgQ09ORklHX0JMS19ERVZfWEQgaXMgbm90IHNldA0KQ09ORklHX1BB UklERV9QQVJQT1JUPXkNCiMgQ09ORklHX1BBUklERSBpcyBub3Qgc2V0DQoj IENPTkZJR19CTEtfREVWX0hEIGlzIG5vdCBzZXQNCg0KIw0KIyBOZXR3b3Jr aW5nIG9wdGlvbnMNCiMNCkNPTkZJR19QQUNLRVQ9bQ0KIyBDT05GSUdfTkVU TElOSyBpcyBub3Qgc2V0DQojIENPTkZJR19GSVJFV0FMTCBpcyBub3Qgc2V0 DQojIENPTkZJR19ORVRfQUxJQVMgaXMgbm90IHNldA0KIyBDT05GSUdfRklM VEVSIGlzIG5vdCBzZXQNCkNPTkZJR19VTklYPW0NCkNPTkZJR19JTkVUPXkN CiMgQ09ORklHX0lQX01VTFRJQ0FTVCBpcyBub3Qgc2V0DQojIENPTkZJR19J UF9BRFZBTkNFRF9ST1VURVIgaXMgbm90IHNldA0KIyBDT05GSUdfSVBfUE5Q IGlzIG5vdCBzZXQNCiMgQ09ORklHX0lQX1JPVVRFUiBpcyBub3Qgc2V0DQoj IENPTkZJR19ORVRfSVBJUCBpcyBub3Qgc2V0DQojIENPTkZJR19ORVRfSVBH UkUgaXMgbm90IHNldA0KIyBDT05GSUdfSVBfQUxJQVMgaXMgbm90IHNldA0K IyBDT05GSUdfU1lOX0NPT0tJRVMgaXMgbm90IHNldA0KIyBDT05GSUdfSU5F VF9SQVJQIGlzIG5vdCBzZXQNCkNPTkZJR19JUF9OT1NSPXkNCkNPTkZJR19T S0JfTEFSR0U9eQ0KQ09ORklHX0lQWD1tDQpDT05GSUdfSVBYX0lOVEVSTj15 DQojIENPTkZJR19BVEFMSyBpcyBub3Qgc2V0DQoNCiMNCiMgU0NTSSBzdXBw b3J0DQojDQojIENPTkZJR19TQ1NJIGlzIG5vdCBzZXQNCg0KIw0KIyBOZXR3 b3JrIGRldmljZSBzdXBwb3J0DQojDQpDT05GSUdfTkVUREVWSUNFUz15DQoj IENPTkZJR19BUkNORVQgaXMgbm90IHNldA0KQ09ORklHX0RVTU1ZPW0NCiMg Q09ORklHX0VRVUFMSVpFUiBpcyBub3Qgc2V0DQpDT05GSUdfTkVUX0VUSEVS TkVUPXkNCiMgQ09ORklHX05FVF9WRU5ET1JfM0NPTSBpcyBub3Qgc2V0DQoj IENPTkZJR19MQU5DRSBpcyBub3Qgc2V0DQojIENPTkZJR19ORVRfVkVORE9S X1NNQyBpcyBub3Qgc2V0DQojIENPTkZJR19ORVRfVkVORE9SX1JBQ0FMIGlz IG5vdCBzZXQNCiMgQ09ORklHX05FVF9JU0EgaXMgbm90IHNldA0KQ09ORklH X05FVF9FSVNBPXkNCiMgQ09ORklHX1BDTkVUMzIgaXMgbm90IHNldA0KIyBD T05GSUdfQVBSSUNPVCBpcyBub3Qgc2V0DQojIENPTkZJR19DUzg5eDAgaXMg bm90IHNldA0KIyBDT05GSUdfREU0WDUgaXMgbm90IHNldA0KIyBDT05GSUdf REVDX0VMQ1AgaXMgbm90IHNldA0KIyBDT05GSUdfREdSUyBpcyBub3Qgc2V0 DQojIENPTkZJR19FRVhQUkVTU19QUk8xMDAgaXMgbm90IHNldA0KQ09ORklH X05FMktfUENJPW0NCiMgQ09ORklHX1RMQU4gaXMgbm90IHNldA0KIyBDT05G SUdfVklBX1JISU5FIGlzIG5vdCBzZXQNCiMgQ09ORklHX05FVF9QT0NLRVQg aXMgbm90IHNldA0KIyBDT05GSUdfRkRESSBpcyBub3Qgc2V0DQojIENPTkZJ R19ETENJIGlzIG5vdCBzZXQNCiMgQ09ORklHX1BQUCBpcyBub3Qgc2V0DQoj IENPTkZJR19TTElQIGlzIG5vdCBzZXQNCiMgQ09ORklHX05FVF9SQURJTyBp cyBub3Qgc2V0DQojIENPTkZJR19UUiBpcyBub3Qgc2V0DQojIENPTkZJR19I T1NURVNTX1NWMTEgaXMgbm90IHNldA0KIyBDT05GSUdfV0FOX0RSSVZFUlMg aXMgbm90IHNldA0KIyBDT05GSUdfTEFQQkVUSEVSIGlzIG5vdCBzZXQNCiMg Q09ORklHX1gyNV9BU1kgaXMgbm90IHNldA0KDQojDQojIEFtYXRldXIgUmFk aW8gc3VwcG9ydA0KIw0KIyBDT05GSUdfSEFNUkFESU8gaXMgbm90IHNldA0K DQojDQojIElTRE4gc3Vic3lzdGVtDQojDQojIENPTkZJR19JU0ROIGlzIG5v dCBzZXQNCg0KIw0KIyBDRC1ST00gZHJpdmVycyAobm90IGZvciBTQ1NJIG9y IElERS9BVEFQSSBkcml2ZXMpDQojDQojIENPTkZJR19DRF9OT19JREVTQ1NJ IGlzIG5vdCBzZXQNCg0KIw0KIyBDaGFyYWN0ZXIgZGV2aWNlcw0KIw0KQ09O RklHX1ZUPXkNCkNPTkZJR19WVF9DT05TT0xFPXkNCkNPTkZJR19TRVJJQUw9 eQ0KIyBDT05GSUdfU0VSSUFMX0NPTlNPTEUgaXMgbm90IHNldA0KIyBDT05G SUdfU0VSSUFMX0VYVEVOREVEIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NFUklB TF9OT05TVEFOREFSRCBpcyBub3Qgc2V0DQojIENPTkZJR19VTklYOThfUFRZ UyBpcyBub3Qgc2V0DQojIENPTkZJR19NT1VTRSBpcyBub3Qgc2V0DQojIENP TkZJR19RSUMwMl9UQVBFIGlzIG5vdCBzZXQNCiMgQ09ORklHX1dBVENIRE9H IGlzIG5vdCBzZXQNCiMgQ09ORklHX1JUQyBpcyBub3Qgc2V0DQojIENPTkZJ R19WSURFT19ERVYgaXMgbm90IHNldA0KIyBDT05GSUdfTlZSQU0gaXMgbm90 IHNldA0KIyBDT05GSUdfSk9ZU1RJQ0sgaXMgbm90IHNldA0KDQojDQojIEZ0 YXBlLCB0aGUgZmxvcHB5IHRhcGUgZGV2aWNlIGRyaXZlcg0KIw0KIyBDT05G SUdfRlRBUEUgaXMgbm90IHNldA0KDQojDQojIEZpbGVzeXN0ZW1zDQojDQpD T05GSUdfUVVPVEE9eQ0KIyBDT05GSUdfTUlOSVhfRlMgaXMgbm90IHNldA0K Q09ORklHX0VYVDJfRlM9eQ0KQ09ORklHX0lTTzk2NjBfRlM9bQ0KQ09ORklH X0pPTElFVD15DQpDT05GSUdfRkFUX0ZTPW0NCkNPTkZJR19NU0RPU19GUz1t DQpDT05GSUdfVU1TRE9TX0ZTPW0NCkNPTkZJR19WRkFUX0ZTPW0NCkNPTkZJ R19QUk9DX0ZTPXkNCkNPTkZJR19ORlNfRlM9bQ0KQ09ORklHX05GU0Q9bQ0K IyBDT05GSUdfTkZTRF9TVU4gaXMgbm90IHNldA0KQ09ORklHX1NVTlJQQz1t DQpDT05GSUdfTE9DS0Q9bQ0KIyBDT05GSUdfQ09EQV9GUyBpcyBub3Qgc2V0 DQpDT05GSUdfU01CX0ZTPW0NCkNPTkZJR19TTUJfV0lOOTU9eQ0KQ09ORklH X05DUF9GUz1tDQpDT05GSUdfTkNQRlNfUEFDS0VUX1NJR05JTkc9eQ0KQ09O RklHX05DUEZTX0lPQ1RMX0xPQ0tJTkc9eQ0KQ09ORklHX05DUEZTX1NUUk9O Rz15DQpDT05GSUdfTkNQRlNfTkZTX05TPXkNCkNPTkZJR19OQ1BGU19PUzJf TlM9eQ0KQ09ORklHX05DUEZTX01PVU5UX1NVQkRJUj15DQpDT05GSUdfSFBG U19GUz1tDQpDT05GSUdfTlRGU19GUz1tDQojIENPTkZJR19TWVNWX0ZTIGlz IG5vdCBzZXQNCiMgQ09ORklHX0FGRlNfRlMgaXMgbm90IHNldA0KIyBDT05G SUdfSEZTX0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX1JPTUZTX0ZTIGlzIG5v dCBzZXQNCkNPTkZJR19BVVRPRlNfRlM9eQ0KIyBDT05GSUdfVUZTX0ZTIGlz IG5vdCBzZXQNCiMgQ09ORklHX0JTRF9ESVNLTEFCRUwgaXMgbm90IHNldA0K IyBDT05GSUdfU01EX0RJU0tMQUJFTCBpcyBub3Qgc2V0DQojIENPTkZJR19T T0xBUklTX1g4Nl9QQVJUSVRJT04gaXMgbm90IHNldA0KIyBDT05GSUdfTUFD X1BBUlRJVElPTiBpcyBub3Qgc2V0DQpDT05GSUdfTkxTPXkNCg0KIw0KIyBO YXRpdmUgTGFuZ3VhZ2UgU3VwcG9ydA0KIw0KQ09ORklHX05MU19DT0RFUEFH RV80Mzc9bQ0KIyBDT05GSUdfTkxTX0NPREVQQUdFXzczNyBpcyBub3Qgc2V0 DQojIENPTkZJR19OTFNfQ09ERVBBR0VfNzc1IGlzIG5vdCBzZXQNCiMgQ09O RklHX05MU19DT0RFUEFHRV84NTAgaXMgbm90IHNldA0KQ09ORklHX05MU19D T0RFUEFHRV84NTI9bQ0KIyBDT05GSUdfTkxTX0NPREVQQUdFXzg1NSBpcyBu b3Qgc2V0DQojIENPTkZJR19OTFNfQ09ERVBBR0VfODU3IGlzIG5vdCBzZXQN CiMgQ09ORklHX05MU19DT0RFUEFHRV84NjAgaXMgbm90IHNldA0KIyBDT05G SUdfTkxTX0NPREVQQUdFXzg2MSBpcyBub3Qgc2V0DQojIENPTkZJR19OTFNf Q09ERVBBR0VfODYyIGlzIG5vdCBzZXQNCiMgQ09ORklHX05MU19DT0RFUEFH RV84NjMgaXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0NPREVQQUdFXzg2NCBp cyBub3Qgc2V0DQojIENPTkZJR19OTFNfQ09ERVBBR0VfODY1IGlzIG5vdCBz ZXQNCiMgQ09ORklHX05MU19DT0RFUEFHRV84NjYgaXMgbm90IHNldA0KIyBD T05GSUdfTkxTX0NPREVQQUdFXzg2OSBpcyBub3Qgc2V0DQojIENPTkZJR19O TFNfQ09ERVBBR0VfODc0IGlzIG5vdCBzZXQNCkNPTkZJR19OTFNfSVNPODg1 OV8xPW0NCkNPTkZJR19OTFNfSVNPODg1OV8yPW0NCiMgQ09ORklHX05MU19J U084ODU5XzMgaXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0lTTzg4NTlfNCBp cyBub3Qgc2V0DQojIENPTkZJR19OTFNfSVNPODg1OV81IGlzIG5vdCBzZXQN CiMgQ09ORklHX05MU19JU084ODU5XzYgaXMgbm90IHNldA0KIyBDT05GSUdf TkxTX0lTTzg4NTlfNyBpcyBub3Qgc2V0DQojIENPTkZJR19OTFNfSVNPODg1 OV84IGlzIG5vdCBzZXQNCiMgQ09ORklHX05MU19JU084ODU5XzkgaXMgbm90 IHNldA0KIyBDT05GSUdfTkxTX0tPSThfUiBpcyBub3Qgc2V0DQoNCiMNCiMg Q29uc29sZSBkcml2ZXJzDQojDQpDT05GSUdfVkdBX0NPTlNPTEU9eQ0KQ09O RklHX1ZJREVPX1NFTEVDVD15DQoNCiMNCiMgU291bmQNCiMNCkNPTkZJR19T T1VORD1tDQojIENPTkZJR19TT1VORF9NU05EQ0xBUyBpcyBub3Qgc2V0DQoj IENPTkZJR19TT1VORF9NU05EUElOIGlzIG5vdCBzZXQNCkNPTkZJR19TT1VO RF9PU1M9bQ0KIyBDT05GSUdfU09VTkRfUEFTIGlzIG5vdCBzZXQNCkNPTkZJ R19TT1VORF9TQj1tDQojIENPTkZJR19TT1VORF9BRExJQiBpcyBub3Qgc2V0 DQojIENPTkZJR19TT1VORF9HVVMgaXMgbm90IHNldA0KIyBDT05GSUdfU09V TkRfTVBVNDAxIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NPVU5EX1BTUyBpcyBu b3Qgc2V0DQojIENPTkZJR19TT1VORF9NU1MgaXMgbm90IHNldA0KIyBDT05G SUdfU09VTkRfU1NDQVBFIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NPVU5EX1RS SVggaXMgbm90IHNldA0KIyBDT05GSUdfU09VTkRfTUFEMTYgaXMgbm90IHNl dA0KIyBDT05GSUdfU09VTkRfV0FWRUZST05UIGlzIG5vdCBzZXQNCiMgQ09O RklHX1NPVU5EX0NTNDIzMiBpcyBub3Qgc2V0DQojIENPTkZJR19TT1VORF9P UEwzU0EyIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NPVU5EX01BVUkgaXMgbm90 IHNldA0KIyBDT05GSUdfU09VTkRfU0dBTEFYWSBpcyBub3Qgc2V0DQojIENP TkZJR19TT1VORF9PUEwzU0ExIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NPVU5E X1NPRlRPU1MgaXMgbm90IHNldA0KIyBDT05GSUdfU09VTkRfWU0zODEyIGlz IG5vdCBzZXQNCiMgQ09ORklHX1NPVU5EX1ZNSURJIGlzIG5vdCBzZXQNCiMg Q09ORklHX1NPVU5EX1VBUlQ2ODUwIGlzIG5vdCBzZXQNCg0KIw0KIyBBZGRp dGlvbmFsIGxvdyBsZXZlbCBzb3VuZCBkcml2ZXJzDQojDQojIENPTkZJR19M T1dMRVZFTF9TT1VORCBpcyBub3Qgc2V0DQoNCiMNCiMgS2VybmVsIGhhY2tp bmcNCiMNCiMgQ09ORklHX01BR0lDX1NZU1JRIGlzIG5vdCBzZXQNCg== - ---1029770296-1850802630-912777522=:179--
Please read the FAQ at http://www.tux.org/lkml/
------------------------------ From: Chip Salzenberg <chip@perlsupport.com> Date: Fri, 4 Dec 1998 15:31:00 -0500 Subject: Re: suspendd-v0.1.0 released
According to Pavel Machek: > > Hi, all. I've just thrown together a simple daemon which allows you > > to configure actions to be taken upon APM suspend or resume events. > > Ouch, should not this functionality be merged into apmd?
It already is. apmd can be configured to use a similar mechanism to /etc/rc?.d/*, and in fact the Debian distribution already is. This is a non-problem, and suspendd is a non-solution. - -- Chip Salzenberg - a.k.a. - <chip@perlsupport.com> "When do you work?" "Whenever I'm not busy."
Please read the FAQ at http://www.tux.org/lkml/
------------------------------ From: Rik van Riel <H.H.vanRiel@phys.uu.nl> Date: Fri, 4 Dec 1998 20:39:43 +0100 (CET) Subject: Re: Problem with 1G RAM
On Fri, 4 Dec 1998, Neil Conway wrote:
> OK, who wants to volunteer to insert a check in the kernel: STOP if > __PAGE_OFFSET is incompatible with the amount of RAM specified by > "mem=xxxM" ? Failing that, print a warning, and reduce the RAM to > (say) 960MB or whatever.
mirkwood:~/linux/arch/i386/kernel# grep MAXMEM * setup.c:#define MAXMEM ((unsigned long)(-PAGE_OFFSET-VMALLOC_RESERVE)) setup.c: if (memory_end > MAXMEM) setup.c: memory_end = MAXMEM; mirkwood:~/linux/arch/i386/kernel# It looks to me that there already is code like this inside kernel 2.1.131. Question is why it doesn't work correctly.
Let's see what happens:
MAXMEM = -0xC0000000-(64<<20) The only reason this could go wrong is when something fouls up with the conversion from a signed to an unsigned number.
In that case:
#define MAXMEM (MAX_INT - PAGE_OFFSET - VMALLOC_RESERVE + 1)
then again, I may have overlooked something silly :)
cheers,
Rik -- the flu hits, the flu hits, the flu hits -- MORE +-------------------------------------------------------------------+ | Linux memory management tour guide. H.H.vanRiel@phys.uu.nl | | Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ | +-------------------------------------------------------------------+
Please read the FAQ at http://www.tux.org/lkml/
------------------------------ From: "Andre M. Hedrick" <hedrick@Astro.Dyer.Vanderbilt.Edu> Date: Fri, 4 Dec 1998 14:40:47 -0600 (CST) Subject: Re: IDE disk geometry + patch
On Fri, 4 Dec 1998 Andries.Brouwer@cwi.nl wrote:
No history and experience are his guide (about 6+ years).
> Hmm. It sounds like you react without thinking. > Look at the code I want to replace. It corrects bios_cyl > under certain circumstances. I want to correct bios_cyl > under a wider set of circumstances. > It is not at all the case today that the Linux kernel > preserves the BIOS view on the number of cylinders.
Please try this before you get to far..... Reset the BIOS on your mainboard for AUTO/AUTO and do not use the silly disk-detect which gets the RAW CHS correct, but it to stupid to adjust for LBA. I am will ing to bet if you poke your nose into what the BIOS declares for each disk. The RAW LBA settings are wrong by the total missing number of cylinders that you claim are not detected by the kernel.
Trust me I know this does/can/usually is the case........ I have a disk that is exactly 16383,16,63 and the BIOS gets it dead wrong everytime I auto-detect........Now if I go and manually enter the 'TRUE' CHS values into the bios-disk parameters as a user defined setting, it will work.......Second is to skip this pain in the rear, and set the flags to AUTO/AUTO and include that PIO settings are AUTO also. An AWARD Bios's config options that are effected are at the top of each column of options.
AMI Bios's require the former method be used....drat...... The key clue to you problem was detection of "1024,255,63" this is my classic 'screaming red-flag' warning that the BIOS can't or is not allowed to count beyond a sector limit for an 8.0 Gig device (using the REAL definition of a MEG of disk space)
1Meg != 1,000,000 bytes (sales pitch) 1Meg != 1,024,000 bytes (memory) 1Meg == 1,048,576 bytes (reality) == 2^20
Now FDISK and LILO are a whole other issue....... > Now think about the fdisk and LILO interaction. > What is the effect of a too small number of cylinders? > That part of the disk is inaccessible.
Yes if you choose not to inform the kernel that your computer is an idiot that can't count.
ide_setup: hda=1247,255,63 ide_setup: hdc=1247,255,63 ide: Intel 82371 (single FIFO) DMA Bus Mastering IDE Controller on PCI bus 0 function 57 ide: timings == a307e377 ide0: BM-DMA at 0xf000-0xf007 ide1: BM-DMA at 0xf008-0xf00f hda: QUANTUM FIREBALL EL10.2A, 9787MB w/418kB Cache, CHS=1247/255/63, (U)DMA hdb: QUANTUM FIREBALL EL10.2A, 9787MB w/418kB Cache, CHS=1247/255/63, (U)DMA ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15
(Note, beginning steps of hardware RAID 1)
ide: PDC20246 UDMA Bus Mastering with ROM enabled but no address Controller on PCI bus 0 function 152 ide: timings == 000003ee ide0: BM-DMA at 0x7c00-0x7c07 ide1: BM-DMA at 0x7c08-0x7c0f ide: Intel 82371 (single FIFO) DMA Bus Mastering IDE Controller on PCI bus 0 function 57 ide: ports are not enabled (BIOS) hda: QUANTUM FIREBALL EL10.2A, 9787MB w/418kB Cache, CHS=19885/16/63, UDMA hdc: QUANTUM FIREBALL EL10.2A, 9787MB w/418kB Cache, CHS=19885/16/63, UDMA ide0 at 0x6c00-0x6c07,0x7002 on irq 11 ide1 at 0x7400-0x7407,0x7802 on irq 11 (shared with ide0) ide_setup: hda=1247,255,63 ide_setup: hdc=1247,255,63 hda: QUANTUM FIREBALL EL10.2A, 9787MB w/418kB Cache, CHS=1247/255/63, UDMA hdc: QUANTUM FIREBALL EL10.2A, 9787MB w/418kB Cache, CHS=1247/255/63, UDMA
This logs from a modified version of 2.0.35. Note that all three cases work with on/off board chipsets
> For LILO one may live with that - there have always > been restrictions on the place of the kernel on disk. > But for fdisk that is inacceptable - people struggle > with this, and - as far as I can see - there is no > reason at all to inflict these problems unto them. > > The number of people with 8+ GB disks increases quickly. > The handling of large IDE disks has always been broken, > but in 2.0.35 and 2.1.90 this problem was partially > corrected by inserting the test for C/H/S=16383/16/63. > However, this only solves the problem if the BIOS is > not using a translation (`LBA' or `Large' or so). > People with a large IDE disk and translating BIOS > still cannot use the entire disk (without overriding > the kernel view by giving LILO additional hda=C,H,S > parameters, or going into expert mode of fdisk, etc.). > > The sooner this is corrected, the better.
I agree, but lets not carelessly blind-side the BIOS....I have done this many times by disregarding Mark's and Gadi's warnings.......thus trashed my various systems at least one order of magnitude that you have. However I did learn.......... As for the issue at hand.......I have been looking to that problem for several months, well the next day after I got my first 8.0+ Gig drive. I have dirty solutions that are getting cleaner everyday. Feel free to post a real patch and document it and ask people to test it and report back...........did I forget the FLAME factor......... When I started to begin maintaining the IDE-driver at 2.1.121/122 transistion........I got out my asbestos suit and needed it.......not til 2.1.126/127 did I resolve the need parts of patch code not submitted in the beginning. I thought I got it right with 6 different system tests and various mainboards. Except for that ASUS P55T2P4D (decouple PIIX3 from host/isa bridges) with a Promise Ultra33......but I had a quick solution, because I guess every possible breaks and gamble/lost/re-patched what I thought was obvious. My warning is to make ever WAG (wild a** guess) of problems and test the limits of every combination you can think of to break and bust you solution, note you will miss at least one......... > Andries >
Cheers, Andre Hedrick The IDE-FNG for Linux The APC UPS Specialist for Linux
http://www.dyer.vanderbilt.edu/server/udma/ http://www.dyer.vanderbilt.edu/server/apcupsd/apcupsd-3.5.0.bin.tar.gz
Please read the FAQ at http://www.tux.org/lkml/
------------------------------ From: Rik van Riel <H.H.vanRiel@phys.uu.nl> Date: Fri, 4 Dec 1998 21:47:04 +0100 (CET) Subject: Re: [PATCH] swapin readahead and fixes
On Fri, 4 Dec 1998, Chris Evans wrote: > On Thu, 3 Dec 1998, Rik van Riel wrote: > > > here is a patch (against 2.1.130, but vs. 2.1.131 should > > be trivial) that improves the swapping performance both > > during swapout and swapin and contains a few minor fixes. > > I'm very interested in performance for sequential swapping. This > occurs in for example scientific applications which much sweep > through vast arrays much larger than physical RAM. > > This is one area in which FreeBSD stomps on us. Theoretically it > should be possible to get swap with readahead pulling pages into RAM > at disk speed.
We're not at that point yet, not at all :(
We probably could put in an algorithm that does that as well, but the current patch consists mainly of a proof- of-concept (read really stupid) readahead algorithm :)
The advantage of that algorithm however is that it doesn't incur any extra disk seeks (only linear readahead inside the swap area). The way kswapd swaps out things this might also help with the readahead of tiled date, etc...
I will compile a new patch (against 2.1.130 again, since 2.1.131 contains mostly VM mistakes that I want reversed) this weekend...
regards,
Rik -- the flu hits, the flu hits, the flu hits -- MORE +-------------------------------------------------------------------+ | Linux memory management tour guide. H.H.vanRiel@phys.uu.nl | | Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ | +-------------------------------------------------------------------+
Please read the FAQ at http://www.tux.org/lkml/
------------------------------ From: Alexander Viro <viro@math.psu.edu> Date: Fri, 4 Dec 1998 16:32:19 -0500 (EST) Subject: Re: /proc and /kern
On 3 Dec 1998, Mirian Crzig Lennox wrote:
> At a minimum, it would be nice if there were some way for stat() to > tell the caller "this is a file of indefinite size", rather than the > misleading "this is an empty file". That way, ls could be modified to > display "--" or some other non-numeric for the file size.
You have it. lseek(foo,0,SEEK_END)==-ESPIPE worked for ages on VAXen and it works on Linux. All you need is to replace lseek() method for those files with dummy returning -ESPIPE. Look for file_operations structures in fs/proc/*.c - they contain method tables. grep is your friend. Al - -- There are no "civil aviation for dummies" books out there and most of you would probably be scared and spend a lot of your time looking up if there was one. :-) Jordan Hubbard in c.u.b.f.m
Please read the FAQ at http://www.tux.org/lkml/
------------------------------ From: Krzysztof Halasa <khc@intrepid.pm.waw.pl> Date: 03 Dec 1998 22:59:26 +0100 Subject: Re: Synchronous protocols on Linux
Michael Lausch <mla@gams.co.at> writes:
> some time ago i fetched the GPL source from sdlcomm's ftp site. i > still have it. The driver works now for 1 month in a 2.0.x environment > without downtime in Cisco HDLC mode. > <ftp://ftp.gams.at/pub/linux/sdl/sdlcomm-n2-cisco-hdlc-0.1.tar.gz>
Yes, but... it lacks FR protocol. SDL had source of Cisco, sync PPP and raw HDLC available on their ftp. They were also selling FR driver, with object-only FR module. Some time ago they stopped to provide any drivers, and they have some "devel kit" available under NDA.
I assume current driver manufacturer (there is info on ftp.sdlcomm.com) signed the NDA and is providing binary-only drivers for Cisco, PPP, raw and FR protocols for free. I believe it may violate the GPL, if the code is based on part of Linux kernel.
Anyway, this binary FR driver is good as a toy, but not in mission-critical router. - -- Krzysztof Halasa Network Administrator of The Palace of Youth in Warsaw
Please read the FAQ at http://www.tux.org/lkml/
------------------------------ From: Alexander Viro <viro@math.psu.edu> Date: Fri, 4 Dec 1998 17:05:41 -0500 (EST) Subject: [PATCH] More rmdir fixes (was: Linux-2.1.131..)
On Wed, 2 Dec 1998, Linus Torvalds wrote:
> > 2.1.131 is out there now - and will be the last kernel release for a > while. I'm going to Finland for a week and a half, and will be back mid > December. During that time I hope people will beat on this. I'll be able > to read email when I'm gone, but as I haven't been back in over a year, > I'm not very likely to. > > Alan, I have got any replies (positive or negative) about the VFS fixes in > pre-2.1.131-3 (which are obviously in the real 131 too), so I hope that > means that I successfully fixed all filesystems. The chance of that being > true is remote, but hey, I can hope. If not, I assume you'll be doing > your ac patches anyway (any bugs wrt rmdir() should be fairly obvious once > seen), and people might as well consider those official..
Here comes the tail of rmdir fixes. I hope there will be no more surprises in this area. Summary: a) sysvfs: handling of busy directories wasn't updated back when we switched to dentries. Fixed (to new scheme). b) qnx4: plugged an inode leak. c) affs: directories behave as sticky there, but sticky bit wasn't set in i_mode. Fixed. d) ufs: this beast allows deletion of busy directory (as ext2 does), but handling of this case wasn't updated (== stopped working). Fixed. e) NFSD rmdir missed locking and quite a few tests. Fixed (see below) f) filesystem-independant tests (e.g. S_ISDIR(dentry) ;-) moved from filesystems to VFS (where the rest of them lived). Error codes made consistent (IMHO the situation when 3 filesystems return different errors under the same filesystem-independant conditions and 4th one flames and returns 0 is somewhat over the top). g) do_rmdir() now does dentry lookup and locking. All tests and actual call of rmdir() method moved to new function - VFS_rmdir(). It has the same interface as rmdir() method. It has been made public and included into the export list. NFSD rmdir() does required locking and calls VFS_rmdir().
Remaining problems: UMSDOS rename() is still slightly broken - it returns EBUSY if the target already exists and is an empty directory (side effect of new busy-detection scheme). I'll fix it as soon as I'll get to rename() cleanup. NFSD should do some tests in unlink() (and maybe in some other operations). Cheers, Al Patch against 2.1.131 follows:
diff -u --recursive --new-file v2.1.131/linux/fs/ChangeLog linux/fs/ChangeLog - --- v2.1.131/linux/fs/ChangeLog Tue Oct 25 12:10:14 1994 +++ linux/fs/ChangeLog Fri Dec 4 11:48:58 1998 @@ -8,3 +8,67 @@ * fcntl.c (sys_fcntl): Add more of a security check to the F_SETOWN fcntl(). +[Tons of changes missed, indeed. This list is worth restarting since +at least some fixes WILL break third-party filesystems. Sorry, but +there was no other way to fix rmdir/rename deadlock, for one.] + +Wed Dec 2 (Linus, fill the rest, please) + + * namei.c (do_rmdir) and rmdir method in filesystems: + Locking of directory we remove was taken to VFS. + See comments in do_rmdir(). Unfixed filesystems + will bloody likely deadlock in rmdir(). + +Thu Dec 3 17:25:31 1998 Al Viro (viro@math.psu.edu) + + * namei.c (do_rmdir): + Reject non-directories here. + Two (probably) obsolete checks moved here too: we fail if + the directory we remove is the same as parent (BUG: we + serve mountpoints later) or if it lives on a different + device. + * sysvfs/namei.c (sysv_rmdir): + Bugectomy: old check for victim being busy (inode->i_count) + wasn't replaced (with checking dentry->d_count) and escaped + Linus in the last round of changes. Shot and buried. + +Fri Dec 4 00:54:12 1998 AV + + * namei.c (check_sticky): New function check_sticky(dir, inode). + If dir is sticky check whether we can unlink/rmdir/rename + the inode. Returns 1 if we can't. If dir isn't sticky - + return 0 (i.e. no objections). Some filesystems require + suser() here; some are fine with CAP_FOWNER. The later + seems more reasonable. + * namei.c (do_rmdir): + Moved the check for sticky bit here. + * affs/{inode,namei}.c: + All AFFS directories have sticky semantics (i.e. non-owner + having write permisssions on directory can unlink/rmdir/rename + only the files he owns), but AFFS didn't set S_ISVTX on them. + Fixed. NB: maybe this behaviour should be controlled by mount + option. Obvious values being 'sticky' (current behaviour), + 'nonsticky' (normal behaviour) and maybe some play on 'D' + permissions bit. FIXME. + * qnx4/namei.c (qnx4_rmdir): + Plugged inode leak. + * ufs/namei.c (ufs_rmdir): + Changed handling of busy directory to new scheme. + +Fri Dec 4 10:30:58 1998 AV + + * namei.c (VFS_rmdir): New function. It gets inode of the parent and + dentry of the victim, does all checks and applies fs-specific + rmdir() method. It should be called with semaphores down + on both the victim and its parent and with bumped d_count on + victim (see comments in do_rmdir). + * include/linux/fs.h: Added VFS_rmdir + * kernel/ksyms.c: Added VFS_rmdir to export list (for NFSD). + * nfsd/vfs.c: Fixed rmdir handling. + + Remaining problems with rmdir: + UMSDOS_rename is broken. Call it with the dest. existing and + being an empty directory and you've got EBUSY. At least it + doesn't do any harm, so that will wait several days till rename + cleanup. + TODO: unlink handling in NFSD does no tests. diff -u --recursive --new-file v2.1.131/linux/fs/affs/inode.c linux/fs/affs/inode.c - --- v2.1.131/linux/fs/affs/inode.c Fri May 8 01:58:04 1998 +++ linux/fs/affs/inode.c Thu Dec 3 20:10:38 1998 @@ -170,8 +170,11 @@ } else { inode->i_op = &affs_file_inode_operations; } - - } else if (S_ISDIR(inode->i_mode)) + } else if (S_ISDIR(inode->i_mode)) { + /* Maybe it should be controlled by mount parameter? */ + inode->i_mode |= S_ISVTX; inode->i_op = &affs_dir_inode_operations; + } else if (S_ISLNK(inode->i_mode)) inode->i_op = &affs_symlink_inode_operations; } diff -u --recursive --new-file v2.1.131/linux/fs/affs/namei.c linux/fs/affs/namei.c - --- v2.1.131/linux/fs/affs/namei.c Thu Dec 3 16:58:49 1998 +++ linux/fs/affs/namei.c Fri Dec 4 00:19:14 1998 @@ -319,7 +319,7 @@ error = affs_add_entry(dir,NULL,inode,dentry,ST_USERDIR); if (error) goto out_iput; - - inode->i_mode = S_IFDIR | (mode & 0777 & ~current->fs->umask); + inode->i_mode = S_IFDIR | S_ISVTX | (mode & 0777 & ~current->fs->umask); inode->u.affs_i.i_protect = mode_to_prot(inode->i_mode); d_instantiate(dentry,inode); mark_inode_dirty(inode); @@ -360,17 +360,6 @@ if (!(bh = affs_find_entry(dir,dentry,&ino))) goto rmdir_done; - - retval = -EPERM; - - if (current->fsuid != inode->i_uid && - - current->fsuid != dir->i_uid && !capable(CAP_FOWNER)) - - goto rmdir_done; - - if (inode->i_dev != dir->i_dev) - - goto rmdir_done; - - if (inode == dir) /* we may not delete ".", but "../dir" is ok */ - - goto rmdir_done; - - retval = -ENOTDIR; - - if (!S_ISDIR(inode->i_mode)) - - goto rmdir_done; /* * Make sure the directory is empty and the dentry isn't busy. */ diff -u --recursive --new-file v2.1.131/linux/fs/ext2/namei.c linux/fs/ext2/namei.c - --- v2.1.131/linux/fs/ext2/namei.c Thu Dec 3 16:58:49 1998 +++ linux/fs/ext2/namei.c Fri Dec 4 00:20:29 1998 @@ -643,21 +643,7 @@ inode = dentry->d_inode; DQUOT_INIT(inode); - - retval = -EPERM; - - if ((dir->i_mode & S_ISVTX) && - - current->fsuid != inode->i_uid && - - current->fsuid != dir->i_uid && !capable(CAP_FOWNER)) - - goto end_rmdir; - - if (inode == dir) /* we may not delete ".", but "../dir" is ok */ - - goto end_rmdir; - - - - retval = -ENOTDIR; - - if (!S_ISDIR(inode->i_mode)) - - goto end_rmdir; - - retval = -EIO; - - if (inode->i_dev != dir->i_dev) - - goto end_rmdir; if (le32_to_cpu(de->inode) != inode->i_ino) goto end_rmdir; diff -u --recursive --new-file v2.1.131/linux/fs/hfs/dir.c linux/fs/hfs/dir.c - --- v2.1.131/linux/fs/hfs/dir.c Thu Dec 3 16:58:49 1998 +++ linux/fs/hfs/dir.c Fri Dec 4 08:29:03 1998 @@ -337,9 +337,6 @@ struct hfs_cat_key key; int error; - - if (parent == inode) /* can't delete . */ - - return -EPERM; - - if (build_key(&key, parent, dentry->d_name.name, dentry->d_name.len)) return -EPERM; diff -u --recursive --new-file v2.1.131/linux/fs/minix/namei.c linux/fs/minix/namei.c - --- v2.1.131/linux/fs/minix/namei.c Thu Dec 3 16:58:49 1998 +++ linux/fs/minix/namei.c Fri Dec 4 00:22:28 1998 @@ -429,21 +429,8 @@ retval = -ENOENT; if (!bh) goto end_rmdir; - - retval = -EPERM; inode = dentry->d_inode; - - if ((dir->i_mode & S_ISVTX) && - - current->fsuid != inode->i_uid && - - current->fsuid != dir->i_uid && !capable(CAP_FOWNER)) - - goto end_rmdir; - - if (inode->i_dev != dir->i_dev) - - goto end_rmdir; - - if (inode == dir) /* we may not delete ".", but "../dir" is ok */ - - goto end_rmdir; - - if (!S_ISDIR(inode->i_mode)) { - - retval = -ENOTDIR; - - goto end_rmdir; - - } if (!empty_dir(inode)) { retval = -ENOTEMPTY; goto end_rmdir; diff -u --recursive --new-file v2.1.131/linux/fs/msdos/namei.c linux/fs/msdos/namei.c - --- v2.1.131/linux/fs/msdos/namei.c Thu Dec 3 16:58:49 1998 +++ linux/fs/msdos/namei.c Thu Dec 3 18:16:11 1998 @@ -439,11 +439,6 @@ &bh, &de, &ino); if (res < 0) goto rmdir_done; - - res = -ENOTDIR; - - if (!S_ISDIR(inode->i_mode)) - - goto rmdir_done; - - if (dir->i_dev != inode->i_dev || dir == inode) - - printk("msdos_rmdir: impossible condition\n"); /* * Check whether the directory is empty, then prune * any child dentries and make sure it's not in use. diff -u --recursive --new-file v2.1.131/linux/fs/namei.c linux/fs/namei.c - --- v2.1.131/linux/fs/namei.c Thu Dec 3 16:58:49 1998 +++ linux/fs/namei.c Fri Dec 4 12:21:26 1998 @@ -865,58 +865,67 @@ dput(d2); } - -static inline int do_rmdir(const char * name) - -{ - - int error; - - struct dentry *dir; - - struct dentry *dentry; - - - - dentry = lookup_dentry(name, NULL, 0); - - error = PTR_ERR(dentry); - - if (IS_ERR(dentry)) - - goto exit; +/* + * It's inline, so penalty for filesystems that don't use sticky bit is + * minimal. + */ - - dir = dget(dentry->d_parent); +static inline int check_sticky(struct inode *dir, struct inode *inode) +{ + if (!(dir->i_mode & S_ISVTX)) + return 0; + if (inode->i_uid == current->fsuid) + return 0; + if (dir->i_uid == current->fsuid) + return 0; + return !capable(CAP_FOWNER); +} - - error = -ENOENT; - - if (!dentry->d_inode) - - goto exit; - - /* - - * The dentry->d_count stuff confuses d_delete() enough to - - * not kill the inode from under us while it is locked. This - - * wouldn't be needed, except the dentry semaphore is really - - * in the inode, not in the dentry.. - - */ - - dentry->d_count++; - - double_lock(dir, dentry); - - if (dentry->d_parent != dir) - - goto exit_lock; +int VFS_rmdir(struct inode *dir, struct dentry *dentry) +{ + int error; - - error = -EROFS; - - if (IS_RDONLY(dir->d_inode)) - - goto exit_lock; + if (IS_RDONLY(dir)) + return -EROFS; - - error = permission(dir->d_inode,MAY_WRITE | MAY_EXEC); + error = permission(dir,MAY_WRITE | MAY_EXEC); if (error) - - goto exit_lock; + return error; /* * A subdirectory cannot be removed from an append-only directory. */ - - error = -EPERM; - - if (IS_APPEND(dir->d_inode)) - - goto exit_lock; + if (IS_APPEND(dir)) + return -EPERM; + /* + * Check the sticky bit. + */ + if (check_sticky(dir, dentry->d_inode)) + return -EPERM; /* Disallow removals of mountpoints. */ - - error = -EBUSY; if (dentry->d_mounts != dentry->d_covers) - - goto exit_lock; - - - - error = -EPERM; - - if (!dir->d_inode->i_op || !dir->d_inode->i_op->rmdir) - - goto exit_lock; + return -EBUSY; - - DQUOT_INIT(dir->d_inode); + if (!dir->i_op || !dir->i_op->rmdir) + return -EPERM; + /* + * I suspect that these two checks are atavisms copied from minixfs + * and it looks like they can be dropped. Anyway, it will be simpler + * to drop them from here and even if those checks are needed they + * belong to VFS. + */ + if (dir == dentry->d_inode) + return -EPERM; + if (dir->i_dev != dentry->d_inode->i_dev) + return -EPERM; + /* + * Non-directories can't be rmdir'd. It may confuse the heck of + * NFS and CODA. Testing it in VFS is the Right Thing (tm), anyway. + */ + if (!S_ISDIR(dentry->d_inode->i_mode)) + return -ENOTDIR; + DQUOT_INIT(dir); /* * We try to drop the dentry early: we should have @@ -942,9 +951,42 @@ d_drop(dentry); } - - error = dir->d_inode->i_op->rmdir(dir->d_inode, dentry); + error = dir->i_op->rmdir(dir, dentry); + + return error; +} + +static inline int do_rmdir(const char * name) +{ + int error; + struct dentry *dir; + struct dentry *dentry; + + dentry = lookup_dentry(name, NULL, 0); + error = PTR_ERR(dentry); + if (IS_ERR(dentry)) + goto exit; + + dir = dget(dentry->d_parent); + + error = -ENOENT; + if (!dentry->d_inode) + goto exit; + /* + * The dentry->d_count stuff confuses d_delete() enough to + * not kill the inode from under us while it is locked. This + * wouldn't be needed, except the dentry semaphore is really + * in the inode, not in the dentry.. + */ + dentry->d_count++; + double_lock(dir, dentry); + + /* + * Check that dentry still sits where it did and do the real stuff. + */ + if (dentry->d_parent == dir) + error = VFS_rmdir(dir->d_inode, dentry); - -exit_lock: dentry->d_count--; double_unlock(dentry, dir); exit: diff -u --recursive --new-file v2.1.131/linux/fs/nfs/dir.c linux/fs/nfs/dir.c - --- v2.1.131/linux/fs/nfs/dir.c Thu Dec 3 16:58:50 1998 +++ linux/fs/nfs/dir.c Thu Dec 3 18:19:35 1998 @@ -718,6 +718,9 @@ * * We update inode->i_nlink and free the inode prior to the operation * to avoid possible races if the server reuses the inode. + * + * FIXME! We don't do it anymore (2.1.131) - it interacts badly with + * new rmdir(). -- AV */ static int nfs_rmdir(struct inode *dir, struct dentry *dentry) { diff -u --recursive --new-file v2.1.131/linux/fs/nfsd/vfs.c linux/fs/nfsd/vfs.c - --- v2.1.131/linux/fs/nfsd/vfs.c Thu Dec 3 16:58:50 1998 +++ linux/fs/nfsd/vfs.c Fri Dec 4 13:00:06 1998 @@ -1076,25 +1076,49 @@ * FIXME!! * * This should do a double-lock on both rdentry and the parent + * + * Moreover, it should do checks *both* for unlink and rmdir + * cases. AV */ - - err = fh_lock_parent(fhp, rdentry); - - if (err) - - goto out; - - - - DQUOT_INIT(dirp); - - if (type == S_IFDIR) { - - err = -ENOTDIR; - - if (dirp->i_op && dirp->i_op->rmdir) - - err = dirp->i_op->rmdir(dirp, rdentry); - - } else { + if (type != S_IFDIR) { + /* It's UNLINK */ + err = fh_lock_parent(fhp, rdentry); + if (err) + goto out; + + DQUOT_INIT(dirp); err = -EPERM; if (dirp->i_op && dirp->i_op->unlink) err = dirp->i_op->unlink(dirp, rdentry); + DQUOT_DROP(dirp); + fh_unlock(fhp); + + dput(rdentry); + + } else { + /* It's RMDIR */ + /* See comments in fs/namei.c:do_rmdir */ + rdentry->d_count++; + nfsd_double_down(&dirp->i_sem, &rdentry->d_inode->i_sem); + if (!fhp->fh_pre_mtime) + fhp->fh_pre_mtime = dirp->i_mtime; + fhp->fh_locked = 1; + /* CHECKME: Should we do something with the child? */ + + err = -ENOENT; + if (rdentry->d_parent->d_inode == dirp) + err = VFS_rmdir(dirp, rdentry); + + rdentry->d_count--; + DQUOT_DROP(dirp); + if (!fhp->fh_post_version) + fhp->fh_post_version = dirp->i_version; + fhp->fh_locked = 0; + nfsd_double_up(&dirp->i_sem, &rdentry->d_inode->i_sem); + + dput(rdentry); } - - DQUOT_DROP(dirp); - - fh_unlock(fhp); - - dput(rdentry); if (err) goto out_nfserr; if (EX_ISSYNC(fhp->fh_export)) diff -u --recursive --new-file v2.1.131/linux/fs/qnx4/namei.c linux/fs/qnx4/namei.c - --- v2.1.131/linux/fs/qnx4/namei.c Thu Dec 3 16:58:50 1998 +++ linux/fs/qnx4/namei.c Fri Dec 4 00:49:38 1998 @@ -168,29 +168,9 @@ if (bh == NULL) { return -ENOENT; } - - if ((inode = iget(dir->i_sb, ino)) == NULL) { - - QNX4DEBUG(("qnx4: lookup->iget -> NULL\n")); - - retval = -EACCES; - - goto end_rmdir; - - } - - retval = -EPERM; - - if ((dir->i_mode & S_ISVTX) && - - current->fsuid != inode->i_uid && - - current->fsuid != dir->i_uid && !capable(CAP_FOWNER)) { - - QNX4DEBUG(("qnx4: rmdir->capabilities\n")); - - goto end_rmdir; - - } - - if (inode->i_dev != dir->i_dev) { - - QNX4DEBUG(("qnx4: rmdir->different devices\n")); - - goto end_rmdir; - - } - - if (inode == dir) { /* we may not delete ".", but "../dir" is ok */ - - QNX4DEBUG(("qnx4: inode==dir\n")); - - goto end_rmdir; - - } - - if (!S_ISDIR(inode->i_mode)) { - - QNX4DEBUG(("qnx4: rmdir->not a directory\n")); - - retval = -ENOTDIR; + inode = dentry->d_inode; + if (inode->i_ino != ino) { + retval = -EIO; goto end_rmdir; } #if 0 diff -u --recursive --new-file v2.1.131/linux/fs/smbfs/dir.c linux/fs/smbfs/dir.c - --- v2.1.131/linux/fs/smbfs/dir.c Thu Dec 3 16:58:50 1998 +++ linux/fs/smbfs/dir.c Thu Dec 3 17:22:13 1998 @@ -469,10 +469,6 @@ struct inode *inode = dentry->d_inode; int error; - - error = -ENOTDIR; - - if (!S_ISDIR(inode->i_mode)) - - goto out; - - /* * Close the directory if it's open. */ diff -u --recursive --new-file v2.1.131/linux/fs/sysv/namei.c linux/fs/sysv/namei.c - --- v2.1.131/linux/fs/sysv/namei.c Thu Dec 3 16:58:50 1998 +++ linux/fs/sysv/namei.c Fri Dec 4 00:41:09 1998 @@ -416,21 +416,8 @@ retval = -ENOENT; if (!bh) goto end_rmdir; - - retval = -EPERM; inode = dentry->d_inode; - - if ((dir->i_mode & S_ISVTX) && - - current->fsuid != inode->i_uid && - - current->fsuid != dir->i_uid && !capable(CAP_FOWNER)) - - goto end_rmdir; - - if (inode->i_dev != dir->i_dev) - - goto end_rmdir; - - if (inode == dir) /* we may not delete ".", but "../dir" is ok */ - - goto end_rmdir; - - if (!S_ISDIR(inode->i_mode)) { - - retval = -ENOTDIR; - - goto end_rmdir; - - } if (!empty_dir(inode)) { retval = -ENOTEMPTY; goto end_rmdir; @@ -439,7 +426,7 @@ retval = -ENOENT; goto end_rmdir; } - - if (inode->i_count > 1) { + if (!list_empty(&dentry->d_hash)) { retval = -EBUSY; goto end_rmdir; } diff -u --recursive --new-file v2.1.131/linux/fs/ufs/namei.c linux/fs/ufs/namei.c - --- v2.1.131/linux/fs/ufs/namei.c Thu Dec 3 16:58:50 1998 +++ linux/fs/ufs/namei.c Fri Dec 4 00:46:06 1998 @@ -683,46 +683,15 @@ if (inode->i_sb->dq_op) inode->i_sb->dq_op->initialize (inode, -1); - - retval = -EPERM; - - if ((dir->i_mode & S_ISVTX) && - - current->fsuid != inode->i_uid && - - current->fsuid != dir->i_uid && !fsuser()) - - goto end_rmdir; - - if (inode == dir) /* we may not delete ".", but "../dir" is ok */ - - goto end_rmdir; - - - - retval = -ENOTDIR; - - if (!S_ISDIR(inode->i_mode)) - - goto end_rmdir; - - retval = -EIO; - - if (inode->i_dev != dir->i_dev) - - goto end_rmdir; if (SWAB32(de->d_ino) != inode->i_ino) goto end_rmdir; - - /* - - * Prune any child dentries so that this dentry becomes negative. - - */ - - if (dentry->d_count > 1) { - - ufs_warning (sb, "ufs_rmdir", "d_count=%d, pruning\n", dentry->d_count); - - shrink_dcache_parent(dentry); - - } if (!ufs_empty_dir (inode)) retval = -ENOTEMPTY; else if (SWAB32(de->d_ino) != inode->i_ino) retval = -ENOENT; else { - - if (dentry->d_count > 1) { - - /* - - * Are we deleting the last instance of a busy directory? - - * Better clean up if so. - - * - - * Make directory empty (it will be truncated when finally - - * dereferenced). This also inhibits ufs_add_entry. - - */ - - inode->i_size = 0; - - } retval = ufs_delete_entry (dir, de, bh); dir->i_version = ++event; } @@ -739,6 +708,7 @@ inode->i_nlink); inode->i_version = ++event; inode->i_nlink = 0; + inode->i_size = 0; mark_inode_dirty(inode); dir->i_nlink--; inode->i_ctime = dir->i_ctime = dir->i_mtime = CURRENT_TIME; diff -u --recursive --new-file v2.1.131/linux/fs/umsdos/namei.c linux/fs/umsdos/namei.c - --- v2.1.131/linux/fs/umsdos/namei.c Thu Dec 3 16:58:51 1998 +++ linux/fs/umsdos/namei.c Fri Dec 4 00:31:47 1998 @@ -1011,14 +1011,6 @@ if (!list_empty(&dentry->d_hash)) goto out; - - /* check the sticky bit */ - - ret = -EPERM; - - if (is_sticky(dir, dentry->d_inode->i_uid)) { - -printk("umsdos_rmdir: %s/%s is sticky\n", - -dentry->d_parent->d_name.name, dentry->d_name.name); - - goto out; - - } - - /* check whether the EMD is empty */ ret = -ENOTEMPTY; empty = umsdos_isempty (dentry); diff -u --recursive --new-file v2.1.131/linux/fs/vfat/namei.c linux/fs/vfat/namei.c - --- v2.1.131/linux/fs/vfat/namei.c Thu Dec 3 16:58:51 1998 +++ linux/fs/vfat/namei.c Thu Dec 3 18:35:54 1998 @@ -1416,12 +1416,6 @@ struct super_block *sb = dir->i_sb; int res; - - if (!S_ISDIR(dentry->d_inode->i_mode)) { - - return -ENOTDIR; - - } - - if (dir->i_dev != dentry->d_inode->i_dev || dir == dentry->d_inode) { - - return -EBUSY; - - } if (!list_empty(&dentry->d_hash)) return -EBUSY; diff -u --recursive --new-file v2.1.131/linux/include/linux/fs.h linux/include/linux/fs.h - --- v2.1.131/linux/include/linux/fs.h Fri Nov 13 18:31:14 1998 +++ linux/include/linux/fs.h Fri Dec 4 13:26:04 1998 @@ -776,6 +776,7 @@ extern void put_write_access(struct inode *inode); extern struct dentry * open_namei(const char * pathname, int flag, int mode); extern struct dentry * do_mknod(const char * filename, int mode, dev_t dev); +extern int VFS_rmdir(struct inode *dir, struct dentry *dentry); extern int do_pipe(int *); /* fs/dcache.c -- generic fs support functions */ diff -u --recursive --new-file v2.1.131/linux/kernel/ksyms.c linux/kernel/ksyms.c - --- v2.1.131/linux/kernel/ksyms.c Sat Nov 28 02:08:10 1998 +++ linux/kernel/ksyms.c Fri Dec 4 11:42:46 1998 @@ -172,6 +172,7 @@ EXPORT_SYMBOL(find_inode_number); EXPORT_SYMBOL(is_subdir); EXPORT_SYMBOL(get_unused_fd); +EXPORT_SYMBOL(VFS_rmdir); #if !defined(CONFIG_NFSD) && defined(CONFIG_NFSD_MODULE) EXPORT_SYMBOL(do_nfsservctl);
Please read the FAQ at http://www.tux.org/lkml/
------------------------------ End of linux-kernel-digest V1 #2944 *********************************** 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/
| |