Warning: could not send message for past 4 hours

Mail Delivery Subsystem (MAILER-DAEMON@mbox.est.it)
Mon, 25 May 1998 15:15:07 +0200


This is a MIME-encapsulated message

--PAH00195.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:50:29 +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

--PAH00195.896102107/wigner.cstc.org
Content-Type: message/delivery-status

Reporting-MTA: dns; wigner.cstc.org
Arrival-Date: Mon, 25 May 1998 05:50:29 +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:50:29 +0200

--PAH00195.896102107/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 FAA00554
for <pol@wigner.cstc.org>; Mon, 25 May 1998 05:50:29 +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:29 CEST
Message-ID: <294159@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 4 di un precedente messaggio >>>

Subject: Re: 2.1.102 and APM -- is the patch correct?

On Fri, 15 May 1998, C. Scott Ananian wrote:

> Hmm. We can't restore the top 32-bits of the cycle counter, can we...

But why should it matter? Can't we just guarantee the APM code is the
first to get control after a resume and have it figure out what the new
"epoch" is by reinitializing things?

> <tangent>
> APM 1.2 implemented in the kernel, though. ;-) ] I had gotten reports that
> the BSD apm code worked in cases where the linux code didn't

The main difference I recall between the BSD and linux APM implementations
is that the BSD implementation is synchronous -- it processes one event at
a time, and doesn't queue up events like the linux code does.

At any rate this week I had my tp560 refuse to suspend for me... even with
the patch that I wrote ages ago to fix that. Something else is missing,
dunno what yet though.

I wonder, I wonder if windows uses the 32-bit protected mode interface,
the 16-bit protected mode interface, or the real mode interface to the APM
bios ... Hmm! Wild guess: the 16-bit interfaces are well debugged
because that's what win95 uses (NT 3/4 don't use APM AFAIK), but the
32-bit interface is lacking.

Dean

------------------------------

From: "Adam J. Richter" <adam@yggdrasil.com>
Date: Sun, 24 May 1998 17:06:44 -0700
Subject: Re: Minor comments on 2.1.104pre1

In article <Pine.LNX.3.96.980524233051.677B-100000@perseo.homenet> you write:
>Dear Linus and Linux-Kernel,
>
>Here are a few comments on 2.1.104pre1:
>
>1. kmod does not autoload binfmt_aout.

It works fine for me under 2.1.104pre1. Check that your
/etc/conf.modules properly aliases binfmt-0064 to binfmt_aout.

------------------------------

From: Phil's Kernel Account <kernel@eiterra.nls.net>
Date: Sun, 24 May 1998 20:10:55 -0400 (EDT)
Subject: Re: New Cyrix patch for 2.0.33

On Sun, 24 May 1998, [ISO-8859-1] André Derrick Balsa wrote:

#Hello Alan,

Hey! We're getting to know eachother pretty good! :)

#Alan Cox wrote:
#....
#> No the xor/sahf/movb thing passes for some PII's (Im beginning to wonder
#> if this is a conspiracy) - Intel a) now pass the divide check and b)
#> happen to put a very critical BX register at 0x22/0x23 - basically
#> the cyrix test turns off the bus arbitrators
#OK, I basically followed the algorithm that you outlined in another
#email:
#
#if has cpuid
# do cpuid
#else
# if cyrix 6x86(L)
# turn on cpuid/slop
# else
# do the 486/386 probe
#endif

Which is wrong. At least now, thanks to Intel's "ingenuity." *snort*
Apparently, the BX chipset was DESIGNED to behave like that, to inform the
computers that it's a "Genuine Intel" chipset. As if I gave a flying fsck;
the box I type this on is a VIA VXpro+, and my real workstation is
KR-859CF based. I don't want Intel. Anyways, back on topic. :)

The correct method at this point would be this...

turn on cpuid
if it works
if vendor == cyrix, amd, or centaur
do not probe for BX
else
probe 486/386
endif

This *WILL* fix any of these *STUPID* BX 'features' that break the
checking for other vendors CPUs. My only problem right now is actually
finding the time to hack together a patch against 2.0.33 and 2.1.103, so
we can take care of all of that.

#I also had to change a small detail in setup.c, so I am sending you the
#complete patch against a clean 2.0.33. It has:
#a) Correct identification of Cyrix 6x86(Classic, L and MX) CPU.

AFAIK, the only problem is with the Cx6x86 and Cx6x86L, which both have
cpuid disabled by default. Cx6x86MX and mII have shown no problems,
detecting correctly every time.

#b) Works around the oops in do_fast_gettimeoffset(). A _very_ neat
#time.c patch is in the works by C. Scott Ananian (cananian), but
#meanwhile a workaround is still better than an oops, IMHO.

Agreed entirely. :)

#c) Correctly identifies 6x86 steppings.

Now THAT is a feat. };)

#d) Does not clobber the BX chipset register.

Right now, that'll make do. As SOON as I can find the time to put together
a nice neat little BX fix, I will happily share.

#e) Correctly sets up the SLOP bit for 6x86(Classic, L) CPUs.

SLOP bit hasn't been a problem here. But, as always, YMMV. :)

#f) What else? Makes good coffee, shines your shoes, etc... :-)

iam:root @eiterra:/root# echo "brew" >> /dev/mr.coffee
;)

#BTW I have been told that the new Cyrix MII CPUs have the "Coma bug"
#fixed. More info on this as soon as I can get a part for tests.

Consider this confirmed. The mII *IS* a Cx6x86MX core, but with some MAJOR
changes. Among them includes the fixing of the Coma bug, as well as some
pretty big updates to VSPM, and the AEU. Can we PLEASE use VSPM actively
now? I *LIKE* the idea of addressing memory in 4G blocks. :)

- -Phil R. Jaenke (kernel@nls.net / prj@nls.net)
TheGuyInCharge(tm), Ketyra Designs - We get paid to break stuff :)
Linux pkrea.ketyra.INT 2.0.33 #15 Sat Apr 18 00:40:21 EDT 1998 i586
Linux eiterra.nls.net 2.1.98 #15 Fri May 1 18:21:00 EDT 1998 i586
- - Linus says for 'brave people only.' I say 'keep a backup.' - :)
! I reserve the right to bill spammers for my time and disk space !

------------------------------

From: Michael Elizabeth Chastain <mec@shout.net>
Date: Sun, 24 May 1998 19:19:08 -0500
Subject: Re: Modularized x86 math emulation PATCH against pre-2.1.104-1

Hi Adam,

In arch/i386/config.in, your patch redefines the default processor type
from Pentium to 386 -- this looks gratuitous.

I'm more concerned about the use of CONFIG_MATH_EMULATION_MODULE in
arch/i386/kernel/traps.c. I think that math_emulate_hook is fine.
But I think that it's bad to make the resident kernel be different
depending on whether or not a particular module is compiled. So I
recommend taking out these tests and compiling in math_emulate_hook
and the new code in math_emulate unconditionally.

Unfortunately there's a lot more of this stuff in your patch ...
I really hate it when the resident kernel changes depending on whether
something is a module or not included. Maybe that's just me though.

Regards,

Michael Chastain
<mailto:mec@shout.net>
"love without fear"

------------------------------

From: Trevor Johnson <trevor@jpj.net>
Date: Sun, 24 May 1998 17:32:21 -0700 (PDT)
Subject: Re: 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

ftp://ftp.uk.linux.org/pub/linux/alan/2.0.34pre/
ftp://ftp.psychosis.com/pub/linux/2.0.34pre/
___
Trevor Johnson

------------------------------

From: scratch <scratch@ace.ulyssis.student.kuleuven.ac.be>
Date: Mon, 25 May 1998 03:29:31 +0200 (CEST)
Subject: make modules_install behaviour for sound modules

I hope i won't shoot anyone to the head with this question/remark, I am
just eager to know:

Why is it that "make modules_install" throws some sound modules in the
/lib/modules/2.xx.xxx/misc dir, and others in the sound dir? What's the
reason behind this, and why are some of them in both dirs?

intra:/lib/modules/2.1.103/sound# ls
ad1848.o cs4232.o soundcore.o uart401.o
intra:/lib/modules/2.1.103/misc# ls
ad1848.o cs4232.o mpu401.o parport_pc.o sound.o
adlib_card.o lp.o parport.o sb.o uart401.o

Also, I'm experiencing warning msgs at boot, running 2.1.103 (Alan's diff
of the day applied), concerning missing symbols:

#
# Sound
#
CONFIG_SOUND=m
CONFIG_SOUND_CS4232=m
# (all other CONFIG_SOUND_* are not set

intra:/lib/modules/2.1.103# depmod -a
/lib/modules/2.1.103/misc/sb.o: unresolved symbol(s)
/lib/modules/2.1.103/misc/mpu401.o: unresolved symbol(s)
/lib/modules/2.1.103/misc/adlib_card.o: unresolved symbol(s)

- -- Nico, Leuven, Belgium

------------------------------

From: Daniel Fraga <chapolin@dns001.itanet.com.br>
Date: Sun, 24 May 1998 22:41:12 -0300 (EST)
Subject: make menuconfig problem

When I try "make menuconfig" with the last 2.1.103 I get:

There seems to be a problem with the lxdialog companion utility which is
built prior to running Menuconfig. Usually this is an indicator that you
have upgraded/downgraded your ncurses libraries and did not remove the
old ncurses header file(s) in /usr/include or /usr/include/ncurses.

It is VERY important that you have only one set of ncurses header files
and that those files are properly version matched to the ncurses libraries
installed on your machine.

You may also need to rebuild lxdialog. This can be done by moving to
the /usr/src/linux/scripts/lxdialog directory and issuing the
"make clean all" command.

If you have verified that your ncurses install is correct, you may email
the maintainer <mec@shout.net> or post a message to
<linux-kernel@vger.rutgers.edu> for additional assistance.

But I removed completely ncurses adn reinstalled it again and it
didn't work :(

So I tried "make config" and it was fine. With "make xconfig" it was
working. But after I updated to oss/free 3.8s9 i tgives:

bash-2.01# make xconfig
rm -f include/asm
( cd include ; ln -sf asm-i386 asm)
make -C scripts kconfig.tk
make[1]: Entering directory `/usr/src/linux/scripts'
cat header.tk >> ./kconfig.tk./tkparse < ../arch/i386/config.in >>
kconfig.tk
unknown command=$MAKE -C drivers/sound config || exit
1(drivers/sound/Config.in 11)
echo "set defaults \"arch/i386/defconfig\"" >> kconfig.tk
cat tail.tk >> kconfig.tk
chmod 755 kconfig.tk
make[1]: Leaving directory `/usr/src/linux/scripts'
wish -f scripts/kconfig.tk
can't read "SBC_BASE": no such variable
while executing
"set AEDSP16_BASE $SBC_BASE..."
(file "scripts/kconfig.tk" line 4335)
make: *** [xconfig] Error 1

Fortunately with "make menuconfig" in the xterm it will work!

Thank you!

------------------------------

From: David Woodhouse <Dave@imladris.demon.co.uk>
Date: Mon, 25 May 1998 02:44:18 +0200
Subject: Re: Modularized x86 math emulation PATCH against pre-2.1.104-1

mec@shout.net said:
> Unfortunately there's a lot more of this stuff in your patch ... I
> really hate it when the resident kernel changes depending on whether
> something is a module or not included. Maybe that's just me though.

Nope. Not just you. I'd already picked up on it in his other patch.

I've been looking at how to avoid the same kind of thing in Michael Beck's PC
Speaker driver, so we can try to get it into early 2.3

It already happens in a few places in the kernel, but IMHO it's best avoided
if possible. Unless the hooks are in a particularly critical path, they should
be left in place regardless of whether the module is configured. They're
hardly heavyweight.

Sorry, Adam, we're not picking on you, honest. :) It happens in a lot of other
places, too. I've included a list of the offending config options - the full
list of files was a bit big.

What reason is there in each case for not turning '#ifdef CONFIG_xxx_MODULE' to
'#ifndef CONFIG_xxx', and just removing the conditions altogether on code
marked '#if defined(CONFIG_xxx) || defined(CONFIG_xxx_MODULE)'

If it were my decision, which it isn't, then about the only excuse I'd accept
would be "It's in the networking/syscall critical path."

Otherwise, do we get to #ifdef out the register_netdev and register_chrdev
mechanisms when the user doesn't configure any modules of the relevant type?
That'd save _lots_ of space and time.

CONFIG_6PACK_MODULE
CONFIG_ATALK_MODULE
CONFIG_ATARI_SLM_MODULE
CONFIG_AWE32_SYNTH_MODULE
CONFIG_AX25_MODULE
CONFIG_BINFMT_ELF32_MODULE
CONFIG_BLK_DEV_HD_MODULE
CONFIG_BLK_DEV_IDE_MODULE
CONFIG_DLCI_MODULE
CONFIG_FC4_SOC_MODULE
CONFIG_IPDDP_MODULE
CONFIG_IPV6_MODULE
CONFIG_IPX_MODULE
CONFIG_LAPB_MODULE
CONFIG_LLC_MODULE
CONFIG_MATHEMU_MODULE
CONFIG_MIPS_FPE_MODULE
CONFIG_NETLINK_DEV_MODULE
CONFIG_NETROM_MODULE
CONFIG_NFSD_MODULE
CONFIG_PACKET_MODULE
CONFIG_PARPORT_ARC_MODULE
CONFIG_PARPORT_AX_MODULE
CONFIG_PARPORT_MODULE
CONFIG_PARPORT_PC_MODULE
CONFIG_PCSP_MODULE
CONFIG_PNP_PARPORT_MODULE
CONFIG_ROSE_MODULE
CONFIG_SHAPER_MODULE
CONFIG_SOLARIS_EMUL_MODULE
CONFIG_SPX_MODULE
CONFIG_SUN_OPENPROMFS_MODULE
CONFIG_X25_MODULE

- ---- ---- ----
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: shields@crosslink.net (Michael Shields)
Date: 25 May 1998 01:49:36 +0000
Subject: Re: PATCH: signals security

In article <199805220636.CAA27490@jupiter.cs.uml.edu>,
"Albert D. Cahalan" <acahalan@cs.uml.edu> wrote:
> That might be a job for Mandatory Access Control.
> (why is that always capitalized?)

That's how the Orange Book did it.
- --
Shields, CrossLink.

------------------------------

End of linux-kernel-digest V1 #2011
***********************************

To subscribe to linux-kernel-digest, send the command:

subscribe linux-kernel-digest

in the body of a message to "Majordomo@vger.rutgers.edu". If you want
to subscribe something other than the account the mail is coming from,
such as a local redistribution list, then append that address to the
"subscribe" command; for example, to subscribe "local-linux-kernel":

subscribe linux-kernel-digest local-linux-kernel@your.domain.net

A non-digest (direct mail) version of this list is also available; to
subscribe to that instead, replace all instances of "linux-kernel-digest"
in the commands above with "linux-kernel".

--PAH00195.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