--PAI00195.896102107/wigner.cstc.org
**********************************************
** THIS IS A WARNING MESSAGE ONLY **
** YOU DO NOT NEED TO RESEND YOUR MESSAGE **
**********************************************
The original message was received at Mon, 25 May 1998 05:49:36 +0200
from pol@wigner.cstc.org [192.168.1.2]
----- The following addresses had transient non-fatal errors -----
"|exec /usr/lib/mailagent/filter >> /home/pol/var/log/mailagent.bak 2>&1"
(expanded from: <pol@wigner.cstc.org>)
----- Transcript of session follows -----
451 <linux-kernel@vger.rutgers.edu>... vger.rutgers.edu: Name server timeout
451 <linux-kernel@vger.rutgers.edu>... vger.rutgers.edu: Name server timeout
451 "|exec /usr/lib/mailagent/filter >> /home/pol/var/log/mailagent.bak 2>&1"... vger.rutgers.edu: Name server timeout
451 "|exec /usr/lib/mailagent/filter >> /home/pol/var/log/mailagent.bak 2>&1"... vger.rutgers.edu: Name server timeout
451 "|exec /usr/lib/mailagent/filter >> /home/pol/var/log/mailagent.bak 2>&1"... mbox.est.it: Name server timeout
"|exec /usr/lib/mailagent/filter >> /home/pol/var/log/mailagent.bak 2>&1"... Deferred: Name server: host name lookup failure
Warning: message still undelivered after 4 hours
Will keep trying until message is 5 days old
451 <linux-kernel@vger.rutgers.edu>... vger.rutgers.edu: Name server timeout
--PAI00195.896102107/wigner.cstc.org
Content-Type: message/delivery-status
Reporting-MTA: dns; wigner.cstc.org
Arrival-Date: Mon, 25 May 1998 05:49:36 +0200
Final-Recipient: RFC822; <pol@wigner.cstc.org>
X-Actual-Recipient: RFC822; |exec /usr/lib/mailagent/filter >> /home/pol/var/log/mailagent.bak 2>&1@wigner.cstc.org
Action: delayed
Status: 4.4.3
Last-Attempt-Date: Mon, 25 May 1998 15:15:07 +0200
Will-Retry-Until: Sat, 30 May 1998 05:49:36 +0200
--PAI00195.896102107/wigner.cstc.org
Content-Type: message/rfc822
Return-Path: <linux-kernel@vger.rutgers.edu>
Received: from wigner.cstc.org (pol@wigner.cstc.org [192.168.1.2])
by wigner.cstc.org (8.8.8/8.8.8/Debian/GNU) with ESMTP id FAA00517
for <pol@wigner.cstc.org>; Mon, 25 May 1998 05:49:36 +0200
From: linux-kernel@vger.rutgers.edu
Received: from mbox.est.it
by wigner.cstc.org (fetchmail-4.3.9 POP3)
for <pol/wigner.cstc.org> (single-drop); Mon, 25 May 1998 05:49:36 CEST
Message-ID: <294156@bbs.eureka.est.it>
To: Pumilia@mbox.est.it
Date: 25 May 1998 02:59:00 GMT +0100
Subject: linux-kernel-digest V1 #2011
linux-kernel-digest Sunday, 24 May 1998 Volume 01 : Number 2011
In this issue:
Re: Modularized net bridging PATCH against pre-2.1.104-1
Re: Upgrading to a test kernel
Re: To Bogomips or not to Bogomips?
Re: /tmp in swap space
Re: Upgrading to a test kernel
Re: To Bogomips or not to Bogomips?
Re: Tyan 1662D new Award BIOS bugs
Module related stuff
Re: To Bogomips or not to Bogomips?
2.1.103 uniprocessor oops
Re: [SOUND] Aztech Sound Galaxy broken/not supported?
Re: Poor TCP throughput in 2.1.103
Re: Modularized x86 math emulation PATCH against pre-2.1.104-1
Re: /tmp in swap space
lp patch
Re: Tyan 1662D new Award BIOS bugs
Re: Module related stuff
Re: Modularized net bridging PATCH against pre-2.1.104-1
Re: Modularized net bridging PATCH against pre-2.1.104-1
Security bug in 2.1.103: old style stat(2)
Re: Poor TCP throughput in 2.1.103
Re: /tmp in swap space
Re: Modularized x86 math emulation PATCH against pre-2.1.104-1
OPTi 82C931 broken (was Re: 2.1.103 MSS?)
Re: modules on alpha
RE: OPTi 82C931 broken (was Re: 2.1.103 MSS?)
Re: About crypt...
Mount problem in 100+: 2 new clues
Weird(harmless?) IP Masquerade message
Minor comments on 2.1.104pre1
one more comment on 2.1.104pre1...
Obtaining 2.0.34-pre
iproute2 Error.
Re: 2.1.102 and APM -- is the patch correct?
Re: Minor comments on 2.1.104pre1
Re: New Cyrix patch for 2.0.33
Re: Modularized x86 math emulation PATCH against pre-2.1.104-1
Re: Obtaining 2.0.34-pre
make modules_install behaviour for sound modules
make menuconfig problem
Re: Modularized x86 math emulation PATCH against pre-2.1.104-1
Re: PATCH: signals security
See the end of the digest for information on subscribing to the linux-kernel
or linux-kernel-digest mailing lists.
----------------------------------------------------------------------
From: Philip Blundell <Philip.Blundell@pobox.com>
Date: Sun, 24 May 1998 15:19:01 +0100
Subject: Re: Modularized net bridging PATCH against pre-2.1.104-1
>Is this kind of hook permitted?
>
>How many other modules are there that require modular support to be built into
>the kernel? I know the PC Speaker does it, and I assumed that was one of the
>reasons it wasn't accepted.
It happens in a few places in the network code, and parport has at least one
of those as well.
p.
------------------------------
From: Riley Williams <rhw@ps.cus.umist.ac.uk>
Date: Sun, 24 May 1998 18:41:48 +0100 (BST)
Subject: Re: Upgrading to a test kernel
Hi there.
>> Looking for some help from the Red Hat users on this list (or
>> knowledgable others). I've tried a couple of times before to
>> upgrade my existing RH 5.0 system to one of the test kernels, but
>> I usually end up screwing up one thing or another. I have read the
>> documentation, and I've tried to upgrade almost of the packages
>> necessary as listed by the minimum version numbers in the
>> documentation.
>> If anyone is currently running RH 5.0, and has successfully gotten
>> to the point of running a test kernel, I would like to discuss the
>> steps that you took to get to that point.
In my case, here's the procedure I used to update to the latest of
everything...I use the RedHat mirror on SunSite.doc.ic.ac.uk but the
following should also work with RedHat's own site...
Q> #!/bin/bash
Q> mkdir /redhat
Q> mount -t nfs -o ro,soft,rsize=8192,wsize=8192 \
Q> 193.63.255.4:/public/Mirrors/ftp.redhat.com/ /redhat
Q> cd /redhat/pub/redhat/current/updates/i386
Q> for Z in *.i386.rpm ; do
Q> X=`echo $Z | sed 's/-[0-9]*\./ /' | cut -d ' ' -f 1`
Q> Y=`rpm -q $X 2> /dev/null`
Q> if [ "$Y" != '' ]; then
Q> if [ $Y.i386.rpm != $Z ]; then
Q> echo "Updating $Y.i386.rpm to $Z" >&2
Q> rpm -Uvh $Z
Q> fi
Q> fi
Q> done
Q> cd /
Q> umount /redhat
Q> rmdir /redhat
The result of the above sequence is that ALL of your currently
installed RedHat-supplied RPM's are updated to the latest versions,
thus reducing the problems caused by old versions...
Best wishes from Riley.
------------------------------
From: Jon Lewis <jlewis@inorganic5.fdt.net>
Date: Sun, 24 May 1998 13:38:28 -0400 (EDT)
Subject: Re: To Bogomips or not to Bogomips?
On Sun, 24 May 1998, Riley Williams wrote:
> > No. dmesg overflows. It does on my machine pretty fast, it does on
> > production servers. You may not rely on dmesg.
>
> Is anybody planning on fixing the bug in dmesg so it reads the FULL
> message buffer rather than just the first 4k of it?
It's not a bug...it's life. The message buffer has to be limited, or it
opens the kernel up to DoS attacks if the buffer can grow without limit
and consume all memory. It might be nice if the buffer size were made
tunable so that on big systems, you can see all the bootup messages before
the buffer fills.
- ------------------------------------------------------------------
Jon Lewis <jlewis@fdt.net> | Spammers will be winnuked or
Network Administrator | drawn and quartered...whichever
Florida Digital Turnpike | is more convenient.
______http://inorganic5.fdt.net/~jlewis/pgp for PGP public key____
------------------------------
From: Stefan Monnier <monnier+lists/linux/kernel/news/@TEQUILA.SYSTEMSZ.CS.YALE.EDU>
Date: 24 May 1998 13:48:51 -0400
Subject: Re: /tmp in swap space
lmcvoy@dnai.com (Larry McVoy) writes:
> I think you missed the discussion of TMPFS vs UFS performance.
I don't think so.
> Creates in TMPFS are going to be orders of magnitude faster than in UFS.
But the number of files created during an Emacs compilation is rather low
compared to the total time (remember my "benchmark" is to compile Emacs on a
Sun once on a tmpfs partition and the other time with a uifs partition but in
both cases the /tmp files used internally by gcc were on a tmpfs so are
irrelevant for this discussion).
Stefan
------------------------------
From: Riley Williams <rhw@ps.cus.umist.ac.uk>
Date: Sun, 24 May 1998 18:51:17 +0100 (BST)
Subject: Re: Upgrading to a test kernel
Hi again.
>>> Looking for some help from the Red Hat users on this list (or
>>> knowledgable others). I've tried a couple of times before to
>>> upgrade my existing RH 5.0 system to one of the test kernels, but
>>> I usually end up screwing up one thing or another. I have read the
>>> documentation, and I've tried to upgrade almost of the packages
>>> necessary as listed by the minimum version numbers in the
>>> documentation.
>>> If anyone is currently running RH 5.0, and has successfully gotten
>>> to the point of running a test kernel, I would like to discuss the
>>> steps that you took to get to that point.
> In my case, here's the procedure I used to update to the latest of
> everything...I use the RedHat mirror on SunSite.doc.ic.ac.uk but the
> following should also work with RedHat's own site...
> Q> #!/bin/bash
> Q> mkdir /redhat
> Q> mount -t nfs -o ro,soft,rsize=8192,wsize=8192 \
> Q> 193.63.255.4:/public/Mirrors/ftp.redhat.com/ /redhat
> Q> cd /redhat/pub/redhat/current/updates/i386
> Q> for Z in *.i386.rpm ; do
> Q> X=`echo $Z | sed 's/-[0-9]*\./ /' | cut -d ' ' -f 1`
> Q> Y=`rpm -q $X 2> /dev/null`
> Q> if [ "$Y" != '' ]; then
> Q> if [ $Y.i386.rpm != $Z ]; then
> Q> echo "Updating $Y.i386.rpm to $Z" >&2
> Q> rpm -Uvh $Z
> Q> fi
> Q> fi
> Q> done
> Q> cd /
> Q> umount /redhat
> Q> rmdir /redhat
> The result of the above sequence is that ALL of your currently
> installed RedHat-supplied RPM's are updated to the latest versions,
> thus reducing the problems caused by old versions...
Clarification to the above: It ONLY updates rpm's that are already
installed, not updates to ones you haven't installed yet...so no more
emails asking about this please...
Best wishes from Riley.
------------------------------
From: Riley Williams <rhw@ps.cus.umist.ac.uk>
Date: Sun, 24 May 1998 18:56:13 +0100 (BST)
Subject: Re: To Bogomips or not to Bogomips?
Hi Jon.
>>> No. dmesg overflows. It does on my machine pretty fast, it does on
>>> production servers. You may not rely on dmesg.
>> Is anybody planning on fixing the bug in dmesg so it reads the FULL
>> message buffer rather than just the first 4k of it?
> It's not a bug...it's life. The message buffer has to be limited,
> or it opens the kernel up to DoS attacks if the buffer can grow
> without limit and consume all memory. It might be nice if the
> buffer size were made tunable so that on big systems, you can see
> all the bootup messages before the buffer fills.
I think we're talking about different things here...
According to my information, the dmesg buffer in the kernel is 8k in
size, but the dmesg program only grabs the first 4k of it, and THAT is
the bug I was referring to...
Best wishes from Riley.
------------------------------
From: "J. Maynard Gelinas" <maynard@jmg.com>
Date: Sun, 24 May 1998 14:45:21 -0400 (EDT)
Subject: Re: Tyan 1662D new Award BIOS bugs
There may be an underlying relationship between _why_ both fail,
but since you're using a completely different MB and BIOS knowing why
probably won't help us Tyan users _right now_. I don't know enough to
figure out what's different yet, only that the previous BIOS worked, and
this new one doesn't. I'd like to point out that I specified the kernel
driver only to identify the SCSI board to readers; obviously, if it's
having trouble reading the boot loader the kernel and SCSI driver haven't
been loaded yet.
The message was both a heads up to Tyan users and a shot in the
dark for help. BTW: Anyone know if there's an 'Open Source BIOS' project
underway? I suspect a freeware BIOS would probably get regular updates,
and in general _work properly_. ;-)
Thanks!
- --jmg
On Sun, 24 May 1998, Grant R. Guenther wrote:
> J. Maynard Gelinas wrote, concerning a Tyan motherboard:
>
> > Unfortunately, it also seems buggy. My Symbios Logic SCSI
> > controller, with the NCR53C8XX driver, gets recognized after POST and
> > tests for devices on the SCSI chain. But, no matter what setting I use
> > for boot order (SCSI,C,A or C,CDROM,A or what_have_you) the computer
> > intermittantly refuses to attempt to boot off of the SCSI controller. So
> > I'll get a 'INSERT SYSTEM DISK AND PRESS ANY KEY' when it attempts to
> > boot, and if I press a key repeatedly after a while it will somehow catch
> > that the scsi controller wants to boot my primary disk and launch lilo.
>
> Oddly enough, at my work we have precisely the same symptom on a different
> motherboard, different bios, different SCSI controller and probably a
> different kernel.
>
> In our case: Dell Optiplex with BT-958 SCSI controller and 2.0.32.
> Occasionally, the BT-958 will fail to "install" the boot disk into the
> BIOS - although it does detect it.
>
> I mention this only in case there's some remote connection between the
> two phenomena ...
>
------------------------------
From: paul@rasty.ph.unimelb.edu.au (Paul Gortmaker)
Date: Mon, 25 May 1998 04:06:49 +1000 (EST)
Subject: Module related stuff
Hi,
I think this may be a bug in get_module_symbol:
diff -ur linux-pre104/kernel/module.c linux/kernel/module.c
- --- linux-pre104/kernel/module.c Sun May 24 15:09:08 1998
+++ linux/kernel/module.c Sun May 24 20:09:21 1998
@@ -961,7 +961,7 @@
for (mp = module_list; mp; mp = mp->next) {
if (((modname == NULL) || (strcmp(mp->name, modname) == 0)) &&
- - (mp->flags == MOD_RUNNING) && (mp->nsyms > 0)) {
+ (mp->flags & MOD_RUNNING) && (mp->nsyms > 0)) {
for (i = mp->nsyms, sym = mp->syms;
i > 0; --i, ++sym) {
which prevents one from getting/using the module symbols of a module
if any other flags are set. Also, I think the behaviour of the same
function is unclear if CONFIG_MODVERSIONS is enabled. For example, a
test (within a module) for kmod support like:
if (get_module_symbol("", "request_module") == 0) {
printk("%s: module auto-load (kmod) support not present.\n", driver);
printk("%s: parent unable to auto-load daughter module.", driver);
return -ENOSYS;
}
will fail if CONFIG_MODVERSIONS is enabled, but work if it is not
enabled. Since get_module_symbol is currently not used anywhere in
the kernel, I doubt that this has affected anything else but what
I'm working on.
BTW, modules that request "daughter" modules via kmod during their
own initialization works quite well. The only problem is that the
daughter is not marked in use by the parent that loaded it, and so
you can accidentally unload the daughter while the parent is still
using it. Somehow the mod->deps need to be updated to reflect the
parent's dependence on the daughter module when it is loaded, but
I'm not sure of the best way to do this.
Paul.
PS: kerneld (now dead) is still mentioned in MAINTAINERS
------------------------------
From: Peter Svensson <petersv@df.lth.se>
Date: Sun, 24 May 1998 20:11:14 +0200 (MET DST)
Subject: Re: To Bogomips or not to Bogomips?
On Sun, 24 May 1998, Jon Lewis wrote:
> > Is anybody planning on fixing the bug in dmesg so it reads the FULL
> > message buffer rather than just the first 4k of it?
>
> It's not a bug...it's life. The message buffer has to be limited, or it
> opens the kernel up to DoS attacks if the buffer can grow without limit
> and consume all memory. It might be nice if the buffer size were made
> tunable so that on big systems, you can see all the bootup messages before
> the buffer fills.
Sure it is a bug. We are talking about the fact that current dmesg(8)
implementations only copy 4k of the kernel ring buffer, even though it can
be (and usually is?) larger.
Peter
- --
Peter Svensson ! Pgp key available by finger, fingerprint:
<petersv@df.lth.se> ! 8A E9 20 98 C1 FF 43 E3 07 FD B9 0A 80 72 70 AF
- ------------------------------------------------------------------------
Remember, Luke, your source will be with you... always...
------------------------------
From: Myles Uyema <myles@puck.nether.net>
Date: Sun, 24 May 1998 08:13:34 -1000
Subject: 2.1.103 uniprocessor oops
Got an oops the other day when trying to 'make clean' in /usr/src/linux.
/dev/hda5 is mounted at /usr/src. Kernel was built with gcc 2.7.2.3 and
binutils 2.9.1.0.4. I believe this condition also exists in 2.1.pre104
uniprocessor as well.
These kernel messages occurred prior to the OOPS. The problem hasn't
surfaced on SMP-built kernels.
May 22 19:55:43 uyema kernel: EXT2-fs warning (device 03:0a): \
ext2_free_blocks: bit already cleared for block 83510
<<< Continua nel prossimo messaggio >>>
--PAI00195.896102107/wigner.cstc.org--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu