lkml.org 
[lkml]   [1998]   [Dec]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patches in this message
/
Date
From
SubjectRe: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/

\
 
 \ /
  Last update: 2005-03-22 13:45    [W:0.163 / U:0.376 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site