>From smtp Tue Oct 28 19:54 EST 1997
>From linux-kernel@vger.rutgers.edu Tue Oct 28 16:12:15 0500 1997
X-Warning: Original message contained 8-bit characters, however during
the SMTP transport session the receiving system was unable to
announce capability of receiving 8-bit SMTP (RFC 1651-1653),
and as this message does not have MIME headers (RFC 2045-2049)
to enable encoding change, we had very little choices.
X-Warning: We ASSUME it is less harmful to add the MIME headers, and
convert the text to Quoted-Printable, than not to do so,
and to strip the message to 7-bits.. (RFC 1428 Appendix A)
X-Warning: We don't know what character set the user used, thus we had to
write these MIME-headers with our local system default value.
MIME-Version: 1.0
Content-Transfer-Encoding: QUOTED-PRINTABLE
Received: from vger.rutgers.edu ([128.6.190.2] EHLO vger.rutgers.edu ident: root [port 56109]) by nic.funet.fi with ESMTP id <1364-27915>; Tue, 28 Oct 1997 23:20:45 +0200
Received: by vger.rutgers.edu id <970858-249>; Tue, 28 Oct 1997 16:12:55 -0500
Content-Length: 76943
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Auto-Forwarded-From: nimitz!gmi
Auto-Forward-Count: 1
From: owner-linux-kernel-digest@vger.rutgers.edu
To: linux-kernel-digest@vger.rutgers.edu
Subject: linux-kernel-digest V1 #1272
Reply-To: linux-kernel@vger.rutgers.edu
Errors-To: owner-linux-kernel-digest@vger.rutgers.edu
Precedence: bulk
Message-Id: <19971028211255Z970858-249+5949@vger.rutgers.edu>
Date: Tue, 28 Oct 1997 16:12:15 -0500
linux-kernel-digest Tuesday, 28 October 1997 Volume 01 : Num=
ber 1272
In this issue:
Re: 2.1.60 NFS probs...
Re: Problems with 3C905 and Linux
Re: 2.1.60 NFS probs...
Re: FAT32 Problem=20
Re: 2.1.60 NFS probs...
Re: Makefile defaulting to SMP
Re: 2.1.60 NFS probs...=20
Re: CD Filesystem still broken!
Re: 2.1.60 NFS probs...
Re: 2.1.60 NFS probs (updated patch attached)
Re: Patch: Linux on Alphas and IPX protocol
updated smbfs for 2.1.60
Kernel messages
to whom it may concern (about dcache)
Re: 2.1.60 NFS probs (updated patch attached)
Re: Kernel messages=20
ADMIN: linux-kernel-digest/linux-kernel
iput: inode 542827 on device 03:02 still has mappings.
problem with mprotect
[2.1.59] vfat error
Re: Makefile defaulting to SMP
updated dcache management patch for 2.1.60
Re: to whom it may concern (about dcache)
How do I debug kernel MEMORY LEAKS?
Re: to whom it may concern (about dcache)
Linux 2.0.31 went nuts
Re: How do I debug kernel MEMORY LEAKS?
Kernels 2.1 with 386DX/387 IRQ13 PC boxes
OFF-TOPIC: Corel using Linux
Re: irq2dev_map in 2.1.60
See the end of the digest for information on subscribing to the linux-k=
ernel
or linux-kernel-digest mailing lists.
----------------------------------------------------------------------
From: Bill Hawes <whawes@star.net>
Date: Tue, 28 Oct 1997 09:56:36 -0500
Subject: Re: 2.1.60 NFS probs...
Matthew Kirkwood wrote:
> However, the following rather painless message can be repeatably
> provoked by ( cd /usr/src/linux ; make menuconfig ), among other
> things:
> NFS: invalidating pending RPC requests
>=20
> Once this has happened, that process hangs, and any logins on other
> consoles fail also. Stopping and starting the NFS server fixes this
> and ps shows a
> /bin/sh scripts/Menuconfig arch/i386/config.in
> in the "D" state and nothing else of particular interest.
> "ps l" claims that every process but itself is in "end" which I find
> vaguely confusing.
>=20
> It looks to me as if the machine is hanging processes in exactly the
> same places as it would previously have corrupted files.
Hi Matthew,
Thanks for the report ... the pending RPC request problem looks very
interesting. If an RPC request is getting stuck, this previously would
have been a silent memory leak. I'll look into why this is happening
...
Regards,
Bill
------------------------------
From: Troels Arvin <rhl@www.studmed.ku.dk>
Date: Tue, 28 Oct 1997 15:52:51 +0100
Subject: Re: Problems with 3C905 and Linux
At 12:31 28-10-97 +0100, Peter Enderborg wrote:
>> Summary: Server freezes with clean kernel 2.0.31 (and - I have now
>> discovered - also with an updated version of 3c59x.c). Network suppo=
rt
>> compiled staticly into kernel; no support for other network devices.
>> Network card: 3Com Fast EtherLink XL PCI (alias Boomerang) (3C905-TX=
rev.
>> B) running at 100Mbit. Computer: Pentium, HX-motherboard, 32MB RAM.
>Try this patch: (in linux/drivers/net/3c59x.c)
>
>797,801c797,798
>< /* pme patch */
>< /* vp->full_bus_master_tx =3D 1; */
>< vp->full_bus_master_tx =3D 0;=20
>< /* end patch */
>< printk(" Enabling bus-master (not transmits) but %s
>receives.\n",
>---
>> vp->full_bus_master_tx =3D 1;
>> printk(" Enabling bus-master transmits and %s receives.\n=
",
:-(
Doesn't work. Server stille freezes - after about half an hour. Thanks
anyways.
Greetings from Troels Arvin, Copenhagen, Denmark
http://www.mdb.ku.dk/tarvin/
------------------------------
From: Ketil Z Malde <ketil@ii.uib.no>
Date: 28 Oct 1997 15:52:21 +0100
Subject: Re: 2.1.60 NFS probs...
Matthew Kirkwood <matthew.kirkwood@lmh.ox.ac.uk> writes:
> ne.c:v1.10 9/23/94 Donald Becker (becker@cesdis.gsfc.nasa.gov)
> NE*000 ethercard probe at 0x300: 00 00 e8 2b 76 73
> eth0: NE2000 found at 0x300, using IRQ 4.
> Looking up port of RPC 100003/2 on 163.1.138.129
> Looking up port of RPC 100005/1 on 163.1.138.129
> VFS: Mounted root (nfs filesystem).
> Once root is mounted, various daemons fire off, and then the attempt
> to mount /home produces:
> portmap: RPC call returned error 111
> RPC: task of released request still queued!
> RPC: (task is on xprt_pending)
> portmap: RPC call returned error 111
> RPC: task of released request still queued!
> RPC: (task is on xprt_pending)
> lockd_up: makesock failed, error=3D-111
> portmap: RPC call returned error 111
> RPC: task of released request still queued!
> RPC: (task is on xprt_pending)
> Although this may be due to the RH startup scripts producing a broken
> routing table. After this everything's OK and I can log in, fix the
> routes and fire up Quake, ftp, telnet, ssh, etc...
FWIW, I see the same kind of messages on 2.1.58 compiled on RH
thunderbird, when trying to mount up NFS volumes at boot. If make them
``noauto'' in fstab, I can mount them painlessly after boot.
The network card is 3Com Etherlink III, and the NFS server is a Solaris
box, if that matters.=20
~kzm
- --=20
If I haven't seen further, it is by standing in the footprints of giant=
s
------------------------------
From: Noel Maddy <ncm@biostat.hfh.edu>
Date: Tue, 28 Oct 1997 09:56:09 -0500
Subject: Re: FAT32 Problem=20
On Mon, 27 Oct 1997, Bob Nielsen wrote:
> On Mon, 27 Oct 1997, Giuseppe Catastini wrote:
>
[FIPS can't split a FAT32 partition]
>=20
> Giuseppe,
>=20
> As far as I know, the only way to repartition a FAT32 partition is to=
use
> the commercial program Partition Magic version 3.x. Partition Magic =
can
> also convert a FAT32 partition to FAT16. See www.powerquest.com for =
more
> details. Hopefully FIPS will have this capability soon.
>=20
> Bob
But beware the draconian licensing! The license for Partition Magic=20
states that once you have used the licensed copy on one machine, you=20
must not use it on any other machine until you have destroyed or sold=20
the original machine (of course, making sure that it's no longer=20
installed). Talk about single-use, throw-away software!
I'm not saying you shouldn't use Partition Magic, just that you should=20
be aware of this ridiculous license. I bought it because I got myself=20
into a situation where I had to split an NTFS and didn't want to spend=20
the time backing up and restoring. But I was hoping this would be an=20
investment in a tool that would be useful for my support work. Fat=20
chance :(
- --=20
"Some Internet functionality may require Internet access..."
- Microsoft Office 97 requirement=
s
Noel Maddy <nmaddy1@biostat.hfh.edu>
------------------------------
From: Jonathan Stanton <jonathan@cs.jhu.edu>
Date: Tue, 28 Oct 1997 10:38:14 -0500 (EST)
Subject: Re: 2.1.60 NFS probs...
Hi,=20
I've been running the 2.1.60 kernel on a dual Pent II system for
several days now and I have noticed a possibly related problem with NFS=
.
The NFS server is a BSDI/3.0 box. I don't have his problems with start=
up
of nfs, but I have had the same problem with an nfs intensive writes
causeing a process to get stuck.
Senerio:
1) Running X, use Netscape for awhile (my home directory is NFS'd
so my netscape cache is over nfs). After switching to a new page with
lots of grphics netscape hangs.
2) checking it with ps -l, I see it is stuck in 'nfs_delete' in
the 'D' state. I think the function name is cut off by the limited fie=
ld
size, from looking at the source I think it is nfs_delete_inode() in
fs/nfs/inode.c. =20
3) From the source it looks like the client has entered an
uninterruptable loop, and even though there is a timout of (5*HZ) after
waiting about half an hour it hasn't recovered.
4) The netscape process is unkillable, kill -9, root kill, nothing
I could do would get rid of it. Since it was eating 12M of my 32 M sys=
tem
I rebooted and when unmounting the file systems I got errors like
these.
> RPC: sendmsg returned error 101=20
The netscape stuck problem happened again after the reboot, so I don't
think it was a fluke. =20
On Tue, 28 Oct 1997, Matthew Kirkwood wrote:
> Hi,
>=20
> I'm experiencing some difficulty with NFS-root in 2.1.60 (+Bill Hawes
> nfs_client60-patch):
[..]
>=20
> However, the following rather painless message can be repeatably
> provoked by ( cd /usr/src/linux ; make menuconfig ), among other
> things:
> NFS: invalidating pending RPC requests
>=20
> Once this has happened, that process hangs, and any logins on other
> consoles fail also. Stopping and starting the NFS server fixes this
> and ps shows a
> /bin/sh scripts/Menuconfig arch/i386/config.in
> in the "D" state and nothing else of particular interest.
> "ps l" claims that every process but itself is in "end" which I find
> vaguely confusing.
I think that is because the 'correct' System.map file is not in /boot (=
on
Redhat 4.2). When I had a 2.0.30 System.map file there I got 'end' for =
all
processes, but when I copied the current 2.1.60 System.map I got correc=
t
looking functions.
Jonathan
- -------------------------------------------------------
Jonathan R. Stanton jonathan@cs.jhu.edu
Dept. of Computer Science Finger for PGP key
Johns Hopkins University =20
PGP: 13 EE B7 5D 3B F9 5E 9C 41 30 AA 78 30 54 59 D0
- -------------------------------------------------------
------------------------------
From: Michael Elizabeth Chastain <mec@shout.net>
Date: Tue, 28 Oct 1997 09:42:11 -0600
Subject: Re: Makefile defaulting to SMP
I have a patch for this:
ftp://ftp.shout.net/pub/users/mec/patch/config-smp.2154
This makes CONFIG_SMP and CONFIG_SMP_PROF ordinary configuration
options.
Michael Chastain
<mailto:mec@shout.net>
"love without fear"
------------------------------
From: Michael Lausch <mla@gams.co.at>
Date: Tue, 28 Oct 1997 16:54:32 +0100
Subject: Re: 2.1.60 NFS probs...=20
>>>>> "js" =3D=3D Jonathan Stanton <jonathan@cs.jhu.edu>
>>>>> wrote the following on Tue, 28 Oct 1997 10:38:14 -0500 (EST)
js> Hi,=20
js> I've been running the 2.1.60 kernel on a dual Pent II system for
js> several days now and I have noticed a possibly related problem with=
NFS.
js> The NFS server is a BSDI/3.0 box. I don't have his problems with s=
tartup
js> of nfs, but I have had the same problem with an nfs intensive write=
s
js> causeing a process to get stuck.
js> Senerio:
js> 1) Running X, use Netscape for awhile (my home directory is NFS'd
js> so my netscape cache is over nfs). After switching to a new page w=
ith
js> lots of grphics netscape hangs.
js> 2) checking it with ps -l, I see it is stuck in 'nfs_delete' in
js> the 'D' state. I think the function name is cut off by the limited=
field
js> size, from looking at the source I think it is nfs_delete_inode() i=
n
js> fs/nfs/inode.c. =20
Same happened to me when testing NFS throughput with bonnie after the
message ""NFS: invalidating pending RPC requests" and "NFS: inode had
failed requests".=20
[deleted]
------------------------------
From: Erik Andersen <andersen@inconnect.com>
Date: Tue, 28 Oct 1997 09:19:19 -0700 (MST)
Subject: Re: CD Filesystem still broken!
Hmm. I will look into this this evening. I have been doing a lot of w=
ork
on the 2.1.x CD-ROM stuff in my private development tree, but I havn't
noticed this particular problem. That doesn't mean that the problem
doesn't exist though... I will look into this this evening with 2.1.60
and see what I can see.
=20
-Erik
- --
Erik B. Andersen Web: http://www.inconnect.com/~andersen/=20
email: andersee@debian.org
- --This message was written using 73% post-consumer electrons--
On Tue, 28 Oct 1997, Steven N. Hirsch wrote:
> All,
>=20
> Even after fixing isofs in 2.1.60, ISO filesystem handling is still
> broken. I've been reporting this until blue in the face, but have
> received absolutely zero response. =20
>=20
> For about the third time: Can ANYONE confirm or deny that there are
> problems with isofs/cdrom in recent 2.1.x kernels?
>=20
> The symptoms are simple: About 2/3 of the directory entries are simp=
ly
> missing. What is there seems to be correct.
>=20
> Thanks for any feedback whatsoever.
>=20
> Steve
>=20
>=20
>=20
------------------------------
From: Matthew Kirkwood <matthew.kirkwood@lmh.ox.ac.uk>
Date: Tue, 28 Oct 1997 16:28:00 +0000 (GMT)
Subject: Re: 2.1.60 NFS probs...
On Tue, 28 Oct 1997, Jonathan Stanton wrote:
> > "ps l" claims that every process but itself is in "end" which I fin=
d
> > vaguely confusing.
>
> I think that is because the 'correct' System.map file is not in /boot=
(on
> Redhat 4.2). When I had a 2.0.30 System.map file there I got 'end' fo=
r all
> processes, but when I copied the current 2.1.60 System.map I got corr=
ect
> looking functions.
Good guess! :)
It's stuck in "nfs_delete_" SOMETHING, where SOMETHING =3D ?
Matthew.
- --
Matthew Kirkwood | Mail: matthew.kirkwood@lmh.ox.ac.uk
LMH JCR, | Web: http://www-jcr.lmh.ox.ac.uk/~weejock/
Oxford OX2 6QA, | PGP: finger weejock@ferret.lmh.ox.ac.uk
England. | =20
------------------------------
From: Bill Hawes <whawes@star.net>
Date: Tue, 28 Oct 1997 11:47:45 -0500
Subject: Re: 2.1.60 NFS probs (updated patch attached)
This is a multi-part message in MIME format.
- --------------02552BE3E8FD2A56BBCC3D17
Content-Type: text/plain; charset=3Dus-ascii
Content-Transfer-Encoding: 7bit
Matthew Kirkwood wrote:
> Once this has happened, that process hangs, and any logins on other
> consoles fail also. Stopping and starting the NFS server fixes this
> and ps shows a
Using make menuconfig I replicated your report, and have problem fixed
now -- it was just a mistake on my part. I meant to do an interruptibl=
e
wait while the pending requests are taken care of ...
The good news in this is that the pending requests are now being
detected and handled, rather than causing file corruption or memory
leaks. With make menuconfig I've also managed to trigger the "inode ha=
s
failed requests" message, which again means that a former memory leak i=
s
being handled.
The failed requests could also potentially trigger a spurious error
message. If a later operation by the same process happened to use the
old inode, the failed request could have been reported as an error
against the current operation, leading to mystery failures.
Please carry on with the testing and let me know of any other anomalies
...
Regards,
Bill
- --------------02552BE3E8FD2A56BBCC3D17
Content-Type: text/plain; charset=3Dus-ascii; name=3D"nfs_client60-patc=
h"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename=3D"nfs_client60-patch"
- --- linux-2.1.60/fs/nfs/dir.c.old Sat Oct 25 07:43:18 1997
+++ linux-2.1.60/fs/nfs/dir.c Mon Oct 27 15:42:49 1997
@@ -333,7 +333,6 @@
{
struct nfs_dirent *cache =3D dircache;
int i;
- - int freed =3D 0;
=20
for (i =3D NFS_MAX_DIRCACHE; i--; cache++) {
if (sb && sb->s_dev !=3D cache->dev)
@@ -347,14 +346,8 @@
if (cache->entry) {
free_page((unsigned long) cache->entry);
cache->entry =3D NULL;
- - freed++;
}
}
- -#ifdef NFS_PARANOIA
- -if (freed)
- -printk("nfs_invalidate_dircache_sb: freed %d pages from %s\n",=20
- -freed, kdevname(sb->s_dev));
- -#endif
}
=20
/*
@@ -472,9 +465,9 @@
struct inode *inode;
int error =3D -EACCES;
=20
+ nfs_invalidate_dircache(dir);
inode =3D nfs_fhget(dir->i_sb, fhandle, fattr);
if (inode) {
- - nfs_invalidate_dircache(dir);
d_instantiate(dentry, inode);
nfs_renew_times(dentry);
error =3D 0;
@@ -638,14 +631,15 @@
{
struct qstr sqstr;
struct dentry *sdentry;
+ unsigned long hash;
int i, error;
=20
sqstr.name =3D silly;
sqstr.len =3D slen;
- - sqstr.hash =3D init_name_hash();
+ hash =3D init_name_hash();
for (i=3D 0; i < slen; i++)
- - sqstr.hash =3D partial_name_hash(silly[i], sqstr.hash);
- - sqstr.hash =3D end_name_hash(sqstr.hash);
+ hash =3D partial_name_hash(silly[i], hash);
+ sqstr.hash =3D end_name_hash(hash);
sdentry =3D d_lookup(parent, &sqstr);
if (!sdentry) {
sdentry =3D d_alloc(parent, &sqstr);
@@ -674,6 +668,11 @@
return -EIO; /* No need to silly rename. */
}
=20
+#ifdef NFS_PARANOIA
+if (!dentry->d_inode)
+printk("NFS: silly-renaming %s/%s, negative dentry??\n",
+dentry->d_parent->d_name.name, dentry->d_name.name);
+#endif
if (dentry->d_flags & DCACHE_NFSFS_RENAMED) {
return -EBUSY; /* don't allow to unlink silly inode -- nope,
* think a bit: silly DENTRY, NOT inode --
@@ -729,20 +728,28 @@
error =3D nfs_proc_remove(NFS_SERVER(dir),
NFS_FH(dir), dentry->d_name.name);
if (error < 0)
- - printk("NFS " __FUNCTION__ " failed (err =3D %d)\n",
- - -error);
+ printk("NFS: can't silly-delete %s/%s, error=3D%d\n",
+ dentry->d_parent->d_name.name,
+ dentry->d_name.name, error);
if (dentry->d_inode) {
if (dentry->d_inode->i_nlink)
dentry->d_inode->i_nlink --;
- - } else
+ } else {
+#ifdef NFS_PARANOIA
printk("nfs_silly_delete: negative dentry %s/%s\n",
dentry->d_parent->d_name.name,
dentry->d_name.name);
+#endif
+ }
nfs_invalidate_dircache(dir);
- - /*
- - * The dentry is unhashed, but we want to make it negative.
- - */
- - d_delete(dentry);
+ }
+ /*
+ * Check whether to expire the dentry ...
+ */
+ else {
+ unsigned long age =3D jiffies - dentry->d_time;
+ if (age > 10*HZ)
+ d_drop(dentry);
}
}
=20
@@ -769,12 +776,22 @@
return -ENOENT;
}
=20
+ error =3D -ENAMETOOLONG;
if (dentry->d_name.len > NFS_MAXNAMLEN)
- - return -ENAMETOOLONG;
+ goto out;
=20
error =3D nfs_sillyrename(dir, dentry);
=20
if (error && error !=3D -EBUSY) {
+#ifdef NFS_PARANOIA
+if (dentry->d_count > 1)
+printk("nfs_unlink: dentry %s/%s, d_count=3D%d\n",
+dentry->d_parent->d_name.name, dentry->d_name.name, dentry->d_count);
+if (dentry->d_inode && dentry->d_inode->i_count > 1)
+printk("nfs_unlink: dentry %s/%s, inode i_count=3D%d\n",
+dentry->d_parent->d_name.name, dentry->d_name.name, dentry->d_inode->i=
_count);
+#endif
+ /* N.B. should check for d_count > 1 and fail */
error =3D nfs_proc_remove(NFS_SERVER(dir),
NFS_FH(dir), dentry->d_name.name);
if (!error) {
@@ -785,11 +802,12 @@
d_delete(dentry);
}
}
- -
+out:
return error;
}
=20
- -static int nfs_symlink(struct inode *dir, struct dentry *dentry, con=
st char *symname)
+static int
+nfs_symlink(struct inode *dir, struct dentry *dentry, const char *symn=
ame)
{
struct nfs_sattr sattr;
int error;
@@ -802,11 +820,12 @@
return -ENOENT;
}
=20
+ error =3D -ENAMETOOLONG;
if (dentry->d_name.len > NFS_MAXNAMLEN)
- - return -ENAMETOOLONG;
+ goto out;
=20
if (strlen(symname) > NFS_MAXPATHLEN)
- - return -ENAMETOOLONG;
+ goto out;
=20
sattr.mode =3D S_IFLNK | S_IRWXUGO; /* SunOS 4.1.2 crashes without th=
is! */
sattr.uid =3D sattr.gid =3D sattr.size =3D (unsigned) -1;
@@ -827,10 +846,12 @@
*/
d_drop(dentry);
}
+out:
return error;
}
=20
- -static int nfs_link(struct inode *inode, struct inode *dir, struct d=
entry *dentry)
+static int=20
+nfs_link(struct inode *inode, struct inode *dir, struct dentry *dentry=
)
{
int error;
=20
@@ -843,18 +864,37 @@
return -ENOENT;
}
=20
+ error =3D -ENAMETOOLONG;
if (dentry->d_name.len > NFS_MAXNAMLEN)
- - return -ENAMETOOLONG;
+ goto out;
+
+ /*
+ * The NFS server may want to use a new fileid for the link,
+ * so we can't reuse the existing inode for the new dentry.
+ * To force a new lookup after the link operation, we can just
+ * drop the new dentry, as long as it's not busy. (See above.)
+ */
+ error =3D -EBUSY;
+ if (dentry->d_count > 1) {
+#ifdef NFS_PARANOIA
+printk("nfs_link: dentry %s/%s busy, count=3D%d\n",
+dentry->d_parent->d_name.name, dentry->d_name.name, dentry->d_count);
+#endif
+ goto out;
+ }
+ d_drop(dentry);
=20
error =3D nfs_proc_link(NFS_SERVER(inode), NFS_FH(inode), NFS_FH(dir)=
,
dentry->d_name.name);
if (!error) {
nfs_invalidate_dircache(dir);
+#if 0
inode->i_count ++;
inode->i_nlink ++; /* no need to wait for nfs_refresh_inode() */
d_instantiate(dentry, inode);
- - error =3D 0;
+#endif
}
+out:
return error;
}
=20
@@ -875,16 +915,31 @@
* implementation that only depends on the dcache stuff instead of
* using the inode layer
*
+ * Unfortunately, things are a little more complicated than indicated
+ * above. The NFS server may decide to use a new fileid for the rename=
d
+ * file, so we can't link the new name to the old inode. Otherwise, th=
e
+ * server might reuse the fileid after the old file has been removed,=20
+ * which would leave the new dentry holding an invalid fileid (possibl=
y
+ * leading to file corruption). To handle this consider these cases:
+ * (1) within-directory:
+ * -- no problem, just use nfs_proc_rename
+ * (2) cross-directory, only one user for old and new dentry:
+ * -- drop both dentries to force new lookups, then use rename
+ * (3) cross-directory, multiple users for old, one user for new:
+ * -- drop new dentry, silly-rename old dentry and make a link
+ * (4) cross-directory, multiple users for new dentry:
+ * -- sorry, we're busy.
*/
static int nfs_rename(struct inode *old_dir, struct dentry *old_dentry=
,
struct inode *new_dir, struct dentry *new_dentry)
{
- - int error;
- -
- - dfprintk(VFS, "NFS: rename(%x/%ld, %s -> %x/%ld, %s)\n",
- - old_dir->i_dev, old_dir->i_ino, old_dentry->d_name.name,
- - new_dir->i_dev, new_dir->i_ino, new_dentry->d_name.name);
+ int update =3D 1, error;
=20
+#ifdef NFS_DEBUG_VERBOSE
+printk("nfs_rename: old %s/%s, count=3D%d, new %s/%s, count=3D%d\n",
+old_dentry->d_parent->d_name.name,old_dentry->d_name.name,old_dentry->=
d_count,
+new_dentry->d_parent->d_name.name,new_dentry->d_name.name,new_dentry->=
d_count);
+#endif
if (!old_dir || !S_ISDIR(old_dir->i_mode)) {
printk("nfs_rename: old inode is NULL or not a directory\n");
return -ENOENT;
@@ -895,37 +950,66 @@
return -ENOENT;
}
=20
- - if (old_dentry->d_name.len > NFS_MAXNAMLEN || new_dentry->d_name.le=
n > NFS_MAXNAMLEN)
- - return -ENAMETOOLONG;
- -
- - if (new_dir !=3D old_dir) {
- - error =3D nfs_sillyrename(old_dir, old_dentry);
- -
- - if (error =3D=3D -EBUSY) {
- - return -EBUSY;
- - } else if (error =3D=3D 0) { /* did silly rename stuff */
- - error =3D nfs_link(old_dentry->d_inode,
- - new_dir, new_dentry);
- - =09
- - return error;
- - }
- - /* no need for silly rename, proceed as usual */
+ error =3D -ENAMETOOLONG;
+ if (old_dentry->d_name.len > NFS_MAXNAMLEN ||
+ new_dentry->d_name.len > NFS_MAXNAMLEN)
+ goto out;
+ /*
+ * Examine the cases as noted above.
+ */
+ if (new_dir =3D=3D old_dir)
+ goto simple_case;
+ error =3D -EBUSY;
+ if (new_dentry->d_count > 1) {
+#ifdef NFS_PARANOIA
+printk("nfs_rename: new dentry %s/%s busy, count=3D%d\n",
+new_dentry->d_parent->d_name.name, new_dentry->d_name.name,
+new_dentry->d_count);
+#endif
+ goto out;
}
+ d_drop(new_dentry);
+ if (old_dentry->d_count > 1)
+ goto complex_case;
+ d_drop(old_dentry);
+ update =3D 0;
+=09
+ /* no need for silly rename, proceed as usual */
+simple_case:
error =3D nfs_proc_rename(NFS_SERVER(old_dir),
NFS_FH(old_dir), old_dentry->d_name.name,
NFS_FH(new_dir), new_dentry->d_name.name);
- - if (!error) {
- - nfs_invalidate_dircache(old_dir);
- - nfs_invalidate_dircache(new_dir);
- - /*
- - * We know these paths are still valid ...
- - */
- - nfs_renew_times(old_dentry);
- - nfs_renew_times(new_dentry->d_parent);
+ if (error)
+ goto out;
+ nfs_invalidate_dircache(new_dir);
+ nfs_invalidate_dircache(old_dir);
=20
- - /* Update the dcache */
+ /* Update the dcache if needed */
+ if (update)
d_move(old_dentry, new_dentry);
- - }
+ goto out;
+
+ /*
+ * We don't need to update the dcache in this case ... the
+ * new dentry has been dropped, and the old one silly-renamed.
+ */
+complex_case:
+ error =3D nfs_sillyrename(old_dir, old_dentry);
+ if (error)
+ goto out;
+ nfs_invalidate_dircache(old_dir);
+
+ error =3D nfs_link(old_dentry->d_inode, new_dir, new_dentry);
+ if (error)
+ goto out;
+ nfs_invalidate_dircache(new_dir);
+#ifdef NFS_PARANOIA
+printk("nfs_rename: dentry %s/%s linked to %s/%s, old count=3D%d\n",
+new_dentry->d_parent->d_name.name,new_dentry->d_name.name,
+old_dentry->d_parent->d_name.name,old_dentry->d_name.name,old_dentry->=
d_count);
+#endif
+
+out:
return error;
}
=20
- --- linux-2.1.60/fs/nfs/inode.c.old Sat Oct 25 07:43:18 1997
+++ linux-2.1.60/fs/nfs/inode.c Tue Oct 28 12:12:24 1997
@@ -91,16 +91,19 @@
static void
nfs_delete_inode(struct inode * inode)
{
+ int failed;
+
dprintk("NFS: delete_inode(%x/%ld)\n", inode->i_dev, inode->i_ino);
/*
* Flush out any pending write requests ...
*/
if (NFS_WRITEBACK(inode) !=3D NULL) {
unsigned long timeout =3D jiffies + 5*HZ;
- - printk("NFS: invalidating pending RPC requests\n");
+ printk("NFS: inode %ld, invalidating pending RPC requests\n",
+ inode->i_ino);
nfs_invalidate_pages(inode);
while (NFS_WRITEBACK(inode) !=3D NULL && jiffies < timeout) {
- - current->state =3D TASK_UNINTERRUPTIBLE;
+ current->state =3D TASK_INTERRUPTIBLE;
current->timeout =3D jiffies + HZ/10;
schedule();
}
@@ -109,8 +112,10 @@
printk("NFS: Arghhh, stuck RPC requests!\n");
}
=20
- - if (check_failed_request(inode))
- - printk("NFS: inode had failed requests\n");
+ failed =3D check_failed_request(inode);
+ if (failed)
+ printk("NFS: inode %ld had %d failed requests\n",
+ inode->i_ino, failed);
clear_inode(inode);
}
=20
- --- linux-2.1.60/fs/nfs/write.c.old Sat Oct 25 07:43:18 1997
+++ linux-2.1.60/fs/nfs/write.c Tue Oct 28 11:49:19 1997
@@ -652,10 +652,20 @@
=20
if (rqoffset < end && offset < rqend
&& (pid =3D=3D 0 || req->wb_pid =3D=3D pid)) {
- - if (!WB_HAVELOCK(req))
+ if (!WB_HAVELOCK(req)) {
+#ifdef NFS_PARANOIA
+printk("nfs_flush: flushing inode=3D%ld, %d @ %lu\n",
+req->wb_inode->i_ino, req->wb_bytes, rqoffset);
+#endif
nfs_flush_request(req);
+ }
last =3D req;
}
+ } else {
+#ifdef NFS_PARANOIA
+printk("nfs_flush_pages: in progress inode=3D%ld, %d @ %lu\n",
+req->wb_inode->i_ino, req->wb_bytes, rqoffset);
+#endif
}
if (invalidate)
req->wb_flags |=3D NFS_WRITE_INVALIDATE;
@@ -676,6 +686,7 @@
=20
req =3D head =3D NFS_WRITEBACK(inode);
while (req !=3D NULL) {
+ /* N.B. check for task in progress? */
if (req->wb_pid =3D=3D pid) {
req->wb_flags |=3D NFS_WRITE_CANCELLED;
rpc_exit(&req->wb_task, 0);
- --------------02552BE3E8FD2A56BBCC3D17--
------------------------------
From: "Eloy A. Paris" <eparis@ven.ra.rockwell.com>
Date: 28 Oct 1997 17:08:02 GMT
Subject: Re: Patch: Linux on Alphas and IPX protocol
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
: > I also needed to modify ipxripd-0.7 to work on 64 bit machines (sam=
e
: > problem: unsigned long
: > instead of __u32). Patch included.
:
: Kernel no problem. I've no idea who if anyone maintains ipxripd howev=
er
I think it is Volker Lendeke. I don't have his e-mail address handy
but I think he is maintaining it.
E.-
- --=20
Eloy A. Paris
Information Technology Department
Rockwell Automation de Venezuela
Telephone: +58-2-9432311 Fax: +58-2-9431645
------------------------------
From: Bill Hawes <whawes@star.net>
Date: Tue, 28 Oct 1997 12:19:43 -0500
Subject: updated smbfs for 2.1.60
This is a multi-part message in MIME format.
- --------------4203D593236E89B935170AB9
Content-Type: text/plain; charset=3Dus-ascii
Content-Transfer-Encoding: 7bit
I've attached the latest smbfs snapshot against 2.1.60. The changes ar=
e
mostly for performance improvements, but with modifications to make Win
95 directory listings work again (hopefully!)
The Win 95 problem was resolved by falling back to info level 1 request=
s
if the CONFIG_SMB_WIN95 option is specified. This is not ideal; if you=
r
environment includes both Win 95 and Win NT, you'll have to decide whic=
h
one you want to work :-( (Or just get rid of Win 95 ...) Eventually I
plan to use a run-time test for the type of server.
Regards,
Bill
- --------------4203D593236E89B935170AB9
Content-Type: application/x-gzip; name=3D"smbfs_60-patch.gz"
Content-Transfer-Encoding: base64
Content-Disposition: inline; filename=3D"smbfs_60-patch.gz"
H4sICPUnVjQAA3NtYmZzXzYwLXBhdGNoANQ8a3Pbtpaf5V+B5k6zkknKoiQ7ftS+dWwl1TS=
x
O7bTdHv3DoeWKJtriVRJym42zf72PQ8ABClSkpPZ2buZiUURwAFwcN7nQI7jiGkYLf50um2=
3
vdfZCaPRdDEOdujlTjq79SZp+74dT8eNaz8Tl6NMdHdFZ/+ws3vY3xPuwcGrLcuyNgHSuF5=
E
DGBPdHuHbv9w94AB/PijcPZ27W5HWPDh7osff9wSW+JvQTQOJ2JnW5wPXn94612/f+29P33=
3
7vJMbO9AByfNkgXAwwnSWy+MJvHRlgXded5JilPD39nMn7dHOMYKI+6Or5py+CScBmLbFvL=
r
48zzk8D35Nft1hGuZRkqDmOoIvgzC5JIAQijeBx48TxI/CyMo5QmxN5euaUG8jhMNgcMnSv=
g
Oo9xOKb2MAozL4njrLmMLdqcgzjht5m/uqvQUJMgCp68LJwFqeo8DqIs+VSPrzAeZVPel6O=
O
gd6Jprk/sc2f+jz4ePBjbm85ovhvEaXhXRSMBUIczcZ2/mYaR3fCT+5gPdbK+Uoz2QWgJYC=
1
m0NQ8tAU8hZwHt7tNB49iG3GmT/26G2zqovN2IVPmBbmQaZwu3v2nrDcbt9+RUyxfKxIAID=
5
yiNLg+QxSPT+iA79LEvqDymFpZRYJYkX0dibBtFddt/kpQnV9uhPQ9gTDAqyElYL5DKaxml=
Q
6rdEXHrCYBr4abBiRwo7fdc+AOz0O4AkxE6jIckCQW1Pk7Gf+cYBju592Po2v17uPfcTf1b=
R
nd4TwpxVssWply30UStg4IWPfEjnoQGP/NG9oihsoR13O3tACFa3062kByAFGqZmpy/ePdB=
d
6TwmSRCs7a3lQhLA+qcr++vNGVIgl0H+eOxlsbfBaKJlfBFPJh6SmvV8IPxyGVS+oUkIFB1=
G
q2DRoBqQBVSGETMByuECPIMPtpxN1CxQudK0UlG6XeGConwFyvYZmpbglLR11z3sdXJl6/a=
Q
jODvnlK1EpD4gSFln+YBqOyT5RaYA987Fe+9GYiKjEYRLb8NMpHdB4KZVkzihL/Og1E4CYH=
D
FLEAif9tDEQWqb5AoPHM4+Ymf7TES35wTkDi3DonizYxCjwza/SJM3qSMdS/IFrMWATFUUQ=
a
DubAv3AsjSKTongiPU0npgAYUoi256H0EDOgzNU9tmdRRkK2AZg4g8mDEStt4H0xwn7BuC0=
G
QDEC1ajwBWhUwSIS+iThY5CikIKF3YGyZc0uwhToapQEs4DGLxNWWSM9k57Kw1eT0Z7t9sF=
k
s90O43wb/5Nlpo4TTLY319752enZTwNv8NuNcFHOlWkHzmYS3lWS2yweL8DOYppaojlgt3E=
t
NU7SuqYorpzrAWytYFq9jFk1M2RJGNHCiQR7pKwPQCkhOpZg+FPQ9JVwUHpXNoxZDUCTVb/=
F
qibeYuUgk0vzdj+d7aSf0iwo7xQbFv5oFKSp2mivY7vIbAe26/JWC8f9y+nV6cXl8BQOG8V=
A
iRbIlP91cPX68nogXEUv4SSCbkv0klNSeg+ofvAYIcD0zfS2VXzZbEFvchm2HGk4b2ivqu5=
k
RJKpMilpcLQ+SUdbKDzCkQnZH7MBXiH4y53ni2zjvmMwg7Kgrrvzzeuot0QN8Mqmwa+TtMZ=
u
VW+pT27AWgaMrwYi9OILw0pOUBrPU3G8JT5Lu/AVMSLYhZI+G1JL+wqhafP6tRdPmtKexIm=
+
wFzgPIJc3xY39yhoU9D70ynoqaf7IBJPgXjyYStZDJZhAIuGt6DOWKcRUBp676doOUZ3MA4=
E
dq7/2kIMJyLMzB42Qp0t0oyG5osU8SIBfwOmZ9MjbWOHHTJhtuRxFzdUOnT6aGmE7L2yQYB=
b
LjrZPcbIF6mbthxUMdf+Y0BrnfppJkDosoJGhrHxfSTACEyC9N7c7VcObPPI5kWcBYeg99L=
w
vwKJEGDoeDEdA4oeUSMCsElANtcMAbZbpA8BDQ2cjdhZHDNQ5yT0qBPq9SBJwNY4VsYrTi+=
x
xHgB+m6EE9H8jjq2YD34jUf99VcJoPjuWOjpcAWfYTQNWNkP+nxGMToxxJop+rbEHGRX9tB=
8
UTzOQ/F9uvO9QSGgwI+/n8IDSDB8+I/oBdgFzSUxJlejzKKwLe0mtJfAhYEv+BT5gEf882w=
Y
hZHkC+fbtdWbIkqQrZREbjDOvrv2htfnwysDeXgihK/GEpvCwu+AV/NTazSCaRpw52rr2+j=
7
BQ529aTW+jktOaW1dkbiqXiRHcJTEmQLUChEUuysdnd7aCdZ3T5oza50V5H/8APY4SKGA0b=
O
icVTnMBp+LcAC7xREBf3YGQQ//BxHOKzGjeN44fFXMg9oI34BM4ayBxkSz/L2Q7l2a2PNiM=
P
fA3QUfr4n/TEhgDCYSx6RLvdpt3nY8axFoX1Q3h9O3zy6891NW6tdeRjbUA+VsM4y7WH2dB=
i
xBkML+nNFzpjsoC6+6hiet096W/Q6ljQOyfka8zDMckr/veAHvQ8iUdLnWxxPXx7M7h6b4s=
O
KTyr8YD+ue44Y0VYmGHuo5+A8Gkfj4UBspE8HHCUUjAlHmEbHSbEHqhFMN56vQO59Cp9vJX=
b
FPV2QnqrYlaJ/+RxsIUMBjCZooy0j9Oo8Y7o77Fo1jS3FEQ8tXoHy14PSOSQhAmJA2EYQcO=
G
B0CRh4IQEaWRZgyRepUibvQskbm3b7tICKxhiRKKzmlbnTOfwFIzu6TH4uzy4sIbXvx6+m5=
4
foRmcwR2hnYbxSfwCknzlYYbviHBd8odmBg8UrLHqIhgkuHN8PQdmOlnPw9uvOvh74OjRt1=
A
qUUf2Xlp1oxvAQBr9cxLocTngyqtpX46zS7fVfYhtrmLQXqBhPWi2JsFM/L5y9POYMZtpp3=
l
tjaF9FH8EPnVt75kdcVyoAkC7Orjbx/EX4Kf3uqny1aLn99cDd5WzohiqnZC3WjOt9F0IE+=
R
zYCfAPCDwi7gEQ3kKrZq2eLtm1+8nwdXF4N3JFgJ2SioULYWUIuDsMc2g99WTD1DewTEVap=
I
F2l+/AkMDLD1J1P/LqUotDSggDveDDkD9HF4cbBbBvDXsXABqjQ2ZKNxBMerMXG0PAQg6qO=
Q
jRrDm8PLh0h4Etfl0yPcUMTIYqucAj8/B8GcPQgUu4LFLv4hnwQdU1DGdzLKhqJJGdhsJpO=
A
OtinvFq/s4efKKDkyWB/NFWkGYqH6Q2ursSLouQ/pAly4GLiw8RohTKXgSvZzKUi7Vyqr6U=
t
YqNJFji7ob0qWRXn0PS0iHDzR1sG3xo7WFr4iHyJCFZOJC0YJK/cWYZq5V8OYRf8pNTfLe1=
M
j0EkyHU8JWD5ElscAtS12KTugpSTn9wtMJDXfoFOGP97Ia6CUTyb4+HCUI7V8JKt2o2S/UZ=
d
hWKI78lPIHn//vLDxQ26HdfDy4siQo1tADp5D/X4nIVpGpYXv4ROhumYyHQqkKn7Hi6bKaL=
x
/vIc3KUz78P1wDvD9bO67YPRAtq2Dw4+2y6fi0q9lCeSCu96cAW7N0y7ktsjP7UnWXZ/jog=
a
jETjzE8fBIsAFBC5GNUioE4sYCQiY7fA1p4x79nwW9ngpA3vHlCMtY92hvTcNarLg34BI1K=
5
ts0m2jdgIPucpBMvxenNzZX3YXjeEi9firx5AY3gumprsw0vWi3lFH81GJR+BKm84tXre7t=
+
fXcbrG89GFzf3fPXB4Q5QMjQLe/BOkb897MJYu0+1HRieTIkwuXVi1XQyL5CLHRaKzIHVH6=
w
VPHx6rDfO+x21uUNaLBZ6dHZP9zdPQQa1lkDVkj7SNfVyScd1l9qAVrnwPZyVB/M6DVB/aU=
x
eUB+uakm3q9j7lVNNUvLF222lcLqpZY0mPnz+zjRmY9vC7AbneYJyNnbxZ0MP7GRVQDw/vQ=
3
7/TtQOxu//S7GX9Fi9DLdNEJaoZyCQ2nzG3BXW2wVTCNWohB51l+fwxgyhBUDQRmnHEWVQl=
x
0Ef5Z+1rMQjm0XCCMUIW3v4UAX4SwZ9hmqUUV6UgInDGXfhoBCcE9afx9C5OkkD7d9Fidku=
R
WhUARs0KQh9Tl2AGjZ7GzVabk1wqQl4oDymkB7bMXHNcjrXxZ02GmaNuBfWmxmEY0FN6Sbf=
+
AZ/iD4zOHZG2NWtgYHKlYixMRl60X7fFe/8hKE6KgwGfCOk7djX/0CE/GC9zrzyFagNXTuR=
t
8C1vwrAVNOGHF2bNHJYt9FhVx9GhkJjldno6YP+ZQhsVdUEAM8cAxiWlNy6MmGxLBp1iMzo=
M
DzIExCOrmgHIGA3afAYZ15PxYuhEsHmsjCBBPxydNl0yhGToT07HYWY9I/lHhQVUAaFchMk=
w
shhol8pd3H2VcG0UiIdLF+h5riwNsC8WU6nWFOfnhh2c/CEVVoHj483jFJYj7UYq9DGbaGs=
1
EOCPxCACwFD1KP9C4WpAmdFLtqNJuyI+bpXNUJoLH9AGpSA5iAlc2zEvesvKiaIq4C3yZuN=
l
1U6VH5l7YsQu6SLhzIyOpy7mThY7GHA0fS63x/mnnquCgwqMqohgSTSPYW6wUjlaSpK4wQd=
m
BB35PCWhgAzKy3AMAiUq454li0Dlw1wqlOoqH5D5S09WVeXD4BTWWprDeBCzGM2zmHs+yDi=
a
zmoY7j+6dTIsbu6Mo2BPYTa6B0vFNKyL5yBXOfLTQHQO1fRSMTRZatniRRvI1bVFxzYorCV=
+
IBtn4yU2ilzgHqmJ3RUT48xdnJyixY0q6jPFy7cuqqtwSWf6qmd3XUzpHaiCWYrQnxVTkzH=
l
B2AqIw8glRwP2FHbKwgpSl45ZVlZUGdKfynqUPmWxspeog6bhnqxDX1iC8YtusYGNnSXHK3=
Y
7Rakw8MS5ix5nl9IOBtEaDDmFdcccpJFcoBiSic/qEMOEuABqeBFsZRO8uBRORGk5DBlgro=
U
gO+6PZsPbofqZrTNwQJiOr31+SQ5icw1DpQ89lXS5z7MStaIsq64g6fSIWXjQzG1maOH52c=
M
NE2Tsn6u0M2lqtw77Paf4WQSBqlwjAGcweViGheNAasLWk8ZBTAH2HW3wTQMHpGaeSDCQAN=
t
F5y7URyNU7DfmpipCgBjPCpdkKE9WUxVMZrEINWFMMqpOCTzZ3OdZnYa7D0d04J/gAm2xU+=
/
Y4Z4eO1dXV7e5CLY0l2b1Pe4aEu3KgetzA4TTxJQYEdTFZZOSOWLMcxF72xcrVSJoPa/Ric=
C
gFZR/2446XTBs36VJsZZ84SxcmWlQccp1ANOoe72lB5bzTxYRSjIoGsxI409qrzDjncxJVV=
j
0WlvOQDgYyAWJAAQSMxlQOSVAL9FY5mHzQkO1Nc9plOZ6Lk+owxjzRiCa8xTYuVyIZCshlz=
H
yeR5WJuPA0aWEYg6fmyJkxI1w4jPm9tuhXUoygn+nIPkB7rhOZB0bCCnp2+koeLKbSVjWmZ=
u
oDH2xkk8N5n3C4XdEQsl2aWMECbF1LvVRVbljpJE98lG7+7r0jhANVZ8AkkqTkljs5ZoMdf=
J
c3k2WhAxRUh/LX7MCYt1wd8lvWxS5JaTSU4fm3SnFC4K1+bRUYtIRX0hGhCm1SPLcSTKtb2=
o
oqumXuADLShtzqa6tkymKg8nz8J3jBT8xrQXRoDJKAtJZlGMQToOBPWbHAeuHTKdhWLRh1C=
m
Wu9Vh3a131G7+mzGgckv33Q/I0AWboU+DT8Ig4LftJuZTN7ozeRh5YvT94Oby8t3lxdvj5a=
4
RIcBTjjXcPobdn83uCj5IfXhRnnR4WsLleXwdfXuHQof0Wdf8aWSy1yRPQspViLiZAz2Acp=
m
4tvxmGtjMgodjaWQZjHrbHIvQShHqnTHQVrGHCGbkMNjfQ28isiRTYa4CXmVuYZOJQNhyZb=
b
sMX4Atj0wZ80Dj6XWmVNCCcpl00+rMTxYEWF8BTyQETmP7SkAQYMgyiPJ41BRI0oqGRtPEb=
G
oErdKYh3TD0tUcxs8+oN/2QFK3ItJddxuXv9XEjxUiicBLhxTtK5PwpgKi6Cki/B7/IUyW2=
v
XgVIRUKnBiixCk7WLJiN5p+aL+mNczK6pbQdcXH6D17HP21R4E9CEdc/PWu0OVYtKR+T+bf=
T
4B94FP+k8XwMEv+rOmtk8QPtakV39j1NbUs72XSEiusxVTsn8gQsa439bUpdkyUPpUhgrYa=
y
F7YMotcWFInC6JecQsnjFXc0+Eokib43SShOF3eiS6Kv0z/s9dbe0eDhq0UfBQsx2+LWZFt=
0
emKppf4CRV0ShFdUmR6pzelwquWZ1xtWXGIwkioyVHJgAy4t8Lp7nDpI1U3QqqLp0m1Qvna=
K
ZXybXDWV1rQOvHIcD4u6uLBDRb1geCG8RbVQl2fe28ENZes/DM8xa64sCizXB8ciaS5lszE=
f
OuPLRJjhJMGvp145DM2CwkiKszThkRI26uZsHlQpr/Vi8BFr1g5LwXp91yqeZwL+H3G83Ax=
F
S8MQZkCrkGM3BAKzEzcYGE1iPEIUEEGSyqtRRjHcYg5/rodvP1xfuarEVKIKp6dh2H1547I=
K
tBD4XN2dbE5HlXw39cjHIAknn+gmZxMGDN/8u3c1OD23RQGFNtdiAflIeQ8YabVUDlbVFgs=
V
bitFiwpLdQZvTj+8uzFqYUfx/BPflKNTfgmwYXrOoLVw8uKkXPZa2DrgtXrjtkBoevsgPp8=
1
1xFjzDiT9TMZpEZWPkhmH1Zq8oHmJfIBytgCg7te1CJJfb2RyaPX2JiuvY/Zmdo7lStuua2=
7
qvYcGVx/dbNe0ueZcL5lzBYOlbZW3WSbjKIaMZ/fV1tuIgv1f+0qW31qvXzJTd/ZE+XMt5F=
X
tzbJq1tr8uqFvL3368dfm7KqTYAkUY8WNf4EsmNw5bHjZI46e39ujNqWz9Z+q9Tv49lNVb8=
i
bOEIV0Yqej3KuVKqqnSFzzsfXg0v3lxSvYjo94qN1zenNx+uuU103eXbngYWnU2w6KzGovP=
s
23xG6nSKQOnSFLh3mOoTskb9Vl+O2t3DQnhrd++VLuU3XXPTEz49Oxtc68tDKUlCrs4ZLRL=
2
tJeqlQwdmxf71HYvaWUCriZqiVKxD2vRDDzXEVdjvFRw0mDWpkhnCzWsy7YG3djt0Gb3Onq=
z
tdVk/8eb/fa97mOxSBdrRvZ0BoEDSJykUjWJBKepf1lCajz8zze30xADAhgynGOIIArugLg=
e
Ax3X/TtRKfgSogNj1P2kpSDjxiEeuoCqoqX0bazCPLTPb4rz5C8ZZ3nAHaOgXHgA2x6y1ka=
9
R+imeIh+85SEWSAvAmEKABQxhjJug5HP8e+Aa3Z2OYVz0NcVCzJpVo14RGEVepzP1eFJLt+=
o
qtcseG/5koshQIXMH8lpM64PaMftaxC8ZVVeq3vGxbxngjAH8p7y0EjxRpC6G+F8ybMsDVV=
a
AP0Xcwox6TOh8mFCnC12Jb5AXfWIST5eD25KN45svp7x9NixyweDeAcOl7VcGN9FutjL630=
I
3JzS+JowVbRibnVtwdeLdJsq0yyVMPyxCNLMix8qdoA1AiBDT6Tl/cyBqpZHDjtRfosG8xE=
M
01p8yMz3CqnjLOeKdQAZLExMKhwc9MzLZs3iLdeqDXC0WG9d5sl1PoMHUnJIXoOWt1ZVMQI=
1
ytR+SRx/kdsh5iIhpSdejQlbnH24uhpc3Hg3w/cDXQHWk1G1TvdVfml7wwOePRLdfPMWrfI=
W
i0Urlkzpr9Qdy2fI+9uTNnVnd/f5+3sA2/lff4v7r+QW93vP3mIy+/+wRdfd5S26bvfZW1y=
g
Mfrwr79HZEByZLHwYk8HzIjRQSlFo5U/NeZ5Cxg0wTwnPPa6gm/7yQwE1wfPcRf8eLuYLJc=
q
rrIR1C/7EDYwNgAQxHFJ0R09S691qHqJFBAAM5XYhFRWRZurRp2XW7q22nHlwL7SJWvUJ8+=
8
upvWS+crOpnrWQ1OLk00tueWBcjrG89csqexeTsaaVTOlQh3+3uSOfrPZ46ijv6X5Q2U4sQ=
b
u6901R0YKYCVJt0nJu6WgbBtetOSqn/CNzImHkkBLjF08rcLqh0q3MEptN+V2u+w3aodL72=
t
Qpe75S4ExVjb7fRB3tbddbulMuRCRXuY3n/d7w4yTmRZgZpWXmnNd6dvYRY2UO5WuK+pXET=
Z
m2Z7Kfzz4ZX+yY76+dQtTQpCrpwv7ymMngWk5SWa7kHf7mNdu3vg2n1JLhUYlNhi3Ei0O/q=
3
aPBnUvinHMDhwpR0FD8JJlD1sxBcuo+B8iSgH0wZ0cUHn2s9sAIlwp8STXyBYVybnDn94xC=
L
+TxIdqbxEzi5I58u+IUpeHYUOBHzqT8K1K/PSFIAwb4vtjn7PQ5G+EMLGxADj6rJg7dUydK=
z
oXHN6bpLFKhgODVJdyDkb9e8fw37DNLo3zL1izOjGHCHiYtJoVhW/QgG12gXimI7nNmZY5l=
p
KTx2hAEEkCG45DH+doOfjO7pV5AWaYvzFpw0heXDQxNgiAOS00YCFvM4+B5fF3obff6nvCN=
t
auPIfoZf0U6VA2IkrItLBHtJTLJUMLgMKX/wulQCRqC1rtIMxi7H/337XX1Nz0ik8mFrN5X=
C
kqaved3v9buf8QEnR4xW21BP6iHnsiESVWAexgnE0tvwFBVX707f9H8+Oz7//XLdusteLUY=
T
pc/TaAzH5Xo8mH4iH8y3g/z+cbbQ32ijsnVxpaR4ZV5hG1Q93iI+6AeN1kdQ4WyoDRDQSjv=
E
mtOrNhqHNgXYWmF83Vxt/Ku5ceg+JBcDsVw7D2R7OReDexw0ZulXB4uzdyCK85hHrnHcsQM=
K
bZnN820wrvXvNWoCTAvWwV+OL0/6f7x9e/IODSL6DPQRcf2tJDNK4aE5I9bC4g98dvHeGRh=
p
QdnA3sPIwMZsozx7Thg84mF6T/FJf56h758/elLdVczv0PqIB0DP8XCNYkzVh70ttxvH1aB=
D
dotT9CCZRvaUUPVDgNYfyffFTUqG4VccFfxN/bC1vaUX0dHcgPoei70xajW4TrL72UK/xvN=
b
9Q+JvuEcd/pWqZP/zhPUh9GxSeHlhcpArESZXoueOb8Mg7iYahadPK5amkWCnGOddseGeq6=
R
/+CIMGukOT3U6OiPSVKzdlD/igC3xz66/GyJ3u9H+e2wlP5X9yLXHBESgntHWFsvuoFyhJH=
K
V780IPRRjJA1iSptb9SMpbaqV9gHlvWNs2FxV49OoYo7CR7bJ2jFX9PXWD6aPqSHkYFwwpZ=
M
SKHMHGERmaxdnKwwgPJX0S6uwireC+B4ecQuanRqOl0KBYT0RCbgnQNRpA+nZ1oreMuJZ1x=
q
g07CPo77T2NNQla+K5MW6lulV1CDzPVl+NZT2aeRJrzg5JsyWRrh36GDe966dAODXlYTL9B=
y
W6LHkpuDqtXZaTOK7TjR1OwQfwqhZfMFJJMl/xRglZHMErJALNtDJhykzcmLbNY4/ZyOe+g=
X
r+iLaqlGQ73XHOH5VR3/PdCi88Xli7bXqg2t8NfE66tKeyu3984BtPsVLn7iaTWjSuKrmk3=
H
X+vBEP7Uu83iJBwboHli2JEJcMXXeIuni9kD5tIF+06Wa5Z5xB75mkrDAzWazMeYZxezK20=
X
eXG+TwKm2/DjZGc2fDiy3mB4ZgdSvkBIDbLuUqEx5hNZzgKzMqUeoZjiXEpsr4ZObQmb7DV=
1
VDVGAvY9KpGRoTO4u08yTmevU+8E4Y5PZbCFVyzwYBGm22WjZN2WZaKwPeK6tpwgQ3qrGjE=
B
u0TYS1lBgNe0hF1u7xl+ea2S03QCfp3B7Y8Oj9/eCx/4Y7nmBmy/r/8Yh8vATUvjUg9YV2B=
e
fj09f63/nJ30wTn7sg/GfYDil1azw/5TmAh0zQTSGCLApzxT/37ISF4cRrCzzp01z673Qw8=
A
4Q4aRTAxzWJ0d5+D1LpNrV4UXuQ1WAzmon8CqUl+6dYkJeh1iuoYPe2n9OsrdamxOWN0bur=
D
w8MSiKX3vo1aZTFiZ4cuJ2qnvy7b51bb8Z4tbhlJVpzGETI2jR9u7yDaIwW+i2iR6m43wWk=
U
5HMjM00fNISuv+YIRe6MrFAGKWJHU0tHGMKaLuVM1ASntpX6J5Ad7q7hnad6k4DDCmeCrdL=
k
hRKHU75WIqucqZFPgUCqSjrTR7EmiTX9ttGWDG0UzaoxpRQTq3Aiil2VV7gfmhRS3B6dfQg=
1
i0kW6w1XtLCy0aqDKn11PJ/Hh07mccHFmGotjnP1C7ZG8AdSL/1fSZYEh90mlQHZNQE20Uh=
o
TjFMgdBC3zDXB7AHA/1agwWTFBphALwA4KLF441MCSDpCjN0slWHuRbp9VeNwNQfrSUDjZM=
S
Vpze5DMtiGQ3gyli6Y2mEgNQsg1ycHACh1cJBcSszIjdgNfgVWFZJOh6frWtNpkc6KeZxIb=
N
XtVIubWsLwTIgu8G/MDjaFpgQ1/dbKNwiDSfm89uZmNg2GF33767uLr45eKsf37VMq4+K3c=
A
sSMBmePZpqdflfRlP6KfGtBuDeE+LR/o9cES+xAeiJ02Rvkk+kNLTFiaCpGLARV5aTX17aD=
p
dxeu0Zoo6uB2AfsERCaqhCUPFI0oTFMvTONi8ISFHHECimYrbJBvs4bz7ewxA1iPKHgWdUg=
Q
0ZeOR58x7Ch7BK1ZgwbXT/DuPofSCUPIsJ1OZw939xhEmI0hPWBzuy1xz+IKbRyuwEMOkgj=
b
WOsEAphfKLr2bENJQnp1fPm75g6uTt69++Pt1enPZyecnBe89x/G6WbtsGyGplW9idhburM=
s
aaFg+SSwYA/ArJXhIl1e0IeVQOO3rIINJRJ2gFM2SfPQSnWUed13QNG39TRri3HMaCBuZpO=
J
Jjd1PtcHLdRT7Rx0jfceZkJnhkSPOKe0t4kaDvvyhCRfuRgsQrm6BmIZd5s9XKZhILWsIsK=
/
M6D6yU4F2VxF3gcFWJ+uYe+5ahSX41Hw3XYbX2y3vWNebO6OchjTHOkxSaX+36RC8oS3QI9=
U
N3TD2QQBAUQmghy12+k43orRjDs4SU/daUSJKkxpYRqxtMwz01fbNrJ/mkfGeHinIo9k5/4=
f
VWyp/ybN1l6Xzvhet2sUW99RK23iO84vTiDRpRJHMweDflLtdizsXnytIzrguzQHgyKTlh7=
S
VaKSlMAT0MmGrxEH+iNejx92P9YDDHcjgx3zesLETAyhNxwDjinYb2dZ+2E6+rKJDmFmvLo=
G
I2MCuXKEj5s1QYq9PazgoYG25+S8mthqZ1Hz6bota4Gh8+/vv6pHlCGdsPshSKiYJEJ/+fL=
l
S/8GMGXG0duvqPvp0Eq8osfABHNqcwABQF+RQOtOQDBrdUkol1JvwwA9zqAj5MQB2S4dAUN=
K
HN6TGK2z4/M3x+dt5u+YZ9MX5lyzkEMt5GnGUrPQIGE41mHcfMVngfhVNGVKvqmnzm4Yt6W=
c
m3e/RU6k2Tj0/GI7g+yhiYsqHwUAXTUGnaD9LmHdgcTlRL0sG+L0jKdAYIAbusBEX6B9VC2=
q
1EVKB/SvJfZ63aEwQ6p8UYdWE0gals8e9LULNtFtV+8HMQm4wv3mPkfbtLqgzcU1Om43lY4=
3
qzvBZgC1wMNuJSdYr2PgBcujVPnpFFx0fP+c5G/1z9kH50q4RPd3dx3rgTt/wY01TEzmIsT=
i
ZpxxqJ57FNHxAYOpvJbW3Vo/I0K0/F1MvkDkEGNn0zkquwco6O7vy2EW1wY3zd/fQ/teBKB=
Y
jTJFETarQPsA4cvj96gw6V+N36Pe1fF75JO+x8XbuO7mX6k494S4Oyr3Fw8JlBi71VPdjqb=
R
n6clM1DgNUdIQ75CiQmyDXVX/cphLlz4dTSXCLonpcitTp3L7u4SHSDkUJ8Odgbh6J7EC4v=
l
4ix4Wj9pHk8zySwHlPBKxFg7CjvgciRpVA9rMCoY5ZnkNpcAVC+LkJNtjtIH2TUBl/kZmO1=
N
2mAbKavmafqpjx6hLcsEvbn8rf/25OR39Sd+fH1xfvX++PQqzLkILGjj5Pi349NzjuHbbVO=
+
HOOpy/E7aKy6HLEGCIM7QYidpBPQP4FxS4pIos7p7fFvJ+jaUMeOWKZDcgZy6Q1WF4uBK/2=
S
q4le0mg+Fu+wxOSQCysGowJ9PflmCdwmZeIw82JcImbQ9n/SANewpbpsYMmjC+YmHX1O8fs=
w
oySamSxM0vlm6R28HeExgeqAkvBI5VxnqKpKw36KearOucX/im8gFja2JN1JVkLmJmXLlxT=
c
lBk8dRWxtGFvOTAfuh9F89sBB3t9EXQ0prTbovAUik2g7aqX0eifdXaG9FaGZzwUNRE0Pc0=
U
QRRJZg4C+jqiIPkc8+I8Nxle1yLz1TnnSpd0I5SN5ZGVBIWz4rRdSc556iKT6Ap5Qb6M44l=
l
b07eEIhiZWi8F4y2sBMwOkurI3X+x9mZwyQxV1Jd0ymAM1ii7C5G3tAkvumSqj3agtcY+Am=
G
ruKWenWZd/H4R9yN/mLwaOhesFS9BmtOk+iu6NgF3rQ4dnFMVWBO1RKHDqyx0IREnEm33eR=
8
nDFJl8DiMYZgWfbfLzlAqDhsYFlgWAtpW3E8Z5wkNo7XvzpZkSrhZPGVwWLUgUoanba+Ona=
8
u6MhVmCNmznET4MVl7KOot2eZBlIdsim2WI5TFomjsTGYHAnng8WuRadhrOFuZNARqX0Hro=
B
OSbzoKBuG44WYHSe4UDgP4HeFCpPJ3OlT8oQauKEw23z+kFsnw7G4Qm01mQqWrm404PMSM7=
P
H2fbtvynvD2+XcZrAaXJD6hw1tzszacfJFWJnrgOHtiTGdfypOkylv2lwN413FDzEVR+vgB=
g
PY4y/daj3FzRnOzEGQK63c8AIGi34jxlmPMIWgVuKXnw3jII1BgtfelDHMTrgEnRYOWwsEd=
a
PBXbDfxXnIKkhKHC5Zc7rqC9WaEfydaYVD7BhYlFosinQNqx3SZsiD+jIs9tGW844biDEUp=
B
+WDc59pxWDbN/opjis4+GGc0RQq1dT2Ajdta3HzuUwASEPJCnjKYtH87yuZ1+ihhufiFQ3X=
x
s56YP9HN2CwMhTwqDYUfZSjiXWko/IxDGb1hbCh+S3hWF0DQF/0qtpcvWTZCSPCrC+i4q3z=
1
F0C/IVydH0u0F8ySsQJBcmZ/c9LA2DV9D/RnDpnjLluym1IoMGTBoM2Yn/Exk0U7ojlN5Z2=
a
0jDX/HZxg0HK0kEGLe8xlx4FV2EfrXoqvwW/gXwuCX7tkuru8a058HVW/VJdaT7qso2ZXPH=
j
ryfvAFagwfrzT7XpLjje2EC2ep0w3QsaJ5/N0APRSFM2m8+FQNaePGe1iftGh8FWu+zLSzl=
+
ZnF2vEh79+RsWhR2WTYZr2aZtJVeOyw5xqWy0kHx5Q1bCUsxx9RBKzmxssIAHEWxWI8eI1e=
x
Qy/OPngkmaiRwgZoDCSlKT6BI8o0WUPcPWzrJl98NXS43CpRgjRPF5krYXsCvcmSz+XEOA0=
V
84wMrtgqcf1yd8B/8DOQa2oWfzVNTb0+8ZevsRAgZCw5KmlYAeDbUgDfRgGM5RafCl88OJg=
g
8anwtePDMiEqAZNJ0IebKcYpGHkv8goE/cgDA+FYLwGuu8NMAcqmeNIG3y7d4Ftng83dFdn=
f
23B/CxvM1L+4gUJiCx3mfgdCqZqn5IrcjIfig+fr4n3l+loZAUjWKhTdqxw1S98zdbdIH5+=
t
etJgiciNOXcyrpIfeXexYcMC+fg7uawSAwtQY/2UZsDR2ZRY1Wds4C5e28X9OrQNveu6uFG=
4
HAwhBC37CYRV3nBVl9k0X8zGbF4VWzuBfJvaoxuK8GlwIioWhOoEYg5LWs6DloAa0ZZMFm1=
L
k4M1TgttQ0r6Em1o5ja8aXTuW2duh3WNtjRzW7Y2PqSZGxCfEcShAahAcnbpOEPfLi4DgWK=
m
0YDK0XF3yLDiyZHDrNuV8SO7Sp4QU2XxfY3YSE5OtA7rlAhSpBUiHRkSbLPiaY2WXXN0jAs=
T
6Y/MzhwdGQkC/BUcuB0dGYHAOFytXm7Jx3a7WBJTjp4/KPyfRA3zlf1YVxB7lsszjj4O/TS=
I
aOi9xi1P3KHZ74rIiW3hDMwtkIjwKRCPrMQHKwAyyvlq4o2Wb6LkBodLWGo7HRSM0SwwOu3=
w
MXEOxOWAi9MRGTOcEXlsw/vQ8fQPgZXaZB2Hzu9zZQ+FzFhgsC07aTOKLuGt8Z2WcNb+XAU=
N
r4wly6rmvp1cpy5SRYp3u7eKYaETcyYiTDQ+xvAvsDyisszZUwGSvrCdU8Fd/XuWzEdwBzp=
E
wJLjxDn2pUNAWQloZi5mS1ITF6fNwiL9pbC2yyNPZHrCtCLmuEhZ83oz/+XgaRGrAnQN9ZF=
G
ad9ATslQzpeelEcgZpbaPCIuCKMT0dekpLMmeaWdg7o5BQ5GfPBzImGQA8785DhFNWRqX9g=
2
04ZydyUhJe2fJaKzoUdE8atDRHF4qyGyKzGU3cYHEEdE+k3Q3OENcg3xJeriHUaGvIKsDvq=
J
+AHMNPouHqZO7EcJmCntYxWg+aYzF67vfP+YbnwGz2qExS3pg0n7iHpMq7/k3o9SRye1SlA=
9
XQbxfRXsnnOBGxzi5RrUpgNjXkNg65UiEWFode0Us8wRgarIDJfqq7z+ZG8w3LC8C+oFjJb=
K
7Iif1+IUip5oGJOl9lHYCOXoiUf5BphONdNxPQZnpXvwC6TekKfqUwrBlkajbAdhBQf4PwG=
t
RnX/AIOVqDMoqlGTP5pyMBj6EusNRa6GdPiy7+uSUKNcSgFgyXXyMnrlsFdkmV3L6CULLYK=
b
wt5ERhoxYcGhDcknbLK+n+LLqyRCGJMywvoYpA4EAHIOSrRMKjch5TLS8lVMA6XjEHGJLdR=
o
fz2SUmGIbFTAM3xW2A3f7UkuHWbxeRhHI54YBKiJ02mDBHmqIO8uVDgF3ZA5PXBqj2BSsmZ=
k
TJlI3M/Yy83hOWLjF/zQEioPSExJr9SEvVa9jUy/jddGoEO0THHRRp240r/LePaWzBpR18q=
t
ZG4rPoNWfrVXU82dus+5kxOPOVp9BZ5CoWRYYZiWjepoHCcZ+Jxl8yNWZdFFP8udFwsFl8B=
E
U70ceIFVl0M4umQ1oYgUWHlqPDeuo7deKB3rngVj20VHNyij11XJfnPH80Qv2s5pBHg5yN1=
f
rADsR630bNELNk5wqVjXFTL0cFw3w/dKiawL0XBKpyqEHggcDvKcCjkhpPkQVY1AS0H4Fzu=
7
72DcAoS2SWQQlMHoY2WC09eSKI+HAD94qvZn9Xb/AdXYF+50oQAA
- --------------4203D593236E89B935170AB9--
------------------------------
From: Chris Evans <chris@ferret.lmh.ox.ac.uk>
Date: Tue, 28 Oct 1997 17:15:44 +0000 (GMT)
Subject: Kernel messages
Hi,
I'm using:
2.0.31pre10
I got these (see below). What are they all about? I don't have any
masquerading rules defined! Although I believe I do have masquerade
support compiled in.
MASQ: failed TCP/UDP checksum from x.x.x.x!
MASQ: failed TCP/UDP checksum from x.x.x.x!
Real address replaced by x.x.x.x, of course. I saw 4 of these, with the
address x.x.x.x all the same.
Is someone trying it on??
Cheers
Chris
------------------------------
From: teunis <teunis@mauve.computersupportcentre.com>
Date: Tue, 28 Oct 1997 10:29:28 -0700 (MST)
Subject: to whom it may concern (about dcache)
I'm getting alot of "d_alloc: 6361 unused, pruning dcache"
Is it anything I should worry about?
(linux-2.1.60 + loop-9 + cyrix patch + sound-fix)
[loopback isn't in use at the moment... sound module isn't installed]
TIA and G'day, eh? :)
- Teunis
------------------------------
From: Matthew Kirkwood <matthew.kirkwood@lmh.ox.ac.uk>
Date: Tue, 28 Oct 1997 17:47:15 +0000 (GMT)
Subject: Re: 2.1.60 NFS probs (updated patch attached)
> Please carry on with the testing and let me know of any other anomali=
es
> ...
I'm currently around 3/4 of the way through a compile of 2.1.60 on my
nfsroot box, without any difficulties at all.
Later, I'll pick up bonnie and some other disk thrashers.
Matthew.
- --
Matthew Kirkwood | Mail: matthew.kirkwood@lmh.ox.ac.uk
LMH JCR, | Web: http://www-jcr.lmh.ox.ac.uk/~weejock/
Oxford OX2 6QA, | PGP: finger weejock@ferret.lmh.ox.ac.uk
England. | =20
------------------------------
From: Nigel Metheringham <Nigel.Metheringham@ThePLAnet.net>
Date: Tue, 28 Oct 1997 17:55:58 +0000
Subject: Re: Kernel messages=20
chris@ferret.lmh.ox.ac.uk said:
} I got these (see below). What are they all about? I don't have any
} masquerading rules defined! Although I believe I do have masquerade
} support compiled in.
} MASQ: failed TCP/UDP checksum from x.x.x.x!
} MASQ: failed TCP/UDP checksum from x.x.x.x!
Oh, what an interesting side effect....
If you have masq compiled in, all incoming packets destined for a local=
=20
address will pass through the masq checks. Since masq involves rewrit=
ing=20
packets and regenerating the checksums, quite early on it checks UDP/TC=
P=20
packets for correct checksums on the basis that rewriting a broken pack=
et=20
is a waste of time. Nothing else reports broken checksums at all, but =
the=20
masq code does (at too high a level of message in retrospect).
} Is someone trying it on??
No, just some broken kit or wiring out there...
I guess that it may be time to look at that code and see if we can spee=
d=20
it up by moving the checksum check after the relevance check. You may=20
only get this if the packets are destined for a port about 60000 - need=
to=20
check code for that.
Nigel.
- --=20
[ Nigel.Metheringham@theplanet.net - Systems Software Engineer ]
[ Tel : +44 113 251 6012 Fax : +44 113 224 0003 ]
[ Friends don't let friends use sendmail! ]
------------------------------
From: Todd Derr <infidel+@pitt.edu>
Date: Tue, 28 Oct 1997 13:06:16 -0500 (EST)
Subject: ADMIN: linux-kernel-digest/linux-kernel
Hello,
Now that we have a reasonable percentage of the list back
online, here's a quick recap for those who are still wondering what
was going on: First, someone on the kernel-digest list was feeding
back to the linux-kernel list, causing the big mail storm last week.
Then, the linux-kernel list was truncated, which is why everyone had
to resubscribe. Sorry for the inconvenience on both counts.
Also, if you're using the linux-kernel list, I would like to
remind/notify you of the existance of the linux-kernel-digest list,
which carries the same content as the kernel lists in digest format
(usually a few messages daily). All readers of linux-kernel should
consider subscribing instead to linux-kernel-digest if possible; the
digest list takes up a lot less CPU cycles to send out, which means
overall lower latency through vger. You will still be able to post to
the linux-kernel list if you are subscribed to the digest.
thank you,
todd j. derr
owner-linux-kernel/kernel-digest@vger.rutgers.edu
------------------------------
From: Dragisa Duric <dragisha@rstel.net>
Date: Tue, 28 Oct 1997 19:42:44 +0100 (MET)
Subject: iput: inode 542827 on device 03:02 still has mappings.
Hi,
I am getting lots of these on my two machines with 2.0.31 kernel. Als=
o,
I got "IRQ DEADLOCK ON..." or something like that yesterday with SMP
kernel (above message is without SMP). One of my machines had tons of
"still has mappings" after clean reboot, beofre first login prompt. I a=
m
running RedHat 4.2 with official updates and 2.0.31 as only difference
froms tock RedHat in system part.
Clean reboot to runlevel 1, or init 1 from troubled runlevel (machine
remains responsive after above message(s)) and fsck from there, gives n=
o
error message at all!?
dd
------------------------------
From: Asko Seeba <asko@cs.ut.ee>
Date: Tue, 28 Oct 1997 20:56:05 +0200 (EET)
Subject: problem with mprotect
Hey! I'm quite a new here and don't know, if my question here is annoyi=
ng
or not, but I still try... :)
I'm using Linux 2.1.57 on pentium and try to use mprotect function.=20
Problem is that even the example at 'man mprotect' doesn't work. It
returns with -1 and sets the errno to EINVAL.
So, do You know, if that mprotect needs any special requirements in sen=
se
of upgrading any library or smthng and/or is there any other known reas=
on
for behaving so?
- --
Asko Seeba (alias Joka Jehoowa Wennapoeg).
------------------------------
From: Andrea Arcangeli <arcangeli@mbox.queen.it>
Date: Tue, 28 Oct 1997 19:56:09 +0100 (CET)
Subject: [2.1.59] vfat error
I have the file pippo.tar.gz in /windoze that is a vfat ts.
cd /windoze
tar xzf pippo.tar.gz
result a fs error with some warining.
Then pippo.tar.gz is a directory.
I umount /windoze and after another error pippo.tar.gz return a file.
pippo.tar.gz was composed by
pippo/
pippo/......
pippo/xxx/....
Andreas Arcangeli
------------------------------
From: Erik Andersen <andersen@inconnect.com>
Date: Tue, 28 Oct 1997 12:01:16 -0700 (MST)
Subject: Re: Makefile defaulting to SMP
Hi Michael,
Just out of curiosity, have you sent this to Linus? I think he might b=
e
willing to apply this if you ask. Worst case, he might give an officia=
l
statement on why he thinks this to be the Wrong Thing (tm). Personally=
, I
think it is the Right Thing(tm), and I suspect there are a lot of other
people that feel the same way.
=20
-Erik
- --
Erik B. Andersen Web: http://www.inconnect.com/~andersen/=20
email: andersee@debian.org
- --This message was written using 73% post-consumer electrons--
On Tue, 28 Oct 1997, Michael Elizabeth Chastain wrote:
> I have a patch for this:
>=20
> ftp://ftp.shout.net/pub/users/mec/patch/config-smp.2154
>=20
> This makes CONFIG_SMP and CONFIG_SMP_PROF ordinary configuration
> options.
>=20
> Michael Chastain
> <mailto:mec@shout.net>
> "love without fear"
>=20
------------------------------
From: Bill Hawes <whawes@star.net>
Date: Tue, 28 Oct 1997 14:09:31 -0500
Subject: updated dcache management patch for 2.1.60
This is a multi-part message in MIME format.
- --------------0E7512FA049994C1F9994D6B
Content-Type: text/plain; charset=3Dus-ascii
Content-Transfer-Encoding: 7bit
I've made a few changes to the dcache management to improve performance=
,
especially for file find operations. The main change is to use an
explicit dentry timestamp rather than relying on the inode i_atime
field. This allows the code to detect when it reaches very recently
used dentries, to change the search behavior.
In limited testing against 2.0.31 it seems to be comparable, and in som=
e
cases much better. I'm sure further improvements are possible, so let
me know if you find cases where it doesn't seem to be working very well=
.
Regards,
Bill
- --------------0E7512FA049994C1F9994D6B
Content-Type: text/plain; charset=3Dus-ascii; name=3D"dcache_60-patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename=3D"dcache_60-patch"
- --- linux-2.1.60/include/linux/dcache.h.old Sat Oct 25 07:43:21 1997
+++ linux-2.1.60/include/linux/dcache.h Sat Oct 25 20:55:28 1997
@@ -51,6 +51,7 @@
unsigned long d_time; /* used by d_revalidate */
struct dentry_operations *d_op;
struct super_block * d_sb; /* The root of the dentry tree */
+ unsigned long d_reftime; /* last time referenced */
};
=20
struct dentry_operations {
- --- linux-2.1.60/fs/dcache.c.old Sat Oct 25 07:43:17 1997
+++ linux-2.1.60/fs/dcache.c Sun Oct 26 11:39:19 1997
@@ -97,9 +97,10 @@
goto out;
}
=20
- - if (!list_empty(&dentry->d_lru))
+ if (!list_empty(&dentry->d_lru)) {
dentry_stat.nr_unused--;
- - list_del(&dentry->d_lru);
+ list_del(&dentry->d_lru);
+ }
if (list_empty(&dentry->d_hash)) {
struct inode *inode =3D dentry->d_inode;
struct dentry * parent;
@@ -116,6 +117,11 @@
}
list_add(&dentry->d_lru, &dentry_unused);
dentry_stat.nr_unused++;
+ /*
+ * Update the timestamp
+ */
+ dentry->d_reftime =3D jiffies;
+
out:
if (count >=3D 0) {
dentry->d_count =3D count;
@@ -154,18 +160,28 @@
* we need inodes or memory. The selected dentries
* are moved to the old end of the list where
* prune_dcache() can find them.
+ *=20
+ * Negative dentries are included in the selection so
+ * that they don't accumulate at the end of the list.
+ * The returned value is the total number of dentries
+ * selected, which may be much larger than the number
+ * of inodes.
*/
- -int select_dcache(int count, int page_count)
+int select_dcache(int inode_count, int page_count)
{
- - struct list_head *tail =3D &dentry_unused;
- - struct list_head *next =3D dentry_unused.prev;
- - int forward =3D 0, young =3D 0, depth =3D dentry_stat.nr_unused >> =
1;
- - int found =3D 0, pages =3D 0;
+ struct list_head *next, *tail =3D &dentry_unused;
+ int found =3D 0, forward =3D 0, young =3D 8;
+ int depth =3D dentry_stat.nr_unused >> 1;
+ unsigned long min_value =3D 0, max_value =3D 4;
=20
#ifdef DCACHE_DEBUG
- -printk("select_dcache: %d unused, count=3D%d, pages=3D%d\n",
- -dentry_stat.nr_unused, count, page_count);
+printk("select_dcache: unused=3D%d, inodes=3D%d, pages=3D%d\n",
+dentry_stat.nr_unused, inode_count, page_count);
#endif
+ if (page_count)
+ max_value =3D -1;
+
+ next =3D tail->prev;
while (next !=3D &dentry_unused && depth--) {
struct list_head *tmp =3D next;
struct dentry *dentry =3D list_entry(tmp, struct dentry, d_lru);
@@ -182,56 +198,59 @@
continue;
}
/*
+ * Check the dentry's age to see whether to change direction.
+ */
+ if (!forward) {
+ int age =3D (jiffies - dentry->d_reftime) / HZ;
+ if (age < dentry_stat.age_limit) {
+ if (!--young) {
+ forward =3D 1;
+ /*
+ * If we're scanning forward, don't take
+ * files with too few or too many pages.
+ */
+ if (page_count) {
+ min_value =3D 3;
+ max_value =3D 15;
+ }
+ next =3D dentry_unused.next;
+#ifdef DCACHE_DEBUG
+printk("select_dcache: %s/%s age=3D%d, scanning forward\n",
+dentry->d_parent->d_name.name, dentry->d_name.name, age);
+#endif
+ }
+ continue;
+ }
+ }=20
+
+ /*
* Select dentries based on the page cache count ...
* should factor in number of uses as well.
*/
if (inode) {
- - if (inode->i_state)
+ if (inode->i_state || inode->i_count > 1)
continue;
value =3D inode->i_nrpages;=09
- - }
- - /*
- - * Consider various exemptions ...
- - */
- - if (!page_count) {
- - if (!inode)
- - continue;
- - if (value >=3D 3)
- - continue;
- - } else if (!forward) {
- - if (inode) {
- - int age =3D CURRENT_TIME - inode->i_atime;
- - if (age < dentry_stat.age_limit) {
- - if (++young > 8) {
- - forward =3D 1;
- - next =3D dentry_unused.next;
- -#ifdef DCACHE_DEBUG
- -printk("select_dcache: age=3D%d, pages=3D%d, scanning forward\n", ag=
e, pages);
- -#endif
- - }
- - continue;
- - }
- - }
} else {
- - /*
- - * If we're scanning from the front, don't take
- - * files with only a trivial amount of memory.
- - */
- - if (value < 3 || value > 15)
+ /* Don't take negative dentries from the front */
+ if (forward)
continue;
}
+
+ if (value >=3D max_value || value < min_value)
+ continue;
/*
- - * Move the dentry behind the tail
+ * Move the selected dentries behind the tail.
*/
if (tmp !=3D tail->prev) {
list_del(tmp);
list_add(tmp, tail->prev);
}
tail =3D tmp;
- - pages +=3D value;
- - if (++found >=3D count)
+ found++;
+ if (inode && --inode_count <=3D 0)
break;
- - if (page_count && pages >=3D page_count)
+ if (page_count && (page_count -=3D value) <=3D 0)
break;
}
return found;
@@ -364,7 +383,7 @@
if (goal) {
if (goal > 50)
goal =3D 50;
- - count =3D select_dcache(128, goal);
+ count =3D select_dcache(32, goal);
#ifdef DCACHE_DEBUG
printk("check_dcache_memory: goal=3D%d, count=3D%d\n", goal, count);
#endif
- --- linux-2.1.60/fs/inode.c.old Sat Oct 25 07:43:17 1997
+++ linux-2.1.60/fs/inode.c Sun Oct 26 09:16:27 1997
@@ -358,33 +384,30 @@
*/
static void try_to_free_inodes(int goal)
{
- - int retried =3D 0, found;
+ int retry =3D 1, found;
=20
/*
* Check whether to preshrink the dcache ...
*/
- - if (inodes_stat.preshrink) {
- - spin_unlock(&inode_lock);
- - select_dcache(goal, 0);
- - prune_dcache(goal);
- - spin_lock(&inode_lock);
- - }
+ if (inodes_stat.preshrink)
+ goto preshrink;
=20
- -repeat:
- - found =3D free_inodes(goal);
- -
- - /*
- - * If we didn't free any inodes, do a limited
- - * pruning of the dcache to help the next time.
- - */
- - if (!found) {
+ retry =3D 0;
+ do {
+ if (free_inodes(goal))
+ break;
+ /*
+ * If we didn't free any inodes, do a limited
+ * pruning of the dcache to help the next time.
+ */
+ preshrink:
spin_unlock(&inode_lock);
- - select_dcache(goal, 0);
- - prune_dcache(goal);
+ found =3D select_dcache(goal, 0);
+ if (found < goal)
+ found =3D goal;
+ prune_dcache(found);
spin_lock(&inode_lock);
- - if (inodes_stat.preshrink && !retried++)
- - goto repeat;
- - }
+ } while (retry--);
}
=20
/*
@@ -440,11 +463,11 @@
* If the allocation failed, do an extensive pruning of=20
* the dcache and then try again to free some inodes.
*/
- - prune_dcache(128);
+ prune_dcache(inodes_stat.nr_inodes >> 2);
inodes_stat.preshrink =3D 1;
=20
spin_lock(&inode_lock);
- - free_inodes(128);
+ free_inodes(inodes_stat.nr_inodes >> 2);
{
struct list_head *tmp =3D inode_unused.next;
if (tmp !=3D &inode_unused) {
- --------------0E7512FA049994C1F9994D6B--
------------------------------
From: "Adam D. Bradley" <artdodge@cs.bu.edu>
Date: Tue, 28 Oct 1997 14:19:29 -0500 (EST)
Subject: Re: to whom it may concern (about dcache)
> I'm getting alot of "d_alloc: 6361 unused, pruning dcache"
Someone said the other day that these are just debug/informational
messages, and they indicate things are working correctly.
Adam
- --
Things look so bad everywhere Adam D. Bradley artdodge@cs.bu.=
edu
In this whole world what is fair Boston University Computer Scie=
nce
We walk blind and we try to see Ph.D. student and Linux hac=
ker
Falling behind in what could be ----> Bring me a Higher Love ----> =
<><
------------------------------
From: Brian Topping <topping@mauswerks.com>
Date: Tue, 28 Oct 1997 11:58:21 -0800
Subject: How do I debug kernel MEMORY LEAKS?
Hi all,
I am trying to figure out how to debug a memory leak. I know what file
the problem is coming from (a networking module that I wrote that cache=
s
skbuffs), but I can't tell what I did wrong. I found the
<shift-scrollock> method of dumping the mem info. [btw, why is this
different than the info from /proc/meminfo?]. What do the regulars do
to get even more info about what is going on?
I think I need to find good documentation (even if it is reading the
source, at last resort) on how to treat skbuffs and the context and
meanings of the different flags, since I am probably not setting the
buffer up correctly for it to be released by the protocol stack after i=
t
is sent. Does this exist anywhere?
Thanks!
Brian
------------------------------
From: Tsurng-Chen Chern <maxchern@earthlink.net>
Date: Tue, 28 Oct 1997 11:59:36 -0800 (PST)
Subject: Re: to whom it may concern (about dcache)
Yes, indeed, check linux/fs/dcache.c, you can simply get
rid of these message by setting the flag off.
On Tue, 28 Oct 1997, Adam D. Bradley wrote:
>=20
> > I'm getting alot of "d_alloc: 6361 unused, pruning dcache"
>=20
> Someone said the other day that these are just debug/informational
> messages, and they indicate things are working correctly.
>=20
> Adam
> --
> Things look so bad everywhere Adam D. Bradley artdodge@cs.b=
u.edu
> In this whole world what is fair Boston University Computer Sc=
ience
> We walk blind and we try to see Ph.D. student and Linux h=
acker
> Falling behind in what could be ----> Bring me a Higher Love ---->=
<><
>=20
>=20
Max Chern, Unix Software Engineer | Voice: 818-296-5014
EarthLink Network, Inc. | Fax: 818-296-5113
maxchern@earthlink.net | 3100 New York Dr., Ste 201
http://www.earthlink.net/ | Pasadena, CA 91107
------------------------------
From: Andi Gutmans <andi@vipe.technion.ac.il>
Date: Tue, 28 Oct 1997 22:02:04 +0200 (IST)
Subject: Linux 2.0.31 went nuts
Hi,
I upgraded to 2.0.31 yesterday after having 2.0.30 running pretty
smoothly. Everything started to segfault slowly but surely. Actually, I
think probably net related stuff.
Here is what i caught in /var/log/messages.
Oct 28 21:47:00 vipe kernel: general protection: 0000
Oct 28 21:47:00 vipe kernel: CPU: 0
Oct 28 21:47:00 vipe kernel: EIP: 0010:[inet_setsockopt+31/92]
Oct 28 21:47:00 vipe kernel: EFLAGS: 00010246
Oct 28 21:47:00 vipe kernel: eax: 0185a47c ebx: bffff398 ecx: 00000=
004
edx: 01b4d810
Oct 28 21:47:00 vipe kernel: esi: 00000001 edi: 00000009 ebp: bffff=
39c
esp: 01d4af54
Oct 28 21:47:00 vipe kernel: ds: 0018 es: 0018 fs: 002b gs: 002b
ss: 0018
Oct 28 21:47:00 vipe kernel: Process beisa (pid: 6609, process nr: 97,
stackpage=3D01d4a000)
Oct 28 21:47:00 vipe kernel: Stack: bffff398 00000009 00000001 00135802
0185a47c 00000001 00000009 bffff398
Oct 28 21:47:00 vipe kernel: 00000004 bffff35c 0000000d 00000004
00135ea8 0000000a 00000001 00000009
Oct 28 21:47:00 vipe kernel: bffff398 00000004 03ae6414 bffff398
03030300 03030302 06040404 05050206
Oct 28 21:47:01 vipe kernel: Call Trace: [sys_setsockopt+106/128]
[sys_socketcall+624/732] [system_call+85/128]
Oct 28 21:47:01 vipe kernel: Code: c3 53 57 6a 01 52 e8 06 87 fe ff 83 =
c4
14 5b 5e 5f c3 8d 76
Oct 28 21:47:05 vipe kernel: general protection: 0000
Oct 28 21:47:05 vipe kernel: CPU: 0
Oct 28 21:47:05 vipe kernel: EIP: 0010:[ip_options_build+483/484]
Oct 28 21:47:05 vipe kernel: EFLAGS: 00010202
Oct 28 21:47:05 vipe kernel: eax: 7f080008 ebx: 001acfb0 ecx: 047c6=
e38
edx: 001acfc4
Oct 28 21:47:05 vipe kernel: esi: 047c6e6c edi: 06074484 ebp: 2a084=
484
esp: 001acf88
Oct 28 21:47:05 vipe kernel: ds: 0018 es: 0018 fs: 002b gs: 0018
ss: 0018
Oct 28 21:47:05 vipe kernel: Process swapper (pid: 0, process nr: 0,
stackpage=3D001ab164)
Oct 28 21:47:05 vipe kernel: Stack: 0014d2f3 001acfc4 00000000 2a084484
06074484 047c6e6c 047c6e30 047c0023
Oct 28 21:47:05 vipe kernel: 2a084484 047c6e6c 047c6e38 00000023
7f080000 00000000 047c6e1c 00000220
Oct 28 21:47:05 vipe kernel: 047c0000 00191f00 047c6e00 00000000
00000003 047c0008 2a084484 06074484
Oct 28 21:47:05 vipe kernel: Call Trace: [icmp_echo+75/120]
[el3_start_xmit+368/504] [ipfw_input_check+35/40] [i
cmp_rcv+273/284]
Oct 28 21:47:05 vipe kernel: Code: f6 83 ec 2c 55 57 56 53 8b 54 24 50 =
31
c0 b9 03 00 00 00 8b
Oct 28 21:47:05 vipe kernel: Aiee, killing interrupt handler
Oct 28 21:47:05 vipe kernel: kfree of non-kmalloced memory: 001ad1ac,
next=3D 047c6e6c, order=3D101139588
Oct 28 21:47:05 vipe kernel: kfree of non-kmalloced memory: 001ad19c,
next=3D 047c6e6c, order=3D101139588
Oct 28 21:47:05 vipe kernel: kfree of non-kmalloced memory: 001ad6b0,
next=3D 047c6e6c, order=3D101139588
Oct 28 21:47:05 vipe kernel: idle task may not sleep
Oct 28 21:47:32 vipe kernel: general protection: 0000
Oct 28 21:47:32 vipe kernel: CPU: 0
Oct 28 21:47:32 vipe kernel: EIP: 0010:[inet_setsockopt+31/92]
Oct 28 21:47:32 vipe kernel: EFLAGS: 00010246
Oct 28 21:47:32 vipe kernel: eax: 00590d58 ebx: bffffd44 ecx: 00000=
004
edx: 03760018
Oct 28 21:47:32 vipe kernel: esi: 00000001 edi: 00000009 ebp: bffff=
d58
esp: 00533f54
Oct 28 21:47:32 vipe kernel: ds: 0018 es: 0018 fs: 002b gs: 002b
ss: 0018
Oct 28 21:47:32 vipe kernel: Process in.telnetd (pid: 10201, process nr=
:
36, stackpage=3D00533000)
Oct 28 21:47:32 vipe kernel: Stack: bffffd44 00000009 00000001 00135802
00590d58 00000001 00000009 bffffd44=20
Oct 28 21:47:32 vipe kernel: 00000004 bffffd04 0000000d 00000004
00135ea8 00000000 00000001 00000009=20
Oct 28 21:47:32 vipe kernel: bffffd44 00000004 02664c0c bffffd44
03030300 03030302 06040404 05050206=20
Oct 28 21:47:32 vipe kernel: Call Trace: [sys_setsockopt+106/128]
[sys_socketcall+624/732] [system_call+85/128]=20
Oct 28 21:47:32 vipe kernel: Code: c3 53 57 6a 01 52 e8 06 87 fe ff 83 =
c4
14 5b 5e 5f c3 8d 76=20
Oct 28 21:47:35 vipe in.telnetd[10202]: connect from
pc1.rifkin.technion.ac.il
Oct 28 21:47:35 vipe kernel: general protection: 0000
Oct 28 21:47:35 vipe kernel: CPU: 0
Oct 28 21:47:35 vipe kernel: EIP: 0010:[inet_setsockopt+31/92]
Oct 28 21:47:35 vipe kernel: EFLAGS: 00010246
Oct 28 21:47:35 vipe kernel: eax: 02797c5c ebx: bffffd44 ecx: 00000=
004
edx: 02664c0c
Oct 28 21:47:35 vipe kernel: esi: 00000001 edi: 00000009 ebp: bffff=
d58
esp: 03da1f54
Oct 28 21:47:35 vipe kernel: ds: 0018 es: 0018 fs: 002b gs: 002b
ss: 0018
Oct 28 21:47:35 vipe kernel: Process in.telnetd (pid: 10202, process nr=
:
36, stackpage=3D03da1000)
Oct 28 21:47:35 vipe kernel: Stack: bffffd44 00000009 00000001 00135802
02797c5c 00000001 00000009 bffffd44=20
Oct 28 21:47:35 vipe kernel: 00000004 bffffd04 0000000d 00000004
00135ea8 00000000 00000001 00000009=20
Oct 28 21:47:35 vipe kernel: bffffd44 00000004 01fd1810 bffffd44
03030300 03030302 06040404 05050206=20
Oct 28 21:47:35 vipe kernel: Call Trace: [sys_setsockopt+106/128]
[sys_socketcall+624/732] [system_call+85/128]=20
Oct 28 21:47:35 vipe kernel: Code: c3 53 57 6a 01 52 e8 06 87 fe ff 83 =
c4
14 5b 5e 5f c3 8d 76=20
Oct 28 21:47:39 vipe in.telnetd[10204]: connect from
pc1.rifkin.technion.ac.il
Oct 28 21:47:40 vipe kernel: general protection: 0000
Oct 28 21:47:40 vipe kernel: CPU: 0
Oct 28 21:47:40 vipe kernel: EIP: 0010:[inet_setsockopt+31/92]
Oct 28 21:47:40 vipe kernel: EFLAGS: 00010246
Oct 28 21:47:40 vipe kernel: eax: 03efb47c ebx: bffffd44 ecx: 00000=
004
edx: 03243414
Oct 28 21:47:40 vipe kernel: esi: 00000001 edi: 00000009 ebp: bffff=
d58
esp: 03336f54
Oct 28 21:47:40 vipe kernel: ds: 0018 es: 0018 fs: 002b gs: 002b
ss: 0018
Oct 28 21:47:40 vipe kernel: Process in.telnetd (pid: 10204, process nr=
:
38, stackpage=3D03336000)
Oct 28 21:47:40 vipe kernel: Stack: bffffd44 00000009 00000001 00135802
03efb47c 00000001 00000009 bffffd44=20
Andi
- --
Andi Gutmans - Computer Science, Technion, Israel Institute of Technolo=
gy
Web: http://andi.il.eu.org/ ICQ: 1568297 PGP: finger andi@vipe.technion=
.ac.il
KeyID 62F5661D fingerprint =3D 1A 87 A2 10 2F EF EF AB 47 E0 4D 42 F5 =
B5 49 AD
------------------------------
From: Bill Hawes <whawes@star.net>
Date: Tue, 28 Oct 1997 15:43:24 -0500
Subject: Re: How do I debug kernel MEMORY LEAKS?
Brian Topping wrote:
> I am trying to figure out how to debug a memory leak. I know what fi=
le
> the problem is coming from (a networking module that I wrote that cac=
hes
> skbuffs), but I can't tell what I did wrong. I found the
> <shift-scrollock> method of dumping the mem info. [btw, why is this
> different than the info from /proc/meminfo?]. What do the regulars d=
o
> to get even more info about what is going on?
Memory leaks are tricky to debug! That's why there are so many of them
...
> I think I need to find good documentation (even if it is reading the
> source, at last resort) on how to treat skbuffs and the context and
^^^^^^^^^^^
Best to make this the first resort ...
Regards,
Bill
------------------------------
From: root <root@mangue.ibm.net>
Date: Tue, 28 Oct 1997 21:58:20 +0100 (MET)
Subject: Kernels 2.1 with 386DX/387 IRQ13 PC boxes
Hello there,
I have a problem with kernels since at least 2.1.46 and up to 2.1.59
with my 386DX33 (AMD compatible) and my 387 Cyrix FasMath CX83D87-33 GP
math coprocessor. I think the problem appears also with a standart Inte=
l
80386/80387 when IRQ13 is used.
First, if the kernel is build and run, it display just after math
coprocessor detection the message "lock in an interrupt context". Secon=
d,
it display that all the time so the kernel will not boot.
Problems are in directory linux/arch/i386/kernel, in files traps.c an=
d
irq.c (and include/linux/kernel.h).
To remind things, when IRQ13 is called, function "math_error_irq" in
irq.c is called (see "struct irqaction irq13"), and it calls "math_erro=
r"
in traps.c.
Function "math_error" is only called at two places, the second one is
inside traps.c in "do_coprocessor_error" following an exception 16, so
in fact the prototype of "math_error" in file include/linux/kernel.h
could be put between #ifdef CONFIG_M386 , if someone want to clean.
The message "lock in an interrupt context" is due to the call of
"lock_kernel()" and "unlock_kernel()" in "math_error" because then
this function is called within an IRQ handler - IRQ 13 handler, and thi=
s
protection is probably not needed.
Because function "math_error" is only called at two places (for i386
architecture, I do not know for the others), we can safely put the
kernel protection in "do_coprocessor_error", and remove it from
"math_error".
******************** The function are then : *************************
void math_error(void)
{
struct task_struct * task;
clts();
#ifdef __SMP__
task =3D current;
#else
task =3D last_task_used_math;
last_task_used_math =3D NULL;
if (!task) {
__asm__("fnclex");
return;
}
#endif
/*
* Save the info for the exception handler
*/
__asm__ __volatile__("fnsave %0":"=3Dm" (task->tss.i387.hard));
task->flags&=3D~PF_USEDFPU;
stts();
force_sig(SIGFPE, task);
task->tss.trap_no =3D 16;
task->tss.error_code =3D 0;
}
asmlinkage=20
void do_coprocessor_error(struct pt_regs * regs, long error_code)
{
ignore_irq13 =3D 1;
lock_kernel();
math_error();
unlock_kernel();
}
**********************************************************************
Then, the kernel will boot ONLY if SMP is NOT defined at compile time=
.
Now, the second problem is that the message "lock from interrupt
context" is continously displayed (if SMP is defined). I also found
a patch which seems to work but I am less sure of it : it seems that
the math assembly instruction "fnclex" is never executed...
If it is added in irq.c like :
static void math_error_irq(int cpl, void *dev_id, struct pt_regs *regs)
{
outb(0,0xF0);
printk ("IRQ13 ");
if (ignore_irq13 || !hard_math)
return;
math_error();
__asm__("fnclex");
}
the kernel will boot without any problem, and coprocessor seems to work
correctly.
Now my question : How to test it? How to generate an IRQ13 interrupt?
I tried writing a small C program which divide by zero or takes one
of its operand outside the valid address range. I tried to intercept
SIGFPE, I looked at /proc/interrupts. No way to produce such an
external interrupt from my coprocessor. I also have a "printk()" insi=
de
"math_error_irq" to log this IRQ but it seems to never happen.
If you have any solution, I would like to hear it...
Thanks for reading,
Etienne.
- -- E-mail : etienne.lorrain@ibm.net
- ------------- On ne voit bien qu'avec le coeur, --------------------
- ----- l'essentiel est invisible pour les yeux . St Exupery ---------
------------------------------
From: Michael Nelson <mikenel@wam.umd.edu>
Date: Tue, 28 Oct 1997 15:59:58 -0500 (EST)
Subject: OFF-TOPIC: Corel using Linux
It's a bit off-topic, but I thought some of the developers here might b=
e
interested...
http://www.infoworld.com/cgi-bin/displayStory.pl?971028.ecorel.htm
- -mike
------------------------------
From: "Russell Coker - mailing lists account" <bofh@snoopy.virtual.net.=
au>
Date: Wed, 29 Oct 97 06:59:21 +1000
Subject: Re: irq2dev_map in 2.1.60
>> That's OK. Please let me know whether your system works with my p=
atch.
>Back to 2.1.59... too many errors.
>Let me show:
>First d_count=3D1 (I get this one with .59 too) and quotaon when booti=
ng:
>Oct 28 08:45:24 fortuny kernel: Oops: 0000
>Oct 28 08:45:24 fortuny kernel: CPU: 0
>Oct 28 08:45:24 fortuny kernel: EIP: 0010:[<c011c74c>]
>Oct 28 08:45:24 fortuny kernel: EFLAGS: 00010282
>Oct 28 08:45:24 fortuny kernel: eax: 00000000 ebx: c3da8000 ecx:
>c3d6f1e8 edx: 00000018
>Oct 28 08:45:24 fortuny kernel: esi: 00000020 edi: c03d3fac ebp:
>c0fae360 esp: c3da9ed4
>Oct 28 08:45:24 fortuny kernel: ds: 0018 es: 0018 ss: 0018 Oct 28
>08:45:24 fortuny kernel: Process quotaon (pid: 25, process nr: 5, stac=
kpa
I get the same thing. Quota seems badly broken in 2.1.60 (as oppose=
d to
2.1.5[89] where a minor patch would fix it). I don't even know where t=
o
start looking for this one.
>Later interrupts:
>Oct 28 08:45:24 fortuny kernel: ISDN subsystem Rev:
>1.44/1.41/1.44/1.27/1.8 load ed
>Oct 28 08:45:24 fortuny kernel: HiSax: Driver for Siemens chip set ISD=
N
>cards Oct 28 08:45:24 fortuny kernel: HiSax: Version 2.1
>Oct 28 08:45:24 fortuny kernel: HiSax: Revisions 1.15/1.10/1.10/1.30/1=
.8
>Oct 28 08:45:24 fortuny kernel: HiSax: Card 1 Protocol EDSS1 Id=3Dhisa=
x0 (0)
>Oct 28 08:45:24 fortuny kernel: HiSax: Teles IO driver Rev. 1.11 Oct 2=
8
>08:45:24 fortuny kernel: HiSax: Creatix/Teles PnP config irq:3 isac:12=
0 =20
>cfg:0
>Oct 28 08:45:24 fortuny kernel: HiSax: hscx A:180 hscx B:1a0 Oct 28
>08:45:24 fortuny kernel: Teles3: HSCX version A: V2.1 B: V2.1 Oct 28
>08:45:24 fortuny kernel: Teles3: ISAC 2086/2186 V1.1 Oct 28 08:45:24
>fortuny kernel: Teles: Spurious interrupt! Oct 28 08:45:24 fortuny ker=
nel:
>Teles: Spurious interrupt!
^^^^^^^^^^^^^^^^^^^^^^^
Did it do that before?
>As I lost lots of data in a 2.1.5? kernel due to dentries=B4 errors I =
prefer
>to stay in .59.
Fair enough. If you need quotas then you need something other than
2.1.60.
>If you want me to try something I=B4ll do my best.
It's up to you (and others). I'm happy to spend my spare time doing
minor hacking on device drivers for hardware I don't own if someone els=
e
will test it...
The URL for the HiSax patch (for those who are interested) is
ftp://snoopy.virtual.net.au/Linux/kernel/patch/hisax.60
- --=20
- -----------------------------------------------------------
In return for "mailbag contention" errors from buggy Exchange
servers I'll set my mail server to refuse mail from your domain.
The same response applies when a message to a postmaster
account bounces.
"Russell Coker - mailing lists account" <bofh@snoopy.virtual.net.au>
- -----------------------------------------------------------
------------------------------
End of linux-kernel-digest V1 #1272
***********************************
To subscribe to linux-kernel-digest, send the command:
subscribe linux-kernel-digest
in the body of a message to "Majordomo@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-diges=
t"
in the commands above with "linux-kernel".