--PAK00195.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:49:49 +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
--PAK00195.896102108/wigner.cstc.org
Content-Type: message/delivery-status
Reporting-MTA: dns; wigner.cstc.org
Arrival-Date: Mon, 25 May 1998 05:49:49 +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:49:49 +0200
--PAK00195.896102108/wigner.cstc.org
Content-Type: message/rfc822
Content-Transfer-Encoding: 8bit
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 FAA00523
for <pol@wigner.cstc.org>; Mon, 25 May 1998 05:49:49 +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:49 CEST
Message-ID: <294157@bbs.eureka.est.it>
To: Pumilia@mbox.est.it
Date: 25 May 1998 02:59:02 GMT +0100
Subject: linux-kernel-digest V1 #2011
<<< Questo messaggio e' la parte 2 di un precedente messaggio >>>
May 22 19:55:43 uyema kernel: EXT2-fs warning (device 03:0a): \
ext2_free_blocks: bit already cleared for block 83518
May 22 19:55:43 uyema kernel: EXT2-fs warning (device 03:0a): \
ext2_free_blocks: bit already cleared for block 83522
------------------------------
From: Derrik <dpates@kalifornia.com>
Date: Sun, 24 May 1998 11:24:38 -0700 (PDT)
Subject: Re: [SOUND] Aztech Sound Galaxy broken/not supported?
On Sun, 24 May 1998, David Burrows wrote:
> I have managed to get isapnp to activate the card, as I have been
> successfully using the internal plug and play modem to dial into the net.
> After insmodding sound, ad1848.. I try to insmod sgalaxy io=0x220 irq=7
> dma=1 dma2=5 sgbase=0x534, and it fails giving some quite generic error
> which I can't quite remember at the moment (resource busy?) I've tried
> swapping the values of io and sgbase, and at a hunch tried using 0x530
> instead of 0x534, but to no avail..
Have you tried a different IRQ? If you have the parport driver or anything
else that makes use of the parallel port loaded, that may be causing your
troubles. If it supports it, try IRQ 5, 9 or 10 (if those are free). You
may have better luck.
Derrik Pates
dpates@kalifornia.com
dpates@acm.org
------------------------------
From: Shaw Carruthers <shaw@shawc.demon.co.uk>
Date: Sun, 24 May 1998 19:31:15 +0100 (GMT+0100)
Subject: Re: Poor TCP throughput in 2.1.103
On Sun, 24 May 1998, Eric Schenk wrote:
>
> Just to clarify here, am I correct in assuming that in this trace
> you where sending data from the linux box 194.159.255.135 to some
> other box at 158.152.146.90?
>
Sorry, I should have made clear that 194.159.255.135 is the ftp server at
my ISP which is sending to ftp running on my Linux box 158.152.146.90.
- --
Shaw Carruthers - shaw@shawc.demon.co.uk
London SW14 7JW UK
This is not a sig( with homage to Magritte).
------------------------------
From: bytor@logicsouth.com
Date: Sun, 24 May 1998 14:49:19 -0400 (EDT)
Subject: Re: Modularized x86 math emulation PATCH against pre-2.1.104-1
On Sun, 24 May 1998, Adam J. Richter wrote:
> Here is an untested patch that modularizes x86 math emulation.
> It includes kmod support, so that the kernel can be made to automatically
> load the math_emu module when a program starts executing floating point
> instructions, and "kmod -a" will unload the module if no floating point
> code has been run for a while.
>
> There are two significant advantages to the modularization
> of x86 math emulation:
>
> 1. Users of 386's are likely also to have limited RAM
> resources. Under this arrangement, the ~100kB
> used by math emulation is only occupied when a
> floating point program has recently run. At other
> times, the memory is free for other purposes.
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?
+----------------------+----------------------------------------+
| bytor@logicsouth.com | UNIX _is_ user-friendly. It's just not |
| By-Tor@EfNet | ignorant-friendly and idiot-friendly. |
+----------------------+----------------------------------------+
------------------------------
From: Jelle Foks <jelle@flying.demon.nl>
Date: Sun, 24 May 1998 18:54:31 +0000 ( )
Subject: Re: /tmp in swap space
On Fri, 22 May 1998, Jim Wilcoxson wrote:
> Disk space is dirt cheap and getting cheaper all the time. Plus, there
> could be a reliability concern here. If a program goes wild and fills /tmp
> (which just happened to me last week btw), I wouldn't want my machine to
> crash because it couldn't swap.
That's exactly why I asked the question about using the ulimit settings as
disk quota for the filesystem. That way, a process limited to a certain
amount of RAM is equally limited to trashing in /tmp.
Just as we need a way to control /tmp usage now, it would still be
necessary to control usage for the combined /tmp and swap. Ideal would be
a filesystem that is optimized for temporary storage and that takes ulimit
settings into account.
Currently, processes get an 'out of memory' or 'out of disc space' when
swap or /tmp is full. It may be possible to design a set of rules for
killing and suspending processes when /tmp or swap runs out. With these
rules, it may be possible, in case of /tmp or swap filling or trashing, to
find and kill just the process that is trashing (-hmm, wouldn't that be
possible just for swap in the current kernel?-).
Currently, if one program fills /tmp and/or swap, then other programs that
try to use additional /tmp and/or swap fail (exit, get killed,etc.). I
dont think it is impossible to counteract some trashing of /tmp. For
example, in addition to limiting the amount of space per process, if a
process creates files in /tmp, and then does not exit normally (gets
killed as a result of an error (segmentation fault)), its files in /tmp
could be removed automatically. This may even be controllable by the
program itself, telling the kernel which return values from 'exit(n)' mean
that the temporary files should or should not be kept, or telling the
kernel the maximum lifetime of its /tmp files (with lifetime in
hh:mm:ss, but maybe also related to other (child?) processes still
running). Probably, most of this kind of space usage control does not
have to be done in the kernel, but could be done in userspace. However,
the daemon would need special information from the kernel.
The basic version of such space control rules could for example return
'out of disc space' to processes before all space is used, disallowing a
process which fills /tmp to also fill all swap.
> Wouldn't it be difficult to figure out disk space requirements for this
> configuration? It seems like if I knew that at times I needed 100MB for
> /tmp, and 100MB for swap, I'd be forced into making sure there was 200MB
> available in /tmp if the two shared that area.
Determining the amount of space needed for the integrated /tmp and
swap would be done the same way you now determine the amount of swap you
need and the amount of /tmp space you need. I think this is mostly done by
using experience from the past, by examining the amount of used space in a
similar configuration, etc. The difference is that, if /tmp and swap are
integrated you only have to determing one amount for both, instead of two
separately. It would seem to me that it becomes easier with /tmp and swap
integrated (Yes of course, the first time when you change to integrated
/tmp and swap, your best guess will be to add the amounts for /tmp and
swap).
The reason I thought about the possibility to use the same disk
space for /tmp and swap is not the saving of some drive space. The reason
is that both the swap and /tmp contain the same type of data: temporary
storage. Why have two different kinds of temporary storage if you can use
a single integrated solution?
If there are enough reasons to not integrate /tmp and swap, then I
still think that there are some good reasons to design a special fileystem
just for /tmp (that only already looks like a lot of work to me). In that
case, I would like to ask people for pointers (preferrable on the net)
about publications about filesystem types and their relative advantages
(in order to find a good candidate for /tmp).
> Jim
>
>
> At 06:43 PM 5/22/98 +0000, Jelle Foks wrote:
> >Hello,
> >
> >I recently saw that Solaris shares the drive space for swap and for the
> >files in the /tmp directory (/tmp is mounted from the swap partition as
> >filesystem type swapfs).
> >
> >Has anybody thought about this? Has this already been done for linux in
> >some patch somewhere? Are there solid reasons not to do this? would a
> >significant performance impact be unavoidable? Would it be difficult to
> >use the ulimit settings for quota on the '/tmp-filesystem'?=20
> >
> >Greetings,
> >
> >Jelle.
------------------------------
From: Andrea Arcangeli <arcangeli@mbox.queen.it>
Date: Sun, 24 May 1998 20:52:04 +0200 (CEST)
Subject: lp patch
I forgot this in my latest lp diff. Nobody noticed a stall since it' s
needed in rare conditions not easily reproducible. It' s against my latest
diff (that should be in pre-104 just now).
- --- linux/drivers/char/lp.c 1998/05/17 11:51:36 1.44
+++ linux/drivers/char/lp.c 1998/05/24 17:31:39
@@ -168,6 +168,7 @@
register unsigned long int timeslip = (jiffies - dev->time);
if ((timeslip > dev->timeslice) && (dev->port->waithead != NULL)) {
lp_parport_release(minor);
+ lp_table[minor].irq_missed = 1;
schedule ();
lp_parport_claim(minor);
} else
BTW, today one guy said me that he applyed pre-104 and lp continue to
stall for him (since he said me that, I supposed my lp latest diff is just
in pre-104), so frustrated I find out an HP Deskjet 600 (the precise one
of the guy) to test hard the workaround with the buggy hardware myself and
here works fine as expected (and just reported from the helpful
alpha-testers). The old lp stall under the same conditions with the same
printer. I have no idea of what could be wrong for him but sure his
problem is not the HP hardware bug I workarounded.
Andrea[s] Arcangeli
------------------------------
From: David Woodhouse <Dave@imladris.demon.co.uk>
Date: Sun, 24 May 1998 19:53:49 +0200
Subject: Re: Tyan 1662D new Award BIOS bugs
maynard@jmg.com said:
>
> 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_. ;-)
In general, Tyan users are already aware that Tyan aren't at all interested in
making their BIOS either compliant or fully functional. I've attempted to talk
to Tyan about such matters before, but even though I did manage to extract a
"what's all this about" mail from them after three or four mails and a
telephone call, I've heard nothing since. Not even an acknowledgement of my
explanations.
Basically, Tyan offer no support for their boards, and their BIOS is shite.
They seem to have no interest in fixing this. There is a simple answer:
DO NOT BUY TYAN HARDWARE.
Last time I looked at alt.comp.periphs.mainboard.tyan it was mostly full of
posts from people complaining about Tyan's lack of support, and trying to put
together a Class Action¹ against them. If you've already made the mistake of
buying Tyan hardware, and it's too late to send it back, then perhaps you
could try joining up with them. Good luck.
As for the "OpenBIOS" project, it was discussed at length, but we have yet to
see any code, and there have only been 7 postings to the list since the 11th
of April. Take a look at http://www.linkscape.net/openbios/ if you're
interested.
¹ - Whatever one of them is. I have no knowledge of the US legal system, and I
like it that way :)
- ---- ---- ----
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.
- ---- ---- ----
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: Richard Henderson <rth@dot.cygnus.com>
Date: Sun, 24 May 1998 11:57:04 -0700
Subject: Re: Module related stuff
On Mon, May 25, 1998 at 04:06:49AM +1000, Paul Gortmaker wrote:
> - (mp->flags == MOD_RUNNING) && (mp->nsyms > 0)) {
> + (mp->flags & MOD_RUNNING) && (mp->nsyms > 0)) {
Actually, it should be more like the test in qm_symbols:
if ((mod->flags & (MOD_RUNNING | MOD_DELETED)) != MOD_RUNNING)
well, the inverse of that.
And come to think of it, I have no idea why there exists a
get_module_symbol. I think perhaps it has been there for a
long time and I didn't kill it with the rewrite early in the
2.1 series.
> Also, I think the behaviour of the same
> function is unclear if CONFIG_MODVERSIONS is enabled.
Yep. You could perhaps use the string comparison test from modutils
when it is throwing away symbol versioning:
/* String comparison for non-co-versioned kernel and module. */
static int
ncv_strcmp(const char *a, const char *b)
{
size_t alen = strlen(a), blen = strlen(b);
if (blen == alen + 10 && b[alen] == '_' && b[alen+1] == 'R')
return strncmp(a, b, alen);
else if (alen == blen + 10 && a[blen] == '_' && a[blen+1] == 'R')
return strncmp(a, b, blen);
else
return strcmp(a, b);
}
> 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.
You might consider not using it at all. What are you up to anyway?
> 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.
No, you need to handle this yourself, because mod->deps only describe
symbol dependancies, not usage. So you must mark the daughter in use
with MOD_INC_USE_COUNT.
Without knowing exactly what you are up to, I would recommend an
interface like the following:
parent exports:
struct my_child {
struct my_child *next, *prev;
struct module *the_child;
void (*foo)();
int (*bar)();
int etc;
};
void register_child (struct my_child *);
child does:
static struct my_child {
0, 0, &__this_module,
child_foo, child_bar
} me;
void init_module(void) {
register_child (&me);
}
void cleanup_module(void) {
unregister_child (&me);
}
Now the parent can just request the module as normal and the child
gives you all the information you might have previously found with
get_module_symbol. The parent protects the child against garbage
collection with __MOD_INC_USE_COUNT (ptr->the_child).
This is similar to the way the scsi subsystem treats its modules.
r~
------------------------------
From: Stefan Traby <stefan@sime.com>
Date: Sun, 24 May 1998 21:04:17 +0200
Subject: Re: Modularized net bridging PATCH against pre-2.1.104-1
Hi David !
<<< Continua nel prossimo messaggio >>>
--PAK00195.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