--PAJ00195.896102108/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:50:01 +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
--PAJ00195.896102108/wigner.cstc.org
Content-Type: message/delivery-status
Reporting-MTA: dns; wigner.cstc.org
Arrival-Date: Mon, 25 May 1998 05:50:01 +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:08 +0200
Will-Retry-Until: Sat, 30 May 1998 05:50:01 +0200
--PAJ00195.896102108/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 FAA00530
for <pol@wigner.cstc.org>; Mon, 25 May 1998 05:50:01 +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:50:01 CEST
Message-ID: <294158@bbs.eureka.est.it>
To: Pumilia@mbox.est.it
Date: 25 May 1998 02:59:04 GMT +0100
Subject: linux-kernel-digest V1 #2011
<<< Questo messaggio e' la parte 3 di un precedente messaggio >>>
> > +#elif defined(CONFIG_BRIDGE_MODULE)
> > + if (handle_bridge_hook) (*handle_bridge_hook)(skb,type);
> > #endif
>
> 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.
Funny, I used exact this method for a 2.0.x kernel driver I wrote
(i386/AXP) (hook in net/core/dev.c) and I also (re-)used
"skb->pkt_bridged = IS_BRIDGED" to avoid problems. So loading my module
disables bridging code (and needed bridging compiled in).
I see there no big problem at all, when initializing a hook in init_module
and setting the hook to NULL in cleanup_module.
I like that kinds of hooks, and it doesn't make me nervous at all.
Please give me a simple reason why not to use hooks like this.
But be careful, maybe a reason make me avoid using {,un}register_netdevice,
{add,del}_timer, dynamic proc registration; it's the same game.
- --
ciao -
Stefan
Stefan Traby phone: +43-3133-6107-2
Mitterlasznitzstr. 13 fax: +43-3133-6107-9
8302 Nestelbach mailto://stefan@sime.com
Austria
------------------------------
From: David Woodhouse <Dave@imladris.demon.co.uk>
Date: Sun, 24 May 1998 20:11:24 +0200
Subject: Re: Modularized net bridging PATCH against pre-2.1.104-1
stefan@sime.com said:
> > 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.
> I see there no big problem at all, when initializing a hook in
> init_module and setting the hook to NULL in cleanup_module. I like
> that kinds of hooks, and it doesn't make me nervous at all.
> Please give me a simple reason why not to use hooks like this.
No reason. The hooks are fine. But the hooks aren't put in unless you have
CONFIG_BRIDGE_MODULE defined. It's the practice of only putting the hooks in
when you compile the kernel with modular support that I was questioning.
It means that if you decide to add modular support for something, you still
need to recompile the kernel and reboot.
- ---- ---- ----
David Woodhouse, Robinson College, CB3 9AN, England. (+44) 0976 658355
Dave@imladris.demon.co.uk http://www.imladris.demon.co.uk
finger pgp@dwmw2.robinson.cam.ac.uk for PGP key.
------------------------------
From: Tigran Aivazian <tigran@aivazian.demon.co.uk>
Date: Sun, 24 May 1998 20:38:13 +0100 (BST)
Subject: Security bug in 2.1.103: old style stat(2)
Hello guys,
IN fs/stat.c cp_old_stat() issues warning about old style stat() usage
continuously; this can be used by a malicious person to fill up system
logs.
Just thought would let you know, since /proc/pci and /dev/cua? behave in a
different manner (only one warning until next reboot).
Regards,
Tigran.
------------------------------
From: Shaw Carruthers <shaw@shawc.demon.co.uk>
Date: Sun, 24 May 1998 20:37:25 +0100 (GMT+0100)
Subject: Re: Poor TCP throughput in 2.1.103
On 24 May 1998, Andi Kleen wrote:
>
> Then disable VJ compression on your end (with the -vj option of pppd).
> That should give you a small penalty for small packets (telnet etc.),
> but looks like the cleanest way to me.
>
Yes, that is a good solution as it eliminates the stalls due to vj
compression errors. I get 2500 bps.
But the Ascend is still dropping packets.
Best solution is to use a window of 13140 or less, as the Ascend can
handle that without packet loss. I then get 2800.
- --
Shaw Carruthers - shaw@shawc.demon.co.uk
London SW14 7JW UK
This is not a sig( with homage to Magritte).
------------------------------
From: lmcvoy@dnai.com (Larry McVoy)
Date: Sun, 24 May 1998 12:59:18 -0600
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.
You may have read the discussion, but you missed the point.
: > 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).
Great. So how about you try that same compile on a Linux box & ext2fs
and demonstrate how much slower it is than when you use tmpfs? You keep
harping on tmpfs vs ufs, which is /not/ the same as tmpfs vs ext2fs.
For all practical purposes, Linux ext2fs performance >= Solaris tmpfs
performance.
I'm sorry to keep beating on this, but the question was "shouldn't we
be thinking about tmpfs?" and the answer is "no, we shouldn't" and the
reason is "ext2fs is just as fast, if not faster" and the fact that "tmpfs
is much faster than ufs" has absolutely no bearing on the discussion.
------------------------------
From: "Adam J. Richter" <adam@yggdrasil.com>
Date: Sun, 24 May 1998 13:00:39 -0700
Subject: Re: Modularized x86 math emulation PATCH against pre-2.1.104-1
>So what happens when the system is low on memory (ie less than 100K
>available with kswapd in a frenzy) and FPU is needed? Or is having ~100kB
>free not an issue?
Another 100kB is pushed out to swap putting kswapd in
that much more of a frenzy, which is no worse than the situation
you would have with fpu emulation compiled in.
Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 205
adam@yggdrasil.com \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
------------------------------
From: Itai Nahshon <nahshon@actcom.co.il>
Date: Sun, 24 May 1998 23:56:05 +0300
Subject: OPTi 82C931 broken (was Re: 2.1.103 MSS?)
>> On 21 May 1998, John Goerzen wrote:
>>
>> > I have tried the SB emul -- it works, but is only 8-bit and chokes on
>> > 16-bit stuff, of course.
>>
>> I'm having similar problems w/ an AZT3000 after my upgrading from 2.0.32
>> to 2.0.33. I trying compiling pnp into the kernel, which didn't help at
>> all. I pnpdumped it and uncommented my config and isapnp doesn't choke
>> when it loads, but I get no sound.
>
>I had similar problems with an Opti931 PnP soundcard. To such an extent
>I've now got a genuine SB16. Which works great.
Well, OPTi 82C931 worked fine for me in Linux-2.1.101. In later
kernels things started to break. Some new problems are probably
related to the changes in config files. I'm upto my neck in other
projects but I will look at this as soon as things get stabilized.
Itai
- --
Itai Nahshon nahshon@actcom.co.il
Also nahshon@vnet.ibm.com
------------------------------
From: Thomas Pornin <bip@orion.ens.fr>
Date: Sun, 24 May 1998 22:57:39 +0200
Subject: Re: modules on alpha
In article <lv1af8dov1j.fsf@sundance.stacken.kth.se> you write:
>Does modules work on alpha (2.0.33), and in that case, why does not
>insmod in modules-2.0.0 and modules-2.1.13 contain support for alpha?
modules work (well, almost all modules work). Try modutils-2.1.85.
It seems also that you must apply the "strip -x" command on the modules
produced with a 2.0.33 kernel; at least, that is what I had to do on
my alpha to make them work.
My personnal advice is to switch to a 2.1.x kernel, the 2.1.102 for instance.
Those behave much better than the 2.0.33 on alphas, and modules are clean.
--Thomas Pornin
------------------------------
From: "David B. Rees" <dbr@oto.dyn.ml.org>
Date: Sun, 24 May 1998 14:04:18 -0700 (PDT)
Subject: RE: OPTi 82C931 broken (was Re: 2.1.103 MSS?)
On 24-May-98 Itai Nahshon wrote:
>>I had similar problems with an Opti931 PnP soundcard. To such an extent
>>I've now got a genuine SB16. Which works great.
>
> Well, OPTi 82C931 worked fine for me in Linux-2.1.101. In later
> kernels things started to break. Some new problems are probably
> related to the changes in config files. I'm upto my neck in other
> projects but I will look at this as soon as things get stabilized.
OPTi 82c931 works fine for me in 2.1.102. I haven't tried 2.1.103 yet.
- -Dave
------------------------------
From: aem@netcom.ca
Date: Sun, 24 May 1998 17:45:35 -0400 (EDT)
Subject: Re: About crypt...
> Anybody know where the newest brand of loopback patches are, and whether
> they are slated for mergeing in 2.3?
My modular loop device driver patches and crypto (IDEA and CAST-128)
are still at ftp://fractal.mta.ca/pub/users/aem/crypto/
The last patch I did was for 2.1.98, though it is alpha as it
does not include the kernel deadlock fixes. The last full
beta patch I did was for 2.1.59 (includes deadlock fixes).
I won't release the patch until I get the deadlock fixes into it,
and add some important features (like encryption modes) to the
encryption modules.
- --
Andrew E. Mileski mailto:aem@netcom.ca
------------------------------
From: Gary Lawrence Murphy <garym@maya.dyn.ml.org>
Date: Sun, 24 May 1998 17:51:30 -0400
Subject: Mount problem in 100+: 2 new clues
Two new clues in my tales of woe trying to regain a working
dev kernel!
The story so far:
Since .98 or so (not exactly sure when) my boot sequence would
hang after the statement "mounting local filesystems" ie just
after the fsck checks and before starting any daemons.
the new data:
Commenting out file systems shows that the culprit is the VFAT
disk --- my VFAT system is not a module but compiled into the
kernel. This doesn't solve my problem, though: The boot now
hangs on the hwclock call (to set system time)
I hope this helps someone get closer to this problem --- since
I have upgraded according to the Changes file, I find I cannot
run any kernel after .90 (91-93 at least, as these apparently
have trouble with ppp-2.3.3)
I realize you may need more information about my system, but the
nature of this glitch also suggests you will need something very
specific about my hardware and rather than post the complete
configuration here, please just let me know what you need and I
will suss it out and post it.
I'm having fun. That's the main thing ;)
Gary Lawrence Murphy <garym@who.net> -------- http://visitweb.com/~garym/
TeleDynamics http://visitweb.com/teledynamics/ RR#1 Sauble Beach, Ont CAN
telecenter design -- telework systems -- intranet/extranet consulting
"You don't play what you know; you play what you hear." ----- Miles Davis
------------------------------
From: A Guy Called Tyketto <tyketto@omnilinx.net>
Date: Sun, 24 May 1998 14:57:48 -0700
Subject: Weird(harmless?) IP Masquerade message
Heya, everyone...
I have started to get these constant messages with IP masquerading, as
I have upgraded to IPCHAINS. I don't think the ipchains program itself is the
cause of it, but nevertheless, this message crop up every minute or so:
IP_MASQ:masq_expire delayed: TCP C0A80102:20B2->C3598163:0015 nlocks-1=0
masq.refcnt-1=2 masq.n_control=1
I've traced the message to the call in net/ipv4/ip_masq.c, but I
haven't had the time yet, to delve into it any further.
Currently, I have a 'typical' IP masquerading setup: 1 box doing the
masquerading via PPP, serving the world to another hidden box, through
10baseT.
The message seems harmless enough, as the setup is still working well.
I'll take a further look into things, and see what I can see.
BL.
- --
Brad Littlejohn | Email: tyketto@omnilinx.net
Unix Systems Administrator, | tyketto@acm.unomaha.edu
Web + NewsMaster, BOFH.. Smeghead! :) | http://www.omnilinx.net/~tyketto
PGP: 1024/E9DF4D85 67 6B 33 D0 B9 95 F4 37 4B D1 CE BD 48 B0 06 93
------------------------------
From: Tigran Aivazian <tigran@aivazian.demon.co.uk>
Date: Sun, 24 May 1998 23:36:15 +0100 (BST)
Subject: Minor comments on 2.1.104pre1
Dear Linus and Linux-Kernel,
Here are a few comments on 2.1.104pre1:
1. kmod does not autoload binfmt_aout.
2. fs/proc/array.c still contains initialisation of tsk =
find_task_by_pid(pid) outside as well as inside of read_lock(), the first
being (imho) unnecessary.
3. fs/stat.c cp_old_stat() uses printk() to warn about old style stat()
usage as many times as does the call, the way it is done for old style
/proc/pci and /dev/cua* is different -- hence inconsistency.
4. kernel/fork.c comment at the top still refers to non-existent files
system_call.s and mm/mm.c
Many regards,
Tigran.
------------------------------
From: Tigran Aivazian <tigran@aivazian.demon.co.uk>
Date: Sun, 24 May 1998 23:46:06 +0100 (BST)
Subject: one more comment on 2.1.104pre1...
Hello again,
one more comment to add to my previous ones:
in net/ipv6/af_inet6.c the function cleanup_module() calls
sock_unregister(AF_INET6) instead of sock_unregister(PF_INET6)
in the spirit of the rest of the kernel source.
Thanks,
Tigran.
------------------------------
From: Woody <root@princectrl.dyn.ml.org>
Date: Sun, 24 May 1998 18:53:57 -0500 (EST)
Subject: Obtaining 2.0.34-pre
Sorry I forgot the addy to the ftp to get the pre's for 2.0.34...it was on
Alan's FTP server I thought....ThanX
Woody
Security Administrator
Localline.com
woody@localline.com
------------------------------
From: Bitburn Access Admin Dept <sysadmin@bitburn.org>
Date: Sun, 24 May 1998 17:00:27 -0700 (PDT)
Subject: iproute2 Error.
I have been hanging on the 2.1.97 kernel for a bit and just went to
2.1.103. I use iproute2 to do my routing changes (from a 56kppp to 128k
ISDN on the fly.) But alas iproute2 seems not to work in this kernel
anymore. I nabbed the latest src from ftp.inr.ac.ru:/ip-routing but it
also seems not to work. Here is the error I get:
root@bitgate:/usr/src/linux# ip route change default via 204.202.175.130
cannot open netlink socket: Invalid argument
cannot open rtnetlink
I also get the error for any iproute2 requests:
root@bitgate:/usr/src/linux# ip route
cannot open netlink socket: Invalid argument
cannot open rtnetlink
I checked over my .config and all seems in order.
This is my first post to the list so be kind :)
Thanks much!
- --Eric
------------------------------
From: Dean Gaudet <dgaudet-list-linux-kernel@arctic.org>
Date: Sun, 24 May 1998 17:47:12 -0700 (PDT)
<<< Continua nel prossimo messaggio >>>
--PAJ00195.896102108/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