--FAF00201.896068177/wigner.cstc.org
**********************************************
** THIS IS A WARNING MESSAGE ONLY **
** YOU DO NOT NEED TO RESEND YOUR MESSAGE **
**********************************************
The original message was received at Sun, 24 May 1998 21:12:58 +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 -----
"|exec /usr/lib/mailagent/filter >> /home/pol/var/log/mailagent.bak 2>&1"... Deferred
Warning: message still undelivered after 4 hours
Will keep trying until message is 5 days old
--FAF00201.896068177/wigner.cstc.org
Content-Type: message/delivery-status
Reporting-MTA: dns; wigner.cstc.org
Arrival-Date: Sun, 24 May 1998 21:12:58 +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.2.0
Last-Attempt-Date: Mon, 25 May 1998 05:49:37 +0200
Will-Retry-Until: Fri, 29 May 1998 21:12:58 +0200
--FAF00201.896068177/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 VAA03616
for <pol@wigner.cstc.org>; Sun, 24 May 1998 21:12:58 +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); Sun, 24 May 1998 21:12:58 CEST
Message-ID: <294146@bbs.eureka.est.it>
To: Pumilia@mbox.est.it
Date: 24 May 1998 18:43:18 GMT +0100
Subject: linux-kernel-digest V1 #2010
<<< Questo messaggio e' la parte 4 di un precedente messaggio >>>
May 23 22:54:05 ferret kernel: Code: ff d0 83 c4 18 85 c0 7d 0d f7 d8 c6 43 63 00 8b 4c 24 1c 89
May 23 22:54:05 ferret kernel: Aiee, killing interrupt handler
May 23 22:54:05 ferret kernel: general protection: 0000
May 23 22:54:05 ferret kernel: CPU: 0
May 23 22:54:05 ferret kernel: EIP: 0010:[ip_send_room+258/288]
May 23 22:54:05 ferret kernel: EFLAGS: 00010246
May 23 22:54:05 ferret kernel: eax: 681d9c51 ebx: 03367098 ecx: 039e6018 edx: 00000014
May 23 22:54:05 ferret kernel: esi: 039e6018 edi: 039e6018 ebp: 1682bfa8 esp: 01912e84
May 23 22:54:05 ferret kernel: ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018
May 23 22:54:05 ferret kernel: Process in.ftpd (pid: 27769, process nr: 65, stackpage=01912000)
May 23 22:54:05 ferret kernel: Stack: 03367098 039e6018 00000800 00000000 00000000 00000014 027f2318 03367098
May 23 22:54:05 ferret kernel: cc8a01a3 1682bfa8 00143cf0 027f2318 03367098 fe8a01a3 00000014 039e6018
May 23 22:54:05 ferret kernel: cc8a01a3 03367098 02032018 01912f2c 02032190 02030407 00000000 1682bfa8
May 23 22:54:05 ferret kernel: Call Trace: [ip_build_header+384/752] [tcp_send_fin+161/688] [tcp_close+292/536] [inet_release+97/108] [sock_release+92/156] [sock_close+37/44] [__fput+28/64]
May 23 22:54:05 ferret kernel: [close_fp+76/92] [sys_close+68/80] [system_call+85/124]
May 23 22:54:05 ferret kernel: Code: ff d0 83 c4 18 85 c0 7d 0d f7 d8 c6 43 63 00 8b 4c 24 1c 89
------------------------------
From: "J. Maynard Gelinas" <maynard@jmg.com>
Date: Sun, 24 May 1998 11:54:44 -0400 (EDT)
Subject: Tyan 1662D new Award BIOS bugs
Hi folks,
I have a Tyan 1662D motherboard with two PPro-180's. After
hearing that Award released a new BIOS through Tyan I went to the download
site and immediately grabbed a copy. [1] It's got support for the new
zip/ls120 MB floppy drives, UDMA33 HDD, and 'Oxygen' 3D video card
support, but - most importantly - it has support to boot off of CDROMs
(which my previous BIOS lacked, and is the feature I most wanted).
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.
This rarely happens on first try, however, and of course this never
happened with the previous BIOS. As you can guess, this makes rebooting
my computer unattended an impossability... I'm seriously considering
moving back to my previous BIOS if this continues unsolved.
So, I'm wondering if others are seeing the same symptoms, whether
you have an NCR based SCSI controller, or anything else. I'd like to
narrow down the problem to either _my_ SCSI controller, or see if it's a
general problem with the new BIOS. Finally, if you happen to have seen
this problem and have _SOLVED_ it... well, you know I'd just _love_ to
hear from you!
Thanks for your time,
J. Maynard Gelinas
[1] see: http://www.tyan.com/html/body_s166x_bios.html
------------------------------
From: Shaw Carruthers <shaw@shawc.demon.co.uk>
Date: Sun, 24 May 1998 16:33:03 +0100 (GMT+0100)
Subject: Re: Poor TCP throughput in 2.1.103
On Sun, 24 May 1998 ak@muc.de wrote:
>
> One thing you could try, maybe it helps: get new net-tools and do
> (replacing ppp0 with your ppp device)
>
> /sbin/ifconfig ppp0 txqueuelen 3
>
Sorry that doesn't help, as I am still advertising a receive window of
16060, which makes the Ascend fire of a string of packets and then stall
when I don't ack them.
--
Shaw Carruthers - shaw@shawc.demon.co.uk
London SW14 7JW UK
This is not a sig( with homage to Magritte).
------------------------------
From: peloy@ven.ra.rockwell.com
Date: 23 May 1998 13:17:43 GMT
Subject: Re: smbfs in 2.1.x
Hi Dave,
David Woodhouse <Dave@imladris.demon.co.uk> wrote:
> I was asked earlier this evening about smbfs in recent 2.1 kernels, and my
> response was basically "RTFM".
>
> However, I don't think I was being fair. It seems that nobody's actually
> _written_ the proverbial FM yet :(
>
> Would someone like to rewrite Documentation/filesystems/smbfs.txt and add the
> 'latest version required' entry in Documentation/Changes?
As far as I know Documentation/filesystems/smbfs.txt is up to date. It
says that the smbfs utilities needed are part of the samba package (>
1.9.18). It also documents the switches that can be passed to the
mount command of smbmount and discusses the problems with Windows 95
boxes.
Documentation/Changes does not mention anything about smbfs and that
can be worked out, as you say.
> While you're at it, tell me what needs doing, and I'll put together some RPMS
> if there aren't any already.
I've put together a Debian package for these smbfs utilities. It's
called smbfsx since package smbfs has the userland utilities for 2.0.x
kernels. The package is part of the upcoming Debian 2.0 (Hamm)
release.
> I originally left smbfs alone because I wasn't using it at the time, but I
> think the time has come for it to be tidied up.
I don't have any problems with smbfs and Windows NT. However, last
time I checked (about a month or so) smbfs was not working properly
with Windows 95 boxes. I'll check it out again.
Bye for now.
E.-
- --
Eloy A. Paris
Information Technology Department
Rockwell Automation Venezuela
Telephone: +58-2-9432311 Fax: +58-2-9431645
------------------------------
From: "Grant R. Guenther" <grant@torque.net>
Date: Sun, 24 May 1998 11:36:10 -0400 (EDT)
Subject: Re: Tyan 1662D new Award BIOS bugs
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 ...
- --------------------------------------------------------------------------
Grant R. Guenther grant@torque.net
- --------------------------------------------------------------------------
------------------------------
From: Riley Williams <rhw@ps.cus.umist.ac.uk>
Date: Sun, 24 May 1998 16:53:16 +0100 (BST)
Subject: Re: To Bogomips or not to Bogomips?
Hi there.
>> Bogomips will still be reported every time at kernel boot time. If
>> anybody wants to check it, just do "dmesg".
> 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?
Best wishes from Riley.
------------------------------
From: "A.N.Kuznetsov" <kuznet@ms2.inr.ac.ru>
Date: Sun, 24 May 1998 19:53:50 +0400 (MSD)
Subject: Re: 2.1.102: ipchains: REJECT does only DENY - network gurus please
Hello!
> It actually fixes two bugs: net_unreach was never send because of a
> missing "-" and it allows sending ICMPs in the firewall checks when there
> is no route. I replaced the unused RTCF_LOG flag with RTCF_BADROUTE.
I beg pardon for silence, I was absent for this week.
Diagnosis is not ready, but it looks as bug.
Actually, such kind of routes should not have RTCF_LOCAL set.
About RTCF_LOG: it is dead, I killed it but forgot to remove
the last reference. RTCF_BADROUTE trick looks OK, but I do not think
that it is necessary. I'll look tomorrow.
Alexey
------------------------------
From: "Adam J. Richter" <adam@yggdrasil.com>
Date: Sun, 24 May 1998 09:16:35 -0700
Subject: Re: Modularized net bridging PATCH against pre-2.1.104-1
>> +#elif defined(CONFIG_BRIDGE_MODULE)
>> + if (handle_bridge_hook) (*handle_bridge_hook)(skb,type);
>> #endif
>Is this kind of hook permitted?
It seems to be fairly common. For convenience, I actually
started by copying similar lines from the dlci module support
code in the same file.
That said, it might make sense to develop some kind
of standard register_ioctl_handler() interface, because those
additions seem fairly common. In general, I would agree that
a register_foo_handler() interface is better in cases where
multiple modules would be likely to connect, since that might
eliminate some special purpose code from the kernel and would
allow that kernel interface to compile without knowing whether
or not CONFIG_FOO_MODULE is defined. On the hand, for interfaces
that seem applicable to only one module or that are being
developed, hook variables keep the kernel smaller than it would
be with a register_foo_handler() function for every interface
that is used by only one module.
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: Soruk of Vulcan <soruk@Eridani.Demon.CO.UK>
Date: Sun, 24 May 1998 17:22:06 +0100 (BST)
Subject: 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.
Any soundcard which claims SB emulation is emulating SBPro, which is only
knows about 8-bit sound. Getting 16-bit sound out of such a card in SB
Emulation is like trying to put a live cow in a mincing machine and
getting a green leaf salad out the other end. It won't work.
I tried using MSS... but it was never able to pick up the IRQ. Knowing my
luck the IRQ fell out the back of the MIDI port on to the carpet on which
my computer is sitting. Needless to say, though, that didn't work either.
- -- Soruk
#include <sigfile.h> [MM1CNV] http://www.eridani.demon.co.uk
------------------------------
From: ak@muc.de
Date: Sun, 24 May 1998 18:22:47 +0200
Subject: Re: 2.1.102: ipchains: REJECT does only DENY - network gurus please
On Sun, May 24, 1998 at 05:53:50PM +0200, A.N.Kuznetsov wrote:
Hallo Alexey,
Good that you are back!
> > It actually fixes two bugs: net_unreach was never send because of a
> > missing "-" and it allows sending ICMPs in the firewall checks when there
> > is no route. I replaced the unused RTCF_LOG flag with RTCF_BADROUTE.
>
> I beg pardon for silence, I was absent for this week.
>
> Diagnosis is not ready, but it looks as bug.
> Actually, such kind of routes should not have RTCF_LOCAL set.
>
> About RTCF_LOG: it is dead, I killed it but forgot to remove
> the last reference. RTCF_BADROUTE trick looks OK, but I do not think
> that it is necessary. I'll look tomorrow.
Ok. I think I fixed the worst problem with the "-" fix in ip_route_input_slow
[dst.error was initialised with the negated errno, but ip_error expected it
positive so it never caused an ICMP]. That is already on vger.
What remains is that there is no rate limitation for network unreachable
ICMPs. This is actually my fault, because I removed Martin Mares' ICMP
rate limiter and replaced it with a dst entry based mechanism [your original
objections were correct]. One possible fix would be to keep a small cache
of the "anonymous" dst_entries generated by no_route. Do you think that
is sufficient, workable, or do you have a better idea, or is it required
to resurrect Martin's code? I personally would prefer a dst_entry based
mechanism over a separate one.
- -Andi
P.S.:
It seems CONFIG_RTNL_OLD_IFINFO does not compile with CONFIG_NET_CLS_ROUTE.
I'm not sure what the correct fix it, but it would be nice if that could
work.
------------------------------
From: Andi Kleen <ak@muc.de>
Date: 24 May 1998 17:26:20 +0200
Subject: Re: Poor TCP throughput in 2.1.103
Shaw Carruthers <shaw@shawc.demon.co.uk> writes:
> On Sun, 24 May 1998 ak@muc.de wrote:
>
> >
> > One thing you could try, maybe it helps: get new net-tools and do
> > (replacing ppp0 with your ppp device)
> >
> > /sbin/ifconfig ppp0 txqueuelen 3
> >
>
> Sorry that doesn't help, as I am still advertising a receive window of
> 16060, which makes the Ascend fire of a string of packets and then stall
> when I don't ack them.
It was not supposed to change the window, it was just a test to see whether
queueing effects on the Linux box cause it.
Seems like the test failed.
- -Andi
------------------------------
From: Riley Williams <rhw@ps.cus.umist.ac.uk>
Date: Sun, 24 May 1998 17:49:05 +0100 (BST)
Subject: Re: port_t again, sorry didn't type the whole thing.
Hi there.
>> check all the (million?) lines of .c files to make sure they use
>> the proper declaration.
> % cat `find /usr/src/linux-2.1.103/ -type f -name '*.c'`|wc -l
> 1118178
You forgot some. I don't have 2.1.103 so please try the following
command instead...
Q> cd /usr/src/linux-2.1.103
Q> cat `find . -type f -name '*.[ch]'` | wc -l
Best wishes from Riley.
------------------------------
From: "Eric Schenk" <eschenk@pc-37249.bc.rogers.wave.ca>
Date: Sun, 24 May 1998 09:43:29 -0600
Subject: Re: Poor TCP throughput in 2.1.103
ak@muc.de <ak@muc.de> writes:
>> The problem is suspected to lie with my ISP's Ascend servers, using larger
<<< Continua nel prossimo messaggio >>>
--FAF00201.896068177/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