--FAG00201.896068190/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:50 +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
--FAG00201.896068190/wigner.cstc.org
Content-Type: message/delivery-status
Reporting-MTA: dns; wigner.cstc.org
Arrival-Date: Sun, 24 May 1998 21:12:50 +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:50 +0200
Will-Retry-Until: Fri, 29 May 1998 21:12:50 +0200
--FAG00201.896068190/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 VAA03612
for <pol@wigner.cstc.org>; Sun, 24 May 1998 21:12:50 +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:50 CEST
Message-ID: <294145@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 3 di un precedente messaggio >>>
edge and level interrupts are handled by the APIC hardware and
this should allow to handle them transparently from software.
My opinion is that the current code has been suggested by
people who are confusing real-time and messed-time. ;-)
Things like disable_interrupt(irq) seems suspicious to me.
Imagine that a level interrupt, that have been accepted by
a local APIC but donnot have been yet dispensed to the CPU,
is so blindly masked. In such a situation the CPU may try
to handle an interrupt with no interrupt actually pending.
BTW, the way edge interrupts are disabled by the current apic
code is explicitely stated as 'should not' by intel docs.
Anyway, these spurious interrupts should'nt make problems,
I think, and are just, IMO, the punishment for the way the
apic code is currently implemented.
Regards,
Gerard.
------------------------------
From: David Burrows <snadge@gemcorp.com.au>
Date: Sun, 24 May 1998 23:20:44 +1000 (EST)
Subject: [SOUND] Aztech Sound Galaxy broken/not supported?
Hi all..
Recently I aquired an all in one, plug and play, internal modem &
soundcard. The soundcard is an Aztech Sound Galaxy Washington 16, which
is documented to be supported in drivers/sound/sgalaxy.c.
Is there anyone out there successfully using this driver? If so I would
greatly appreciate even an "it works for me".. But I doubt this as
sgalaxy.c wouldn't even compile in 2.1.103. (i had to make some trivial
patches)..
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..
Thanks in advance..
Dave.
------------------------------
From: Andrea Arcangeli <arcangeli@mbox.queen.it>
Date: Sun, 24 May 1998 15:33:47 +0200 (CEST)
Subject: Re: More on smbfs - I got it working...
On Sat, 23 May 1998, David Woodhouse wrote:
>Apparently the latest mount utilities are included in the samba distribution.
Debian distribute smbfs and smbfsx packages. The first is for 2.0 the
second for 2.1 and since all __.deb__ live in the directory binary-i386
they include executables, not source code.
andrea@dragon:~/devel/lab2/tinaos$ dpkg -I /park/debian/smbfsx_1.9.18p7-2.deb
new debian package, version 2.0.
size 123046 bytes: control archive= 810 bytes.
599 bytes, 15 lines control
480 bytes, 8 lines md5sums
Package: smbfsx
Version: 1.9.18p7-2
Architecture: i386
Depends: netbase (>= 2.02), libc6
Installed-Size: 308
Maintainer: Eloy A. Paris <peloy@debian.org>
Source: samba
Description: Mount and umount commands for the smbfs and kernels > 2.1.70.
Smbfs is a filesystem which understands the SMB protocol.
This is the protocol Windows for Workgroups, Windows NT or
Lan Manager use to talk to each other. It was inspired by
samba, the program by Andrew Tridgell that turns any unix
site into a file server for DOS or Windows clients.
.
This smbmount utilities will only work with kernels > 2.1.70.
Andrea[s] Arcangeli
------------------------------
From: David Woodhouse <Dave@imladris.demon.co.uk>
Date: Sun, 24 May 1998 14:40:39 +0200
Subject: Re: More on smbfs - I got it working...
arcangeli@mbox.queen.it said:
> Debian distribute smbfs and smbfsx packages. The first is for 2.0 the
> second for 2.1 and since all __.deb__ live in the directory
> binary-i386 they include executables, not source code.
Right. Thanks. When I get round to sorting it out and producing a binary RPM
that works with a non-pgcc-compiled glibc (sorry, folks), I'll call it smbfsx,
too.
- ---- ---- ----
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: ak@muc.de
Date: Sun, 24 May 1998 15:42:46 +0200
Subject: Re: Poor TCP throughput in 2.1.103
On Sun, May 24, 1998 at 02:37:21PM +0200, Shaw Carruthers wrote:
> On Sun, 24 May 1998 ak@muc.de wrote:
>
> >
> > Slow start should detect that. If it doesn't something is fishy in 2.1
> > TCP. Do you have the same problem with 2.0 too?
> >
>
> Yes I have the same problem with 2.0.33. The magic window size is 13140,
> up to this size I get no stalls.
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
after the connection is up.
- -Andi
------------------------------
From: Shaw Carruthers <shaw@shawc.demon.co.uk>
Date: Sun, 24 May 1998 13:37:21 +0100 (GMT+0100)
Subject: Re: Poor TCP throughput in 2.1.103
On Sun, 24 May 1998 ak@muc.de wrote:
>
> Slow start should detect that. If it doesn't something is fishy in 2.1
> TCP. Do you have the same problem with 2.0 too?
>
Yes I have the same problem with 2.0.33. The magic window size is 13140,
up to this size I get no stalls.
Here is what happens in 2.1.103 with the default window:- stalls of about
20 secs.
14:13:17.829699 158.152.146.90.1046 > 194.159.255.135.20: . ack 60833 win
16060 (DF) [tos 0x8]
14:13:17.839699 194.159.255.135.20 > 158.152.146.90.1046: .
60833:62293(1460) ack 1 win 8760 (DF) [tos 0x8]
14:13:18.339699 158.152.146.90.1046 > 194.159.255.135.20: . ack 62293 win
16060 (DF) [tos 0x8]
14:13:18.359699 194.159.255.135.20 > 158.152.146.90.1046: .
62293:63753(1460) ack 1 win 8760 (DF) [tos 0x8]
14:13:18.469699 194.159.255.135.20 > 158.152.146.90.1046: P
63753:64077(324) ack 1 win 8760 (DF) [tos 0x8]
14:13:18.989699 194.159.255.135.20 > 158.152.146.90.1046: .
64077:65537(1460) ack 1 win 8760 (DF) [tos 0x8]
14:13:19.509699 194.159.255.135.20 > 158.152.146.90.1046: .
65537:66997(1460) ack 1 win 8760 (DF) [tos 0x8]
14:13:20.019699 194.159.255.135.20 > 158.152.146.90.1046: .
66997:68457(1460) ack 1 win 8760 (DF) [tos 0x8]
14:13:20.529699 194.159.255.135.20 > 158.152.146.90.1046: .
68457:69917(1460) ack 1 win 8760 (DF) [tos 0x8]
14:13:21.039699 194.159.255.135.20 > 158.152.146.90.1046: .
69917:71377(1460) ack 1 win 8760 (DF) [tos 0x8]
14:13:21.559699 194.159.255.135.20 > 158.152.146.90.1046: .
71377:72837(1460) ack 1 win 8760 (DF) [tos 0x8]
14:13:22.079699 194.159.255.135.20 > 158.152.146.90.1046: .
72837:74297(1460) ack 1 win 8760 (DF) [tos 0x8]
14:13:22.579699 194.159.255.135.20 > 158.152.146.90.1046: .
74297:75757(1460) ack 1 win 8760 (DF) [tos 0x8]
14:13:23.399699 194.159.255.135.20 > 158.152.146.90.1046: .
62293:63753(1460) ack 1 win 8760 (DF) [tos 0x8]
14:13:23.899699 158.152.146.90.1046 > 194.159.255.135.20: . ack 63753 win
16060 (DF) [tos 0x8]
/* stalls here */
14:13:42.289699 194.159.255.135.20 > 158.152.146.90.1046: .
63753:65213(1460) ack 1 win 8760 (DF) [tos 0x8]
14:13:42.799699 158.152.146.90.1046 > 194.159.255.135.20: . ack 65213 win
16060 (DF) [tos 0x8]
14:13:43.459699 194.159.255.135.20 > 158.152.146.90.1046: .
65213:66673(1460) ack 1 win 8760 (DF) [tos 0x8]
14:13:43.969699 158.152.146.90.1046 > 194.159.255.135.20: . ack 66673 win
16060 (DF) [tos 0x8]
- --
Shaw Carruthers - shaw@shawc.demon.co.uk
London SW14 7JW UK
This is not a sig( with homage to Magritte).
------------------------------
From: Chris Evans <chris@ferret.lmh.ox.ac.uk>
Date: Sun, 24 May 1998 15:21:27 +0100 (BST)
Subject: 2.0.34p15/16 stuck sockets
Hi,
I reported a socket stuck in "ESTABLISHED" the other day. I now believe
this to have been cause by the oopses generated when a network interface
is dropped and the module removed.
This is a nasty bug. Here are some oopses I generated by doing this while
upgrading the driver yesterday. By some miracle after this spurt of nasty
oopses, including one of the "Aieeee" variety, the machine is still alive,
and, er, fine :)
Cheers
Chris
May 23 21:33:47 ferret kernel: 13: @039e63e0 length 8000007e status 8000007e
May 23 21:33:47 ferret kernel: 14: @039e63f0 length 80000080 status 80000080
May 23 21:33:47 ferret kernel: 15: @039e6400 length 80000066 status 00000066
May 23 21:33:47 ferret kernel: eth0: Resetting the Tx ring pointer.
<new module is loaded here after rmmod'ing the old one>
May 23 22:48:17 ferret kernel: 3c59x.c:v0.99E 5/12/98 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/vortex.html
May 23 22:48:17 ferret kernel: loading device 'eth0'...
May 23 22:48:17 ferret kernel: eth0: 3Com 3c900 Boomerang 10baseT at 0x6d00, 00:60:97:0d:d0:f7, IRQ 10
May 23 22:48:17 ferret kernel: 8K word-wide RAM 3:5 Rx:Tx split, 10baseT interface.
May 23 22:48:17 ferret kernel: Enabling bus-master transmits and whole-frame receives.
May 23 22:51:58 ferret kernel: Unable to handle kernel paging request at virtual address c5a49e71
May 23 22:51:58 ferret kernel: current->tss.cr3 = 022a7000, (r3 = 022a7000
May 23 22:51:58 ferret kernel: *pde = 00000000
May 23 22:51:58 ferret kernel: Oops: 0002
May 23 22:51:58 ferret kernel: CPU: 0
May 23 22:51:58 ferret kernel: EIP: 0010:[do_dev_queue_xmit+121/504]
May 23 22:51:58 ferret kernel: EFLAGS: 00010202
May 23 22:51:58 ferret kernel: eax: 01ccce60 ebx: 00000000 ecx: 01ccce60 edx: 05a49d61
May 23 22:51:58 ferret kernel: esi: 01ccce60 edi: 01eb1810 ebp: 039e6018 esp: 022a8e30
May 23 22:51:58 ferret kernel: ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018
May 23 22:51:58 ferret kernel: Process rc564 (pid: 583, process nr: 43, stackpage=022a8000)
May 23 22:51:58 ferret kernel: Stack: 01ccce60 01ccc830 01eb1810 039e6018 00000000 0b0f44c3 0013a4da 01ccce60
May 23 22:51:58 ferret kernel: 039e6018 00000000 0014403d 01ccce60 039e6018 00000000 01ccce60 01eb1810
May 23 22:51:58 ferret kernel: 00007d78 01ccc844 00000014 000005dc 0014a8b4 01eb1810 039e6018 01ccce60
May 23 22:51:58 ferret kernel: Call Trace: [dev_queue_xmit+26/36] [ip_queue_xmit+409/492] [tcp_write_xmit+432/504] [tcp_ack+1492/2240] [newary+78/360] [tcp_rcv+2175/2528] [ip_rcv+1091/1396]
May 23 22:51:58 ferret kernel: [do_exit+160/508] [net_bh+252/284] [do_bottom_half+59/96] [handle_bottom_half+11/24]
May 23 22:51:58 ferret kernel: Code: ff 82 10 01 00 00 8b 92 00 01 00 00 eb 03 90 89 ea 89 d5 89
May 23 22:51:58 ferret kernel: Aiee, killing interrupt handler
May 23 22:52:21 ferret kernel: general protection: 0000
May 23 22:52:21 ferret kernel: CPU: 0
May 23 22:52:21 ferret kernel: EIP: 0010:[tcp_do_retransmit+1265/1672]
May 23 22:52:21 ferret kernel: EFLAGS: 00010202
May 23 22:52:21 ferret kernel: eax: 00000240 ebx: 00000000 ecx: 0332febc edx: 4cd1a119
May 23 22:52:21 ferret kernel: esi: 039e6018 edi: 0332febc ebp: 020321e4 esp: 001a80d8
May 23 22:52:21 ferret kernel: ds: 0018 es: 0018 fs: 002b gs: 0018 ss: 0018
May 23 22:52:21 ferret kernel: Process swapper (pid: 0, process nr: 0, stackpage=001a6250)
May 23 22:52:21 ferret kernel: Stack: 0332febc 039e6018 00000800 00000000 00000000 00000240 02032018 00002180
May 23 22:52:21 ferret kernel: 00000010 001a8188 1682bfa8 00000000 00c90407 0000022c 0332fc2c 0332fc40
May 23 22:52:21 ferret kernel: 027f2318 039e6018 0332febc 0014c02e 02032018 00000000 00000000 0014c0a6
May 23 22:52:21 ferret kernel: Call Trace: [tcp_retransmit_time+22/120] [tcp_retransmit+22/116] [tcp_time_write_timeout+19/32] [tcp_retransmit_timer+142/228] [tcp_retransmit_timer+0/228] [timer_bh+749/820] [do_bottom_half+59/96]
May 23 22:52:21 ferret kernel: [handle_bottom_half+11/24] [sys_idle+92/112] [system_call+85/124] [init+0/620] [start_kernel+449/460] [it_real_fn+0/72] [schedule+564/652]
May 23 22:52:21 ferret kernel: Code: ff d2 83 c4 18 85 c0 7d 08 8b 4c 24 30 c6 41 63 00 8b 74 24
May 23 22:52:21 ferret kernel: Aiee, killing interrupt handler
May 23 22:52:21 ferret kernel: general protection: 0000
May 23 22:52:21 ferret kernel: CPU: 0
May 23 22:52:21 ferret kernel: EIP: 0010:[ip_send_room+258/288]
May 23 22:52:21 ferret kernel: EFLAGS: 00010246
May 23 22:52:21 ferret kernel: eax: 4cd1a119 ebx: 03e99e60 ecx: 039e6018 edx: 000006e4
May 23 22:52:21 ferret kernel: esi: 039e6018 edi: 039e6018 ebp: 1e4179c3 esp: 010bce0c
May 23 22:52:21 ferret kernel: ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018
May 23 22:52:21 ferret kernel: Process in.ftpd (pid: 29464, process nr: 35, stackpage=010bc000)
May 23 22:52:21 ferret kernel: Stack: 03e99e60 039e6018 00000800 00000000 00000000 000006e4 00000000 03e99e60
May 23 22:52:21 ferret kernel: cc8a01a3 1e4179c3 00143cf0 00000000 03e99e60 1e4179c3 000006e4 039e6018
May 23 22:52:21 ferret kernel: cc8a01a3 03e99e60 0205d414 001abb14 010bced4 0205d414 00000000 1e4179c3
May 23 22:52:21 ferret kernel: Call Trace: [ip_build_header+384/752] [do_tcp_sendmsg+1134/1636] [tcp_sendmsg+141/216] [inet_sendmsg+149/172] [sock_write+158/180] [sys_write+331/388] [system_call+85/124]
May 23 22:52:21 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:52:21 ferret kernel: kfree of non-kmalloced memory: 001a8298, next= 00000000, order=0
May 23 22:52:21 ferret kernel: kfree of non-kmalloced memory: 001a8288, next= 001aa538, order=9
May 23 22:52:21 ferret kernel: kfree of non-kmalloced memory: 001a879c, next= 00000009, order=1175153
May 23 22:52:21 ferret kernel: idle task may not sleep
May 23 22:52:21 ferret last message repeated 4 times
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: 03367e7c ecx: 039e6018 edx: 0000007f
May 23 22:54:05 ferret kernel: esi: 039e6018 edi: 039e6018 ebp: 1682bfa8 esp: 001a7e58
May 23 22:54:05 ferret kernel: ds: 0018 es: 0018 fs: 002b gs: 0000 ss: 0018
May 23 22:54:05 ferret kernel: Process swapper (pid: 0, process nr: 0, stackpage=001a6250)
May 23 22:54:05 ferret kernel: Stack: 03367e7c 039e6018 00000800 00000000 00000000 0000007f 027f2318 03367e7c
May 23 22:54:05 ferret kernel: cc8a01a3 1682bfa8 00143cf0 027f2318 03367e7c fe8a01a3 0000007f 039e6018
May 23 22:54:05 ferret kernel: cc8a01a3 02032018 03367e7c 02032018 020320d8 02030407 00000000 1682bfa8
May 23 22:54:05 ferret kernel: Call Trace: [ip_build_header+384/752] [tcp_send_ack+267/572] [tcp_queue+252/388] [tcp_data+529/540] [tcp_rcv+2357/2528] [ip_rcv+1091/1396] [net_bh+252/284]
May 23 22:54:05 ferret kernel: [do_bottom_half+59/96]
<<< Continua nel prossimo messaggio >>>
--FAG00201.896068190/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