This message generated a parse failure. Raw output follows here. Please use 'back' to navigate. From devnull@lkml.org Tue Apr 23 22:45:41 2024 Received: from entropy.muc.muohio.edu (entropy.muc.muohio.edu [134.53.213.10]) by herbie.ucs.indiana.edu (8.8.8/8.8.8) with ESMTP id XAA29174 for ; Sun, 24 May 1998 23:36:11 -0500 (EST) Received: from vger.rutgers.edu (root@vger.rutgers.edu [128.6.190.2]) by entropy.muc.muohio.edu (8.8.7/8.8.7) with ESMTP id AAA32416; Mon, 25 May 1998 00:23:43 -0400 Received: by vger.rutgers.edu id <971200-31161>; Sun, 24 May 1998 23:17:12 -0400 Received: from async01.est.it ([194.243.194.225]:1054 "EHLO wigner.cstc.org" ident: "root") by vger.rutgers.edu with ESMTP id <971204-31161>; Sun, 24 May 1998 23:15:51 -0400 Received: from localhost (localhost) by wigner.cstc.org (8.8.8/8.8.8/Debian/GNU) with internal id FAG00201; Mon, 25 May 1998 05:49:50 +0200 Date: Mon, 25 May 1998 05:49:50 +0200 From: Mail Delivery Subsystem Message-Id: <199805250349.FAG00201@wigner.cstc.org> To: Mime-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="FAG00201.896068190/wigner.cstc.org" Subject: Warning: could not send message for past 4 hours Auto-Submitted: auto-generated (warning-timeout) X-Orcpt: rfc822;linux-kernel@vger.rutgers.edu Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk X-Loop: majordomo@vger.rutgers.edu This is a MIME-encapsulated message --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: ) ----- 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; 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: 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 ; 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 (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 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 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 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 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 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 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. 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