From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:02:47 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA11040
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:02:46 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02188
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:03:13 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:40046 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S42225AbPHKUgf>;
	Wed, 11 Aug 1999 23:36:35 +0300
Received:  by vger.rutgers.edu via listexpand id <S156517AbPHKTjd>;
	Wed, 11 Aug 1999 15:39:33 -0400
Received:  by vger.rutgers.edu id <S156072AbPHKS6r>;
	Wed, 11 Aug 1999 14:58:47 -0400
Received: from smtp1.xs4all.nl ([194.109.127.48]:1517 "EHLO smtp1.xs4all.nl")
	by vger.rutgers.edu with ESMTP id <S156193AbPHKSCA>;
	Wed, 11 Aug 1999 14:02:00 -0400
Received: from grobbebol.xs4all.nl (grobbebol.xs4all.nl [194.109.14.68])
	by smtp1.xs4all.nl (8.9.3/8.9.3) with ESMTP id UAA16919
	for <linux-kernel@vger.rutgers.edu>; Wed, 11 Aug 1999 20:00:26 +0200 (CEST)
From: roel@grobbebol.xs4all.nl
Received: (from roel@localhost)
	by grobbebol.xs4all.nl (8.9.3/8.9.3) id RAA22445
	for linux-kernel@vger.rutgers.edu; Wed, 11 Aug 1999 17:58:07 GMT
Date:   Wed, 11 Aug 1999 17:58:06 +0000
To: linux-kernel@vger.rutgers.edu
Subject: 2.2.11 and fs corruption fixed ?
Message-ID: <19990811175806.A9697@grobbebol.xs4all.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.4i
X-OS:   Linux grobbebol 2.2.7
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig


hi *,


before I again crash the filesystems here -- I tried to understand the diffs
between the different versions of linux that worked for me and failed for me
(2.2.7 worked, above failed, see my ~page for the complete story) but I
think I failed here.

Have there been problems found in the kernel that may have caused the fs go
bezerk ? or do I need to try it out ? 
-- 
Grobbebol's Home                 |      Don't give in to spammers.
http://www.xs4all.nl/~bengel     |     Use your real e-mail address
Linux 2.0.34  on  an i586/64 MB  |             on Usenet.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:02:50 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA11085
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:02:49 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02199
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:03:17 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:56184 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S42138AbPHKUjU>;
	Wed, 11 Aug 1999 23:39:20 +0300
Received:  by vger.rutgers.edu via listexpand id <S156034AbPHKTku>;
	Wed, 11 Aug 1999 15:40:50 -0400
Received:  by vger.rutgers.edu id <S154674AbPHKTGY>;
	Wed, 11 Aug 1999 15:06:24 -0400
Received: from 1.0.0.127.in-addr.de ([212.8.197.180]:31855 "EHLO
        pointer.teuto.de") by vger.rutgers.edu with ESMTP
	id <S156715AbPHKS0W>; Wed, 11 Aug 1999 14:26:22 -0400
Received: (from lmb@localhost)
	by pointer.teuto.de (8.8.7/8.8.7) id UAA15128
	for linux-kernel@vger.rutgers.edu; Wed, 11 Aug 1999 20:26:12 +0200
Date:   Wed, 11 Aug 1999 20:26:11 +0200
From: Lars Marowsky-Bree <lmb@teuto.net>
To: linux-kernel@vger.rutgers.edu
Subject: (tiny fix) compiling 2.2.11ac3
Message-ID: <19990811202611.A15024@pointer.teuto.de>
Mail-Followup-To: linux-kernel@vger.rutgers.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/0.96.1i
X-Ctuhulu: HASTUR
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

--- drivers/block/cpqarray.h~   Mon Aug  9 21:04:38 1999
+++ drivers/block/cpqarray.h    Wed Aug 11 17:04:41 1999
@@ -30,7 +30,6 @@
 #include <linux/locks.h>
 #include <linux/malloc.h>
 #include <linux/proc_fs.h>
-#include <linux/md.h>
 #include <linux/timer.h>
 #endif

Otherwise ac3 will not compile cleanly in all cases.

Sincerely,
    Lars Marowsky-Bre
	
--
Lars Marowsky-Bre
Network Management

teuto.net Netzdienste GmbH - DPN Verbund-Partner

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:02:55 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA11128
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:02:52 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02203
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:03:20 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:33560 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S42722AbPHKUsN>;
	Wed, 11 Aug 1999 23:48:13 +0300
Received:  by vger.rutgers.edu via listexpand id <S155175AbPHKTyQ>;
	Wed, 11 Aug 1999 15:54:16 -0400
Received:  by vger.rutgers.edu id <S154480AbPHKTOI>;
	Wed, 11 Aug 1999 15:14:08 -0400
Received: from hamachi.synopsys.com ([204.176.20.26]:37969 "EHLO
        hamachi.synopsys.com") by vger.rutgers.edu with ESMTP
	id <S155193AbPHKRua>; Wed, 11 Aug 1999 13:50:30 -0400
Received: from javelin.synopsys.com (javelin.synopsys.com [146.225.100.38])
	by hamachi.synopsys.com (8.8.8/8.8.8) with ESMTP id KAA14106;
	Wed, 11 Aug 1999 10:49:40 -0700 (PDT)
Received: from goofy.gr05.synopsys.com (goofy.gr05.synopsys.com [146.225.224.69])
	by javelin.synopsys.com (8.8.8/8.8.8) with ESMTP id KAA15236;
	Wed, 11 Aug 1999 10:49:38 -0700 (PDT)
Received: from Synopsys.COM (harri@bilbo [146.225.224.201])
	by goofy.gr05.synopsys.com (8.8.8/8.8.8) with ESMTP id TAA18447;
	Wed, 11 Aug 1999 19:49:34 +0200 (MET DST)
Message-ID: <37B1B7AD.74E34F6D@Synopsys.COM>
Date:   Wed, 11 Aug 1999 19:49:33 +0200
From: Harald Dunkel <harri@synopsys.COM>
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.10 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Frank Horowitz <frank@ned.dem.csiro.au>
CC: linux-kernel@vger.rutgers.edu
Subject: Re: 2.2.11: Complicated memory leak...
References: <v04210100b3d6fdd10c86@[130.116.145.101]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

Hi,

I could reproduce this problem: There are 256 MByte RAM in my PC,
512 MByte swap, SMP enabled, etc. I have neither Vmware, Squid, KDE 
and so on, but there are at least 19 remote disks mounted via NFS2. 
My PC is configured as NIS client. Currently I am running the
Potato Debian distribution, i.e. the C lib is glibc 2.1, and
the kernel has been compiled with gcc 2.95. 

After about 5 minutes or so ypbind, getty and other important jobs 
die with 'out of memory'. Only the reset button helps.


Regards

Harri
-- 
Harald Dunkel | dunkel@Synopsys.COM | O glcklich, wer noch hoffen kann,
Synopsys GmbH | Kaiserstr. 100      | aus diesem Meer des Irrtums 
52134 Herzogenrath, Germany         | aufzutauchen.               Faust, 
+49 2407 9558 (fax? 44: 0)          |   Der Tragdie erster Teil, J.W.G.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:02:57 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA11165
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:02:55 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02212
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:03:23 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:55577 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S42765AbPHKUvZ>;
	Wed, 11 Aug 1999 23:51:25 +0300
Received:  by vger.rutgers.edu via listexpand id <S155023AbPHKTyY>;
	Wed, 11 Aug 1999 15:54:24 -0400
Received:  by vger.rutgers.edu id <S154572AbPHKTOZ>;
	Wed, 11 Aug 1999 15:14:25 -0400
Received: from cyberelk.demon.co.uk ([194.222.36.72]:1830 "EHLO
        cyberelk.demon.co.uk") by vger.rutgers.edu with ESMTP
	id <S155532AbPHKRx4>; Wed, 11 Aug 1999 13:53:56 -0400
Received: from tim by cyberelk.demon.co.uk with local (Exim 2.05 #1 (Debian))
	id 11EcBA-0002Ep-00; Wed, 11 Aug 1999 18:28:44 +0100
Date:   Wed, 11 Aug 1999 18:28:44 +0100 (GMT)
From: Tim Waugh <tim@cyberelk.demon.co.uk>
X-Sender: tim@cyberelk.elk.co.uk
To: Meelis Roos <mroos@tartu.cyber.ee>
cc: linux-kernel@vger.rutgers.edu
Subject: Re: 2.2.11-pre7 tcp problem
In-Reply-To: <Pine.LNX.4.10.9908102230090.7038-100000@ondatra.tartu-labor>
Message-ID: <Pine.LNX.4.10.9908111827510.8468-100000@cyberelk.elk.co.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

On Tue, 10 Aug 1999, Meelis Roos wrote:

> Shot description: outgoing tcp connections to a 2.2.5-22 on the same
> subnet usually work just fine but sometimes the connection just hangs
> before transmitting any data. The process sleeps in tcp_recvmsg, netstat
> shows ESTABLISHED state with empty in/out queues.

It might be a problem with 2.2.5-22.  Try and catch it with tcpdump.

Tim.
*/


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:02:59 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA11213
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:02:59 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02222
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:03:26 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:55577 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S42369AbPHKUxs>;
	Wed, 11 Aug 1999 23:53:48 +0300
Received:  by vger.rutgers.edu via listexpand id <S156089AbPHKTyc>;
	Wed, 11 Aug 1999 15:54:32 -0400
Received:  by vger.rutgers.edu id <S154573AbPHKTOd>;
	Wed, 11 Aug 1999 15:14:33 -0400
Received: from cyberelk.demon.co.uk ([194.222.36.72]:1835 "EHLO
        cyberelk.demon.co.uk") by vger.rutgers.edu with ESMTP
	id <S155609AbPHKRyS>; Wed, 11 Aug 1999 13:54:18 -0400
Received: from tim by cyberelk.demon.co.uk with local (Exim 2.05 #1 (Debian))
	id 11EcCE-0002Er-00; Wed, 11 Aug 1999 18:29:50 +0100
Date:   Wed, 11 Aug 1999 18:29:50 +0100 (GMT)
From: Tim Waugh <tim@cyberelk.demon.co.uk>
X-Sender: tim@cyberelk.elk.co.uk
To: Frank Horowitz <frank@ned.dem.csiro.au>
cc: linux-kernel@vger.rutgers.edu
Subject: Re: 2.2.11: Complicated memory leak...
In-Reply-To: <v04210100b3d6fdd10c86@[130.116.145.101]>
Message-ID: <Pine.LNX.4.10.9908111829280.8468-100000@cyberelk.elk.co.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

On Wed, 11 Aug 1999, Frank Horowitz wrote:

> 	Some combination of VMWare (1.0.3), squid, and KDE (1.1.1), 
> seems to accelerate the memory leak. VMWare (re-installed cleanly for 
> the new kernel; including a re-compilation of the vmmon and vm-net 
> modules) is particularly bad at exacerbating the problem.

But can you get it to happen without vmmon loaded at all?

Tim.
*/


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:03:04 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA11248
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:03:01 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02230
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:03:29 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:20526 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S42613AbPHKU7P>;
	Wed, 11 Aug 1999 23:59:15 +0300
Received:  by vger.rutgers.edu via listexpand id <S156370AbPHKTy7>;
	Wed, 11 Aug 1999 15:54:59 -0400
Received:  by vger.rutgers.edu id <S155299AbPHKTSp>;
	Wed, 11 Aug 1999 15:18:45 -0400
Received: from arus.cloudnet.com ([204.221.240.14]:3144 "EHLO
        arus.cloudnet.com") by vger.rutgers.edu with ESMTP
	id <S156788AbPHKSHc>; Wed, 11 Aug 1999 14:07:32 -0400
Received: from localhost (chris@localhost)
	by arus.cloudnet.com (8.9.3/8.9.3) with ESMTP id NAA10852;
	Wed, 11 Aug 1999 13:04:08 -0500
X-Authentication-Warning: arus.cloudnet.com: chris owned process doing -bs
Date:   Wed, 11 Aug 1999 13:04:08 -0500 (CDT)
From: Chris Zwilling <chris@cloudnet.com>
To: Mark Lord <mlord@pobox.com>
cc: "Mike A. Harris" <mharris@ican.net>,
        Linux Kernel mailing list <linux-kernel@vger.rutgers.edu>
Subject: Re: ADSL or Cable modem support in Linux, etc..
In-Reply-To: <37B19209.4258104E@pobox.com>
Message-ID: <Pine.LNX.4.10.9908111302550.10849-100000@arus.cloudnet.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

On Wed, 11 Aug 1999, Mark Lord wrote:

> 
> "Mike A. Harris" wrote:
> ...
> > What is the support like for ADSL right now?
> ...
> 
> Works fine here (2.2mb/sec), connected via ethernet to the ADSL "modem".
> 
> BUT.. that ease will change soon.  My ISP is shifting to PPP-over-Ethernet
> rather than continuing with the current "bridged" setup.  Other ISPs
> continent-wide are likely to do the same, in the name of "equal access".
> 
> Linux currently has no *mature* open-source PPPoE client, but there
> are some jury-rigged arrangements that work, sort of, at present.
> I'll likely be installed one Real Soon Now..

Here at Cloudnet we have several clients hooked up with ADSL/PPP.  The
equipment that the customers use are Cisco 675 ADSL routers.  The ADSL
routers handles the PPPoE stuff automagically.

;-----------------------------------------;
;                                         ;  Chris Zwilling
;  Don't let people drive you crazy       ;  chris@cloudnet.com
;  when you know it's in walking distance ;  System Administrator
;                                         ;  320.240.8243
;-----------------------------------------;


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:03:08 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA11300
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:03:05 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02240
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:03:32 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:28465 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S42463AbPHKVBf>;
	Thu, 12 Aug 1999 00:01:35 +0300
Received:  by vger.rutgers.edu via listexpand id <S156646AbPHKT5j>;
	Wed, 11 Aug 1999 15:57:39 -0400
Received:  by vger.rutgers.edu id <S154871AbPHKTZs>;
	Wed, 11 Aug 1999 15:25:48 -0400
Received: from finch-post-10.mail.demon.net ([194.217.242.38]:3867 "EHLO
        finch-post-10.mail.demon.net") by vger.rutgers.edu with ESMTP
	id <S156506AbPHKRPO>; Wed, 11 Aug 1999 13:15:14 -0400
Received: from dashcov.demon.co.uk ([158.152.21.162])
	by finch-post-10.mail.demon.net with esmtp (Exim 2.12 #1)
	id 11Ebxf-000DqZ-0A
	for linux-kernel@vger.rutgers.edu; Wed, 11 Aug 1999 17:14:48 +0000
Received: (from yves@localhost)
	by dashcov.demon.co.uk (8.9.0/8.9.0) id SAA12660;
	Wed, 11 Aug 1999 18:14:46 +0100
Date:   Wed, 11 Aug 1999 18:14:46 +0100
From: Yves Colombani <yc@dash.co.uk>
Message-Id: <199908111714.SAA12660@dashcov.demon.co.uk>
To: linux-kernel@vger.rutgers.edu
Subject: 2.0.36:`Aiee, killing interrupt handler`
X-Mailer: XCmail 0.99.7 - with PGP support, PGP engine version 0.5 (Linux)
X-Mailerorigin: http://www.fsai.fh-trier.de/~schmitzj/Xclasses/XCmail/
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

Hello,

we are running a kernel version 2.0.36 on a Slackware 3.5 for doing
gateway stuff (IP masquerading over ISDN for mail, name service, http)
and file service for 3 Solaris boxes, 1 Linux (RedHat 5.0) and
7 Windows NT machines via samba.

We have experienced 3 "problems" (since January, the last one this afternoon)
on similar cases: a windows box copies a lot of files through the network
from the Linux server. Apparently the network driver dies (cf the syslog
messages).
Today I have managed to restart the service by removing the interface
(eth0), then the module (ne.o) and reloading the module then reconfigure
the interface: the machine seems to be working fine since these operations.

Any similar experiences?
Could it be a hardware problem (we have not yet tried to replace the network
card [an ISA NE2000 clone])?

Thanks for your help,
Yves.

Syslog trace for the 3 "Aiee":

Mar 29 10:42:29 comms kernel: bounds: 0000 
Mar 29 10:42:29 comms kernel: CPU:    0 
Mar 29 10:42:29 comms kernel: EIP:    0010:[slhc:slhc_init_R20741a64+-9827/480] 
Mar 29 10:42:29 comms kernel: EFLAGS: 00010202 
Mar 29 10:42:29 comms kernel: eax: 0082c440   ebx: 00000300   ecx: 00000307   edx: 00000307 
Mar 29 10:42:29 comms kernel: esi: 048193c4   edi: 001b80f0   ebp: 00000309   esp: 001b809c 
Mar 29 10:42:29 comms kernel: ds: 0018   es: 0018   fs: 002b   gs: 0018   ss: 0018 
Mar 29 10:42:29 comms kernel: Process swapper (pid: 0, process nr: 0, stackpage=001b62d4) 
Mar 29 10:42:29 comms kernel: Stack: 0000034d 048193c4 0082c418 048193c4 00587e60 0481583d 048193c4 001b80ec  
Mar 29 10:42:29 comms kernel:        0000004d 00000001 048193c4 00000300 0082c418 008d0018 001b80ec 00000034  
Mar 29 10:42:29 comms kernel:        00000001 00584d00 0014d24e 00000300 00404e01 0481547f 048193c4 002db558  
Mar 29 10:42:29 comms kernel: Call Trace: [slhc:slhc_init_R20741a64+-7232/480] [slhc:slhc_init_R20741a64+-7232/480] [slhc:slhc_init_R20741a64+-22471/480] [slhc:slhc_init_R20741a64+-7232/480] [slhc:slhc_init_R20741a64+-7232/480] [tcp_reset_xmit_timer+90/156] [slhc:slhc_init_R20741a64+-23429/480]  
Mar 29 10:42:29 comms kernel:        [slhc:slhc_init_R20741a64+-7232/480] [do_IRQ+101/136] [slhc:slhc_init_R20741a64+-7232/480] [slhc:slhc_init_R20741a64+-7232/480] [IRQ10_interrupt+95/144] [slhc:slhc_init_R20741a64+-7232/480] [slhc:slhc_init_R20741a64+-7365/480] [slhc:slhc_init_R20741a64+-23745/480]  
Mar 29 10:42:29 comms kernel:        [slhc:slhc_init_R20741a64+-7080/480] [ip_rcv+1012/1364] [do_dev_queue_xmit+443/496] [slhc:slhc_init_R20741a64+-7232/480] [slhc:slhc_init_R20741a64+-7080/480] [slhc:slhc_init_R20741a64+-7232/480] [dev_tint+94/136] [slhc:slhc_init_R20741a64+-7232/480]  
Mar 29 10:42:29 comms kernel:        [slhc:slhc_init_R20741a64+-7232/480] [dev_transmit+31/44] [slhc:slhc_init_R20741a64+-7232/480] [net_bh+9/284] [do_bottom_half+59/96] [handle_bottom_half+11/32] [sys_idle+92/112] [system_call+85/128]  
Mar 29 10:42:29 comms kernel:        [init+0/612] [start_kernel+458/468] [it_real_fn+0/72] [schedule+564/652]  
Mar 29 10:42:29 comms kernel: Code: 8b 76 44 89 74 24 10 80 66 14 ef 5b 5e 5f 5d 83 c4 04 c3 83  
Mar 29 10:42:29 comms kernel: Aiee, killing interrupt handler 
Mar 29 10:42:29 comms kernel: kfree of non-kmalloced memory: 001b831c, next= 001b9000, order=1093355 
Mar 29 10:42:29 comms kernel: kfree of non-kmalloced memory: 001b830c, next= 001b9000, order=1093355 
Mar 29 10:42:29 comms kernel: kfree of non-kmalloced memory: 001b8820, next= 001b9000, order=1093355 
Mar 29 10:42:29 comms kernel: idle task may not sleep 

Apr 20 15:40:20 comms kernel: Unable to handle kernel paging request at virtual address ca89f76a 
Apr 20 15:40:20 comms kernel: Unable to handle kernel paging request at virtual address ca89f76a 
Apr 20 15:40:20 comms kernel: current->tss.cr3 = 03d0d000, %cr3 = 03d0d000 
Apr 20 15:40:20 comms kernel: current->tss.cr3 = 03d0d000, %cr3 = 03d0d000 
Apr 20 15:40:20 comms kernel: *pde = 00000000 
Apr 20 15:40:20 comms kernel: *pde = 00000000 
Apr 20 15:40:20 comms kernel: Oops: 0002 
Apr 20 15:40:20 comms kernel: CPU:    0 
Apr 20 15:40:20 comms kernel: EIP:    0010:[slhc:slhc_init_R20741a64+-9821/480] 
Apr 20 15:40:20 comms kernel: EFLAGS: 00010282 
Apr 20 15:40:20 comms kernel: eax: 03a58b40   ebx: 00000300   ecx: 00000307   edx: 00000307 
Apr 20 15:40:20 comms kernel: esi: 048193c4   edi: 0289dd3c   ebp: 00000309   esp: 0289dce8 
Apr 20 15:40:20 comms kernel: ds: 0018   es: 0018   fs: 002b   gs: 002b   ss: 0018 
Apr 20 15:40:20 comms kernel: Process smbd (pid: 19710, process nr: 31, stackpage=0289d000) 
Apr 20 15:40:20 comms kernel: Stack: 0000034e 048193c4 03a58b18 048193c4 022a1f90 0481583d 048193c4 0289dd38  
Apr 20 15:40:20 comms kernel:        0000004e 00000003 048193c4 00000300 03a58b18 02769018 0289dd38 00000034  
Apr 20 15:40:20 comms kernel:        00000001 00004e00 0013b954 00000300 05ee5401 0481547f 048193c4 002db538  
Apr 20 15:40:20 comms kernel: Call Trace: [slhc:slhc_init_R20741a64+-7232/480] [slhc:slhc_init_R20741a64+-7232/480] [slhc:slhc_init_R20741a64+-22471/480] [slhc:slhc_init_R20741a64+-7232/480] [slhc:slhc_init_R20741a64+-7232/480] [dev_kfree_skb+32/76] [slhc:slhc_init_R20741a64+-23429/480]  
Apr 20 15:40:20 comms kernel:        [slhc:slhc_init_R20741a64+-7232/480] [do_IRQ+101/136] [slhc:slhc_init_R20741a64+-7232/480] [slhc:slhc_init_R20741a64+-7232/480] [IRQ10_interrupt+95/144] [slhc:slhc_init_R20741a64+-7232/480] [slhc:slhc_init_R20741a64+-7365/480] [slhc:slhc_init_R20741a64+-23745/480]  
Apr 20 15:40:20 comms kernel:        [slhc:slhc_init_R20741a64+-7080/480] [do_dev_queue_xmit+443/496] [slhc:slhc_init_R20741a64+-7232/480] [slhc:slhc_init_R20741a64+-7232/480] [dev_queue_xmit+26/36] [slhc:slhc_init_R20741a64+-7232/480] [ip_queue_xmit+409/492] [slhc:slhc_init_R20741a64+-7232/480]  
Apr 20 15:40:20 comms kernel:        [tcp_send_skb+627/656] [slhc:slhc_init_R20741a64+-7232/480] [do_tcp_sendmsg+1573/1624] [slhc:slhc_init_R20741a64+-7232/480] [tcp_sendmsg+141/216] [inet_sendmsg+149/172] [sock_write+158/180] [sys_write+339/396]  
Apr 20 15:40:20 comms kernel:        [system_call+85/128]  
Apr 20 15:40:20 comms kernel: Code: 10 80 66 14 ef 5b 5e 5f 5d 83 c4 04 c3 83 ec 10 55 57 56 53  
Apr 20 15:40:20 comms kernel: Aiee, killing interrupt handler 

Aug 11 15:53:42 comms kernel: eth0: DMAing conflict in ne_block_input [DMAstat:1][irqlock:0][intr:1]. 
Aug 11 15:53:42 comms kernel: invalid operand: 0000 
Aug 11 15:53:42 comms kernel: CPU:    0 
Aug 11 15:53:42 comms kernel: EIP:    0010:[<00000067>] 
Aug 11 15:53:42 comms kernel: EFLAGS: 00010202 
Aug 11 15:53:42 comms kernel: eax: 00000048   ebx: 00000365   ecx: 001ba080   edx: 03b81018 
Aug 11 15:53:42 comms kernel: esi: 048193c4   edi: 03a29418   ebp: 048193c4   esp: 001b80c0 
Aug 11 15:53:42 comms kernel: ds: 0018   es: 0018   fs: 002b   gs: 0018   ss: 0018 
Aug 11 15:53:42 comms kernel: Process swapper (pid: 0, process nr: 0, stackpage=001b62d4) 
Aug 11 15:53:42 comms kernel: Stack: 00000001 048193c4 00000300 03a29418 038a2018 001b80ec 00000034 00000001  
Aug 11 15:53:42 comms kernel:        016b6500 0014d266 00000300 00406601 048154bf 048193c4 002db558 0000000a  
Aug 11 15:53:42 comms kernel:        00000000 00000016 00093ce4 038a0307 00000001 0010cd39 0000000a 048193c4  
Aug 11 15:53:42 comms kernel: Call Trace: [slhc:slhc_init_R20741a64+-7232/480] [tcp_reset_xmit_timer+114/156] [slhc:slhc_init_R20741a64+-23365/480] [slhc:slhc_init_R20741a64+-7232/480] [do_IRQ+101/136] [slhc:slhc_init_R20741a64+-7232/480] [slhc:slhc_init_R20741a64+-7232/480]  
Aug 11 15:53:42 comms kernel:        [IRQ10_interrupt+95/144] [slhc:slhc_init_R20741a64+-7232/480] [slhc:slhc_init_R20741a64+-7365/480] [slhc:slhc_init_R20741a64+-23745/480] [slhc:slhc_init_R20741a64+-7080/480] [ip_rcv+1012/1364] [do_dev_queue_xmit+443/496] [slhc:slhc_init_R20741a64+-7232/480]  
Aug 11 15:53:42 comms kernel:        [slhc:slhc_init_R20741a64+-7080/480] [slhc:slhc_init_R20741a64+-7232/480] [dev_tint+94/136] [slhc:slhc_init_R20741a64+-7232/480] [slhc:slhc_init_R20741a64+-7232/480] [dev_transmit+31/44] [slhc:slhc_init_R20741a64+-7232/480] [net_bh+9/284]  
Aug 11 15:53:42 comms kernel:        [do_bottom_half+59/96] [handle_bottom_half+11/32] [sys_idle+92/112] [system_call+85/128] [init+0/612] [start_kernel+458/468] [it_real_fn+0/72] [schedule+564/652]  
Aug 11 14:53:42 comms kerneld: error: exit: Identifier removed
Aug 11 14:53:42 comms kerneld: error: exit: Identifier removed
Aug 11 15:53:42 comms kernel: Code: f0 6e fe 00 f0 53 ff 00 f0 53 ff 00 f0 a4 f0 00 f0 c7 ef 00  
Aug 11 15:53:42 comms kernel: Aiee, killing interrupt handler 
Aug 11 15:53:42 comms kernel: kfree of non-kmalloced memory: 001b831c, next= 00000000, order=1803036 
Aug 11 15:53:42 comms kernel: kfree of non-kmalloced memory: 001b830c, next= 001b831c, order=1803036 
Aug 11 15:53:42 comms kernel: kfree of non-kmalloced memory: 001b8820, next= 001b830c, order=1803036 
Aug 11 15:53:42 comms kernel: idle task may not sleep 
Aug 11 15:53:42 comms last message repeated 4 times



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:03:10 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA11341
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:03:08 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02250
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:03:36 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:2869 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S42823AbPHKVEe>;
	Thu, 12 Aug 1999 00:04:34 +0300
Received:  by vger.rutgers.edu via listexpand id <S156660AbPHKT6T>;
	Wed, 11 Aug 1999 15:58:19 -0400
Received:  by vger.rutgers.edu id <S156212AbPHKT2m>;
	Wed, 11 Aug 1999 15:28:42 -0400
Received: from ellpspace.math.ualberta.ca ([129.128.88.19]:1790 "EHLO
        ellpspace.math.ualberta.ca") by vger.rutgers.edu with ESMTP
	id <S154271AbPHKRjj>; Wed, 11 Aug 1999 13:39:39 -0400
Received: (from michal@localhost)
	by ellpspace.math.ualberta.ca (8.8.8/8.8.8) id LAA18407
	for linux-kernel@vger.rutgers.edu; Wed, 11 Aug 1999 11:39:30 -0600
From: Michal Jaegermann <michal@ellpspace.math.ualberta.ca>
Message-Id: <199908111739.LAA18407@ellpspace.math.ualberta.ca>
Subject: Ramdisk loading
To: linux-kernel@vger.rutgers.edu
Date:   Wed, 11 Aug 1999 11:39:30 -0600 (MDT)
Content-Type: text
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

Does anybody has some code, even in a "concept" stage, which would load
ramdisk images, while booting, from files on CD instead of a raw floppy?

I am thinking about it now mostly on Alpha where this should be easier
as both milo and aboot have some idea about underlying file systems;
but I would not complain about more general solutions. :-)  Creating
some kind of a catalogue, like on "El Torito" bootable CDs, does not
seem to outlandish.

   Michal

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:03:11 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA11377
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:03:11 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02259
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:03:39 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:20030 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S42303AbPHKVIG>;
	Thu, 12 Aug 1999 00:08:06 +0300
Received:  by vger.rutgers.edu via listexpand id <S156718AbPHKUCY>;
	Wed, 11 Aug 1999 16:02:24 -0400
Received:  by vger.rutgers.edu id <S154436AbPHKTfL>;
	Wed, 11 Aug 1999 15:35:11 -0400
Received: from darmol.elte.hu ([157.181.3.1]:3103 "EHLO darmol.elte.hu")
	by vger.rutgers.edu with ESMTP id <S154405AbPHKSRB>;
	Wed, 11 Aug 1999 14:17:01 -0400
Received: from localhost (endre@localhost)
	by darmol.elte.hu (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA31660;
	Wed, 11 Aug 1999 20:15:49 +0200
Date:   Wed, 11 Aug 1999 20:15:49 +0200 (CEST)
From: Hirling Endre <endre@darmol.elte.hu>
To: Yiorgos Adamopoulos <adamo@dblab.ece.ntua.gr>
cc: CaT <cat@zip.com.au>, linux-kernel@vger.rutgers.edu
Subject: Re: lockd errors
In-Reply-To: <EXECMAIL.990811172125.A@kanguru.dblab.ece.ntua.gr>
Message-ID: <Pine.LNX.3.96.990811201343.4043C-100000@darmol.elte.hu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

On Wed, 11 Aug 1999, Yiorgos Adamopoulos wrote:

> > elm reports that:
> > Cannot flock folder "/var/spool/mail/root"! [No locks available]
> 
> It is my understanding that the lockd in the free Unix communities does
> not work as expected (ie. as the Sun lockd does)
> > Could someone help me here as I'm not quite sure what to do about this... :/
> Recompile elm directing it to use dot-locking only.

I don't think so... Mount the filesystem with the 'nolock' option
instead, then elm will use lockfiles without recompiling (not only elm
causes lockd pain..)

greetings
endre

--
..all in all it's just another rule in the firewall. 

                                         /Ping Flood/


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:03:16 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA11414
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:03:14 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02268
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:03:42 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:15950 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S42588AbPHKVMg>;
	Thu, 12 Aug 1999 00:12:36 +0300
Received:  by vger.rutgers.edu via listexpand id <S157352AbPHKUPz>;
	Wed, 11 Aug 1999 16:15:55 -0400
Received:  by vger.rutgers.edu id <S155975AbPHKTh6>;
	Wed, 11 Aug 1999 15:37:58 -0400
Received: from bw151zhb.bluewin.ch ([195.186.1.16]:53557 "EHLO
        bw151zhb.bluewin.ch") by vger.rutgers.edu with ESMTP
	id <S157275AbPHKSi0>; Wed, 11 Aug 1999 14:38:26 -0400
Received: from ds9.ch (olt114pub114.bluewin.ch [195.186.114.114])
	by bw151zhb.bluewin.ch (8.8.7/8.8.5) with ESMTP id UAA22337
	for <linux-kernel@vger.rutgers.edu>; Wed, 11 Aug 1999 20:38:20 +0200 (MET DST)
Message-ID: <37B1C31B.99994327@ds9.ch>
Date:   Wed, 11 Aug 1999 20:38:19 +0200
From: Marcel Lanz <marcel.lanz@ds9.ch>
Organization: DEFIANT@DS9
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.11 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "linux-kernel@vger.rutgers.edu" <linux-kernel@vger.rutgers.edu>
Subject: bttv & 2.2.11 => can't switch channels
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

Since I use 2.2.11 I can't switch between channels on my Haupauge
TV-Card.
I have only one channel.

Any ideas?

	Marcel

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:03:21 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA11488
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:03:20 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02285
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:03:48 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:46169 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S42385AbPHKVRZ>;
	Thu, 12 Aug 1999 00:17:25 +0300
Received:  by vger.rutgers.edu via listexpand id <S157660AbPHKUkD>;
	Wed, 11 Aug 1999 16:40:03 -0400
Received:  by vger.rutgers.edu id <S154623AbPHKTqk>;
	Wed, 11 Aug 1999 15:46:40 -0400
Received: from gilgamesh.cse.ucsc.edu ([128.114.49.60]:1246 "EHLO
        gilgamesh.cse.ucsc.edu") by vger.rutgers.edu with ESMTP
	id <S154274AbPHKTKM>; Wed, 11 Aug 1999 15:10:12 -0400
Received: (from tmk@localhost) by gilgamesh.cse.ucsc.edu (8.9.3/8.6.12) id MAA04103; Wed, 11 Aug 1999 12:10:10 -0700
To: linux-kernel@vger.rutgers.edu
Subject: Help: prefetching taking too long
From: tmk@cse.ucsc.edu (Tom M. Kroeger)
Date:   11 Aug 1999 12:10:10 -0700
Message-ID: <a4u2q63zhp.fsf@gilgamesh.cse.ucsc.edu>
Lines:  151
User-Agent: Gnus/5.070084 (Pterodactyl Gnus v0.84) Emacs/20.3
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

I'm having some trouble with prefetching file data in my
implementation of an inter-file prefetching algorithm.  I've been able
to predict the next file access as high as 89% of the time, but my
implementation is taking way too long to prefetch the data from that
file.

To measure page read times I instrumented async page I/O by measuring
the time between brw_page calling ll_rw_block and end_buffer_io_async
getting called.  To test the inter-file prefetching, I wrote a simple
best case program that goes though a non-changing list of 500 file
names opening each file, reading the first 32k of the file and
sleeping for a second in-between each read.

In a normal kernel (without inter-file prefetching enabled) this
program spends an average of 4ms on each page read (a histogram below
shows the distribution).  Then to test inter-file prefetching I enable
prefetching; run the program once to let the system learn the pattern
in which the files are accessed; clear the I/O caches with a program
that calls malloc until memory exhausts, evicting almost all cached
I/O data.  Finally I re-run the test program and the inter-file
prefetching is able to predict the next file a do a prefetch on the
first 32k of the predicted file.  My problem is that in this case this
prefetching has an average page read time of around 300ms (again
distribution below).  The code called to prefetch the first 32K of a
file is below.  I'm calling try_to_read_ahead() which calls the same
routines that are used to do the read for the non-prefetching case, so
I'm quite puzzled as to why the same read calls are taking about 10
time longer than when they are called by sys_read. (BTW - 2.2.9 
kernel, ext2fs, and ide disk).

Is it possible that I'm over filling the device que, if so then why doesn't
this happen when sys_read calls to read exactly the same data, just on 
user demand vice as a prefetch.

In any case, any ideas, thoughts or sudden rays of bright light would
be greatly appreciated. Thanks for your time,

                               tmk



int prefetch_file_data(struct inode * inode, unsigned long max_ahead)
{
        struct dentry * dentry;
        struct file * f;
        int ahead,error;
        unsigned long page_cache;

        if (max_ahead > inode->i_size) 
                max_ahead = inode->i_size;
        debug (4,"    prefetching data %ld bytes\n",max_ahead);


        error = -ENFILE;
        f = get_empty_filp();
        if (!f)
                return 0;
        dentry = list_entry(inode->i_dentry.next, struct dentry, d_alias);
        f->f_dentry = dentry;
        f->f_pos = 0;
        f->f_reada = 0;
        f->f_op = NULL;
        if (inode->i_op)
                f->f_op = inode->i_op->default_file_ops;
#if 0/1  /* tried both with and without this */
        if (f->f_op && f->f_op->open) { 
                error = f->f_op->open(inode,f); 
                if (error) 
                        put_filp(f);
                        return 0;
        } 
#endif

        ahead = 0;
        while (ahead < max_ahead) {
                debug (2,"PREFETCHING 0x%0x %lu offset %lu\n",
                       inode->i_dev, inode->i_ino,ahead);
                page_cache = try_to_read_ahead(f, ahead,0);
                ahead += PAGE_CACHE_SIZE;
        }
        
        put_filp(f);
        return max_ahead;
}


Page read distributions for readnSleep without prefetching:
times in usecs
log_prefetch Hist:     8118 event      3890 mean  263 min    253458 max
<       1:    0
<       2:    0
<       4:    0
<       8:    0
<      16:    0
<      32:    0
<      64:    0
<     128:    0
<     256:    0
<     512:   23
<    1024: 1461
<    2048: 5586
<    4096:   77
<    8192:   97
<   16384:  253
<   32768:  511
<   65536:   74
<  131072:   31
<  262144:    
<  524288:    0
< 1048576:    0
< 2097152:    0

Page read distributions for readnSleep with inter-file prefetching
log_prefetch Hist:     2508 event    299952 mean  209 min   1005362 max 0 negs
<       1:    0
<       2:    0
<       4:    0
<       8:    0
<      16:    0
<      32:    0
<      64:    0
<     128:    0
<     256:    1
<     512:    7
<    1024:  626
<    2048:   12
<    4096:    0
<    8192:    8
<   16384:   95
<   32768:  133
<   65536:   83
<  131072:  162
<  262144:  303
<  524288:  413
< 1048576:  665
< 2097152:    0


-- 

                       tmk

-----------------------------------------------------------------------
Tom M. Kroeger                           Pray for wind
Graduate Student, UC Santa Cruz      \    Pray for waves
e-mail: tmk@cs.ucsc.edu              |\    and Pray it's your day off!
http://www.cse.ucsc.edu/~tmk         |~\
(831) 459-4458                       |__\
(831) 426-9055 home                 ,----+--



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:03:23 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA11450
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:03:17 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02277
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:03:45 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:38740 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S42126AbPHKVPY>;
	Thu, 12 Aug 1999 00:15:24 +0300
Received:  by vger.rutgers.edu via listexpand id <S157409AbPHKUQB>;
	Wed, 11 Aug 1999 16:16:01 -0400
Received:  by vger.rutgers.edu id <S156011AbPHKTiF>;
	Wed, 11 Aug 1999 15:38:05 -0400
Received: from mail10.svr.pol.co.uk ([195.92.193.214]:16024 "EHLO convert rfc822-to-8bit
        mail10.svr.pol.co.uk") by vger.rutgers.edu with ESMTP
	id <S156028AbPHKSi4>; Wed, 11 Aug 1999 14:38:56 -0400
Received: from modem-16.tretinoin.dialup.pol.co.uk
	([62.136.90.16] helo=periscope.localdomain ident=root)
	by mail10.svr.pol.co.uk with esmtp (Exim 2.12 #2)
	id 11EdH3-0001FU-00; Wed, 11 Aug 1999 19:38:54 +0100
Received: from periscope-systems.freeserve.co.uk (IDENT:mastersj@periscope.localdomain [192.168.0.1])
	by periscope.localdomain (8.9.3/8.8.7) with ESMTP id TAA21432;
	Wed, 11 Aug 1999 19:38:24 +0100
Message-ID: <37B1C320.8E8B87A3@periscope-systems.freeserve.co.uk>
Date:   Wed, 11 Aug 1999 19:38:24 +0100
From: Jonathan Masters <mastersj@periscope-systems.freeserve.co.uk>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Mark Lord <mlord@pobox.com>, linux-kernel@vger.rutgers.edu
Subject: Re: ADSL or Cable modem support in Linux, etc..
References: <Pine.LNX.4.10.9908092107310.4988-100000@asdf.capslock.lan> <37B19209.4258104E@pobox.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8BIT
X-MIME-Autoconverted: from 8bit to quoted-printable by periscope.localdomain id TAA21432
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

Under law, I believe that you can refuse them permission to do the "upgrade"
on the grounds that it is an "upgrade" and you don't want an "upgrade", you
didn't pay for it. It *might* work :) Unfortunately ADSL isn't mainstream
available in the UK. BT is about to finish ADSL trials in London (finishes in
September). Unfortunately, BT use a custom Ethernet card which aint good, but
they might come up with another option/use a card which is supported. NTL
(formally Comtel, formally Telecential) are trialling Cable modems which I
think just connect to a serial port - I think there might be some luck there.

Just my 0.02

Mark Lord wrote:

> "Mike A. Harris" wrote:
> ...
> > What is the support like for ADSL right now?
> ...
>
> Works fine here (2.2mb/sec), connected via ethernet to the ADSL "modem".
>
> BUT.. that ease will change soon.  My ISP is shifting to PPP-over-Ethernet
> rather than continuing with the current "bridged" setup.  Other ISPs
> continent-wide are likely to do the same, in the name of "equal access".
>
> Linux currently has no *mature* open-source PPPoE client, but there
> are some jury-rigged arrangements that work, sort of, at present.
> I'll likely be installed one Real Soon Now..
> --
> Mark Lord
> Real-Time Remedies Inc.
> mlord@pobox.com
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/

--
Jonathan C. Masters                     (jonathan@oxlug.org)
                                        PGP: www.brookes.ac.uk/~95227860/KEY

           "Upon this rock I will build my church,
            and the gates of hell shall not prevail against it".

                 -- Matthew 16, 17-18




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:03:26 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA11530
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:03:23 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02289
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:03:50 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:64347 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S42114AbPHKVSp>;
	Thu, 12 Aug 1999 00:18:45 +0300
Received:  by vger.rutgers.edu via listexpand id <S157688AbPHKUmZ>;
	Wed, 11 Aug 1999 16:42:25 -0400
Received:  by vger.rutgers.edu id <S156569AbPHKTqQ>;
	Wed, 11 Aug 1999 15:46:16 -0400
Received: from mail1.svr.pol.co.uk ([195.92.193.18]:13358 "EHLO
        mail1.svr.pol.co.uk") by vger.rutgers.edu with ESMTP
	id <S153854AbPHKTp5>; Wed, 11 Aug 1999 15:45:57 -0400
Received: from modem-85.levothyroxine.dialup.pol.co.uk
	([62.136.76.85] helo=periscope.localdomain ident=root)
	by mail1.svr.pol.co.uk with esmtp (Exim 2.12 #2)
	id 11EeJu-0002WY-00; Wed, 11 Aug 1999 20:45:55 +0100
Received: from periscope-systems.freeserve.co.uk (IDENT:mastersj@periscope.localdomain [192.168.0.1])
	by periscope.localdomain (8.9.3/8.8.7) with ESMTP id UAA22232;
	Wed, 11 Aug 1999 20:46:00 +0100
Message-ID: <37B1D2F8.CE2927BE@periscope-systems.freeserve.co.uk>
Date:   Wed, 11 Aug 1999 20:46:00 +0100
From: Jonathan Masters <mastersj@periscope-systems.freeserve.co.uk>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Alexander S A Kjeldaas <Alexander.Kjeldaas@fast.no>,
        linux-kernel@vger.rutgers.edu
Subject: Re: 2.2.11
References: <37B1699F.CC5393A2@periscope-systems.freeserve.co.uk> <19990811185949.A40279@midten.fast.no>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

Thanx. I love linux - yes I may need treatment, but I would really love
it if when 2.2.4 comes out in the fall, patch-int-2.2.4 came out at the
same time. Us guys here don't judge each other by the size of our ...
but rather by the version of our kernel. Therefore, keep up the good
work and please be this efficient with 2.2.4. Thanx.

Alexander S A Kjeldaas wrote:

> On Wed, Aug 11, 1999 at 01:16:31PM +0100, Jonathan Masters wrote:
> > Hi,
> >     I'm after a patch for 2.2.11 any idea when it's coming out?
> >
>
> This weekend, or sooner.
>
> astor
>
> --
>  Alexander Kjeldaas, Fast Search & Transfer, Trondheim, Norway

--
Jonathan C. Masters                     (jonathan@oxlug.org)
                                        PGP: www.brookes.ac.uk/~95227860/KEY

           "Upon this rock I will build my church,
            and the gates of hell shall not prevail against it".

                 -- Matthew 16, 17-18




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:03:28 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA11569
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:03:26 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02298
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:03:53 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:59234 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S42387AbPHKVUr>;
	Thu, 12 Aug 1999 00:20:47 +0300
Received:  by vger.rutgers.edu via listexpand id <S156550AbPHKUxz>;
	Wed, 11 Aug 1999 16:53:55 -0400
Received:  by vger.rutgers.edu id <S154572AbPHKTyl>;
	Wed, 11 Aug 1999 15:54:41 -0400
Received: from funky.monkey.org ([152.160.231.196]:36872 "HELO
        funky.monkey.org") by vger.rutgers.edu with SMTP id <S154806AbPHKTOv>;
	Wed, 11 Aug 1999 15:14:51 -0400
Received: by funky.monkey.org (Postfix, from userid 1035)
	id 1AF5723D92; Wed, 11 Aug 1999 15:14:47 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by funky.monkey.org (Postfix) with ESMTP
	id 07A0915CC2; Wed, 11 Aug 1999 15:14:46 -0400 (EDT)
Date:   Wed, 11 Aug 1999 15:14:46 -0400 (EDT)
From: Chuck Lever <cel@monkey.org>
To: Jamie Lokier <lkd@tantalophile.demon.co.uk>
Cc: linux-kernel@vger.rutgers.edu
Subject: Re: clustering page-ins
In-Reply-To: <19990811193427.B14430@pcep-jamie.cern.ch>
Message-ID: <Pine.BSO.4.10.9908111507201.14055-100000@funky.monkey.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

On Wed, 11 Aug 1999, Jamie Lokier wrote:
> Chuck Lever wrote:
> > > preload_page() should duplicate some of the code in do_no_page(): it
> > > should fill in a pte, but only if the pte is "not present" already, and
> > > the new pte should be marked "old" not "young".  If any memory
> > > allocation is required (for pgds and pmds) it should simply return
> > > without doing the allocation.
> > 
> > actually, i think you'd want to do just the opposite.  allocating the
> > extra pmds and ptes during read-ahead is exactly what you want to do,
> > while diddling the entries in already existing pte's will just break page
> > faulting in subtle ways.
> 
> 1. What do you mean by "allocating extra ptes during read-ahead"?  You mean
> allocate pmds when read-ahead crosses a table boundary, e.g. every 1024
> pages on x86?

allocate the necessary structs for all pages that are faulted in via
read-ahead -- of course some of that won't result in an allocation, but
simply an extra lookup operation.  see below.

> > 2.  fault in and map in entire clusters at a time.  if the page fault
> > happens on the first page in a cluster, then watch for sequential cluster
> > faults, and do read-ahead.
> 
> I still don't see what you mean be pre-allocate ptes without faulting in
> pages.  Are you proposing to store "not present" references to the
> read-ahead physical pages so that future faults can avoid the hash
> lookup?

well, not store them (although it could be useful to cache them somehow),
but do the lookup and make sure the memory is allocated while waiting for
the original fault I/O to complete.  in other words, when the page is
finally faulted and mapped, we're sure we do only a lookup, and not an
allocation of any kind.

> so many questions :-)

don't worry, i probably don't know what i'm talking about anyway... :)

i'll try to post a patch soon, that will probably explain a little better.
it's pretty simplistic, but i think it will convey my idea.

	- Chuck Lever
--
corporate:	<chuckl@netscape.com>
personal:	<chucklever@netscape.net> or <cel@monkey.org>

The Linux Scalability project:
	http://www.citi.umich.edu/projects/linux-scalability/


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:03:32 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA11650
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:03:32 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02311
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:03:59 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:41067 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S42236AbPHKVa4>;
	Thu, 12 Aug 1999 00:30:56 +0300
Received:  by vger.rutgers.edu via listexpand id <S155230AbPHKT6B>;
	Wed, 11 Aug 1999 15:58:01 -0400
Received:  by vger.rutgers.edu id <S154460AbPHKT2O>;
	Wed, 11 Aug 1999 15:28:14 -0400
Received: from lightning.swansea.uk.linux.org ([194.168.151.1]:17496 "EHLO
        the-village.bc.nu") by vger.rutgers.edu with ESMTP
	id <S155576AbPHKRWx>; Wed, 11 Aug 1999 13:22:53 -0400
Received: from alan by the-village.bc.nu with local (Exim 2.12 #1)
	id 11Ec0G-0004Qq-00; Wed, 11 Aug 1999 18:17:28 +0100
Subject: Re: lockd errors
To: adamo@dblab.ece.ntua.gr (Yiorgos Adamopoulos)
Date:   Wed, 11 Aug 1999 18:17:23 +0100 (BST)
Cc: cat@zip.com.au, linux-kernel@vger.rutgers.edu
In-Reply-To: <EXECMAIL.990811172125.A@kanguru.dblab.ece.ntua.gr> from "Yiorgos Adamopoulos" at Aug 11, 99 05:21:25 pm
Content-Type: text
Message-Id: <E11Ec0G-0004Qq-00@the-village.bc.nu>
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

> [ please excuse the answer here from a FreeBSD user ]
Why ?

> 
> > elm reports that:
> > Cannot flock folder "/var/spool/mail/root"! [No locks available]
> 
> It is my understanding that the lockd in the free Unix communities does
> not work as expected (ie. as the Sun lockd does)

Linux 2.0 doesnt have a lockd support. You are absolutely right. Linux 2.2
does but if your server is 2.0 that doesn't help

> Recompile elm directing it to use dot-locking only.

Bingo


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:03:36 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA11683
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:03:35 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02318
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:04:02 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:41067 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S42005AbPHKVb0>;
	Thu, 12 Aug 1999 00:31:26 +0300
Received:  by vger.rutgers.edu via listexpand id <S156689AbPHKUCQ>;
	Wed, 11 Aug 1999 16:02:16 -0400
Received:  by vger.rutgers.edu id <S154990AbPHKTep>;
	Wed, 11 Aug 1999 15:34:45 -0400
Received: from 52.ppp1-7.image.dk ([212.54.69.180]:1292 "EHLO image.dk")
	by vger.rutgers.edu with ESMTP id <S156808AbPHKSIS>;
	Wed, 11 Aug 1999 14:08:18 -0400
Received: (from axboe@localhost)
	by image.dk (8.9.3/8.8.7) id UAA02662;
	Wed, 11 Aug 1999 20:08:24 +0200
Date:   Wed, 11 Aug 1999 20:08:23 +0200
From: Jens Axboe <axboe@image.dk>
To: Olaf Dietsche <olaf.dietsche+list.linux-kernel@netcologne.de>
Cc: linux-kernel@vger.rutgers.edu
Subject: Re: [PATCH] `Maximum Physical Memory' in include/asm-i386/page_offset.h
Message-ID: <19990811200823.G1140@image.dk>
References: <87yafibjxk.fsf@tigram.bogus.local>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.6i
In-Reply-To: <87yafibjxk.fsf@tigram.bogus.local>; from Olaf Dietsche on Wed, Aug 11, 1999 at 02:06:47PM +0200
X-OS:   Linux 2.3.13 
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

On Wed, Aug 11 1999, Olaf Dietsche wrote:
> Hi,
> 
> I copied my .config from 2.2.10 over to 2.2.11 and missed the new item 
> `Maximum Physical Memory'. So I made this small patch, which might
> help to spot the error.

People should just remember to do a make oldconfig when moving
.config to another kernel version.

-- 
*  Jens Axboe <axboe@image.dk>
*  Linux CD-ROM Maintainer
*  http://www.kernel.dk

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:03:43 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA11718
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:03:38 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02326
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:04:05 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:28209 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S42857AbPHKVow>;
	Thu, 12 Aug 1999 00:44:52 +0300
Received:  by vger.rutgers.edu via listexpand id <S157626AbPHKUjf>;
	Wed, 11 Aug 1999 16:39:35 -0400
Received:  by vger.rutgers.edu id <S154424AbPHKTqD>;
	Wed, 11 Aug 1999 15:46:03 -0400
Received: from coloc73-138.singnet.com.sg ([165.21.73.138]:3788 "EHLO
        mailz.netnet.com.sg") by vger.rutgers.edu with ESMTP
	id <S154172AbPHKTE7>; Wed, 11 Aug 1999 15:04:59 -0400
Received: from mitac (unverified [202.169.232.190]) by mailz.netnet.com.sg
 (Rockliffe SMTPRA 2.1.6) with SMTP id <B0001024369@mailz.netnet.com.sg>;
 Thu, 12 Aug 1999 03:03:40 +0800
Message-ID: <B0001024369@mailz.netnet.com.sg>
From: "Moonshi Mohsenruddin" <moonshi@email.com>
To: "Anca Florea" <anca.florea@softnet.ro>, <linux-admin@vger.rutgers.edu>,
        <linux-net@vger.rutgers.edu>, <linux-smp@vger.rutgers.edu>,
        <linux-kernel@vger.rutgers.edu>
Subject: RE: question about mail
Date:   Thu, 12 Aug 1999 03:04:17 +0800
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
In-Reply-To: <37B10E3E.CC640A4F@softnet.ro>
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

A simple way is to create a user account for <anybody@domain.com> and in
their $home directory do a "touch .forward" file. Then "vi" the file and
type "office@domain.com"

Then saved it and all mails that comes in for this account will be
forwarded to <office@domain.com>.

- --
Moonshi Mohsenruddin            moonshi@linux.com.sg
http://www.linux.com.sg              icq: 2595480


> -----Original Message-----
> From: owner-linux-net@vger.rutgers.edu
> [mailto:owner-linux-net@vger.rutgers.edu]On Behalf Of Anca Florea
> Sent: Wednesday, August 11, 1999 1:47 PM
> To: linux-admin@vger.rutgers.edu; linux-net@vger.rutgers.edu;
> linux-smp@vger.rutgers.edu; linux-kernel@vger.rutgers.edu
> Subject: question about mail
>
>
> I wanna setup a mail server to handle mail for 2 different domains. I
> wanna setup that all the mail which came for anybody@domain.com to be
> forwarded to office@domain.com regardess anybody exist or no.
>
> Looking forward for your help,
> Anca
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-net" in
> the body of a message to majordomo@vger.rutgers.edu
>
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.0.2i

iQA/AwUBN7FYsWefe0TVuy5lEQL2sACffV8xv5+oZamhoQmMZp3hyqmD13QAnA3C
YCd4lXY4iuSXXaHc2+kf4TwG
=ROxv
-----END PGP SIGNATURE-----



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:03:44 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA11795
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:03:43 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02343
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:04:11 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:24836 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S46665AbPHKWKt>;
	Thu, 12 Aug 1999 01:10:49 +0300
Received:  by vger.rutgers.edu via listexpand id <S156163AbPHKViA>;
	Wed, 11 Aug 1999 17:38:00 -0400
Received:  by vger.rutgers.edu id <S157580AbPHKUgf>;
	Wed, 11 Aug 1999 16:36:35 -0400
Received: from finch-post-11.mail.demon.net ([194.217.242.39]:4057 "EHLO
        finch-post-11.mail.demon.net") by vger.rutgers.edu with ESMTP
	id <S154887AbPHKTjj>; Wed, 11 Aug 1999 15:39:39 -0400
Received: from one47.demon.co.uk ([158.152.11.13])
	by finch-post-11.mail.demon.net with smtp (Exim 2.12 #1)
	id 11EeDd-0009eU-0B
	for linux-kernel@vger.rutgers.edu; Wed, 11 Aug 1999 19:39:26 +0000
Message-ID: <37B1D158.71F641DD@one47.demon.co.uk>
Date:   Wed, 11 Aug 1999 20:39:04 +0100
From: Steve Davies <steve@one47.demon.co.uk>
To: linux-kernel@vger.rutgers.edu
Organization: One 47 Contracting Limited
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en-GB,en-US,en
MIME-Version: 1.0
Newsgroups: linux.kernel
Path:   anonymous
Subject: 2.2.11 and aic7xxx
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Hops: 1
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

Hi,

I've just skipped from 2.2.9 to 2.2.11 (I didn't like some of the problem
reports I saw for 2.2.10), and now I get LOADS of the following messages at
boot time:

(scsi1:0:1:0) Data overrun detected in Data-In phase, tag 1;
  Have seen Data Phase. Length=255, NumSGs=1.
     sg[0] - Addr 0xffc8480 : Length 255
(scsi1:0:1:0) Data overrun detected in Data-In phase, tag 1;
  Have seen Data Phase. Length=255, NumSGs=1.
     sg[0] - Addr 0xffc8480 : Length 255

Looking at the 2.2.11 patch, it updates aic7xxx, so I guess that's where the
version change happened.

The strange thing is that if I wait long enough, it eventually resets itself
into a peaceful state and gets on with life. Something like this seems to
happen every couple of releases/updates of the aic7xxx driver! I guess I chose
the wrong hardware :-(

To be more accurate the hardware is: Dual AIC-7895 Ultra, with Tagged queueing
enabled in the driver (Version 5.1.19/3.2.4)

Same setup for the previous driver has no problems. I've never foung any clues
in the READMEs (Yes I DO read them when I get problems :-)

Thanks for any clues.
Regards,
Steve
--
Steve Davies                   steve@one47.demon.co.uk
One 47 Contracting Limited     http://www.one47.demon.co.uk

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:03:50 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA11760
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:03:41 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02334
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:04:08 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:33092 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S41927AbPHKVxY>;
	Thu, 12 Aug 1999 00:53:24 +0300
Received:  by vger.rutgers.edu via listexpand id <S154331AbPHKUno>;
	Wed, 11 Aug 1999 16:43:44 -0400
Received:  by vger.rutgers.edu id <S154122AbPHKTvO>;
	Wed, 11 Aug 1999 15:51:14 -0400
Received: from coloc73-138.singnet.com.sg ([165.21.73.138]:3801 "EHLO
        mailz.netnet.com.sg") by vger.rutgers.edu with ESMTP
	id <S155377AbPHKTMg>; Wed, 11 Aug 1999 15:12:36 -0400
Received: from mitac (unverified [202.169.232.190]) by mailz.netnet.com.sg
 (Rockliffe SMTPRA 2.1.6) with SMTP id <B0001024388@mailz.netnet.com.sg>;
 Thu, 12 Aug 1999 03:11:20 +0800
Message-ID: <B0001024388@mailz.netnet.com.sg>
From: "Moonshi Mohsenruddin" <moonshi@email.com>
To: "Mike A. Harris" <mharris@meteng.on.ca>, "flippie" <flippie@vwv.com>
Cc: <linux-net@vger.rutgers.edu>, <linux-kernel@vger.rutgers.edu>
Subject: RE: [OT] Linux -> Clustering
Date:   Thu, 12 Aug 1999 03:11:56 +0800
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
In-Reply-To: <Pine.LNX.4.10.9908071704450.498-100000@asdf.capslock.lan>
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

It is called BEOWULF :)

- --
Moonshi Mohsenruddin            moonshi@linux.com.sg
http://www.linux.com.sg              icq: 2595480

> -----Original Message-----
> From: owner-linux-net@vger.rutgers.edu
> [mailto:owner-linux-net@vger.rutgers.edu]On Behalf Of Mike A. Harris
> Sent: Sunday, August 08, 1999 5:05 AM
> To: flippie
> Cc: linux-net@vger.rutgers.edu; linux-kernel@vger.rutgers.edu
> Subject: Re: [OT] Linux -> Clustering
>
>
> On Tue, 3 Aug 1999, flippie wrote:
>
> >Can linux do Clustering
>
> Yes.
>
>
> --
> Mike A. Harris                   Linux advocate      GNU advocate
> Computer Consultant                          Open Source advocate
>
> Tea, Earl Grey, Hot...
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-net" in
> the body of a message to majordomo@vger.rutgers.edu
>
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.0.2i

iQA/AwUBN7FafWefe0TVuy5lEQJr/gCg++W+a9AcLA8joiyeeWSoiqo7VawAoL8M
1qFTBx9lLg4e0u3MY0mFLS9M
=ud/x
-----END PGP SIGNATURE-----



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:03:51 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA11876
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:03:50 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02355
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:04:17 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:15682 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S42198AbPHKWXb>;
	Thu, 12 Aug 1999 01:23:31 +0300
Received:  by vger.rutgers.edu via listexpand id <S157483AbPHKVwG>;
	Wed, 11 Aug 1999 17:52:06 -0400
Received:  by vger.rutgers.edu id <S155142AbPHKUnm>;
	Wed, 11 Aug 1999 16:43:42 -0400
Received: from finch-post-10.mail.demon.net ([194.217.242.38]:3723 "EHLO
        finch-post-10.mail.demon.net") by vger.rutgers.edu with ESMTP
	id <S154264AbPHKTu2>; Wed, 11 Aug 1999 15:50:28 -0400
Received: from alfie.demon.co.uk ([158.152.44.128])
	by finch-post-10.mail.demon.net with esmtp (Exim 2.12 #1)
	id 11EeNu-0001ka-0A
	for linux-kernel@vger.rutgers.edu; Wed, 11 Aug 1999 19:50:03 +0000
Received: (from alfie@localhost)
	by alfie.demon.co.uk (8.9.3/8.9.3/Debian/GNU) id UAA01925
	for linux-kernel@vger.rutgers.edu; Wed, 11 Aug 1999 20:03:33 +0100
To: linux-kernel@vger.rutgers.edu
Path:   not-for-mail
From: Nick.Holloway@alfie.demon.co.uk (Nick Holloway)
Newsgroups: list.linux-kernel
Subject: Re: 2.2.11 compile failure!
Date:   11 Aug 1999 20:03:32 +0100
Organization: Alfie's Internet Node
Lines:  15
Message-ID: <7oshe4$1s3$1@alfie.demon.co.uk>
References: <x88zozzv9iy.fsf@rpppc2.hns.com> <87vhambi74.fsf@tigram.bogus.local>
X-Newsreader: NN version 6.5.0 CURRENT #119
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

olaf.dietsche+list.linux-kernel@netcologne.de (Olaf Dietsche) writes:
> nbecker@fred.net writes:
> > This failure is both when patching from 2.2.10->2.2.11 AND when using
> > a brand new complete tar of 2.2.11.
> > [...] `PAGE_OFFSET_RAW' undeclared (first use in this function)
> you have to configure `Processor type and features -> Maximum Physical Memory'.

This looks like a bug in "xconfig", as it leaves the newly introduced
choice unset, despite there being a default.

I've just checked, "menuconfig" and "oldconfig" do the right thing.

-- 
 `O O'  | Home: Nick.Holloway@alfie.demon.co.uk  http://www.alfie.demon.co.uk/
// ^ \\ | Work: Nick.Holloway@parallax.co.uk

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:03:53 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA11909
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:03:52 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02366
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:04:20 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:27217 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S42718AbPHKW2d>;
	Thu, 12 Aug 1999 01:28:33 +0300
Received:  by vger.rutgers.edu via listexpand id <S154558AbPHKVxe>;
	Wed, 11 Aug 1999 17:53:34 -0400
Received:  by vger.rutgers.edu id <S153954AbPHKUoY>;
	Wed, 11 Aug 1999 16:44:24 -0400
Received: from mail1.svr.pol.co.uk ([195.92.193.18]:20174 "EHLO
        mail1.svr.pol.co.uk") by vger.rutgers.edu with ESMTP
	id <S154673AbPHKTx4>; Wed, 11 Aug 1999 15:53:56 -0400
Received: from modem-85.levothyroxine.dialup.pol.co.uk
	([62.136.76.85] helo=periscope.localdomain ident=root)
	by mail1.svr.pol.co.uk with esmtp (Exim 2.12 #2)
	id 11EeRd-00047V-00; Wed, 11 Aug 1999 20:53:54 +0100
Received: from periscope-systems.freeserve.co.uk (IDENT:mastersj@periscope.localdomain [192.168.0.1])
	by periscope.localdomain (8.9.3/8.8.7) with ESMTP id UAA22330;
	Wed, 11 Aug 1999 20:53:13 +0100
Message-ID: <37B1D4A9.971344A2@periscope-systems.freeserve.co.uk>
Date:   Wed, 11 Aug 1999 20:53:13 +0100
From: Jonathan Masters <mastersj@periscope-systems.freeserve.co.uk>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-kernel@vger.rutgers.edu, linux-admin@vger.rutgers.edu,
        linux-sound@vger.rutgers.edu
Subject: [Fwd: hdd & sound]
Content-Type: multipart/mixed;
 boundary="------------1C7E2ED430416937048681A3"
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

This is a multi-part message in MIME format.
--------------1C7E2ED430416937048681A3
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



--
Jonathan C. Masters                     (jonathan@oxlug.org)
                                        PGP: www.brookes.ac.uk/~95227860/KEY

           "Upon this rock I will build my church,
            and the gates of hell shall not prevail against it".

                 -- Matthew 16, 17-18



--------------1C7E2ED430416937048681A3
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

X-Mozilla-Status2: 00000000
Message-ID: <37B1D45B.768FDD6A@periscope-systems.freeserve.co.uk>
Date: Wed, 11 Aug 1999 20:51:55 +0100
From: Jonathan Masters <mastersj@periscope-systems.freeserve.co.uk>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Mike Ricketts <rickettm@ox.compsoc.net>
Subject: Re: hdd & sound
References: <Pine.LNX.4.10.9908112011350.1973-100000@oakley.keble.ox.ac.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Has Mr Gates been at the kernel source? (well you did say "evil"). Seriously
though, it's scheduler related. Someone please fix this as writing a cd now makes
my 2.2.10 system *UNUSEABLE* since I must have sound to work. Music keeps me
happy. Besides, when this happens, the processor load is all of 4% or so - hardly
enough to cause problems - since it happens on PCI hardware too - it aint my ISA
soundcard (SB 64 AWE Gold) - interestingly, it haoppens when ripping cd's too -
but cdrecord causes less than cdparanoia (my hdds are on one controller, the
cd-writer/cdrom are on the other.). I've already posted my machine specs but more
is available in someone wants. Howz about Alan/Linus comments on this so we know
once and for all? Thanx.

Mike wrote:

> On Sat, 7 Aug 1999, Wakko Warner wrote:
>
> > I'm noticing this one one of my machines.  When writing to a hard drive, the
> > sound drags.  The machine I'm on has piix4 ide and an isa scsi card.  I'm
> > playing sounds from the drive on the scsi card (aha1510 I think is the scsi
> > card).  I tried writing to both an ide and scsi drive, both drag the sound.
> > Sound card is an SB16 pnp /w ide port (not disablable unfortunately).  I had
> > a similar problem on an isa ide card playing sounds off of the hard drive
> > (like 44k 16bit 2ch sound off the drive, sound card was an ess card).  My
> > home box that this is happneing on is 2.2.7.  The one with the isa ide is no
> > longer active, but it was running 2.0.36.
> >
> I see much the same thing under (extremely) heavy disk load, both on
> onboard piix4 ide, and on an onboard aic7??? scsi.
>
> Things it isn't:
>   hardware - too many people are seeing the same thing for that
>   driver specific - it happens on both ide and scsi, and with both sb and
>                     ess cards
>   anything blindingly obvious
>
> Currently I suspect something evil either in sound_core.c or sound_timer.c
> or (more likely) something scheduler related, but this is wild guessing.  Any
> ideas?
>
> --
> Mike <rickettm@ox.compsoc.net>
>
> Q:      What's yellow, and equivalent to the Axiom of Choice?
> A:      Zorn's Lemon.

--
Jonathan C. Masters                     (jonathan@oxlug.org)
                                        PGP: www.brookes.ac.uk/~95227860/KEY

           "Upon this rock I will build my church,
            and the gates of hell shall not prevail against it".

                 -- Matthew 16, 17-18




--------------1C7E2ED430416937048681A3--


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:03:56 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA11951
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:03:55 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02371
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:04:23 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:56406 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S42532AbPHKWcU>;
	Thu, 12 Aug 1999 01:32:20 +0300
Received:  by vger.rutgers.edu via listexpand id <S156703AbPHKWDG>;
	Wed, 11 Aug 1999 18:03:06 -0400
Received:  by vger.rutgers.edu id <S154275AbPHKVeC>;
	Wed, 11 Aug 1999 17:34:02 -0400
Received: from 1.0.0.127.in-addr.de ([212.8.197.180]:32125 "EHLO
        pointer.teuto.de") by vger.rutgers.edu with ESMTP
	id <S156099AbPHKUWa>; Wed, 11 Aug 1999 16:22:30 -0400
Received: (from lmb@localhost)
	by pointer.teuto.de (8.8.7/8.8.7) id WAA15513
	for linux-kernel@vger.rutgers.edu; Wed, 11 Aug 1999 22:22:27 +0200
Date:   Wed, 11 Aug 1999 22:22:27 +0200
From: Lars Marowsky-Bree <lmb@teuto.net>
To: linux-kernel@vger.rutgers.edu
Subject: kdb in deployment kernels?
Message-ID: <19990811222227.C15024@pointer.teuto.de>
Mail-Followup-To: linux-kernel@vger.rutgers.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/0.96.1i
X-Ctuhulu: HASTUR
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

Good morning,

I was thinking about deploying kdb in all of our major projects. The systems
already all have a serial console, and their operation is fairly critical.

Now, before someone kills me for suggesting that I want to deploy a debugging
patch in critical operations ;), that also means that we can track down bugs
which occur as efficient as possible.

If we find a bug and then switch to a debugging kernel on that box, we all
know what happens: first, we will not be able to reproduce the crash with the
debugging kernel, second, it will take ages for this to occur and occur on
some other box which is not running the debugging kernel yet, and third, this
also means an additional down time for switching to the debugging kernel (and
also the 2nd crash which we basically wait for even).

Now, in general having an extended debug utility on the serial console appears
like a real good idea. But I am not sure whether having kdb running in
"standby" affects performance much if it is not used or if there are any
additional caveats we may run into.

Does it interfere with a getty running on the serial console?

The default command sequence ^A appears to be a real bad choice, since it
means "move to beginning of line" in quite a few programs, and is already used
as a command sequence in minicom and screen, both very useful programs if
running on a serial console. I assume this can be changed easily?

Sincerely,
    Lars Marowsky-Bre
	
--
Lars Marowsky-Bre
Network Management

teuto.net Netzdienste GmbH - DPN Verbund-Partner

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:04:00 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA11985
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:03:58 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02378
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:04:26 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:23914 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S42220AbPHKWfm>;
	Thu, 12 Aug 1999 01:35:42 +0300
Received:  by vger.rutgers.edu via listexpand id <S156716AbPHKWDR>;
	Wed, 11 Aug 1999 18:03:17 -0400
Received:  by vger.rutgers.edu id <S153902AbPHKVdc>;
	Wed, 11 Aug 1999 17:33:32 -0400
Received: from kesteren.vuurwerk.nl ([194.178.232.59]:62383 "EHLO
        pc-homme.vuurwerk.nl") by vger.rutgers.edu with ESMTP
	id <S155499AbPHKUVl>; Wed, 11 Aug 1999 16:21:41 -0400
Received: from localhost (homme@localhost)
	by pc-homme.vuurwerk.nl (8.9.3/8.9.3) with ESMTP id WAA00997
	for <linux-kernel@vger.rutgers.edu>; Wed, 11 Aug 1999 22:23:21 +0200
X-Authentication-Warning: pc-homme.vuurwerk.nl: homme owned process doing -bs
Date:   Wed, 11 Aug 1999 22:23:21 +0200 (CEST)
From: "Homme R. Bitter" <homme@vuurwerk.nl>
To: linux-kernel@vger.rutgers.edu
Subject: Re: Gates of Hell
In-Reply-To: <37B1A81A.C87516AB@protozoa.com>
Message-ID: <Pine.LNX.4.10.9908112221500.983-100000@pc-homme.vuurwerk.nl>
X-Nonsense: This header is here for recreational purposes only
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

This person is obviously applying for a collection of coredums in his/her
email box....
Is there a way to make this list more closed ?

Cheers,

--
Homme R. Bitter

Anything that talks to you from inside the fridge should be discarded.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:04:04 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA12021
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:04:01 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02385
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:04:29 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:23914 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S42513AbPHKWjG>;
	Thu, 12 Aug 1999 01:39:06 +0300
Received:  by vger.rutgers.edu via listexpand id <S156748AbPHKWD2>;
	Wed, 11 Aug 1999 18:03:28 -0400
Received:  by vger.rutgers.edu id <S154895AbPHKVfj>;
	Wed, 11 Aug 1999 17:35:39 -0400
Received: from limes.hometree.net ([194.231.17.49]:26487 "EHLO
        limes.hometree.net") by vger.rutgers.edu with ESMTP
	id <S157509AbPHKUbH>; Wed, 11 Aug 1999 16:31:07 -0400
Received: (from bin@localhost)
	by limes.hometree.net (8.9.3/8.9.3) id WAA27673
	for linux-kernel@vger.rutgers.edu; Wed, 11 Aug 1999 22:07:58 +0200
X-Authentication-Warning: limes.hometree.net: bin set sender to hometree.ml.linux.kernel@mail.hometree.net using -f
Received: from GATEWAY by limes with netnews
	for linux-kernel@vger.rutgers.edu (linux-kernel@vger.rutgers.edu)
To: linux-kernel@vger.rutgers.edu
Date:   11 Aug 1999 22:07:57 +0200
From: "Henning P. Schmiedehausen" <hps@tanstaafl.de>
Message-ID: <7osl6t$ri$1@babsi.tanstaafl.de>
Organization: TANSTAAFL! Consulting
References: <14248.37968.303088.956251@desk.crynwr.com>, <Pine.LNX.4.10.9908071659550.498-100000@asdf.capslock.lan>
Reply-To: hps@tanstaafl.de
Subject: Re: First WinModem for Linux
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

mharris@meteng.on.ca (Mike A. Harris) writes:

>On Wed, 4 Aug 1999, Russell Nelson wrote:

>> > Woohoo! It is about time! I'm going to get rid of this damned
>> > real modem that I have now, and walk^H^H^H^H_RUN_ to the nearest
>> > store that sells PC-TEL Linmodems, and buy one immediately.
>>
>>That's short-sighted, Mike.  A Linmodem makes a perfectly fine telco
>>interface.  It takes no more CPU than a buffered UART running at
>>57600.  See http:/linmodems.org for reasonable uses of a linmodem.

>What a crock.  If a Winmodem/linmodem whatever software modem did
>not use up a lot of CPU resources, then it would not suck so bad.
>If the two use the same amount of CPU, then the ones with DSP's
>should remove the DSP, and run just fine without the host CPU
>doing any more work.

>Software modems are a hardware ripoff in any situation no matter
>how anyone explains it to me.  I see them as a total ripoff FOR
>EVERYONE.

Dear Mike,

>Tea, Earl Grey, Hot...

please take one of that and calm down. There are people with no choice
other than ignoring their builtin modems (think Laptop. Think Palmtop). 

There are some software-driven DSP modems (Lucent comes to mind),
which would be very nice having under Linux.

And there is the idea of pulling people with existing hardware from
Windows to Linux.

	Kind regards
		Henning


-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen --             hps@tanstaafl.de
TANSTAAFL! Consulting - Unix, Internet, Security      

Hutweide 15                   Fon.: 09131 / 50654-0    "There ain't no such
D-91054 Buckenhof             Fax.: 09131 / 50654-20    thing as a free Linux"

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:03:55 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA11606
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:03:29 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02302
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:03:57 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:34665 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S42792AbPHKVXj>;
	Thu, 12 Aug 1999 00:23:39 +0300
Received:  by vger.rutgers.edu via listexpand id <S160318AbPHKVFk>;
	Wed, 11 Aug 1999 17:05:40 -0400
Received:  by vger.rutgers.edu id <S156698AbPHKUCV>;
	Wed, 11 Aug 1999 16:02:21 -0400
Received: from finch-post-12.mail.demon.net ([194.217.242.41]:3159 "EHLO
        finch-post-12.mail.demon.net") by vger.rutgers.edu with ESMTP
	id <S154970AbPHKTez>; Wed, 11 Aug 1999 15:34:55 -0400
Received: from ricks.demon.co.uk ([194.222.2.48] helo=oakley.keble.ox.ac.uk)
	by finch-post-12.mail.demon.net with esmtp (Exim 2.12 #1)
	id 11Ee8L-000BQa-0C; Wed, 11 Aug 1999 19:34:02 +0000
Received: from localhost (mike@localhost)
	by oakley.keble.ox.ac.uk (8.9.3/8.9.3) with ESMTP id UAA02004;
	Wed, 11 Aug 1999 20:17:24 +0100
X-Authentication-Warning: oakley.keble.ox.ac.uk: mike owned process doing -bs
Date:   Wed, 11 Aug 1999 20:17:24 +0100 (BST)
From: Mike <mike@oxlug.org>
Reply-To: Mike Ricketts <rickettm@ox.compsoc.net>
To: linux-kernel@vger.rutgers.edu
cc: Wakko Warner <wakko@animx.eu.org>,
        Jonathan Masters <mastersj@periscope-systems.freeserve.co.uk>
Subject: Re: hdd & sound
In-Reply-To: <19990807114132.A978@animx.eu.org>
Message-ID: <Pine.LNX.4.10.9908112011350.1973-100000@oakley.keble.ox.ac.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

On Sat, 7 Aug 1999, Wakko Warner wrote:

> I'm noticing this one one of my machines.  When writing to a hard drive, the
> sound drags.  The machine I'm on has piix4 ide and an isa scsi card.  I'm
> playing sounds from the drive on the scsi card (aha1510 I think is the scsi
> card).  I tried writing to both an ide and scsi drive, both drag the sound. 
> Sound card is an SB16 pnp /w ide port (not disablable unfortunately).  I had
> a similar problem on an isa ide card playing sounds off of the hard drive
> (like 44k 16bit 2ch sound off the drive, sound card was an ess card).  My
> home box that this is happneing on is 2.2.7.  The one with the isa ide is no
> longer active, but it was running 2.0.36.
> 
I see much the same thing under (extremely) heavy disk load, both on
onboard piix4 ide, and on an onboard aic7??? scsi.

Things it isn't:
  hardware - too many people are seeing the same thing for that
  driver specific - it happens on both ide and scsi, and with both sb and
                    ess cards
  anything blindingly obvious

Currently I suspect something evil either in sound_core.c or sound_timer.c
or (more likely) something scheduler related, but this is wild guessing.  Any
ideas?

-- 
Mike <rickettm@ox.compsoc.net>

Q:	What's yellow, and equivalent to the Axiom of Choice?
A:	Zorn's Lemon.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:04:05 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA12065
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:04:05 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02393
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:04:32 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:29051 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S42824AbPHKWlS>;
	Thu, 12 Aug 1999 01:41:18 +0300
Received:  by vger.rutgers.edu via listexpand id <S156841AbPHKWDf>;
	Wed, 11 Aug 1999 18:03:35 -0400
Received:  by vger.rutgers.edu id <S154961AbPHKVfu>;
	Wed, 11 Aug 1999 17:35:50 -0400
Received: from funky.monkey.org ([152.160.231.196]:35062 "HELO
        funky.monkey.org") by vger.rutgers.edu with SMTP id <S157514AbPHKUcQ>;
	Wed, 11 Aug 1999 16:32:16 -0400
Received: by funky.monkey.org (Postfix, from userid 1035)
	id 5E6BF23D86; Wed, 11 Aug 1999 16:32:15 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by funky.monkey.org (Postfix) with ESMTP
	id 4911A15CC2; Wed, 11 Aug 1999 16:32:15 -0400 (EDT)
Date:   Wed, 11 Aug 1999 16:32:14 -0400 (EDT)
From: Chuck Lever <cel@monkey.org>
To: Steve Dodd <dirk@loth.demon.co.uk>
Cc: Linus Torvalds <torvalds@transmeta.com>, linux-kernel@vger.rutgers.edu
Subject: Re: filemap_nopage() tries to copy to page 0, eek.
In-Reply-To: <19990810090358.A139@lamia.loth.demon.co.uk>
Message-ID: <Pine.BSO.4.10.9908111626270.15093-100000@funky.monkey.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

the way i have fixed this is to strip out everything in the no_cached_page
branch of filemap_nopage except for the first few lines that implement the
cluster read.  just after the cluster read, use "goto retry_find;".

so do this:

no_cached_page:
	/*
	 * Try to read in an entire cluster at once.
	 */
...
	for (i = 1 << page_cluster; i > 0; --i, reada += PAGE_CACHE_SIZE)
		new_page = try_to_read_ahead(file, reada, new_page);

	goto retry_find;

page_not_uptodate:

...

On Tue, 10 Aug 1999, Steve Dodd wrote:
> I've just been chasing down the problem with writes to mmap()d areas hanging,
> and it turns out that filemap_nopage() will try to clobber page 0 if the
> page isn't found in the page cache and no_share is true:
> 
> no_cached_page:
>         .
>         .
>         .
>         /*
>          * Now it's ours and locked, we can do initial IO to it:
>          */
>         new_page = 0;
> 
> page_not_uptodate:
>         error = inode->i_op->readpage(file, page);
>         if (!error) {
>                 wait_on_page(page);
>                 if (PageError(page))
>                         goto page_read_error;
>                 goto success;
>         }
> 
> success:
>         old_page = page_address(page);
>         if (!no_share) {
>                 ...
>         }
> 
>         /*
>          * No sharing ... copy to the new page.
>          */
> 	if (!new_page)
> 		printk(KERN_CRIT "filemap_nopage(): erk, new_page == 0\n");
>         copy_page(new_page, old_page);
> 
> I don't claim to understand (yet) what the fix is; I'm also not on clear why
> the page fault handler just tries to re-enter itself, ultimately deadlocking
> on current->mm->mmap_sem -- does it show that I'm /way/ out of my depth
> here? ;-)

	- Chuck Lever
--
corporate:	<chuckl@netscape.com>
personal:	<chucklever@netscape.net> or <cel@monkey.org>

The Linux Scalability project:
	http://www.citi.umich.edu/projects/linux-scalability/


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:04:07 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA12095
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:04:07 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02400
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:04:35 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:38268 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S9624AbPHKWmJ>;
	Thu, 12 Aug 1999 01:42:09 +0300
Received:  by vger.rutgers.edu via listexpand id <S160149AbPHKWNb>;
	Wed, 11 Aug 1999 18:13:31 -0400
Received:  by vger.rutgers.edu id <S156860AbPHKWDn>;
	Wed, 11 Aug 1999 18:03:43 -0400
Received: from mail2.tor.accglobal.net ([204.92.55.104]:51404 "EHLO
        mail2.tor.accglobal.net") by vger.rutgers.edu with ESMTP
	id <S155183AbPHKVgb>; Wed, 11 Aug 1999 17:36:31 -0400
Received: from ppp-040.m2-2.ssm.ican.net ([206.248.78.40] helo=asdf.capslock.lan)
	by mail2.tor.accglobal.net with esmtp (Exim 2.11 #1)
	id 11Eg2v-0003TN-02; Wed, 11 Aug 1999 17:36:29 -0400
Received: from localhost (mharris@localhost)
	by asdf.capslock.lan (8.9.3/8.9.3) with ESMTP id RAA14403;
	Wed, 11 Aug 1999 17:35:31 -0400
X-Authentication-Warning: asdf.capslock.lan: mharris owned process doing -bs
Date:   Wed, 11 Aug 1999 17:35:31 -0400 (EDT)
From: "Mike A. Harris" <mharris@ican.net>
X-Sender: mharris@asdf.capslock.lan
To: Undisclosed recipients:;
Subject: Lost emails fixed.
Message-ID: <Pine.LNX.4.10.9908111729570.4988-100000@asdf.capslock.lan>
Organization: Capslock Computer Consulting
X-Unexpected-Header: The Spanish Inquisition
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

I just determined why I was not getting the mailing list.  I
changed permissions on my incoming mail directory by accident,
and the mail was being accepted by fetchmail, sent to sendmail,
deleted from my ISP's, and then forwarded to procmail which could
not put the mail into my inbox so deleted it.

ARGH!!!!!

I've lost 3 days of email at least, however some stuff did get
through.

Could anyone that has sent me an email in the last few days,
please resend the messages again?  This goes for any of the
mailing lists that I'm on.

Also, anyone who knows someone that has sent something to me,
please forward this to them as well.

procmail is a useful subsystem, however it would be nice if it
would file email that cant be delivered into a separate folder or
something instead of deleting it.

Anyone know how to do that to prevent any possibility of a
repeat occurance in the future?


--
Mike A. Harris                   Linux advocate      GNU advocate
Computer Consultant                          Open Source advocate  

Tea, Earl Grey, Hot...



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:03:58 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA11833
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:03:46 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02347
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:04:14 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:7718 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S42898AbPHKWQQ>;
	Thu, 12 Aug 1999 01:16:16 +0300
Received:  by vger.rutgers.edu via listexpand id <S156343AbPHKViK>;
	Wed, 11 Aug 1999 17:38:10 -0400
Received:  by vger.rutgers.edu id <S154802AbPHKUgp>;
	Wed, 11 Aug 1999 16:36:45 -0400
Received: from finch-post-12.mail.demon.net ([194.217.242.41]:3600 "EHLO
        finch-post-12.mail.demon.net") by vger.rutgers.edu with ESMTP
	id <S154369AbPHKTkk>; Wed, 11 Aug 1999 15:40:40 -0400
Received: from ricks.demon.co.uk ([194.222.2.48] helo=oakley.keble.ox.ac.uk)
	by finch-post-12.mail.demon.net with esmtp (Exim 2.12 #1)
	id 11EeEB-000BlV-0C; Wed, 11 Aug 1999 19:40:03 +0000
Received: from localhost (mike@localhost)
	by oakley.keble.ox.ac.uk (8.9.3/8.9.3) with ESMTP id UAA02593;
	Wed, 11 Aug 1999 20:47:30 +0100
X-Authentication-Warning: oakley.keble.ox.ac.uk: mike owned process doing -bs
Date:   Wed, 11 Aug 1999 20:47:30 +0100 (BST)
From: Mike <mike@oxlug.org>
Reply-To: Mike Ricketts <rickettm@ox.compsoc.net>
To: Marc Mutz <Marc@mutz.com>
cc: Secret Squirrel <secret_squirrel@nym.alias.net>,
        linux-kernel@vger.rutgers.edu
Subject: Re: Modular Kernel Security
In-Reply-To: <37B0A54C.979620E8@Mutz.com>
Message-ID: <Pine.LNX.4.10.9908112046500.2135-100000@oakley.keble.ox.ac.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

On Tue, 10 Aug 1999, Marc Mutz wrote:

> > AFAIK cipe (encripted IP tunneling) only comes as modules.
> > 
> Just checked: CIPE can only be included in the kernel, not compiled as
> module (says make xconfig). This is with patch int-2.2.10-4.
> 
Yes, but try compiling it - it creates a module when you say 'Y' to the
option in menuconfig

-- 
Mike <rickettm@ox.compsoc.net>

"The great question... which I have not been able to answer... is, `What does 
woman want?'"
-- Sigmund Freud


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:04:15 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA12173
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:04:14 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02410
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:04:41 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:38268 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S41978AbPHKWqw>;
	Thu, 12 Aug 1999 01:46:52 +0300
Received:  by vger.rutgers.edu via listexpand id <S160643AbPHKWa3>;
	Wed, 11 Aug 1999 18:30:29 -0400
Received:  by vger.rutgers.edu id <S156049AbPHKV7G>;
	Wed, 11 Aug 1999 17:59:06 -0400
Received: from ARASAN.MIT.EDU ([18.243.1.13]:1158 "EHLO arasan.mit.edu")
	by vger.rutgers.edu with ESMTP id <S156851AbPHKVQ2>;
	Wed, 11 Aug 1999 17:16:28 -0400
Received: (from whiting@localhost)
	by arasan.mit.edu (8.9.3/8.8.5) id RAA06894;
	Wed, 11 Aug 1999 17:16:42 -0400
From: whiting@mit.edu
Message-Id: <199908112116.RAA06894@arasan.mit.edu>
To: linux-kernel@vger.rutgers.edu
Subject: [PATCH] for readability in raid5.c
Date:   Wed, 11 Aug 1999 17:16:41 EDT
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

This line is a little unclear. Also, this will only be one division instead
of two (unless gcc already optimizes to this).

Also, is there any chance of a problem from rounding? Or is the buffer
always going to be a multiple of 8*sizeof(long)?


--- /tmp/raid5.c        Fri May  8 03:17:13 1998
+++ drivers/block/raid5.c       Wed Aug 11 16:55:49 1999
@@ -750,7 +750,7 @@
 #else
 static void xor_block(struct buffer_head *dest, struct buffer_head *source)
 {
-       long lines = dest->b_size / (sizeof (long)) / 8, i;
+       long lines = dest->b_size / ( 8 * (sizeof (long)) ), i;
        long *destp = (long *) dest->b_data, *sourcep = (long *) source->b_data;
 
        for (i = lines; i > 0; i--) {



James

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:04:15 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA12129
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:04:10 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02406
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:04:38 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:38268 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S42095AbPHKWpV>;
	Thu, 12 Aug 1999 01:45:21 +0300
Received:  by vger.rutgers.edu via listexpand id <S154998AbPHKWaQ>;
	Wed, 11 Aug 1999 18:30:16 -0400
Received:  by vger.rutgers.edu id <S155630AbPHKW3x>;
	Wed, 11 Aug 1999 18:29:53 -0400
Received: from [38.149.17.171] ([38.149.17.171]:1964 "HELO ltc.com")
	by vger.rutgers.edu with SMTP id <S155896AbPHKV5U>;
	Wed, 11 Aug 1999 17:57:20 -0400
Received: from PREFECT (PREFECT [38.149.17.184]) by ltc.com (NTMail 3.03.0017/1.afdd) with ESMTP id xa309865 for <linux-kernel@vger.rutgers.edu>; Wed, 11 Aug 1999 18:01:55 -0400
Message-ID: <005101bee444$0c310200$b8119526@ltc.com>
From: "Bradley D. LaRonde" <brad@ltc.com>
To: <linux-kernel@vger.rutgers.edu>
References: <000f01bee3ac$4037a060$b8119526@ltc.com>
Subject: initrd broken (was Re: 2.3.9+ and initrd)
Date:   Wed, 11 Aug 1999 17:54:12 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

I'm pretty sure it's broken.

I think it got broke along with the other fs stuff around 2.3.6.  What
happened back then that broke the the filesystems?  I will attempt to fix
it, but some insight would be helpful.

Regards,
Brad

----- Original Message -----
From: Bradley D. LaRonde <brad@ltc.com>
To: <linux-kernel@vger.rutgers.edu>
Sent: Tuesday, August 10, 1999 11:47 PM
Subject: 2.3.9+ and initrd


> Does anyone have initrd working in 2.3.9 or later?
>
> Regards,
> Brad
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:04:21 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA12260
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:04:20 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02415
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:04:44 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:18205 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S9726AbPHKWyq>;
	Thu, 12 Aug 1999 01:54:46 +0300
Received:  by vger.rutgers.edu via listexpand id <S156648AbPHKWDA>;
	Wed, 11 Aug 1999 18:03:00 -0400
Received:  by vger.rutgers.edu id <S154815AbPHKVf1>;
	Wed, 11 Aug 1999 17:35:27 -0400
Received: from cx425802-a.blvue1.ne.home.com ([24.0.54.216]:1272 "EHLO
        wr5z.localdomain") by vger.rutgers.edu with ESMTP
	id <S156413AbPHKU3c>; Wed, 11 Aug 1999 16:29:32 -0400
Received: from localhost (tmolina@localhost)
	by wr5z.localdomain (8.9.3/8.9.3) with ESMTP id PAA05117
	for <linux-kernel@vger.rutgers.edu>; Wed, 11 Aug 1999 15:29:33 -0500
X-Authentication-Warning: wr5z.localdomain: tmolina owned process doing -bs
Date:   Wed, 11 Aug 1999 15:29:33 -0500 (CDT)
From: Thomas Molina <tmolina@home.com>
X-Sender: tmolina@wr5z.localdomain
To: linux-kernel@vger.rutgers.edu
Subject: 2.3.13 pci_namedevice compile error
Message-ID: <Pine.LNX.4.10.9908111526430.5064-100000@wr5z.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

I get the following error when compiling 2.3.13:

drivers/pci/pci.a(pci.o): In function `pci_scan_bus':
pci.o(.text.init+0x261): undefined reference to `pci_namedevice'
make: *** [vmlinux] Error 1

I also got the infamous error under one configuration:

ncr53c8xx.c: In function `pci_get_base_address':
ncr53c8xx.c:9636: structure has no member named `base_address'
 
smbfs doesn't compile, but I understand that is still broken, so I'm not
worried.



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:04:24 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA12297
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:04:23 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02422
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:04:51 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:43296 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S9377AbPHKXCc>;
	Thu, 12 Aug 1999 02:02:32 +0300
Received:  by vger.rutgers.edu via listexpand id <S154000AbPHKWRf>;
	Wed, 11 Aug 1999 18:17:35 -0400
Received:  by vger.rutgers.edu id <S156034AbPHKVqI>;
	Wed, 11 Aug 1999 17:46:08 -0400
Received: from fenrus.demon.nl ([212.238.78.16]:35814 "EHLO fenrus.demon.nl")
	by vger.rutgers.edu with ESMTP id <S154040AbPHKUlU>;
	Wed, 11 Aug 1999 16:41:20 -0400
Received: from root by fenrus.demon.nl with local (Exim 2.05 #1 (Debian))
	id 11EfBI-0002nW-00; Wed, 11 Aug 1999 22:41:04 +0200
To: prgrssor@cs.bu.edu (Stanislav Krasilovskiy)
CC: linux-kernel@vger.rutgers.edu
Subject: Re: Unkillable Process
X-Newsgroups: fenrus.linux.kernel
In-Reply-To: <Pine.GSO.4.03.9908111319260.3444-100000@csa.bu.edu>
User-Agent: tin/pre-1.4-981002 ("Phobia") (UNIX) (Linux/2.2.10 (i586))
Message-Id: <E11EfBI-0002nW-00@fenrus.demon.nl>
From: Arjan van de Ven <root@fenrus.demon.nl>
Date:   Wed, 11 Aug 1999 22:41:04 +0200
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

Hi,
> I am using a call to kernel_thread to create a process from within a
> system call.  This process loops forever doing something, and waits for a
> semaphore inside the loop using down_interruptible().  I am having a hard
> time killing this process using "kill -" TERM or 9, 

As soon as your thread is sent a signal, the down_interruptible should fall
through. The only thing you have to do is break out of YOUR loop when
signal_pending(current) is true.

Greetings, 
   Arjan van de Ven


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:04:28 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA12339
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:04:27 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02428
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:04:54 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:7473 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S9949AbPHKXHd>;
	Thu, 12 Aug 1999 02:07:33 +0300
Received:  by vger.rutgers.edu via listexpand id <S154846AbPHKW3S>;
	Wed, 11 Aug 1999 18:29:18 -0400
Received:  by vger.rutgers.edu id <S155440AbPHKV4z>;
	Wed, 11 Aug 1999 17:56:55 -0400
Received: from sonne.darmstadt.gmd.de ([141.12.62.20]:38295 "EHLO
        sonne.darmstadt.gmd.de") by vger.rutgers.edu with ESMTP
	id <S154846AbPHKVDL>; Wed, 11 Aug 1999 17:03:11 -0400
Received: from darmstadt.gmd.de (ploesser-isdn [141.12.156.219])
	by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id XAA06729;
	Wed, 11 Aug 1999 23:02:35 +0200 (MET DST)
Message-ID: <37B1E409.696F5B8D@darmstadt.gmd.de>
Date:   Wed, 11 Aug 1999 22:58:49 +0200
From: Joerg Pommnitz <pommnitz@darmstadt.gmd.de>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.11 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-kernel@vger.rutgers.edu
CC: groudier@club-internet.fr
Subject: 2.3.13 ncr53c8xx.c: structure has no member named `base_address' 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

Trying to compile Linux-2.3.13 I get:
ncr53c8xx.c: In function `pci_get_base_address':
ncr53c8xx.c:9636: structure has no member named `base_address'
make[3]: *** [ncr53c8xx.o] Error 1

Regards
	Joerg

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:04:31 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA12387
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:04:31 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02436
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:04:57 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:55096 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S9212AbPHKXK0>;
	Thu, 12 Aug 1999 02:10:26 +0300
Received:  by vger.rutgers.edu via listexpand id <S155127AbPHKW3Y>;
	Wed, 11 Aug 1999 18:29:24 -0400
Received:  by vger.rutgers.edu id <S155535AbPHKV5K>;
	Wed, 11 Aug 1999 17:57:10 -0400
Received: from int2.nea-fast.com ([208.241.120.39]:32943 "EHLO
        int2.nea-fast.com") by vger.rutgers.edu with ESMTP
	id <S160238AbPHKVFH>; Wed, 11 Aug 1999 17:05:07 -0400
Received: from ext1.nea-fast.com (ext1.nea-fast.com [208.241.120.230])
	by int2.nea-fast.com (8.8.8+Sun/8.8.8) with ESMTP id RAA00105;
	Wed, 11 Aug 1999 17:04:40 -0400 (EDT)
Received: from pobox.com (adsl-77-228-201.atl.bellsouth.net [216.77.228.201])
	by ext1.nea-fast.com (8.8.8+Sun/8.8.8) with ESMTP id RAA01934;
	Wed, 11 Aug 1999 17:07:29 -0400 (EDT)
Message-ID: <37B1E567.996B4136@pobox.com>
Date:   Wed, 11 Aug 1999 17:04:39 -0400
From: Jeff Garzik <jgarzik@pobox.com>
Organization: none
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.11pre6 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
CC: Geert Uytterhoeven <Geert.Uytterhoeven@cs.kuleuven.ac.be>,
        torvalds@transmeta.com, mj@ucw.cz, VANDROVE@vc.cvut.cz,
        linux-kernel@vger.rutgers.edu
Subject: Re: New resources - pls, explain :-(
References: <E11EZ58-0004H6-00@the-village.bc.nu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

Alan Cox wrote:
> > Remember, readl() and friends are to be used for PCI mapped memory only! If you
> > want to generalize, accesses have to be done through e.g. device->readl().

> readl() is for all busses.

So is this "the standard"?  It would be nice if I could make this
assumption in the future.


> If you wnt a PCI bus specific readl it should be called pci_readl(). Perhaps
> thats the root of the problem. Define pci_readl() to be strictly ordered,
> do the right byte swapping and be done with it. Define readl() to change
> no order.

Ah, wouldn't it be nice...  Has anyone talked about making a concrete
decision on this issue?

I like rth's suggestion about having bus-specific ioremap() instead of a
generic one; then all readl() etc. would go through that, and do "the
right thing" for that bus.  One could add "bigendian_writel()" and
"littleendian_writel()" to satisfy the Linus constraint of making
unusual usage of writel() obvious.

Regards,

	Jeff




-- 
Entropy requires no maintenance.
                -- Markoff Chaney

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:04:47 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA12582
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:04:47 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02445
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:05:01 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:22593 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S9741AbPHKXOK>;
	Thu, 12 Aug 1999 02:14:10 +0300
Received:  by vger.rutgers.edu via listexpand id <S155930AbPHKW3i>;
	Wed, 11 Aug 1999 18:29:38 -0400
Received:  by vger.rutgers.edu id <S155458AbPHKV4q>;
	Wed, 11 Aug 1999 17:56:46 -0400
Received: from chaos.analogic.com ([204.178.40.224]:1138 "EHLO
        chaos.analogic.com") by vger.rutgers.edu with ESMTP
	id <S155402AbPHKU6d>; Wed, 11 Aug 1999 16:58:33 -0400
Received: (from root@localhost) by chaos.analogic.com (8.9.3/8.7.3) id QAA06922; Wed, 11 Aug 1999 16:56:55 -0400
Date:   Wed, 11 Aug 1999 16:56:54 -0400 (EDT)
From: "Richard B. Johnson" <root@chaos.analogic.com>
Reply-To: root@chaos.analogic.com
To: Linux kernel <linux-kernel@vger.rutgers.edu>
Subject: 2.3.13 Compile errors
Message-ID: <Pine.LNX.3.95.990811165455.6877A-100000@chaos.analogic.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig


First error encountered in `make modules`

make -C scsi modules
gcc -D__KERNEL__ -I/usr/src/linux-2.3.13/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer  -D__SMP__ -pipe -fno-strength-reduce  -DCPU=686 -march=i686 -DMODULE   -c -o scsi.o scsi.c
scsi.c:423: parse error before string constant
scsi.c:423: warning: type defaults to `int' in declaration of `__setup'
scsi.c:423: warning: function declaration isn't a prototype
scsi.c:423: warning: data definition has no type or storage class
scsi.c:445: parse error before string constant
scsi.c:445: warning: type defaults to `int' in declaration of `__setup'
scsi.c:445: warning: function declaration isn't a prototype
scsi.c:445: warning: data definition has no type or storage class
scsi.c:410: warning: `scsi_logging_setup' defined but not used
scsi.c:432: warning: `scsi_luns_setup' defined but not used
make[2]: *** [scsi.o] Error 1
make[2]: Leaving directory `/usr/src/linux-2.3.13/drivers/scsi'
make[1]: *** [_modsubdir_scsi] Error 2
make[1]: Leaving directory `/usr/src/linux-2.3.13/drivers'
make: *** [_mod_drivers] Error 2


Next error encountered in `make modules`


gcc -D__KERNEL__ -I/usr/src/linux-2.3.13/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer  -D__SMP__ -pipe -fno-strength-reduce  -DCPU=686 -march=i686 -DMODULE   -c -o imm.o imm.c
imm.c: In function `imm_detect':
imm.c:169: `PARPORT_MODE_PCPS2' undeclared (first use in this function)
imm.c:169: (Each undeclared identifier is reported only once
imm.c:169: for each function it appears in.)
imm.c:172: `PARPORT_MODE_PCECPPS2' undeclared (first use in this function)
imm.c:176: `PARPORT_MODE_PCECPEPP' undeclared (first use in this function)
make[2]: *** [imm.o] Error 1
make[2]: Leaving directory `/usr/src/linux-2.3.13/drivers/scsi'
make[1]: *** [_modsubdir_scsi] Error 2
make[1]: Leaving directory `/usr/src/linux-2.3.13/drivers'
make: *** [_mod_drivers] Error 2


.config

#
# Automatically generated make config: don't edit
#

#
# Code maturity level options
#
# CONFIG_EXPERIMENTAL is not set

#
# Processor type and features
#
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
CONFIG_M686=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_TSC=y
CONFIG_X86_GOOD_APIC=y
CONFIG_1GB=y
# CONFIG_2GB is not set
# CONFIG_MATH_EMULATION is not set
# CONFIG_MTRR is not set
CONFIG_SMP=y

#
# Loadable module support
#
CONFIG_MODULES=y
# CONFIG_MODVERSIONS is not set
CONFIG_KMOD=y

#
# General setup
#
CONFIG_NET=y
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_QUIRKS=y
CONFIG_PCI_OLD_PROC=y
# CONFIG_MCA is not set
# CONFIG_VISWS is not set
CONFIG_X86_IO_APIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_SYSVIPC=y
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y
CONFIG_BINFMT_AOUT=m
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=m
CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
# CONFIG_PARPORT_PC_FIFO is not set
# CONFIG_PARPORT_AMIGA is not set
# CONFIG_PARPORT_MFC3 is not set
# CONFIG_PARPORT_ATARI is not set
CONFIG_PARPORT_OTHER=y
# CONFIG_PARPORT_1284 is not set
# CONFIG_APM is not set

#
# I2O device support
#
# CONFIG_I2O is not set
# CONFIG_I2O_PCI is not set
# CONFIG_I2O_BLOCK is not set
# CONFIG_I2O_LAN is not set
# CONFIG_I2O_SCSI is not set
# CONFIG_I2O_PROC is not set

#
# Block devices
#
CONFIG_BLK_DEV_FD=y
CONFIG_BLK_DEV_IDE=m

#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_HD_IDE is not set
CONFIG_BLK_DEV_IDEDISK=m
# CONFIG_IDEDISK_MULTI_MODE is not set
CONFIG_BLK_DEV_IDECD=m
CONFIG_BLK_DEV_IDETAPE=m
CONFIG_BLK_DEV_IDEFLOPPY=m
CONFIG_BLK_DEV_IDESCSI=m
# CONFIG_BLK_DEV_CMD640 is not set
# CONFIG_BLK_DEV_RZ1000 is not set
CONFIG_BLK_DEV_IDEPCI=y
# CONFIG_BLK_DEV_IDEDMA_PCI is not set
# CONFIG_BLK_DEV_OFFBOARD is not set
# CONFIG_BLK_DEV_AEC6210 is not set
# CONFIG_BLK_DEV_HPT34X is not set
# CONFIG_BLK_DEV_HPT366 is not set
# CONFIG_BLK_DEV_PIIX is not set
# CONFIG_BLK_DEV_SIS5513 is not set
CONFIG_IDE_CHIPSETS=y

#
# Note: most of these also require special kernel boot parameters
#
# CONFIG_BLK_DEV_4DRIVES is not set
# CONFIG_BLK_DEV_ALI14XX is not set
# CONFIG_BLK_DEV_DTC2278 is not set
# CONFIG_BLK_DEV_HT6560B is not set
# CONFIG_BLK_DEV_QD6580 is not set
# CONFIG_BLK_DEV_UMC8672 is not set
# CONFIG_BLK_CPQ_DA is not set

#
# Additional Block Devices
#
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_NBD=m
# CONFIG_BLK_DEV_MD is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_BLK_DEV_XD=m
CONFIG_PARIDE_PARPORT=m
CONFIG_PARIDE=m

#
# Parallel IDE high-level drivers
#
CONFIG_PARIDE_PD=m
CONFIG_PARIDE_PCD=m
CONFIG_PARIDE_PF=m
CONFIG_PARIDE_PT=m
CONFIG_PARIDE_PG=m

#
# Parallel IDE protocol modules
#
CONFIG_PARIDE_ATEN=m
CONFIG_PARIDE_BPCK=m
CONFIG_PARIDE_COMM=m
CONFIG_PARIDE_DSTR=m
CONFIG_PARIDE_FIT2=m
CONFIG_PARIDE_FIT3=m
CONFIG_PARIDE_EPAT=m
CONFIG_PARIDE_EPIA=m
CONFIG_PARIDE_FRIQ=m
CONFIG_PARIDE_FRPW=m
CONFIG_PARIDE_KBIC=m
CONFIG_PARIDE_KTTI=m
CONFIG_PARIDE_ON20=m
CONFIG_PARIDE_ON26=m
CONFIG_BLK_DEV_IDE_MODES=y
# CONFIG_BLK_DEV_HD is not set

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_NETLINK=y
CONFIG_RTNETLINK=y
CONFIG_NETLINK_DEV=y
CONFIG_FIREWALL=y
CONFIG_FILTER=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_RTNETLINK=y
CONFIG_NETLINK=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_MULTIPATH=y
CONFIG_IP_ROUTE_TOS=y
# CONFIG_IP_ROUTE_VERBOSE is not set
CONFIG_IP_ROUTE_LARGE_TABLES=y
CONFIG_IP_ROUTE_NAT=y
# CONFIG_IP_PNP is not set
CONFIG_IP_FIREWALL=y
CONFIG_IP_FIREWALL_NETLINK=y
CONFIG_NETLINK_DEV=y
CONFIG_IP_ALWAYS_DEFRAG=y
CONFIG_IP_ROUTE_FWMARK=y
CONFIG_IP_TRANSPARENT_PROXY=y
CONFIG_IP_MASQUERADE=y

#
# Protocol-specific masquerading support will be built as modules.
#
CONFIG_IP_MASQUERADE_ICMP=y

#
# Protocol-specific masquerading support will be built as modules.
#
CONFIG_IP_ROUTER=y
CONFIG_NET_IPIP=m
CONFIG_NET_IPGRE=m
# CONFIG_NET_IPGRE_BROADCAST is not set
CONFIG_IP_MROUTE=y
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
CONFIG_IP_ALIAS=y
# CONFIG_SYN_COOKIES is not set

#
# (it is safe to leave these untouched)
#
CONFIG_INET_RARP=m
CONFIG_SKB_LARGE=y

#
#  
#
CONFIG_IPX=m
# CONFIG_IPX_INTERN is not set
CONFIG_ATALK=m

#
# SCSI support
#
CONFIG_SCSI=m

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=m
CONFIG_CHR_DEV_ST=m
CONFIG_BLK_DEV_SR=m
# CONFIG_BLK_DEV_SR_VENDOR is not set
CONFIG_CHR_DEV_SG=m

#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
# CONFIG_SCSI_MULTI_LUN is not set
# CONFIG_SCSI_CONSTANTS is not set
# CONFIG_SCSI_LOGGING is not set

#
# SCSI low-level drivers
#
CONFIG_SCSI_7000FASST=m
CONFIG_SCSI_ACARD=m
CONFIG_SCSI_AHA152X=m
CONFIG_SCSI_AHA1542=m
CONFIG_SCSI_AHA1740=m
CONFIG_SCSI_AIC7XXX=m
# CONFIG_AIC7XXX_TCQ_ON_BY_DEFAULT is not set
CONFIG_AIC7XXX_CMDS_PER_DEVICE=8
CONFIG_AIC7XXX_PROC_STATS=y
CONFIG_AIC7XXX_RESET_DELAY=5
CONFIG_SCSI_ADVANSYS=m
CONFIG_SCSI_IN2000=m
CONFIG_SCSI_AM53C974=m
# CONFIG_SCSI_MEGARAID is not set
CONFIG_SCSI_BUSLOGIC=m
CONFIG_SCSI_OMIT_FLASHPOINT=y
CONFIG_SCSI_DTC3280=m
CONFIG_SCSI_EATA=m
CONFIG_SCSI_EATA_TAGGED_QUEUE=y
# CONFIG_SCSI_EATA_LINKED_COMMANDS is not set
CONFIG_SCSI_EATA_MAX_TAGS=16
CONFIG_SCSI_EATA_DMA=m
CONFIG_SCSI_EATA_PIO=m
CONFIG_SCSI_FUTURE_DOMAIN=m
CONFIG_SCSI_GDTH=m
CONFIG_SCSI_GENERIC_NCR5380=m
# CONFIG_SCSI_GENERIC_NCR53C400 is not set
CONFIG_SCSI_G_NCR5380_PORT=y
# CONFIG_SCSI_G_NCR5380_MEM is not set
CONFIG_SCSI_INITIO=m
CONFIG_SCSI_INIA100=m
CONFIG_SCSI_PPA=m
CONFIG_SCSI_IMM=m
# CONFIG_SCSI_IZIP_EPP16 is not set
# CONFIG_SCSI_IZIP_SLOW_CTR is not set
CONFIG_SCSI_NCR53C406A=m
CONFIG_SCSI_SYM53C416=m
CONFIG_SCSI_NCR53C7xx=m
# CONFIG_SCSI_NCR53C7xx_sync is not set
# CONFIG_SCSI_NCR53C7xx_FAST is not set
# CONFIG_SCSI_NCR53C7xx_DISCONNECT is not set
CONFIG_SCSI_NCR53C8XX=m
# CONFIG_SCSI_SYM53C8XX is not set
CONFIG_SCSI_NCR53C8XX_DEFAULT_TAGS=8
CONFIG_SCSI_NCR53C8XX_MAX_TAGS=32
CONFIG_SCSI_NCR53C8XX_SYNC=20
# CONFIG_SCSI_NCR53C8XX_PROFILE is not set
# CONFIG_SCSI_NCR53C8XX_IOMAPPED is not set
CONFIG_SCSI_PAS16=m
# CONFIG_SCSI_PCI2000 is not set
# CONFIG_SCSI_PCI2220I is not set
# CONFIG_SCSI_PSI240I is not set
CONFIG_SCSI_QLOGIC_FAS=m
CONFIG_SCSI_QLOGIC_ISP=m
CONFIG_SCSI_QLOGIC_FC=m
CONFIG_SCSI_SEAGATE=m
CONFIG_SCSI_DC390T=m
# CONFIG_SCSI_DC390T_NOGENSUPP is not set
CONFIG_SCSI_T128=m
CONFIG_SCSI_U14_34F=m
# CONFIG_SCSI_U14_34F_LINKED_COMMANDS is not set
CONFIG_SCSI_U14_34F_MAX_TAGS=8
CONFIG_SCSI_ULTRASTOR=m

#
# Network device support
#
CONFIG_NETDEVICES=y

#
# ARCnet devices
#
CONFIG_ARCNET=m
# CONFIG_ARCNET_ETH is not set
# CONFIG_ARCNET_1051 is not set
CONFIG_ARCNET_COM90xx=m
CONFIG_ARCNET_COM90xxIO=m
CONFIG_ARCNET_RIM_I=m
CONFIG_ARCNET_COM20020=m
CONFIG_DUMMY=m
CONFIG_EQUALIZER=m

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_NET_VENDOR_3COM=y
# CONFIG_EL1 is not set
CONFIG_EL2=m
CONFIG_ELPLUS=m
CONFIG_EL3=m
CONFIG_3C515=m
CONFIG_VORTEX=m
CONFIG_LANCE=m
# CONFIG_NET_VENDOR_SMC is not set
# CONFIG_NET_VENDOR_RACAL is not set
CONFIG_NET_ISA=y
CONFIG_AT1700=m
CONFIG_E2100=m
CONFIG_DEPCA=m
CONFIG_EWRK3=m
CONFIG_EEXPRESS=m
CONFIG_EEXPRESS_PRO=m
CONFIG_FMV18X=m
CONFIG_HPLAN_PLUS=m
CONFIG_HPLAN=m
CONFIG_HP100=m
CONFIG_NE2000=m
# CONFIG_SK_G16 is not set
CONFIG_NET_EISA=y
CONFIG_PCNET32=m
CONFIG_APRICOT=m
CONFIG_CS89x0=m
CONFIG_DE4X5=m
CONFIG_DEC_ELCP=m
CONFIG_DGRS=m
CONFIG_EEXPRESS_PRO100=m
CONFIG_NE2K_PCI=m
CONFIG_TLAN=m
CONFIG_VIA_RHINE=m
# CONFIG_NET_POCKET is not set
# CONFIG_FDDI is not set

#
# Appletalk devices
#
# CONFIG_LTPC is not set
# CONFIG_COPS is not set
# CONFIG_IPDDP is not set
CONFIG_PLIP=m
CONFIG_PPP=m
CONFIG_PPP_ASYNC=m
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_BSDCOMP=m
CONFIG_SLIP=m
# CONFIG_SLIP_COMPRESSED is not set
# CONFIG_SLIP_SMART is not set
# CONFIG_SLIP_MODE_SLIP6 is not set
# CONFIG_NET_RADIO is not set

#
# Token ring devices
#
# CONFIG_TR is not set

#
# Wan interfaces
#
# CONFIG_HOSTESS_SV11 is not set
# CONFIG_COSA is not set
# CONFIG_SEALEVEL_4021 is not set
# CONFIG_DLCI is not set
# CONFIG_WAN_DRIVERS is not set
# CONFIG_LAPBETHER is not set
# CONFIG_X25_ASY is not set

#
# Amateur Radio support
#
# CONFIG_HAMRADIO is not set

#
# IrDA subsystem support
#
# CONFIG_IRDA is not set

#
# ISDN subsystem
#
# CONFIG_ISDN is not set

#
# Old CD-ROM drivers (not SCSI, not IDE)
#
# CONFIG_CD_NO_IDESCSI is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_SERIAL=y
# CONFIG_SERIAL_CONSOLE is not set
# CONFIG_SERIAL_EXTENDED is not set
# CONFIG_SERIAL_NONSTANDARD is not set
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=256
CONFIG_PRINTER=m
# CONFIG_LP_CONSOLE is not set
# CONFIG_PPDEV is not set

#
# Mice
#
# CONFIG_BUSMOUSE is not set
# CONFIG_MOUSE is not set
CONFIG_QIC02_TAPE=m
# CONFIG_QIC02_DYNCONF is not set

#
#    Edit configuration parameters in ./include/linux/tpqic02.h!
#
# CONFIG_VIDEO_ZORAN is not set
# CONFIG_VIDEO_BUZ is not set
# CONFIG_VIDEO_LML33 is not set
# CONFIG_WATCHDOG is not set
CONFIG_NVRAM=m
# CONFIG_RTC is not set

#
# Video For Linux
#
# CONFIG_VIDEO_DEV is not set

#
# Joystick support
#
# CONFIG_JOYSTICK is not set
# CONFIG_DTLK is not set

#
# Ftape, the floppy tape device driver
#
CONFIG_FTAPE=m
CONFIG_ZFTAPE=m
CONFIG_ZFT_DFLT_BLK_SZ=10240

#
# The compressor will be built as a module only!
#
CONFIG_ZFT_COMPRESSOR=m
# CONFIG_FT_PROC_FS is not set
CONFIG_FT_NORMAL_DEBUG=y
# CONFIG_FT_FULL_DEBUG is not set
# CONFIG_FT_NO_TRACE is not set
# CONFIG_FT_NO_TRACE_AT_ALL is not set

#
# Hardware configuration
#
CONFIG_FT_STD_FDC=y
# CONFIG_FT_MACH2 is not set
# CONFIG_FT_PROBE_FC10 is not set
# CONFIG_FT_ALT_FDC is not set

#
# ONLY for DEC Alpha architectures
#
CONFIG_FT_ALPHA_CLOCK=0

#
# USB drivers - not for the faint of heart
#
# CONFIG_USB is not set

#
# Filesystems
#
CONFIG_QUOTA=y
CONFIG_AUTOFS_FS=m
CONFIG_AFFS_FS=m
CONFIG_HFS_FS=m
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
# CONFIG_UMSDOS_FS is not set
CONFIG_VFAT_FS=m
CONFIG_ISO9660_FS=m
CONFIG_JOLIET=y
CONFIG_MINIX_FS=m
CONFIG_NTFS_FS=m
CONFIG_HPFS_FS=m
CONFIG_PROC_FS=y
CONFIG_DEVPTS_FS=y
CONFIG_ROMFS_FS=m
CONFIG_EXT2_FS=y
CONFIG_SYSV_FS=m
CONFIG_UFS_FS=m
CONFIG_UFS_FS_WRITE=y

#
# Network File Systems
#
CONFIG_CODA_FS=m
CONFIG_NFS_FS=m
CONFIG_SUNRPC=m
CONFIG_LOCKD=m
CONFIG_SMB_FS=m
CONFIG_NCP_FS=m
CONFIG_NCPFS_PACKET_SIGNING=y
CONFIG_NCPFS_IOCTL_LOCKING=y
CONFIG_NCPFS_STRONG=y
CONFIG_NCPFS_NFS_NS=y
CONFIG_NCPFS_OS2_NS=y
# CONFIG_NCPFS_SMALLDOS is not set
CONFIG_NCPFS_MOUNT_SUBDIR=y
# CONFIG_NCPFS_NLS is not set
# CONFIG_NCPFS_EXTRAS is not set

#
# Partition Types
#
CONFIG_BSD_DISKLABEL=y
CONFIG_MAC_PARTITION=y
CONFIG_SMD_DISKLABEL=y
CONFIG_SOLARIS_X86_PARTITION=y
# CONFIG_SGI_DISKLABEL is not set
CONFIG_AMIGA_PARTITION=y
CONFIG_NLS=y

#
# Native Language Support
#
CONFIG_NLS_CODEPAGE_437=m
CONFIG_NLS_CODEPAGE_737=m
CONFIG_NLS_CODEPAGE_775=m
CONFIG_NLS_CODEPAGE_850=m
CONFIG_NLS_CODEPAGE_852=m
CONFIG_NLS_CODEPAGE_855=m
CONFIG_NLS_CODEPAGE_857=m
CONFIG_NLS_CODEPAGE_860=m
CONFIG_NLS_CODEPAGE_861=m
CONFIG_NLS_CODEPAGE_862=m
CONFIG_NLS_CODEPAGE_863=m
CONFIG_NLS_CODEPAGE_864=m
CONFIG_NLS_CODEPAGE_865=m
CONFIG_NLS_CODEPAGE_866=m
CONFIG_NLS_CODEPAGE_869=m
CONFIG_NLS_CODEPAGE_874=m
CONFIG_NLS_ISO8859_1=m
CONFIG_NLS_ISO8859_2=m
CONFIG_NLS_ISO8859_3=m
CONFIG_NLS_ISO8859_4=m
CONFIG_NLS_ISO8859_5=m
CONFIG_NLS_ISO8859_6=m
CONFIG_NLS_ISO8859_7=m
CONFIG_NLS_ISO8859_8=m
CONFIG_NLS_ISO8859_9=m
CONFIG_NLS_ISO8859_15=m
CONFIG_NLS_KOI8_R=m

#
# Console drivers
#
CONFIG_VGA_CONSOLE=y
# CONFIG_VIDEO_SELECT is not set

#
# Sound
#
# CONFIG_SOUND is not set

#
# Kernel hacking
#
CONFIG_MAGIC_SYSRQ=y



Cheers,
Dick Johnson
                   **** FILE SYSTEM WAS MODIFIED ****
Penguin : Linux version 2.2.6 on an i686 machine (400.59 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:04:53 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA12628
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:04:50 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02463
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:05:17 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:22593 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S9666AbPHKXQj>;
	Thu, 12 Aug 1999 02:16:39 +0300
Received:  by vger.rutgers.edu via listexpand id <S160615AbPHKWaJ>;
	Wed, 11 Aug 1999 18:30:09 -0400
Received:  by vger.rutgers.edu id <S154998AbPHKV6I>;
	Wed, 11 Aug 1999 17:58:08 -0400
Received: from gw.simegen.com ([203.2.135.4]:3963 "EHLO gw.simegen.com")
	by vger.rutgers.edu with ESMTP id <S156730AbPHKVNK>;
	Wed, 11 Aug 1999 17:13:10 -0400
Received: from anaconda.simegen.com (zeor.simegen.com) [203.28.9.32] 
	by gw.simegen.com with esmtp (Exim 3.02 #1 (Debian))
	id 11EfgD-0003uR-00; Thu, 12 Aug 1999 07:13:02 +1000
Message-ID: <37B1E74E.3565D59E@zeor.simegen.com>
Date:   Thu, 12 Aug 1999 07:12:46 +1000
From: Dancer <dancer@zeor.simegen.com>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Nickelby Thane <nthane@yahoo.com>
CC: linux-kernel@vger.rutgers.edu
Subject: Re: ESS1788
References: <19990810145330.16984.rocketmail@send205.yahoomail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

Nickelby Thane wrote:
> 
> Hi all. I really hope I don't act stupid by seeking
> help here since I am at end's witts. By using the
> stock kernel in RH 6.0 (2.2.5-15 later upgraded to
> 2.2.5-22) my sound card was detected at ESS1688 which
> was fine for me even though I had an ESS1788.
> Unfortunately when I upgraded to 2.2.10-4 (RPM kernel
> from the RPM repository <UK-based>), my sound card was
> detected as an ESS1868. The bad point is my wav files
> and mp3 files get frighteningly slow making my P133
> like a 286. Midis were okay. I didn't have time to
> test mod files as mikmod was giving me the error"
> cannot initialise sound device" like errors. Is there
> any way to make the kernel correctly identify my sound
> card and correct these errors ? I tried recompiling
> the kernel using the rpm source and at one time,
> download the bzip2 version of it and recompile it but
> to no avail. I do hope I don't get flame for this
> small problem but I do appreciate critical feedback
> from you good guys :-).

The ESS cards _are_ frighteningly slow, nasty cards. Cheap, yes. Mind
you, the only ones I've ever seen are made by Eagle. Other OEM's ESS
cards may be better (but probably not worse). Quite literally, when one
of these cards falls into my hands I break it with a hammer, and replace
it with just about anything else. It's quite satisfying really.

Cheap? Yes. You get what you pay for.

D

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:04:55 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA12664
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:04:53 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02473
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:05:21 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:27217 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S9406AbPHKXVa>;
	Thu, 12 Aug 1999 02:21:30 +0300
Received:  by vger.rutgers.edu via listexpand id <S156983AbPHKWm1>;
	Wed, 11 Aug 1999 18:42:27 -0400
Received:  by vger.rutgers.edu id <S154339AbPHKWFl>;
	Wed, 11 Aug 1999 18:05:41 -0400
Received: from hornisse.agrinet.ch ([212.28.128.30]:4543 "EHLO
        hornisse.agrinet.ch") by vger.rutgers.edu with ESMTP
	id <S154137AbPHKWDK>; Wed, 11 Aug 1999 18:03:10 -0400
Received: from pop.agri.ch (212.28.159.11) by hornisse.agrinet.ch (NPlex 4.0.065)
        id 37B13A6000004999 for linux-kernel@vger.rutgers.edu; Thu, 12 Aug 1999 00:03:08 +0200
Message-ID: <37B1F33E.47376E9E@pop.agri.ch>
Date:   Thu, 12 Aug 1999 00:03:43 +0200
From: Andreas Tobler <toa@pop.agri.ch>
Reply-To: toa@pop.agri.ch
X-Mailer: Mozilla 4.5 (Macintosh; I; PPC)
X-Accept-Language: en
MIME-Version: 1.0
To: kernel <linux-kernel@vger.rutgers.edu>
Subject: kernel ac2 2.2.11 SIZE & PowerMac
Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353"
Content-Transfer-Encoding: 7bit
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

Hi,
I'm kind of frustrated, right now I had to reinstall on the quick my
MacOS on my PowerBook. I don't know if that has something to do with
Alans ac's. But today I got the ac2 of 2.2.11 to compile on my Book, it
went ok as far the process was concerned. Thanks Alan for merging all
the ppc stuff. One thing I don't understand, why the heck has the
vmlinux size grown from two to 6.2MB with the default config??? Can
anybody tell me?
And were there some changes in the hfs support??

I hosed my system TOTALLY, I used xhfs, which I think is a frontend for
hfs support, to transfer the vmlinux to my hfs partition, two times ok,
the third.....
Anyway, maybe a an unlucky combination.

Thanks for any hint, hope to get my my machine back to life. (sorry if
it is an un-wrong/formated) mail
Andreas


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:04:56 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA12698
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:04:56 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02479
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:05:24 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:27217 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S9613AbPHKXWj>;
	Thu, 12 Aug 1999 02:22:39 +0300
Received:  by vger.rutgers.edu via listexpand id <S157069AbPHKWra>;
	Wed, 11 Aug 1999 18:47:30 -0400
Received:  by vger.rutgers.edu id <S155488AbPHKWAT>;
	Wed, 11 Aug 1999 18:00:19 -0400
Received: from mail.uni-bielefeld.de ([129.70.4.90]:35174 "EHLO
        mail.uni-bielefeld.de") by vger.rutgers.edu with ESMTP
	id <S156704AbPHKVZZ>; Wed, 11 Aug 1999 17:25:25 -0400
Received: from Mutz.com (ppp36-100.hrz.uni-bielefeld.de)
 by mail.uni-bielefeld.de
 (Sun Internet Mail Server sims.3.5.1999.03.02.17.58.p5)
 with ESMTP id <0FGB007V4KU4II@mail.uni-bielefeld.de> for
 linux-kernel@vger.rutgers.edu; Wed, 11 Aug 1999 23:25:21 +0200 (MET DST)
Date:   Wed, 11 Aug 1999 21:20:48 +0000
From: Marc Mutz <Marc@Mutz.com>
Subject: Re: Modular Kernel Security
To: Mike Ricketts <rickettm@ox.compsoc.net>
Cc: Secret Squirrel <secret_squirrel@nym.alias.net>,
        linux-kernel@vger.rutgers.edu
Message-id: <37B1E930.51C4925B@Mutz.com>
Organization: University of Bielefeld - Dep. of Mathematics / Dep. of Physics
MIME-version: 1.0
X-Mailer: Mozilla 4.51 [en] (X11; U; Linux 2.2.11 i586)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
X-Accept-Language: en
References: <Pine.LNX.4.10.9908112046500.2135-100000@oakley.keble.ox.ac.uk>
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

Mike wrote:
> 
> On Tue, 10 Aug 1999, Marc Mutz wrote:
> 
> > > AFAIK cipe (encripted IP tunneling) only comes as modules.
> > >
> > Just checked: CIPE can only be included in the kernel, not compiled as
> > module (says make xconfig). This is with patch int-2.2.10-4.
> >
> Yes, but try compiling it - it creates a module when you say 'Y' to the
> option in menuconfig
> 
What, w/o enabling 'loadable module support'? That should be considered
a bug, shouldn't it? I'll write to Alexander and check...

Marc

-- 
Marc Mutz <Marc@Mutz.com>                    http://marc.mutz.com/
University of Bielefeld, Dep. of Mathematics / Dep. of Physics

PGP-keyID's:   0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:05:01 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA12755
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:05:00 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02485
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:05:27 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:52576 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S9258AbPHKX1w>;
	Thu, 12 Aug 1999 02:27:52 +0300
Received:  by vger.rutgers.edu via listexpand id <S154481AbPHKWri>;
	Wed, 11 Aug 1999 18:47:38 -0400
Received:  by vger.rutgers.edu id <S154171AbPHKWA4>;
	Wed, 11 Aug 1999 18:00:56 -0400
Received: from chaos.analogic.com ([204.178.40.224]:1026 "EHLO
        chaos.analogic.com") by vger.rutgers.edu with ESMTP
	id <S160116AbPHKVZe>; Wed, 11 Aug 1999 17:25:34 -0400
Received: (from root@localhost) by chaos.analogic.com (8.9.3/8.7.3) id RAA00155; Wed, 11 Aug 1999 17:25:12 -0400
Date:   Wed, 11 Aug 1999 17:25:12 -0400 (EDT)
From: "Richard B. Johnson" <root@chaos.analogic.com>
Reply-To: root@chaos.analogic.com
To: Linux kernel <linux-kernel@vger.rutgers.edu>
Subject: Modules don't work on 2.3.13 (lots of symbols need to be exported)
Message-ID: <Pine.LNX.3.95.990811171551.122A-100000@chaos.analogic.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig


Hello,

The output from `depmod -a 2.3.13` shows a mess.

/lib/modules/2.3.13/fs/binfmt_misc.o: unresolved symbol(s)
/lib/modules/2.3.13/fs/binfmt_aout.o: unresolved symbol(s)
/lib/modules/2.3.13/fs/autofs.o: unresolved symbol(s)
/lib/modules/2.3.13/fs/romfs.o: unresolved symbol(s)
/lib/modules/2.3.13/fs/affs.o: unresolved symbol(s)
/lib/modules/2.3.13/fs/ufs.o: unresolved symbol(s)
/lib/modules/2.3.13/fs/ntfs.o: unresolved symbol(s)
/lib/modules/2.3.13/fs/hpfs.o: unresolved symbol(s)
/lib/modules/2.3.13/fs/ncpfs.o: unresolved symbol(s)
/lib/modules/2.3.13/fs/smbfs.o: unresolved symbol(s)
/lib/modules/2.3.13/fs/sysv.o: unresolved symbol(s)
/lib/modules/2.3.13/fs/nfs.o: unresolved symbol(s)
/lib/modules/2.3.13/fs/hfs.o: unresolved symbol(s)
/lib/modules/2.3.13/fs/isofs.o: unresolved symbol(s)
/lib/modules/2.3.13/fs/vfat.o: unresolved symbol(s)
/lib/modules/2.3.13/fs/minix.o: unresolved symbol(s)
/lib/modules/2.3.13/fs/coda.o: unresolved symbol(s)
/lib/modules/2.3.13/net/cs89x0.o: unresolved symbol(s)
/lib/modules/2.3.13/net/dgrs.o: unresolved symbol(s)
/lib/modules/2.3.13/net/eql.o: unresolved symbol(s)
/lib/modules/2.3.13/net/82596.o: unresolved symbol(s)
/lib/modules/2.3.13/net/com20020.o: unresolved symbol(s)
/lib/modules/2.3.13/net/com90io.o: unresolved symbol(s)
/lib/modules/2.3.13/net/com90xx.o: unresolved symbol(s)
/lib/modules/2.3.13/net/tulip.o: unresolved symbol(s)
/lib/modules/2.3.13/net/3c505.o: unresolved symbol(s)
/lib/modules/2.3.13/net/de4x5.o: unresolved symbol(s)
/lib/modules/2.3.13/net/ewrk3.o: unresolved symbol(s)
/lib/modules/2.3.13/net/depca.o: unresolved symbol(s)
/lib/modules/2.3.13/net/via-rhine.o: unresolved symbol(s)
/lib/modules/2.3.13/net/tlan.o: unresolved symbol(s)
/lib/modules/2.3.13/net/eepro100.o: unresolved symbol(s)
/lib/modules/2.3.13/net/eepro.o: unresolved symbol(s)
/lib/modules/2.3.13/net/eexpress.o: unresolved symbol(s)
/lib/modules/2.3.13/net/3c59x.o: unresolved symbol(s)
/lib/modules/2.3.13/net/3c515.o: unresolved symbol(s)
/lib/modules/2.3.13/net/3c509.o: unresolved symbol(s)
/lib/modules/2.3.13/net/fmv18x.o: unresolved symbol(s)
/lib/modules/2.3.13/net/at1700.o: unresolved symbol(s)
/lib/modules/2.3.13/net/pcnet32.o: unresolved symbol(s)
/lib/modules/2.3.13/net/lance.o: unresolved symbol(s)
/lib/modules/2.3.13/net/e2100.o: unresolved symbol(s)
/lib/modules/2.3.13/net/hp-plus.o: unresolved symbol(s)
/lib/modules/2.3.13/net/hp.o: unresolved symbol(s)
/lib/modules/2.3.13/net/ne.o: unresolved symbol(s)
/lib/modules/2.3.13/net/ne2k-pci.o: unresolved symbol(s)
/lib/modules/2.3.13/net/3c503.o: unresolved symbol(s)
/lib/modules/2.3.13/net/hp100.o: unresolved symbol(s)
/lib/modules/2.3.13/net/8390.o: unresolved symbol(s)
/lib/modules/2.3.13/net/arcnet.o: unresolved symbol(s)
/lib/modules/2.3.13/net/ppp_async.o: unresolved symbol(s)
/lib/modules/2.3.13/net/ppp_generic.o: unresolved symbol(s)
/lib/modules/2.3.13/scsi/sym53c416.o: unresolved symbol(s)
/lib/modules/2.3.13/scsi/NCR53c406a.o: unresolved symbol(s)
/lib/modules/2.3.13/scsi/eata.o: unresolved symbol(s)
/lib/modules/2.3.13/scsi/ultrastor.o: unresolved symbol(s)
/lib/modules/2.3.13/scsi/wd7000.o: unresolved symbol(s)
/lib/modules/2.3.13/scsi/53c7,8xx.o: unresolved symbol(s)
/lib/modules/2.3.13/scsi/g_NCR5380.o: unresolved symbol(s)
/lib/modules/2.3.13/scsi/in2000.o: unresolved symbol(s)
/lib/modules/2.3.13/scsi/fdomain.o: unresolved symbol(s)
/lib/modules/2.3.13/scsi/u14-34f.o: unresolved symbol(s)
/lib/modules/2.3.13/scsi/eata_pio.o: unresolved symbol(s)
/lib/modules/2.3.13/scsi/eata_dma.o: unresolved symbol(s)
/lib/modules/2.3.13/scsi/BusLogic.o: unresolved symbol(s)
/lib/modules/2.3.13/scsi/tmscsim.o: unresolved symbol(s)
/lib/modules/2.3.13/scsi/aic7xxx.o: unresolved symbol(s)
/lib/modules/2.3.13/scsi/aha1740.o: unresolved symbol(s)
/lib/modules/2.3.13/scsi/aha1542.o: unresolved symbol(s)
/lib/modules/2.3.13/scsi/aha152x.o: unresolved symbol(s)
/lib/modules/2.3.13/scsi/qlogicfc.o: unresolved symbol(s)
/lib/modules/2.3.13/scsi/a100u2w.o: unresolved symbol(s)
/lib/modules/2.3.13/scsi/initio.o: unresolved symbol(s)
/lib/modules/2.3.13/scsi/atp870u.o: unresolved symbol(s)
/lib/modules/2.3.13/scsi/qlogicisp.o: unresolved symbol(s)
/lib/modules/2.3.13/scsi/qlogicfas.o: unresolved symbol(s)
/lib/modules/2.3.13/scsi/advansys.o: unresolved symbol(s)
/lib/modules/2.3.13/scsi/sr_mod.o: unresolved symbol(s)
/lib/modules/2.3.13/scsi/sd_mod.o: unresolved symbol(s)
/lib/modules/2.3.13/scsi/st.o: unresolved symbol(s)
/lib/modules/2.3.13/scsi/scsi_mod.o: unresolved symbol(s)
/lib/modules/2.3.13/block/nbd.o: unresolved symbol(s)
/lib/modules/2.3.13/block/xd.o: unresolved symbol(s)
/lib/modules/2.3.13/block/ide-probe.o: unresolved symbol(s)
/lib/modules/2.3.13/block/ide-mod.o: unresolved symbol(s)
/lib/modules/2.3.13/block/loop.o: unresolved symbol(s)
/lib/modules/2.3.13/cdrom/cdrom.o: unresolved symbol(s)
/lib/modules/2.3.13/ipv4/ip_gre.o: unresolved symbol(s)
/lib/modules/2.3.13/ipv4/ipip.o: unresolved symbol(s)
/lib/modules/2.3.13/misc/zftape.o: unresolved symbol(s)
/lib/modules/2.3.13/misc/tpqic02.o: unresolved symbol(s)
/lib/modules/2.3.13/misc/sunrpc.o: unresolved symbol(s)
/lib/modules/2.3.13/misc/pf.o: unresolved symbol(s)
/lib/modules/2.3.13/misc/pd.o: unresolved symbol(s)
/lib/modules/2.3.13/misc/parport_pc.o: unresolved symbol(s)
/lib/modules/2.3.13/misc/paride.o: unresolved symbol(s)
/lib/modules/2.3.13/misc/nvram.o: unresolved symbol(s)
/lib/modules/2.3.13/misc/ipx.o: unresolved symbol(s)
/lib/modules/2.3.13/misc/ftape.o: unresolved symbol(s)
/lib/modules/2.3.13/misc/appletalk.o: unresolved symbol(s)

To boot from a ramdisk, I need Buslogic.o, scsi_mod.o, and sd_mod.o.
They all show unresolved symbols, hense no boot.

They all need:

/lib/modules/2.3.13/fs/binfmt_misc.o: unresolved symbol(s)
	copy_strings_kernel
/lib/modules/2.3.13/fs/binfmt_aout.o: unresolved symbol(s)
	do_brk
	_fput
/lib/modules/2.3.13/fs/autofs.o: unresolved symbol(s)
	cap_bset
	_fput
/lib/modules/2.3.13/fs/romfs.o: unresolved symbol(s)
	init_special_inode
/lib/modules/2.3.13/fs/affs.o: unresolved symbol(s)
	block_read_full_page
	__mark_buffer_dirty
/lib/modules/2.3.13/fs/ufs.o: unresolved symbol(s)
	init_special_inode
	block_read_full_page
	block_write_partial_page
	__mark_buffer_dirty
	cap_bset
	block_flushpage
	block_write_full_page
/lib/modules/2.3.13/fs/ntfs.o: unresolved symbol(s)
	block_read_full_page
	__mark_buffer_dirty
/lib/modules/2.3.13/fs/hpfs.o: unresolved symbol(s)
	init_special_inode
	block_read_full_page
	hpfs_writepage
	block_write_partial_page
	__mark_buffer_dirty
	block_flushpage
/lib/modules/2.3.13/fs/ncpfs.o: unresolved symbol(s)
	_fput
/lib/modules/2.3.13/fs/smbfs.o: unresolved symbol(s)
	cap_bset
	_fput
/lib/modules/2.3.13/fs/sysv.o: unresolved symbol(s)
	init_special_inode
	block_read_full_page
	block_write_partial_page
	__mark_buffer_dirty
	block_flushpage
	block_write_full_page
/lib/modules/2.3.13/fs/nfs.o: unresolved symbol(s)
	add_to_page_cache_unique
	init_special_inode
	__find_get_page
	__find_lock_page
	page_hash_bits
	_fput
	page_hash_table
/lib/modules/2.3.13/fs/hfs.o: unresolved symbol(s)
	block_read_full_page
	__mark_buffer_dirty
/lib/modules/2.3.13/fs/isofs.o: unresolved symbol(s)
	init_special_inode
	block_read_full_page
/lib/modules/2.3.13/fs/vfat.o: unresolved symbol(s)
	fat_dir_empty
	fat_add_entries
	fat__get_entry
	fat_build_inode
	fat_search_long
	fat_detach
	fat_attach
	fat_new_dir
/lib/modules/2.3.13/fs/minix.o: unresolved symbol(s)
	init_special_inode
	block_read_full_page
	block_write_partial_page
	__mark_buffer_dirty
	block_flushpage
	block_write_full_page
/lib/modules/2.3.13/fs/coda.o: unresolved symbol(s)
	init_special_inode
	block_read_full_page
/lib/modules/2.3.13/net/cs89x0.o: unresolved symbol(s)
	__release_region
	__check_region
	__request_region
	ioport_resource
/lib/modules/2.3.13/net/dgrs.o: unresolved symbol(s)
	__release_region
	__request_region
	ioport_resource
/lib/modules/2.3.13/net/eql.o: unresolved symbol(s)
	cap_bset
/lib/modules/2.3.13/net/82596.o: unresolved symbol(s)
	__release_region
	ioport_resource
/lib/modules/2.3.13/net/com20020.o: unresolved symbol(s)
	__release_region
	__check_region
	__request_region
	ioport_resource
/lib/modules/2.3.13/net/com90io.o: unresolved symbol(s)
	__release_region
	__check_region
	__request_region
	ioport_resource
/lib/modules/2.3.13/net/com90xx.o: unresolved symbol(s)
	__release_region
	__check_region
	__request_region
	ioport_resource
/lib/modules/2.3.13/net/tulip.o: unresolved symbol(s)
	__release_region
	__check_region
	__request_region
	ioport_resource
/lib/modules/2.3.13/net/3c505.o: unresolved symbol(s)
	__release_region
	__check_region
	__request_region
	ioport_resource
/lib/modules/2.3.13/net/de4x5.o: unresolved symbol(s)
	__release_region
	__check_region
	cap_bset
	__request_region
	ioport_resource
/lib/modules/2.3.13/net/ewrk3.o: unresolved symbol(s)
	__release_region
	__check_region
	cap_bset
	__request_region
	ioport_resource
/lib/modules/2.3.13/net/depca.o: unresolved symbol(s)
	__release_region
	__check_region
	cap_bset
	__request_region
	ioport_resource
/lib/modules/2.3.13/net/via-rhine.o: unresolved symbol(s)
	__release_region
	__check_region
	__request_region
	ioport_resource
/lib/modules/2.3.13/net/tlan.o: unresolved symbol(s)
	__release_region
	__check_region
	__request_region
	ioport_resource
/lib/modules/2.3.13/net/eepro100.o: unresolved symbol(s)
	__check_region
	cap_bset
	__request_region
	ioport_resource
/lib/modules/2.3.13/net/eepro.o: unresolved symbol(s)
	__release_region
	__check_region
	__request_region
	ioport_resource
/lib/modules/2.3.13/net/eexpress.o: unresolved symbol(s)
	__release_region
	__request_region
	ioport_resource
/lib/modules/2.3.13/net/3c59x.o: unresolved symbol(s)
	__release_region
	__check_region
	__request_region
	ioport_resource
/lib/modules/2.3.13/net/3c515.o: unresolved symbol(s)
	__release_region
	__check_region
	__request_region
	ioport_resource
/lib/modules/2.3.13/net/3c509.o: unresolved symbol(s)
	__release_region
	__check_region
	disable_irq_nosync
	__request_region
	ioport_resource
/lib/modules/2.3.13/net/fmv18x.o: unresolved symbol(s)
	__release_region
	__check_region
	__request_region
	ioport_resource
/lib/modules/2.3.13/net/at1700.o: unresolved symbol(s)
	__release_region
	__check_region
	__request_region
	ioport_resource
/lib/modules/2.3.13/net/pcnet32.o: unresolved symbol(s)
	__release_region
	__check_region
	__request_region
	ioport_resource
/lib/modules/2.3.13/net/lance.o: unresolved symbol(s)
	__release_region
	__check_region
	__request_region
	ioport_resource
/lib/modules/2.3.13/net/e2100.o: unresolved symbol(s)
	__release_region
	__check_region
	__request_region
	ioport_resource
/lib/modules/2.3.13/net/hp-plus.o: unresolved symbol(s)
	__release_region
	__check_region
	__request_region
	ioport_resource
/lib/modules/2.3.13/net/hp.o: unresolved symbol(s)
	__release_region
	__check_region
	__request_region
	ioport_resource
/lib/modules/2.3.13/net/ne.o: unresolved symbol(s)
	__release_region
	__check_region
	__request_region
	ioport_resource
/lib/modules/2.3.13/net/ne2k-pci.o: unresolved symbol(s)
	__release_region
	__check_region
	__request_region
	ioport_resource
/lib/modules/2.3.13/net/3c503.o: unresolved symbol(s)
	__release_region
	__check_region
	__request_region
	ioport_resource
/lib/modules/2.3.13/net/hp100.o: unresolved symbol(s)
	__release_region
	__check_region
	__request_region
	ioport_resource
/lib/modules/2.3.13/net/8390.o: unresolved symbol(s)
	disable_irq_nosync
/lib/modules/2.3.13/net/arcnet.o: unresolved symbol(s)
	dev_base_lock
/lib/modules/2.3.13/net/ppp_async.o: unresolved symbol(s)
	cap_bset
/lib/modules/2.3.13/net/ppp_generic.o: unresolved symbol(s)
	cap_bset
/lib/modules/2.3.13/scsi/sym53c416.o: unresolved symbol(s)
	__check_region
	__request_region
	ioport_resource
/lib/modules/2.3.13/scsi/NCR53c406a.o: unresolved symbol(s)
	__check_region
	__request_region
	ioport_resource
/lib/modules/2.3.13/scsi/eata.o: unresolved symbol(s)
	__release_region
	__check_region
	__request_region
	ioport_resource
/lib/modules/2.3.13/scsi/ultrastor.o: unresolved symbol(s)
	__check_region
	__request_region
	ioport_resource
/lib/modules/2.3.13/scsi/wd7000.o: unresolved symbol(s)
	__check_region
	__request_region
	ioport_resource
/lib/modules/2.3.13/scsi/53c7,8xx.o: unresolved symbol(s)
	__release_region
	__check_region
	__request_region
	ioport_resource
/lib/modules/2.3.13/scsi/g_NCR5380.o: unresolved symbol(s)
	__release_region
	__check_region
	__request_region
	ioport_resource
/lib/modules/2.3.13/scsi/in2000.o: unresolved symbol(s)
	__request_region
	ioport_resource
/lib/modules/2.3.13/scsi/fdomain.o: unresolved symbol(s)
	__check_region
	__request_region
	ioport_resource
/lib/modules/2.3.13/scsi/u14-34f.o: unresolved symbol(s)
	__release_region
	__check_region
	__request_region
	ioport_resource
/lib/modules/2.3.13/scsi/eata_pio.o: unresolved symbol(s)
	__release_region
	__check_region
	__request_region
	ioport_resource
/lib/modules/2.3.13/scsi/eata_dma.o: unresolved symbol(s)
	__release_region
	__check_region
	__request_region
	ioport_resource
/lib/modules/2.3.13/scsi/BusLogic.o: unresolved symbol(s)
	__release_region
	__check_region
	__request_region
	ioport_resource
/lib/modules/2.3.13/scsi/tmscsim.o: unresolved symbol(s)
	__release_region
	__check_region
	__request_region
	ioport_resource
/lib/modules/2.3.13/scsi/aic7xxx.o: unresolved symbol(s)
	__release_region
	__check_region
	__request_region
	ioport_resource
/lib/modules/2.3.13/scsi/aha1740.o: unresolved symbol(s)
	__check_region
	__request_region
	ioport_resource
/lib/modules/2.3.13/scsi/aha1542.o: unresolved symbol(s)
	__check_region
	__request_region
	ioport_resource
/lib/modules/2.3.13/scsi/aha152x.o: unresolved symbol(s)
	__release_region
	__check_region
	__request_region
	ioport_resource
/lib/modules/2.3.13/scsi/qlogicfc.o: unresolved symbol(s)
	__release_region
	__check_region
	__request_region
	ioport_resource
/lib/modules/2.3.13/scsi/a100u2w.o: unresolved symbol(s)
	__request_region
	ioport_resource
/lib/modules/2.3.13/scsi/initio.o: unresolved symbol(s)
	__request_region
	ioport_resource
/lib/modules/2.3.13/scsi/atp870u.o: unresolved symbol(s)
	__request_region
	ioport_resource
/lib/modules/2.3.13/scsi/qlogicisp.o: unresolved symbol(s)
	__release_region
	__check_region
	__request_region
	ioport_resource
/lib/modules/2.3.13/scsi/qlogicfas.o: unresolved symbol(s)
	__check_region
	__request_region
	ioport_resource
/lib/modules/2.3.13/scsi/advansys.o: unresolved symbol(s)
	__release_region
	__check_region
	__request_region
	ioport_resource
/lib/modules/2.3.13/scsi/sr_mod.o: unresolved symbol(s)
	blk_ioctl
/lib/modules/2.3.13/scsi/sd_mod.o: unresolved symbol(s)
	blk_ioctl
	cap_bset
/lib/modules/2.3.13/scsi/st.o: unresolved symbol(s)
	cap_bset
/lib/modules/2.3.13/scsi/scsi_mod.o: unresolved symbol(s)
	__release_region
	init_task_union
	cap_bset
	get_option
	ioport_resource
/lib/modules/2.3.13/block/nbd.o: unresolved symbol(s)
	cap_bset
	_fput
/lib/modules/2.3.13/block/xd.o: unresolved symbol(s)
	blk_ioctl
	__release_region
	__check_region
	cap_bset
	__request_region
	ioport_resource
/lib/modules/2.3.13/block/ide-probe.o: unresolved symbol(s)
	__check_region
	__request_region
	ioport_resource
/lib/modules/2.3.13/block/ide-mod.o: unresolved symbol(s)
	blk_ioctl
	__release_region
	cap_bset
	ioport_resource
/lib/modules/2.3.13/block/loop.o: unresolved symbol(s)
	file_moveto
	__mark_buffer_dirty
	cap_bset
	_fput
/lib/modules/2.3.13/cdrom/cdrom.o: unresolved symbol(s)
	cap_bset
/lib/modules/2.3.13/ipv4/ip_gre.o: unresolved symbol(s)
	cap_bset
/lib/modules/2.3.13/ipv4/ipip.o: unresolved symbol(s)
	cap_bset
/lib/modules/2.3.13/misc/zftape.o: unresolved symbol(s)
	cap_bset
/lib/modules/2.3.13/misc/tpqic02.o: unresolved symbol(s)
	__release_region
	__check_region
	__request_region
	ioport_resource
/lib/modules/2.3.13/misc/sunrpc.o: unresolved symbol(s)
	csum_partial_copy_generic
/lib/modules/2.3.13/misc/pf.o: unresolved symbol(s)
	blk_ioctl
/lib/modules/2.3.13/misc/pd.o: unresolved symbol(s)
	blk_ioctl
	cap_bset
/lib/modules/2.3.13/misc/parport_pc.o: unresolved symbol(s)
	__release_region
	__check_region
	__request_region
	ioport_resource
/lib/modules/2.3.13/misc/paride.o: unresolved symbol(s)
	__release_region
	__check_region
	__request_region
	ioport_resource
/lib/modules/2.3.13/misc/nvram.o: unresolved symbol(s)
	cap_bset
/lib/modules/2.3.13/misc/ipx.o: unresolved symbol(s)
	cap_bset
/lib/modules/2.3.13/misc/ftape.o: unresolved symbol(s)
	__release_region
	__check_region
	__request_region
	ioport_resource
/lib/modules/2.3.13/misc/appletalk.o: unresolved symbol(s)
	cap_bset


Cheers,
Dick Johnson
                   **** FILE SYSTEM WAS MODIFIED ****
Penguin : Linux version 2.2.4 on an i686 machine (400.59 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:05:04 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA12789
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:05:04 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02493
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:05:31 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:17761 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S9514AbPHKX3p>;
	Thu, 12 Aug 1999 02:29:45 +0300
Received:  by vger.rutgers.edu via listexpand id <S157485AbPHKWsa>;
	Wed, 11 Aug 1999 18:48:30 -0400
Received:  by vger.rutgers.edu id <S154485AbPHKWBK>;
	Wed, 11 Aug 1999 18:01:10 -0400
Received: from mail1.tor.accglobal.net ([204.92.55.105]:59963 "EHLO
        mail1.tor.accglobal.net") by vger.rutgers.edu with ESMTP
	id <S154102AbPHKVas>; Wed, 11 Aug 1999 17:30:48 -0400
Received: from ppp-040.m2-2.ssm.ican.net ([206.248.78.40] helo=asdf.capslock.lan)
	by mail1.tor.accglobal.net with esmtp (Exim 2.11 #1)
	id 11EfxN-0000Bp-01; Wed, 11 Aug 1999 17:30:45 -0400
Received: from localhost (mharris@localhost)
	by asdf.capslock.lan (8.9.3/8.9.3) with ESMTP id RAA14368;
	Wed, 11 Aug 1999 17:29:48 -0400
X-Authentication-Warning: asdf.capslock.lan: mharris owned process doing -bs
Date:   Wed, 11 Aug 1999 17:29:48 -0400 (EDT)
From: "Mike A. Harris" <mharris@ican.net>
X-Sender: mharris@asdf.capslock.lan
To: Moonshi Mohsenruddin <moonshi@email.com>
cc: flippie <flippie@vwv.com>, linux-net@vger.rutgers.edu,
        linux-kernel@vger.rutgers.edu
Subject: RE: [OT] Linux -> Clustering
In-Reply-To: <B0001024388@mailz.netnet.com.sg>
Message-ID: <Pine.LNX.4.10.9908111729041.4988-100000@asdf.capslock.lan>
Organization: Capslock Computer Consulting
X-Unexpected-Header: The Spanish Inquisition
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

On Thu, 12 Aug 1999, Moonshi Mohsenruddin wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>It is called BEOWULF :)

That is one solution, but there are others as well.  MOSIX is
another and SGI or SUN is doing NUMA I believe as well.  I'm sure
other solutions exist too.


--
Mike A. Harris                   Linux advocate      GNU advocate
Computer Consultant                          Open Source advocate  

Tea, Earl Grey, Hot...


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:05:09 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA12815
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:05:07 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02506
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:05:34 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:44137 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S9633AbPHKXe6>;
	Thu, 12 Aug 1999 02:34:58 +0300
Received:  by vger.rutgers.edu via listexpand id <S157278AbPHKWsT>;
	Wed, 11 Aug 1999 18:48:19 -0400
Received:  by vger.rutgers.edu id <S153856AbPHKWAs>;
	Wed, 11 Aug 1999 18:00:48 -0400
Received: from BEAVER.JPRC.COM ([207.86.147.217]:2839 "EHLO beaver.jprc.com")
	by vger.rutgers.edu with ESMTP id <S160268AbPHKV2D>;
	Wed, 11 Aug 1999 17:28:03 -0400
Received: (from karl@localhost)
	by beaver.jprc.com (8.8.7/8.8.7) id RAA05090;
	Wed, 11 Aug 1999 17:27:57 -0400
To: linux-kernel@vger.rutgers.edu
Subject: 2.2.11-ac3 sound/maestro.c fails to declare locks
X-Face: "5(T0tZd{6}pd~YzBG8O/*EW,.]6]@`m^e;fv65W^Y&=d"M\1H}>T~4_.kcDD.O~y3k)a6h
 R;Nmi>9|>Nm${2IpM0^RcUEa\jcq?KOP)C&~x51l~zCHTulL^_T|u0I^kB'z@]{`2YjQu
From: Karl Kleinpaste <karl@justresearch.com>
Date:   11 Aug 1999 17:27:56 -0400
Message-ID: <vxk4si66m8z.fsf@beaver.jprc.com>
Lines:  22
User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Shinjuku)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

FYI.  During "make modules", I get this error:

make[2]: Entering directory `/usr/src/linux-2.2.11-ac3/drivers/sound'
...
maestro.c: In function `ac97_mixer_ioctl':
maestro.c:1554: `s' undeclared (first use this function)
maestro.c:1554: (Each undeclared identifier is reported only once
maestro.c:1554: for each function it appears in.)
make[2]: *** [maestro.o] Error 1

There are 4 instances of code of the form

			spin_lock_irqsave(&s->lock, flags);
			val = card->mix.recmask_io(card,1,0);
			spin_unlock_irqrestore(&s->lock, flags);

with no `s' in sight.  Just to make it compile (I don't actually use
this module; having it enabled for compilation was evidently a mousing 
error in "make xconfig"), I added a "struct ess_state *s;" at the top
of the function and "s = &card->channels[0];".

--karl

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:05:11 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA12857
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:05:10 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02513
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:05:37 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:31096 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S9440AbPHKXkp>;
	Thu, 12 Aug 1999 02:40:45 +0300
Received:  by vger.rutgers.edu via listexpand id <S156158AbPHKXAP>;
	Wed, 11 Aug 1999 19:00:15 -0400
Received:  by vger.rutgers.edu id <S154028AbPHKWRb>;
	Wed, 11 Aug 1999 18:17:31 -0400
Received: from [200.250.58.146] ([200.250.58.146]:64075 "HELO
        frajuto.conectiva") by vger.rutgers.edu with SMTP
	id <S156043AbPHKVkQ>; Wed, 11 Aug 1999 17:40:16 -0400
Received: (qmail 21878 invoked from network); 11 Aug 1999 21:50:36 -0000
Received: from frajuto.conectiva (192.168.255.201)
  by frajuto.conectiva with SMTP; 11 Aug 1999 21:50:36 -0000
Date:   Wed, 11 Aug 1999 18:50:36 -0300 (EST)
From: Arnaldo Carvalho de Melo <acme@conectiva.com.br>
X-Sender: acme@frajuto.conectiva
To: Linux Kernel List <linux-kernel@vger.rutgers.edu>
cc: Linus Torvalds <torvalds@transmeta.com>, tech@conectiva.com.br
Subject: PATCH: __setup(ip_auto_config_setup)
Message-ID: <Pine.LNX.4.10.9908111845530.6185-100000@frajuto.conectiva>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

Linus,

    Please apply the following patch to make ip and nfsaddrs kernel
parameters work in the new __setup scheme. Tested with etherboot and
2.3.13.

--- linux.orig/net/ipv4/ipconfig.c	Wed Aug 11 15:03:22 1999
+++ linux/net/ipv4/ipconfig.c	Wed Aug 11 15:31:22 1999
@@ -12,6 +12,10 @@
  *  BOOTP rewritten to construct and analyse packets itself instead
  *  of misusing the IP layer. num_bugs_causing_wrong_arp_replies--;
  *					     -- MJ, December 1998
+ *  
+ *  Fixed ip_auto_config_setup calling at startup in the new "Linker Magic"
+ *  initialization scheme.
+ *	- Arnaldo Carvalho de Melo <acme@conectiva.com.br>, 08/11/1999
  */
 
 #include <linux/config.h>
@@ -912,7 +916,7 @@
 	return 0;
 }
 
-void __init ip_auto_config_setup(char *addrs, int *ints)
+static int __init ip_auto_config_setup(char *addrs)
 {
 	char *cp, *ip, *dp;
 	int num = 0;
@@ -920,10 +924,10 @@
 	ic_set_manually = 1;
 	if (!strcmp(addrs, "off")) {
 		ic_enable = 0;
-		return;
+		return 1;
 	}
 	if (ic_proto_name(addrs))
-		return;
+		return 1;
 
 	/* Parse the whole string */
 	ip = addrs;
@@ -971,4 +975,14 @@
 		ip = cp;
 		num++;
 	}
+
+	return 0;
 }
+
+static int __init nfsaddrs_config_setup(char *addrs)
+{
+	return ip_auto_config_setup(addrs);
+}
+
+__setup("ip=", ip_auto_config_setup);
+__setup("nfsaddrs=", nfsaddrs_config_setup);


         - Arnaldo




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:05:18 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA12891
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:05:13 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02518
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:05:40 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:21262 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S9567AbPHKXrl>;
	Thu, 12 Aug 1999 02:47:41 +0300
Received:  by vger.rutgers.edu via listexpand id <S157547AbPHKXCz>;
	Wed, 11 Aug 1999 19:02:55 -0400
Received:  by vger.rutgers.edu id <S154131AbPHKWSK>;
	Wed, 11 Aug 1999 18:18:10 -0400
Received: from [207.90.208.66] ([207.90.208.66]:3683 "EHLO helium.inexs.com")
	by vger.rutgers.edu with ESMTP id <S154133AbPHKVvE>;
	Wed, 11 Aug 1999 17:51:04 -0400
Received: (from campbell@localhost)
	by helium.inexs.com (8.9.1a/8.9.0) id QAA00722
	for linux-kernel@vger.rutgers.edu; Wed, 11 Aug 1999 16:50:49 -0500
Date:   Wed, 11 Aug 1999 16:50:49 -0500
From: Chuck Campbell <campbell@neosoft.com>
To: linux-kernel@vger.rutgers.edu
Subject: kernel 2.2.11-ac2 modules problem
Message-ID: <19990811165049.B32595@helium.inexs.com>
Reply-To: campbell@neosoft.com
Mail-Followup-To: linux-kernel@vger.rutgers.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.4us
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

The kernel builds, but installs all of its modules into linux-2.2.11-ac1 
instead of -ac2.

Just a FYI...

-chuck

-- 
ACCEL Services, Inc.| Specialists in Gravity, Magnetics |  1(713)993-0671 ph.
1980 Post Oak Blvd. |   and Integrated Interpretation   |  1(713)960-1157 fax
    Suite 2050      |                                   |
 Houston, TX, 77056 |          Chuck Campbell           | campbell@neosoft.com
                    |  President & Senior Geoscientist  |

     "Integration means more than having all the maps at the same scale!"

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:05:19 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA12963
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:05:19 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02522
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:05:43 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:51493 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S10140AbPHKX4b>;
	Thu, 12 Aug 1999 02:56:31 +0300
Received:  by vger.rutgers.edu via listexpand id <S157453AbPHKXKl>;
	Wed, 11 Aug 1999 19:10:41 -0400
Received:  by vger.rutgers.edu id <S155213AbPHKW3d>;
	Wed, 11 Aug 1999 18:29:33 -0400
Received: from mail.uni-bielefeld.de ([129.70.4.90]:36969 "EHLO
        mail.uni-bielefeld.de") by vger.rutgers.edu with ESMTP
	id <S156083AbPHKV5g>; Wed, 11 Aug 1999 17:57:36 -0400
Received: from Mutz.com (ppp36-61.hrz.uni-bielefeld.de)
 by mail.uni-bielefeld.de
 (Sun Internet Mail Server sims.3.5.1999.03.02.17.58.p5)
 with ESMTP id <0FGB0094CMBKJQ@mail.uni-bielefeld.de>; Wed,
 11 Aug 1999 23:57:30 +0200 (MET DST)
Date:   Wed, 11 Aug 1999 21:34:35 +0000
From: Marc Mutz <Marc@Mutz.com>
Subject: Re: Mount
To: Jonathan Masters <mastersj@periscope-systems.freeserve.co.uk>
Cc: linux-kernel@vger.rutgers.edu, linux-admin@vger.rutgers.edu
Message-id: <37B1EC6B.925A54D5@Mutz.com>
Organization: University of Bielefeld - Dep. of Mathematics / Dep. of Physics
MIME-version: 1.0
X-Mailer: Mozilla 4.51 [en] (X11; U; Linux 2.2.11 i586)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
X-Accept-Language: en
References: <37B0C155.98C3E787@periscope-systems.freeserve.co.uk>
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

Jonathan Masters wrote:
> 
> Hi,
>     I've just received a cd which is written in the standard iso9660
> format. However the stupid author, wrote some of the file names (in his
> html) in upper case and some in lower case. Since the majority are in
> upper case and since linux seems to mount the device by default so that
> files appear in lower case, I must ask - how do I mount a cdrom such
> that all files appear as upper case rather than lower case. Thanks. (The
> CD has 1000s of small files which are linked to so it isn't realistic to
> fix by hand - there must be an easier way anyway.... Thanks again.
> 
> Oh, one more while I'm here, I tried putting an rc6 ext2fs on a cd but
> it simply refuses to mount (yes I did create the image correctly and
> pass mount the right options). Any ideas? <interrupted>
>
Have you tried the following:
#setup
losetup -e rc6 /dev/loop0 /dev/cdrom
mke2fs /dev/loop0
losetup -d /dev/loop0
#mounting
mount -t ext2 /dev/cdrom /mnt/crypto-cd -o loop,encryption=rc6

or did you something different?

> I'm also waiting for the li
> patch for 2.2.11
You don't need to :-)
patch-int-2.2.10-4 applies fairly cleanly to 2.2.11. Just on reject for
loop.c that can be most easily done by hand (just remove the lines
marked with '-' in drivers/block/loop.c.rej and add lines marked with
'+' to loop.c)

Marc

-- 
Marc Mutz <Marc@Mutz.com>                    http://marc.mutz.com/
University of Bielefeld, Dep. of Mathematics / Dep. of Physics

PGP-keyID's:   0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH)



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:05:22 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA13003
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:05:22 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02531
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:05:49 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:51493 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S9697AbPHLACx>;
	Thu, 12 Aug 1999 03:02:53 +0300
Received:  by vger.rutgers.edu via listexpand id <S154469AbPHKXWY>;
	Wed, 11 Aug 1999 19:22:24 -0400
Received:  by vger.rutgers.edu id <S153872AbPHKXVy>;
	Wed, 11 Aug 1999 19:21:54 -0400
Received: from int2.nea-fast.com ([208.241.120.39]:34195 "EHLO
        int2.nea-fast.com") by vger.rutgers.edu with ESMTP
	id <S155496AbPHKWox>; Wed, 11 Aug 1999 18:44:53 -0400
Received: from ext1.nea-fast.com (ext1.nea-fast.com [208.241.120.230])
	by int2.nea-fast.com (8.8.8+Sun/8.8.8) with ESMTP id SAA15403;
	Wed, 11 Aug 1999 18:44:39 -0400 (EDT)
Received: from pobox.com (adsl-77-228-201.atl.bellsouth.net [216.77.228.201])
	by ext1.nea-fast.com (8.8.8+Sun/8.8.8) with ESMTP id SAA03627;
	Wed, 11 Aug 1999 18:47:26 -0400 (EDT)
Message-ID: <37B1FCD5.7AFE38B2@pobox.com>
Date:   Wed, 11 Aug 1999 18:44:37 -0400
From: Jeff Garzik <jgarzik@pobox.com>
Organization: none
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.11pre6 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
CC: Geert.Uytterhoeven@cs.kuleuven.ac.be, torvalds@transmeta.com, mj@ucw.cz,
        VANDROVE@vc.cvut.cz, linux-kernel@vger.rutgers.edu
Subject: Re: New resources - pls, explain :-(
References: <E11Egok-0004go-00@the-village.bc.nu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

Alan Cox wrote:
> > right thing" for that bus.  One could add "bigendian_writel()" and
> > "littleendian_writel()" to satisfy the Linus constraint of making
> > unusual usage of writel() obvious.

> So every I/O has an if in it. Nothing like stalling the pipeline before we
> probably stall on I/O writes to make things twice as painful.

Various implementations of writel() do stuff to stall the pipeline a bit
anyway.  It's really a convenience/speed tradeoff.  IMHO writel() should
continue to "do the right thing" as it currently does, regardless of its
bus, while allowing saavy driver writers to employ BUS_writel() if they
so desire.

My main motivation is keeping the codebase the same across multiple
buses.  The 'if' has to occur somewhere, if your driver supports
multiple buses.  I would rather have the ifs in a common place,
writel(), to avoid

	void vga_mm_wcrt (caddr_t vga_base, unsigned char reg, unsigned char
val)
	{
		if (zorro_bus) {
			zorro_writeb
			zorro_writeb
		} else if (pci_bus) {
			...use pci_writeb to duplicate above logic...
		} else if (sbus) {
			...use sbus_writeb to duplicate above logic...
		}
	}

-- 
Entropy requires no maintenance.
                -- Markoff Chaney

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:05:25 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA13043
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:05:25 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02539
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:05:53 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:51493 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S9356AbPHLAJr>;
	Thu, 12 Aug 1999 03:09:47 +0300
Received:  by vger.rutgers.edu via listexpand id <S156119AbPHKXph>;
	Wed, 11 Aug 1999 19:45:37 -0400
Received:  by vger.rutgers.edu id <S154131AbPHKXDD>;
	Wed, 11 Aug 1999 19:03:03 -0400
Received: from lightning.swansea.uk.linux.org ([194.168.151.1]:20357 "EHLO
        the-village.bc.nu") by vger.rutgers.edu with ESMTP
	id <S156662AbPHKWTS>; Wed, 11 Aug 1999 18:19:18 -0400
Received: from alan by the-village.bc.nu with local (Exim 2.12 #1)
	id 11EgdV-0004fZ-00; Wed, 11 Aug 1999 23:14:17 +0100
Subject: Re: 2.2.11: Complicated memory leak...
To: harri@synopsys.COM (Harald Dunkel)
Date:   Wed, 11 Aug 1999 23:14:08 +0100 (BST)
Cc: frank@ned.dem.csiro.au, linux-kernel@vger.rutgers.edu
In-Reply-To: <37B1B7AD.74E34F6D@Synopsys.COM> from "Harald Dunkel" at Aug 11, 99 07:49:33 pm
Content-Type: text
Message-Id: <E11EgdV-0004fZ-00@the-village.bc.nu>
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

> My PC is configured as NIS client. Currently I am running the
> Potato Debian distribution, i.e. the C lib is glibc 2.1, and
> the kernel has been compiled with gcc 2.95. 
> 
> After about 5 minutes or so ypbind, getty and other important jobs 
> die with 'out of memory'. Only the reset button helps.

Next question. Is everyone seeing this using gcc 2.95


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:05:29 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA13088
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:05:28 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02545
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:05:56 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:44368 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S9944AbPHLAPR>;
	Thu, 12 Aug 1999 03:15:17 +0300
Received:  by vger.rutgers.edu via listexpand id <S157043AbPHKXsd>;
	Wed, 11 Aug 1999 19:48:33 -0400
Received:  by vger.rutgers.edu id <S154312AbPHKXDY>;
	Wed, 11 Aug 1999 19:03:24 -0400
Received: from lightning.swansea.uk.linux.org ([194.168.151.1]:20540 "EHLO
        the-village.bc.nu") by vger.rutgers.edu with ESMTP
	id <S153980AbPHKWV3>; Wed, 11 Aug 1999 18:21:29 -0400
Received: from alan by the-village.bc.nu with local (Exim 2.12 #1)
	id 11Egh7-0004ft-00; Wed, 11 Aug 1999 23:18:01 +0100
Subject: Re: bttv & 2.2.11 => can't switch channels
To: marcel.lanz@ds9.ch (Marcel Lanz)
Date:   Wed, 11 Aug 1999 23:17:47 +0100 (BST)
Cc: linux-kernel@vger.rutgers.edu
In-Reply-To: <37B1C31B.99994327@ds9.ch> from "Marcel Lanz" at Aug 11, 99 08:38:19 pm
Content-Type: text
Message-Id: <E11Egh7-0004ft-00@the-village.bc.nu>
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

> Since I use 2.2.11 I can't switch between channels on my Haupauge
> TV-Card.
> I have only one channel.
> 
> Any ideas?

What errors are coming back when you attempt to tune the card. Do you have
the tuner loaded, what does it report at start up


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:05:35 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA13159
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:05:34 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02554
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:05:59 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:44368 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S10143AbPHLASy>;
	Thu, 12 Aug 1999 03:18:54 +0300
Received:  by vger.rutgers.edu via listexpand id <S154303AbPHKX4u>;
	Wed, 11 Aug 1999 19:56:50 -0400
Received:  by vger.rutgers.edu id <S155440AbPHKXOy>;
	Wed, 11 Aug 1999 19:14:54 -0400
Received: from lightning.swansea.uk.linux.org ([194.168.151.1]:20560 "EHLO
        the-village.bc.nu") by vger.rutgers.edu with ESMTP
	id <S155977AbPHKW34>; Wed, 11 Aug 1999 18:29:56 -0400
Received: from alan by the-village.bc.nu with local (Exim 2.12 #1)
	id 11Egok-0004go-00; Wed, 11 Aug 1999 23:25:54 +0100
Subject: Re: New resources - pls, explain :-(
To: jgarzik@pobox.com (Jeff Garzik)
Date:   Wed, 11 Aug 1999 23:25:48 +0100 (BST)
Cc: alan@lxorguk.ukuu.org.uk, Geert.Uytterhoeven@cs.kuleuven.ac.be,
        torvalds@transmeta.com, mj@ucw.cz, VANDROVE@vc.cvut.cz,
        linux-kernel@vger.rutgers.edu
In-Reply-To: <37B1E567.996B4136@pobox.com> from "Jeff Garzik" at Aug 11, 99 05:04:39 pm
Content-Type: text
Message-Id: <E11Egok-0004go-00@the-village.bc.nu>
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

> I like rth's suggestion about having bus-specific ioremap() instead of a
> generic one; then all readl() etc. would go through that, and do "the

Its cute but if you think harder the implementation would suck

> right thing" for that bus.  One could add "bigendian_writel()" and
> "littleendian_writel()" to satisfy the Linus constraint of making
> unusual usage of writel() obvious.

So every I/O has an if in it. Nothing like stalling the pipeline before we
probably stall on I/O writes to make things twice as painful.

Alan


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:05:38 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA13193
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:05:38 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02566
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:06:05 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:42336 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S9202AbPHLAWK>;
	Thu, 12 Aug 1999 03:22:10 +0300
Received:  by vger.rutgers.edu via listexpand id <S156607AbPHKX6X>;
	Wed, 11 Aug 1999 19:58:23 -0400
Received:  by vger.rutgers.edu id <S153972AbPHKXWE>;
	Wed, 11 Aug 1999 19:22:04 -0400
Received: from bw151zhb.bluewin.ch ([195.186.1.16]:56558 "EHLO
        bw151zhb.bluewin.ch") by vger.rutgers.edu with ESMTP
	id <S156000AbPHKWo7>; Wed, 11 Aug 1999 18:44:59 -0400
Received: from ds9.ch (olt115pub159.bluewin.ch [195.186.115.159])
	by bw151zhb.bluewin.ch (8.8.7/8.8.5) with ESMTP id AAA26546;
	Thu, 12 Aug 1999 00:44:39 +0200 (MET DST)
Message-ID: <37B1FCD5.F07947F4@ds9.ch>
Date:   Thu, 12 Aug 1999 00:44:37 +0200
From: Marcel Lanz <marcel.lanz@ds9.ch>
Organization: DEFIANT@DS9
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.11 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
CC: linux-kernel@vger.rutgers.edu
Subject: Re: bttv & 2.2.11 => can't switch channels
References: <E11Egh7-0004ft-00@the-village.bc.nu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

Alan Cox wrote:
> 
> > Since I use 2.2.11 I can't switch between channels on my Haupauge
> > TV-Card.
> > I have only one channel.
> >
> > Any ideas?
> 
> What errors are coming back when you attempt to tune the card. Do you have
> the tuner loaded, what does it report at start up
Ugh. no errors.

At bootup my kernel said:

Aug 12 00:34:36 defiant kernel: Linux video capture interface: v1.00
Aug 12 00:34:36 defiant kernel: bttv0: Brooktree Bt878 (rev 2) bus: 0,
devfn: 88, irq: 15, memory: 0xe2000000.
Aug 12 00:34:36 defiant kernel: bttv: 1 Bt8xx card(s) found.
Aug 12 00:34:36 defiant kernel: bttv0: Hauppauge eeprom: tuner=Philips
FI1216 MK2 (5)
Aug 12 00:34:36 defiant kernel: bttv0: fader chip: TEA6300
Aug 12 00:34:36 defiant kernel: bttv0: model: BT878(Hauppauge new)
...
Aug 12 00:34:57 defiant kernel: bttv0: PLL: 28636363 => 35468950 ... ok

I use xawtv-2.38 and bttv-support is compiled into the kernel.
If I tune the card. No errors occured. 
The channel-identifier from xawtv changes, but the picture is the same.

marcel

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:05:41 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA13228
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:05:41 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02580
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:06:08 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:57456 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S9656AbPHLAaK>;
	Thu, 12 Aug 1999 03:30:10 +0300
Received:  by vger.rutgers.edu via listexpand id <S156744AbPHLAFh>;
	Wed, 11 Aug 1999 20:05:37 -0400
Received:  by vger.rutgers.edu id <S157358AbPHKXfG>;
	Wed, 11 Aug 1999 19:35:06 -0400
Received: from lightning.swansea.uk.linux.org ([194.168.151.1]:20607 "EHLO
        the-village.bc.nu") by vger.rutgers.edu with ESMTP
	id <S153937AbPHKWv7>; Wed, 11 Aug 1999 18:51:59 -0400
Received: from alan by the-village.bc.nu with local (Exim 2.12 #1)
	id 11Eh9Z-0004ic-00; Wed, 11 Aug 1999 23:47:26 +0100
Subject: Re: New resources - pls, explain :-(
To: jgarzik@pobox.com (Jeff Garzik)
Date:   Wed, 11 Aug 1999 23:47:19 +0100 (BST)
Cc: alan@lxorguk.ukuu.org.uk, Geert.Uytterhoeven@cs.kuleuven.ac.be,
        torvalds@transmeta.com, mj@ucw.cz, VANDROVE@vc.cvut.cz,
        linux-kernel@vger.rutgers.edu
In-Reply-To: <37B1FCD5.7AFE38B2@pobox.com> from "Jeff Garzik" at Aug 11, 99 06:44:37 pm
Content-Type: text
Message-Id: <E11Eh9Z-0004ic-00@the-village.bc.nu>
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

> Various implementations of writel() do stuff to stall the pipeline a bit
> anyway.  It's really a convenience/speed tradeoff.  IMHO writel() should
> continue to "do the right thing" as it currently does, regardless of its

They don't do the right thing at the moment. Its platform specific whether
you get ordering, endian conversion and other stuff. In short its a mess

> buses.  The 'if' has to occur somewhere, if your driver supports
> multiple buses.  I would rather have the ifs in a common place,
> writel(), to avoid
> 
> 	void vga_mm_wcrt (caddr_t vga_base, unsigned char reg, unsigned char
> val)
> 	{
> 		if (zorro_bus) {
> 			zorro_writeb
> 			zorro_writeb
> 		} else if (pci_bus) {
> 			...use pci_writeb to duplicate above logic...
> 		} else if (sbus) {
> 			...use sbus_writeb to duplicate above logic...
> 		}
> 	}

But you should be unrolling the loop for each case to avoid the overhead


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:05:45 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA13287
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:05:45 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02587
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:06:12 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:57456 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S9765AbPHLAd2>;
	Thu, 12 Aug 1999 03:33:28 +0300
Received:  by vger.rutgers.edu via listexpand id <S156886AbPHLAFo>;
	Wed, 11 Aug 1999 20:05:44 -0400
Received:  by vger.rutgers.edu id <S153902AbPHKXhm>;
	Wed, 11 Aug 1999 19:37:42 -0400
Received: from lightning.swansea.uk.linux.org ([194.168.151.1]:20631 "EHLO
        the-village.bc.nu") by vger.rutgers.edu with ESMTP
	id <S154381AbPHKW5k>; Wed, 11 Aug 1999 18:57:40 -0400
Received: from alan by the-village.bc.nu with local (Exim 2.12 #1)
	id 11EhFs-0004jR-00; Wed, 11 Aug 1999 23:53:56 +0100
Subject: PATCH: was Re: 2.3.13 pci_namedevice compile error
To: tmolina@home.com (Thomas Molina)
Date:   Wed, 11 Aug 1999 23:53:50 +0100 (BST)
Cc: linux-kernel@vger.rutgers.edu
In-Reply-To: <Pine.LNX.4.10.9908111526430.5064-100000@wr5z.localdomain> from "Thomas Molina" at Aug 11, 99 03:29:33 pm
Content-Type: text
Message-Id: <E11EhFs-0004jR-00@the-village.bc.nu>
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

> drivers/pci/pci.a(pci.o): In function `pci_scan_bus':
> pci.o(.text.init+0x261): undefined reference to `pci_namedevice'
> make: *** [vmlinux] Error 1
> 
> I also got the infamous error under one configuration:
> 
> ncr53c8xx.c: In function `pci_get_base_address':
> ncr53c8xx.c:9636: structure has no member named `base_address'


diff -u --new-file --recursive --exclude-from ../exclude linux.13p8/drivers/scsi/ncr53c8xx.c linux.ac/drivers/scsi/ncr53c8xx.c
--- linux.13p8/drivers/scsi/ncr53c8xx.c	Sat Aug  7 17:55:28 1999
+++ linux.ac/drivers/scsi/ncr53c8xx.c	Fri Aug  6 01:23:13 1999
@@ -588,9 +588,7 @@
 #endif
 
 #if defined(__i386__) || !defined(NCR_IOMAPPED)
-__initfunc(
-static vm_offset_t remap_pci_mem(u_long base, u_long size)
-)
+static vm_offset_t __init remap_pci_mem(u_long base, u_long size)
 {
 	u_long page_base	= ((u_long) base) & PAGE_MASK;
 	u_long page_offs	= ((u_long) base) - page_base;
@@ -599,9 +597,7 @@
 	return (vm_offset_t) (page_remapped? (page_remapped + page_offs) : 0UL);
 }
 
-__initfunc(
-static void unmap_pci_mem(vm_offset_t vaddr, u_long size)
-)
+static void __init unmap_pci_mem(vm_offset_t vaddr, u_long size)
 {
 	if (vaddr)
 		iounmap((void *) (vaddr & PAGE_MASK));
@@ -3701,9 +3697,7 @@
 **==========================================================
 */
 
-__initfunc(
-void ncr_script_fill (struct script * scr, struct scripth * scrh)
-)
+void __init ncr_script_fill (struct script * scr, struct scripth * scrh)
 {
 	int	i;
 	ncrcmd	*p;
@@ -3778,9 +3772,7 @@
 **==========================================================
 */
 
-__initfunc(
-static void ncr_script_copy_and_bind (ncb_p np, ncrcmd *src, ncrcmd *dst, int len)
-)
+static void __init ncr_script_copy_and_bind (ncb_p np, ncrcmd *src, ncrcmd *dst, int len)
 {
 	ncrcmd  opcode, new, old, tmp1, tmp2;
 	ncrcmd	*start, *end;
@@ -4036,10 +4028,8 @@
 **	Get target set-up from Symbios format NVRAM.
 */
 
-__initfunc(
-static void
-	ncr_Symbios_setup_target(ncb_p np, int target, Symbios_nvram *nvram)
-)
+static void __init 
+ncr_Symbios_setup_target(ncb_p np, int target, Symbios_nvram *nvram)
 {
 	tcb_p tp = &np->target[target];
 	Symbios_target *tn = &nvram->target[target];
@@ -4059,10 +4049,8 @@
 **	Get target set-up from Tekram format NVRAM.
 */
 
-__initfunc(
-static void
-	ncr_Tekram_setup_target(ncb_p np, int target, Tekram_nvram *nvram)
-)
+static void __init 
+ncr_Tekram_setup_target(ncb_p np, int target, Tekram_nvram *nvram)
 {
 	tcb_p tp = &np->target[target];
 	struct Tekram_target *tn = &nvram->target[target];
@@ -4088,9 +4076,7 @@
 }
 #endif /* SCSI_NCR_NVRAM_SUPPORT */
 
-__initfunc(
-static int ncr_prepare_setting(ncb_p np, ncr_nvram *nvram)
-)
+static int __init ncr_prepare_setting(ncb_p np, ncr_nvram *nvram)
 {
 	u_char	burst_max;
 	u_long	period;
@@ -4372,9 +4358,7 @@
 
 #ifdef SCSI_NCR_DEBUG_NVRAM
 
-__initfunc(
-void ncr_display_Symbios_nvram(ncb_p np, Symbios_nvram *nvram)
-)
+void __init ncr_display_Symbios_nvram(ncb_p np, Symbios_nvram *nvram)
 {
 	int i;
 
@@ -4404,9 +4388,7 @@
 
 static u_char Tekram_boot_delay[7] __initdata = {3, 5, 10, 20, 30, 60, 120};
 
-__initfunc(
-void ncr_display_Tekram_nvram(ncb_p np, Tekram_nvram *nvram)
-)
+void __init ncr_display_Tekram_nvram(ncb_p np, Tekram_nvram *nvram)
 {
 	int i, tags, boot_delay;
 	char *rem;
@@ -4465,9 +4447,8 @@
 **	start the timer daemon.
 */
 
-__initfunc(
-static int ncr_attach (Scsi_Host_Template *tpnt, int unit, ncr_device *device)
-)
+static int __init 
+ncr_attach (Scsi_Host_Template *tpnt, int unit, ncr_device *device)
 {
         struct host_data *host_data;
 	ncb_p np;
@@ -8807,9 +8788,7 @@
 */
 
 #ifndef NCR_IOMAPPED
-__initfunc(
-static int ncr_regtest (struct ncb* np)
-)
+static int __init ncr_regtest (struct ncb* np)
 {
 	register volatile u_int32 data;
 	/*
@@ -8833,9 +8812,7 @@
 }
 #endif
 
-__initfunc(
-static int ncr_snooptest (struct ncb* np)
-)
+static int __init ncr_snooptest (struct ncb* np)
 {
 	u_int32	ncr_rd, ncr_wr, ncr_bk, host_rd, host_wr, pc;
 	int	i, err=0;
@@ -9098,9 +9075,7 @@
 /*
  *	calculate NCR SCSI clock frequency (in KHz)
  */
-__initfunc(
-static unsigned ncrgetfreq (ncb_p np, int gen)
-)
+static unsigned __init ncrgetfreq (ncb_p np, int gen)
 {
 	unsigned ms = 0;
 
@@ -9148,9 +9123,7 @@
 /*
  *	Get/probe NCR SCSI clock frequency
  */
-__initfunc(
-static void ncr_getclock (ncb_p np, int mult)
-)
+static void __init ncr_getclock (ncb_p np, int mult)
 {
 	unsigned char scntl3 = INB(nc_scntl3);
 	unsigned char stest1 = INB(nc_stest1);
@@ -9238,9 +9211,8 @@
 #define	ARG_SEP	','
 #endif
 
-__initfunc(
-void ncr53c8xx_setup(char *str, int *ints)
-)
+
+void __init ncr53c8xx_setup(char *str, int *ints)
 {
 #ifdef SCSI_NCR_BOOT_COMMAND_LINE_SUPPORT
 	char *cur = str;
@@ -9351,9 +9323,7 @@
 **   Returns the number of boards successfully attached.
 */
 
-__initfunc(
-static void ncr_print_driver_setup(void)
-)
+static void __init ncr_print_driver_setup(void)
 {
 #define YesNo(y)	y ? 'y' : 'n'
 	printk ("ncr53c8xx: setup=disc:%c,specf:%d,ultra:%d,tags:%d,sync:%d,"
@@ -9392,10 +9362,8 @@
 static ushort	ncr_chip_ids[]   __initdata	= SCSI_NCR_CHIP_IDS;
 
 #ifdef SCSI_NCR_NVRAM_SUPPORT
-__initfunc(
-static int
+static int __init 
 ncr_attach_using_nvram(Scsi_Host_Template *tpnt, int nvram_index, int count, ncr_device device[])
-)
 {
 	int i, j;
 	int attach_count = 0;
@@ -9476,9 +9444,7 @@
 }
 #endif /* SCSI_NCR_NVRAM_SUPPORT */
 
-__initfunc(
-int ncr53c8xx_detect(Scsi_Host_Template *tpnt)
-)
+int __init ncr53c8xx_detect(Scsi_Host_Template *tpnt)
 {
 	int i, j;
 	int chips;
@@ -9605,44 +9571,16 @@
 **   Return the offset immediately after the base address that has 
 **   been read. Btw, we blindly assume that the high 32 bits of 64 bit 
 **   base addresses are set to zero on 32 bit architectures.
+**   (the pci generic code now does this for us)
 **
 */
-#if LINUX_VERSION_CODE <= LinuxVersionCode(2,1,92)
-__initfunc(
-static int 
-pci_read_base_address(u_char bus, u_char device_fn, int offset, u_long *base)
-)
-{
-	u_int32 tmp;
-
-	pcibios_read_config_dword(bus, device_fn, offset, &tmp);
-	*base = tmp;
-	offset += sizeof(u_int32);
-	if ((tmp & 0x7) == 0x4) {
-#if BITS_PER_LONG > 32
-		pcibios_read_config_dword(bus, device_fn, offset, &tmp);
-		*base |= (((u_long)tmp) << 32);
-#endif
-		offset += sizeof(u_int32);
-	}
-	return offset;
-}
-#else	/* LINUX_VERSION_CODE > LinuxVersionCode(2,1,92) */
-__initfunc(
-static int 
+
+static int __init 
 pci_get_base_address(struct pci_dev *pdev, int index, u_long *base)
-)
 {
-	*base = pdev->base_address[index++];
-	if ((*base & 0x7) == 0x4) {
-#if BITS_PER_LONG > 32
-		*base |= (((u_long)pdev->base_address[index]) << 32);
-#endif
-		++index;
-	}
+	*base = pdev->resource[++index].start;
 	return index;
 }
-#endif
 
 /*
 **   Read and check the PCI configuration for any detected NCR 
@@ -9650,10 +9588,9 @@
 **   been detected.
 */
 
-__initfunc(
-static int ncr53c8xx_pci_init(Scsi_Host_Template *tpnt,
+
+static int __init ncr53c8xx_pci_init(Scsi_Host_Template *tpnt,
 			      uchar bus, uchar device_fn, ncr_device *device)
-)
 {
 	ushort vendor_id, device_id, command;
 	uchar cache_line_size, latency_timer;
@@ -10907,9 +10844,7 @@
 static void nvram_stop(ncr_slot *np, u_char *gpreg);
 static void nvram_setBit(ncr_slot *np, u_char write_bit, u_char *gpreg, int bit_mode);
 
-__initfunc(
-static int ncr_get_Symbios_nvram (ncr_slot *np, Symbios_nvram *nvram)
-)
+static int __init ncr_get_Symbios_nvram (ncr_slot *np, Symbios_nvram *nvram)
 {
 	static u_char Symbios_trailer[6] = {0xfe, 0xfe, 0, 0, 0, 0};
 	u_char	gpcntl, gpreg;
@@ -10998,9 +10933,8 @@
 /*
  * Read Symbios NvRAM data and compute checksum.
  */
-__initfunc(
-static u_short nvram_read_data(ncr_slot *np, u_char *data, int len, u_char *gpreg, u_char *gpcntl)
-)
+static u_short __init nvram_read_data(ncr_slot *np, u_char *data, int len,
+				      u_char *gpreg, u_char *gpcntl)
 {
 	int	x;
 	u_short	csum;
@@ -11017,9 +10951,7 @@
 /*
  * Send START condition to NVRAM to wake it up.
  */
-__initfunc(
-static void nvram_start(ncr_slot *np, u_char *gpreg)
-)
+static void __init nvram_start(ncr_slot *np, u_char *gpreg)
 {
 	nvram_setBit(np, 1, gpreg, SET_BIT);
 	nvram_setBit(np, 0, gpreg, SET_CLK);
@@ -11031,9 +10963,9 @@
  * WRITE a byte to the NVRAM and then get an ACK to see it was accepted OK,
  * GPIO0 must already be set as an output
  */
-__initfunc(
-static void nvram_write_byte(ncr_slot *np, u_char *ack_data, u_char write_data, u_char *gpreg, u_char *gpcntl)
-)
+static void __init nvram_write_byte(ncr_slot *np, u_char *ack_data,
+				    u_char write_data, u_char *gpreg,
+				    u_char *gpcntl)
 {
 	int x;
 	
@@ -11047,9 +10979,9 @@
  * READ a byte from the NVRAM and then send an ACK to say we have got it,
  * GPIO0 must already be set as an input
  */
-__initfunc(
-static void nvram_read_byte(ncr_slot *np, u_char *read_data, u_char ack_data, u_char *gpreg, u_char *gpcntl)
-)
+static void __init nvram_read_byte(ncr_slot *np, u_char *read_data,
+				   u_char ack_data, u_char *gpreg,
+				   u_char *gpcntl)
 {
 	int x;
 	u_char read_bit;
@@ -11067,9 +10999,8 @@
  * Output an ACK to the NVRAM after reading,
  * change GPIO0 to output and when done back to an input
  */
-__initfunc(
-static void nvram_writeAck(ncr_slot *np, u_char write_bit, u_char *gpreg, u_char *gpcntl)
-)
+static void __init nvram_writeAck(ncr_slot *np, u_char write_bit,
+				  u_char *gpreg, u_char *gpcntl)
 {
 	OUTB (nc_gpcntl, *gpcntl & 0xfe);
 	nvram_doBit(np, 0, write_bit, gpreg);
@@ -11080,9 +11011,8 @@
  * Input an ACK from NVRAM after writing,
  * change GPIO0 to input and when done back to an output
  */
-__initfunc(
-static void nvram_readAck(ncr_slot *np, u_char *read_bit, u_char *gpreg, u_char *gpcntl)
-)
+static void __init nvram_readAck(ncr_slot *np, u_char *read_bit,
+				 u_char *gpreg, u_char *gpcntl)
 {
 	OUTB (nc_gpcntl, *gpcntl | 0x01);
 	nvram_doBit(np, read_bit, 1, gpreg);
@@ -11093,9 +11023,8 @@
  * Read or write a bit to the NVRAM,
  * read if GPIO0 input else write if GPIO0 output
  */
-__initfunc(
-static void nvram_doBit(ncr_slot *np, u_char *read_bit, u_char write_bit, u_char *gpreg)
-)
+static void __init nvram_doBit(ncr_slot *np, u_char *read_bit,
+			       u_char write_bit, u_char *gpreg)
 {
 	nvram_setBit(np, write_bit, gpreg, SET_BIT);
 	nvram_setBit(np, 0, gpreg, SET_CLK);
@@ -11108,9 +11037,7 @@
 /*
  * Send STOP condition to NVRAM - puts NVRAM to sleep... ZZzzzz!!
  */
-__initfunc(
-static void nvram_stop(ncr_slot *np, u_char *gpreg)
-)
+static void __init nvram_stop(ncr_slot *np, u_char *gpreg)
 {
 	nvram_setBit(np, 0, gpreg, SET_CLK);
 	nvram_setBit(np, 1, gpreg, SET_BIT);
@@ -11119,9 +11046,8 @@
 /*
  * Set/clear data/clock bit in GPIO0
  */
-__initfunc(
-static void nvram_setBit(ncr_slot *np, u_char write_bit, u_char *gpreg, int bit_mode)
-)
+static void __init nvram_setBit(ncr_slot *np, u_char write_bit,
+				u_char *gpreg, int bit_mode)
 {
 	UDELAY (5);
 	switch (bit_mode){
@@ -11172,9 +11098,7 @@
 static void Tnvram_Stop(ncr_slot *np, u_char *gpreg);
 static void Tnvram_Clk(ncr_slot *np, u_char *gpreg);
 
-__initfunc(
-static int ncr_get_Tekram_nvram (ncr_slot *np, Tekram_nvram *nvram)
-)
+static int __init ncr_get_Tekram_nvram (ncr_slot *np, Tekram_nvram *nvram)
 {
 	u_char gpcntl, gpreg;
 	u_char old_gpcntl, old_gpreg;
@@ -11209,9 +11133,8 @@
 /*
  * Read Tekram NvRAM data and compute checksum.
  */
-__initfunc(
-static u_short Tnvram_read_data(ncr_slot *np, u_short *data, int len, u_char *gpreg)
-)
+static u_short __init Tnvram_read_data(ncr_slot *np, u_short *data, int len,
+				       u_char *gpreg)
 {
 	u_char	read_bit;
 	u_short	csum;
@@ -11236,9 +11159,8 @@
 /*
  * Send read command and address to NVRAM
  */
-__initfunc(
-static void Tnvram_Send_Command(ncr_slot *np, u_short write_data, u_char *read_bit, u_char *gpreg)
-)
+static void __init Tnvram_Send_Command(ncr_slot *np, u_short write_data,
+				       u_char *read_bit, u_char *gpreg)
 {
 	int x;
 
@@ -11252,9 +11174,8 @@
 /*
  * READ a byte from the NVRAM
  */
-__initfunc(
-static void Tnvram_Read_Word(ncr_slot *np, u_short *nvram_data, u_char *gpreg)
-)
+static void __init Tnvram_Read_Word(ncr_slot *np, u_short *nvram_data, 
+				    u_char *gpreg)
 {
 	int x;
 	u_char read_bit;
@@ -11273,9 +11194,8 @@
 /* 
  * Read bit from NVRAM
  */
-__initfunc(
-static void Tnvram_Read_Bit(ncr_slot *np, u_char *read_bit, u_char *gpreg)
-)
+static void __init Tnvram_Read_Bit(ncr_slot *np, u_char *read_bit,
+				   u_char *gpreg)
 {
 	UDELAY (2);
 	Tnvram_Clk(np, gpreg);
@@ -11285,9 +11205,8 @@
 /*
  * Write bit to GPIO0
  */
-__initfunc(
-static void Tnvram_Write_Bit(ncr_slot *np, u_char write_bit, u_char *gpreg)
-)
+static void __init Tnvram_Write_Bit(ncr_slot *np, u_char write_bit,
+				    u_char *gpreg)
 {
 	if (write_bit & 0x01)
 		*gpreg |= 0x02;
@@ -11305,9 +11224,7 @@
 /*
  * Send STOP condition to NVRAM - puts NVRAM to sleep... ZZZzzz!!
  */
-__initfunc(
-static void Tnvram_Stop(ncr_slot *np, u_char *gpreg)
-)
+static void __init Tnvram_Stop(ncr_slot *np, u_char *gpreg)
 {
 	*gpreg &= 0xef;
 	OUTB (nc_gpreg, *gpreg);
@@ -11319,9 +11236,7 @@
 /*
  * Pulse clock bit in GPIO0
  */
-__initfunc(
-static void Tnvram_Clk(ncr_slot *np, u_char *gpreg)
-)
+static void __init Tnvram_Clk(ncr_slot *np, u_char *gpreg)
 {
 	OUTB (nc_gpreg, *gpreg | 0x04);
 	UDELAY (2);

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:05:50 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA13327
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:05:48 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02598
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:06:16 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:4613 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S9391AbPHLAkA>;
	Thu, 12 Aug 1999 03:40:00 +0300
Received:  by vger.rutgers.edu via listexpand id <S157017AbPHLAWQ>;
	Wed, 11 Aug 1999 20:22:16 -0400
Received:  by vger.rutgers.edu id <S157068AbPHKX7g>;
	Wed, 11 Aug 1999 19:59:36 -0400
Received: from alpha.bur.adelphia.net ([24.48.40.2]:31676 "EHLO
        alpha.bur.adelphia.net") by vger.rutgers.edu with ESMTP
	id <S154155AbPHKX6R>; Wed, 11 Aug 1999 19:58:17 -0400
Received: from amd.fast.net (IDENT:root@surf15-131.bur.adelphia.net [24.48.40.131])
	by alpha.bur.adelphia.net (8.9.2/8.9.2) with ESMTP id TAA13814;
	Wed, 11 Aug 1999 19:57:48 -0400 (EDT)
Received: from pii.fast.net (hirsch@pii.fast.net [192.168.245.30])
	by amd.fast.net (8.8.7/8.8.7) with ESMTP id UAA00613;
	Wed, 11 Aug 1999 20:04:06 -0400
Date:   Wed, 11 Aug 1999 20:04:06 -0400 (EDT)
From: "Steven N. Hirsch" <shirsch@adelphia.net>
X-Sender: hirsch@pii.fast.net
To: Matthew Eaton <matthewe@adelphia.net>
cc: linux-kernel@vger.rutgers.edu
Subject: 2.2.11 + sb1000 fixed (Yay Alan!)
In-Reply-To: <Pine.LNX.3.96.990811154514.3364A-100000@oberon.avalon.mil>
Message-ID: <Pine.LNX.4.10.9908111959150.8124-100000@pii.fast.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

On Wed, 11 Aug 1999, Matthew Eaton wrote:

> Looks like the sb1000 driver no longer works with 2.2.11... It connects,
> but doesn't seem to register as an ipv4 device.
> 
> Have you looked into the problem yet? Is it problem in the kernel or the
> driver?

Well, I looked at the symptoms <g>.  

Alan Cox (as usual) found the problem and suggested the fix:

--- linux/drivers/net/sb1000.c.orig	Tue Aug 10 07:22:05 1999
+++ linux/drivers/net/sb1000.c	Wed Aug 11 18:46:27 1999
@@ -273,7 +273,7 @@
 
 	dev->type		= ARPHRD_ETHER;
 	dev->hard_header_len 	= 0;
-	dev->mtu		= 0;
+	dev->mtu		= 1500;
 	dev->addr_len		= ETH_ALEN;
 	/* hardware address is 0:0:serial_number */
 	dev->dev_addr[0] = 0;



Seems that the IP layer in 2.2.11 will not register an interface whose mtu
is < 68 bytes.  Since the SB1000 was never intended for outgoing packets,
it had been traditionally advertising an mtu of 0.  

A suggestion to the networking gurus, shouldn't the kernel log a complaint
in such a case?  To silently reject the interface doesn't seem helpful.

At any rate, works fine now!

Steve



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:05:52 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA13368
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:05:51 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02609
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:06:19 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:26646 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S9771AbPHLAmr>;
	Thu, 12 Aug 1999 03:42:47 +0300
Received:  by vger.rutgers.edu via listexpand id <S156864AbPHLAWf>;
	Wed, 11 Aug 1999 20:22:35 -0400
Received:  by vger.rutgers.edu id <S157458AbPHLACv>;
	Wed, 11 Aug 1999 20:02:51 -0400
Received: from lightning.swansea.uk.linux.org ([194.168.151.1]:20921 "EHLO
        the-village.bc.nu") by vger.rutgers.edu with ESMTP
	id <S153872AbPHKXWh>; Wed, 11 Aug 1999 19:22:37 -0400
Received: from alan by the-village.bc.nu with local (Exim 2.12 #1)
	id 11EheD-0004kx-00; Thu, 12 Aug 1999 00:19:06 +0100
Subject: Re: ESS1788
To: dancer@zeor.simegen.com (Dancer)
Date:   Thu, 12 Aug 1999 00:19:00 +0100 (BST)
Cc: nthane@yahoo.com, linux-kernel@vger.rutgers.edu
In-Reply-To: <37B1E74E.3565D59E@zeor.simegen.com> from "Dancer" at Aug 12, 99 07:12:46 am
Content-Type: text
Message-Id: <E11EheD-0004kx-00@the-village.bc.nu>
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

> The ESS cards _are_ frighteningly slow, nasty cards. Cheap, yes. Mind
> you, the only ones I've ever seen are made by Eagle. Other OEM's ESS

They are pretty average and generic SB16 equivalents. I've got a couple.
The only problem with them is that the documentation about detecting
the version should be in the fiction section



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:05:55 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA13394
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:05:54 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02620
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:06:22 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:26646 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S9385AbPHLApl>;
	Thu, 12 Aug 1999 03:45:41 +0300
Received:  by vger.rutgers.edu via listexpand id <S157071AbPHLAWp>;
	Wed, 11 Aug 1999 20:22:45 -0400
Received:  by vger.rutgers.edu id <S154512AbPHLADm>;
	Wed, 11 Aug 1999 20:03:42 -0400
Received: from lightning.swansea.uk.linux.org ([194.168.151.1]:21055 "EHLO
        the-village.bc.nu") by vger.rutgers.edu with ESMTP
	id <S154957AbPHKXXu>; Wed, 11 Aug 1999 19:23:50 -0400
Received: from alan by the-village.bc.nu with local (Exim 2.12 #1)
	id 11Ehfi-0004lB-00; Thu, 12 Aug 1999 00:20:38 +0100
Subject: Re: kernel ac2 2.2.11 SIZE & PowerMac
To: toa@pop.agri.ch
Date:   Thu, 12 Aug 1999 00:20:32 +0100 (BST)
Cc: linux-kernel@vger.rutgers.edu
In-Reply-To: <37B1F33E.47376E9E@pop.agri.ch> from "Andreas Tobler" at Aug 12, 99 00:03:43 am
Content-Type: text
Message-Id: <E11Ehfi-0004lB-00@the-village.bc.nu>
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

> Alans ac's. But today I got the ac2 of 2.2.11 to compile on my Book, it
> went ok as far the process was concerned. Thanks Alan for merging all
> the ppc stuff. One thing I don't understand, why the heck has the
> vmlinux size grown from two to 6.2MB with the default config??? Can
> anybody tell me?

That sounds like a bad build or something deeply nasty in the PPC merge.
It shouldnt have grown

> And were there some changes in the hfs support??

None. 

Make sure your report goes to the linuxppc folks too


Alan


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:06:00 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA13435
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:05:58 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02634
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:06:25 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:26646 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S9872AbPHLAsW>;
	Thu, 12 Aug 1999 03:48:22 +0300
Received:  by vger.rutgers.edu via listexpand id <S157189AbPHLAXh>;
	Wed, 11 Aug 1999 20:23:37 -0400
Received:  by vger.rutgers.edu id <S154171AbPHLAEr>;
	Wed, 11 Aug 1999 20:04:47 -0400
Received: from jim.southcom.com.au ([203.31.83.230]:1366 "EHLO
        jim.southcom.com.au") by vger.rutgers.edu with ESMTP
	id <S156862AbPHKX2d>; Wed, 11 Aug 1999 19:28:33 -0400
Received: from pandora.woodward.southcom.com.au (IDENT:jim@pandora.woodward.southcom.com.au [203.39.137.20])
	by jim.southcom.com.au (8.9.3/8.8.8) with ESMTP id JAA03161
	for <linux-kernel@vger.rutgers.edu>; Thu, 12 Aug 1999 09:28:17 +1000
Date:   Thu, 12 Aug 1999 09:36:06 +1000 (EST)
From: Jim Woodward <jim@jim.southcom.com.au>
X-Sender: jim@pandora.woodward.southcom.com.au
To: Linux Kernel <linux-kernel@vger.rutgers.edu>
Subject: weird socket refusal by kernel 2.2.11
Message-ID: <Pine.LNX.4.10.9908120930400.1370-100000@pandora.woodward.southcom.com.au>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig


I just upgraded both my systems to kernel 2.2.11 - one a 486 DX2-80 and a
P166

Very strange thing happened, the 486 wouldnt accept any connections to it
I logged in to it from the console, no firewall problems were logged,
nothing logged in /var/log/secure, infact it said there that the
connection was accepted and not refused.

As soon as I telnetted to these ports locally, it worked again from my
other machine, could get access fine.

anyone else had this problem?

It seemed likd it established the connection then dropped it.

the only other thing that ran on this box between now and when i last
logged into it was a tape backup using the ftape drivers to drive a
Colorado QIC-80 2120 tape drive.

any ideas?

--
"There is an old saying.. Well, theres lots of them actually..."
  _______________________________________________________________________
 | name: james woodward (jim@jim.southcom.com.au)                        |
 |  www: http://www.jim.southcom.com.au, http://www.toto.southcom.com.au |
 |  www: http://www.mailbag.southcom.com.au                              |
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:06:05 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA13515
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:06:05 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02674
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:06:32 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:31011 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S9980AbPHLA5i>;
	Thu, 12 Aug 1999 03:57:38 +0300
Received:  by vger.rutgers.edu via listexpand id <S154296AbPHLAfC>;
	Wed, 11 Aug 1999 20:35:02 -0400
Received:  by vger.rutgers.edu id <S156571AbPHLAPF>;
	Wed, 11 Aug 1999 20:15:05 -0400
Received: from neon-best.transmeta.com ([206.184.214.10]:13743 "EHLO
        neon.transmeta.com") by vger.rutgers.edu with ESMTP
	id <S154315AbPHKXyn>; Wed, 11 Aug 1999 19:54:43 -0400
Received: from deepthought.transmeta.com (mailhost.transmeta.com [10.1.1.15])
	by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id QAA10644;
	Wed, 11 Aug 1999 16:54:17 -0700
Received: from penguin.transmeta.com (root@penguin.transmeta.com [10.1.2.202])
	by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id QAA26464;
	Wed, 11 Aug 1999 16:54:16 -0700 (PDT)
Received: from localhost (torvalds@localhost) by penguin.transmeta.com (8.9.3/8.7.3) with ESMTP id QAA05048; Wed, 11 Aug 1999 16:55:08 -0700
X-Authentication-Warning: penguin.transmeta.com: torvalds owned process doing -bs
Date:   Wed, 11 Aug 1999 16:55:08 -0700 (PDT)
From: Linus Torvalds <torvalds@transmeta.com>
To: Chuck Lever <cel@monkey.org>
cc: Steve Dodd <dirk@loth.demon.co.uk>, linux-kernel@vger.rutgers.edu
Subject: Re: filemap_nopage() tries to copy to page 0, eek.
In-Reply-To: <Pine.BSO.4.10.9908111155060.16434-100000@funky.monkey.org>
Message-ID: <Pine.LNX.4.10.9908111652590.5034-100000@penguin.transmeta.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig



On Wed, 11 Aug 1999, Chuck Lever wrote:
>
> i assume you're looking at a late 2.3 kernel?  :)

Yes, Steve looks to be right. I've been busy at LinuxWorld so I only
glanced at it, but it looks like a real bug that probably (from that first
glance mind you - not much real work involved) involves moving the 

	if (!new_page) {
		allocate new page

thing down to the "success:" part. The commont about overapping the
allocation with the IO is probably fairly bogus anyway..

		Linus


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:06:11 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA13608
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:06:11 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02698
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:06:38 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:21817 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S9541AbPHLBJU>;
	Thu, 12 Aug 1999 04:09:20 +0300
Received:  by vger.rutgers.edu via listexpand id <S156627AbPHLA6n>;
	Wed, 11 Aug 1999 20:58:43 -0400
Received:  by vger.rutgers.edu id <S153921AbPHLAgr>;
	Wed, 11 Aug 1999 20:36:47 -0400
Received: from atlrel1.hp.com ([156.153.255.210]:2451 "EHLO atlrel1.hp.com")
	by vger.rutgers.edu with ESMTP id <S155055AbPHLAUR>;
	Wed, 11 Aug 1999 20:20:17 -0400
Received: from xboibrg4.boi.hp.com (xboibrg4.boi.hp.com [15.56.8.165])
	by atlrel1.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id UAA02554;
	Wed, 11 Aug 1999 20:19:25 -0400 (EDT)
Received: by xboibrg4.boi.hp.com with Internet Mail Service (5.5.2448.0)
	id <QKP8SLG2>; Wed, 11 Aug 1999 18:19:55 -0600
Message-ID: <D53173D574D6D211945500A0C9E95BEB279E6B@xsj02.sj.hp.com>
From: "WANG,YIDING (HP-SanJose,ex1)" <yiding_wang@am.exch.hp.com>
To: "'Marc Mutz'" <Marc@Mutz.com>,
        Jonathan Masters <mastersj@periscope-systems.freeserve.co.uk>
Cc: linux-kernel@vger.rutgers.edu, linux-admin@vger.rutgers.edu
Subject: RE: Mount
Date:   Wed, 11 Aug 1999 18:19:23 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

Here is a script you can use to convert all file name:

1, upper2lower:
	for file in `ls`
	do
		newname=`echo $file | tr "[A-Z] "[a-z]"
		mv $file $newname
	done

2, lower2upper:
	for file in `ls`
	do
		newname=`echo $file | tr "[a-z] "[A-Z]"
		mv $file $newname
	done

-eddie
-----Original Message-----
From: Marc Mutz [mailto:Marc@Mutz.com]
Sent: Wednesday, August 11, 1999 2:35 PM
To: Jonathan Masters
Cc: linux-kernel@vger.rutgers.edu; linux-admin@vger.rutgers.edu
Subject: Re: Mount


Jonathan Masters wrote:
> 
> Hi,
>     I've just received a cd which is written in the standard iso9660
> format. However the stupid author, wrote some of the file names (in his
> html) in upper case and some in lower case. Since the majority are in
> upper case and since linux seems to mount the device by default so that
> files appear in lower case, I must ask - how do I mount a cdrom such
> that all files appear as upper case rather than lower case. Thanks. (The
> CD has 1000s of small files which are linked to so it isn't realistic to
> fix by hand - there must be an easier way anyway.... Thanks again.
> 
> Oh, one more while I'm here, I tried putting an rc6 ext2fs on a cd but
> it simply refuses to mount (yes I did create the image correctly and
> pass mount the right options). Any ideas? <interrupted>
>
Have you tried the following:
#setup
losetup -e rc6 /dev/loop0 /dev/cdrom
mke2fs /dev/loop0
losetup -d /dev/loop0
#mounting
mount -t ext2 /dev/cdrom /mnt/crypto-cd -o loop,encryption=rc6

or did you something different?

> I'm also waiting for the li
> patch for 2.2.11
You don't need to :-)
patch-int-2.2.10-4 applies fairly cleanly to 2.2.11. Just on reject for
loop.c that can be most easily done by hand (just remove the lines
marked with '-' in drivers/block/loop.c.rej and add lines marked with
'+' to loop.c)

Marc

-- 
Marc Mutz <Marc@Mutz.com>                    http://marc.mutz.com/
University of Bielefeld, Dep. of Mathematics / Dep. of Physics

PGP-keyID's:   0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH)



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:06:12 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA13550
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:06:07 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02685
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:06:35 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:21817 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S9236AbPHLBB7>;
	Thu, 12 Aug 1999 04:01:59 +0300
Received:  by vger.rutgers.edu via listexpand id <S155151AbPHLAmy>;
	Wed, 11 Aug 1999 20:42:54 -0400
Received:  by vger.rutgers.edu id <S153872AbPHLAWj>;
	Wed, 11 Aug 1999 20:22:39 -0400
Received: from Cantor.suse.de ([194.112.123.193]:11295 "HELO Cantor.suse.de")
	by vger.rutgers.edu with SMTP id <S154306AbPHLADo>;
	Wed, 11 Aug 1999 20:03:44 -0400
Received: from Galois.suse.de (Galois.suse.de [194.112.123.130])
	by Cantor.suse.de (Postfix) with ESMTP
	id 8FFE132CD3; Thu, 12 Aug 1999 02:03:31 +0200 (MEST)
Received: from Wotan.suse.de (Wotan.suse.de [10.10.0.1])
	by Galois.suse.de (Postfix) with ESMTP
	id 02C3267A9; Thu, 12 Aug 1999 02:03:31 +0200 (MEST)
Received: from hay.suse.de (Hay.suse.de [10.10.0.114])
	by Wotan.suse.de (Postfix) with ESMTP
	id BFF2B7F8B; Thu, 12 Aug 1999 02:03:07 +0200 (MEST)
Received: from localhost (bk@localhost)
	by hay.suse.de (8.9.3/8.9.3) with ESMTP id CAA00456;
	Thu, 12 Aug 1999 02:03:06 +0200
X-Authentication-Warning: hay.suse.de: bk owned process doing -bs
Date:   Thu, 12 Aug 1999 02:03:02 +0200 (CEST)
From: Bernhard Kaindl <bk@suse.de>
To: "Christopher E. Brown" <cbrown@denalics.net>
Cc: linux-kernel@vger.rutgers.edu, Alan Cox <alan@lxorguk.ukuu.org.uk>,
        becker@cesdis1.gsfc.nasa.gov
Subject: Re: 2.2.11 and tulip.c issues
In-Reply-To: <Pine.LNX.4.10.9908111106220.117-100000@borg.denalics.net>
Message-ID: <Pine.LNX.4.10.9908120155370.419-100000@hay.suse.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

On Wed, 11 Aug 1999, Christopher E. Brown wrote:
>
>       Having a major problem with the tulip driver and 2.2.11.
> System has been tried with 2.2.11pre7 tulip v91, 2.2.11 tulip v91,
> 2.2.11 tulip v91 with the diff between 89H standard and 2.2.11-89H,
> and 2.2.11 with tulip 89H included in 2.2.11.

Hi, Ive the same situtaion.

>       I am having problems with large transfers.  Small stuff,
> interactive, web, etc works fine, but large transfers halt after 200K
> - 6MB.  I have tried scp and ftp transfers from the 2.2.11 to a
> 2.1.115 and a 2.0.36 box, started from either end comes to a halt,
> there is still network activity, and the 2.2.11 box can still talk to
> anyone but that transfer is dead, no more data moves ever.

Here, NFS stops after a while with 0.89H 75% of my cards are affected,
like yours.

>       At first I though it was an issue with 2.2.11 and v91 (I have
> to run 91, the new 21143 cards I have require it), but after screwing
> around for hours with it I dug up an older 21140 card that runs fine
> with 89H, it moved more data (6MB compared to < 1MB), but still came
> to a halt.

Maybe the de4x5 driver is also an option.

>       I don't know anything else to try.  I do with that 91 would
> get put into the current kernel though better than 75% of the cards
> around here will not function with 89H.  A dump of traffic between the
> 2.2.11/89H host (borg) and the 2.1.115 host (news) during one of the
> halts is below.

As said, a test with 0.89H gave same results here: On 7 from 9
Systems, a network install of a default Linux system was not possible.
NFS halted here. 0.90 worked well on all these systems.

In case you dont have 0.90, it is in 2.0.37 and Ishould have diff for
2.2.11 at ftp://ftp.suse.com/pub/people/bk/kernel/for-2.2.11/tulip-0.90.diff
within 24 hours.

Also, there is a 0.91g tulip.c, which is quite good hidden in the second
part of a link on the tulip development page. 
http://cesdis.gsfc.nasa.gov/linux/drivers/test/tulip.c

There are also two secret 0.90 versions:
http://cesdis1.gsfc.nasa.gov/linux/drivers/test/tulip.c-90q
http://cesdis1.gsfc.nasa.gov/linux/drivers/test/tulip.c-90z

Please tell me your results.

 - Bernd



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:06:15 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA13475
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:06:02 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02655
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:06:29 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:31011 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S9773AbPHLAvf>;
	Thu, 12 Aug 1999 03:51:35 +0300
Received:  by vger.rutgers.edu via listexpand id <S157384AbPHLAX4>;
	Wed, 11 Aug 1999 20:23:56 -0400
Received:  by vger.rutgers.edu id <S154544AbPHLAFX>;
	Wed, 11 Aug 1999 20:05:23 -0400
Received: from [206.152.126.99] ([206.152.126.99]:4499 "EHLO mattshouse.com")
	by vger.rutgers.edu with ESMTP id <S157228AbPHKXcz>;
	Wed, 11 Aug 1999 19:32:55 -0400
Received: from matthew.linuxnet (IDENT:root@matthew.linuxnet [192.168.1.5])
	by mattshouse.com (8.9.1/8.9.1) with SMTP id RAA23683;
	Wed, 11 Aug 1999 17:27:04 -0500
From: Matthew <matthew@mattshouse.com>
Reply-To: matthew@mattshouse.com
Organization: Mattshouse
To: linux-kernel@vger.rutgers.edu, becker@cesdis.edu
Subject: via-rhine nic crazyness on PIII Xeon SMP running 2.2.5 - 2.2.11
Date:   Wed, 11 Aug 1999 18:15:11 -0500
X-Mailer: KMail [version 1.0.17]
Content-Type: 	text/plain; charset=US-ASCII
MIME-Version: 1.0
Message-Id: <99081118321500.05912@matthew.linuxnet>
Content-Transfer-Encoding: 7BIT
X-KMail-Mark: 
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

Donald and l-k members,

I have a production Oracle database running on Redhat 6.0 w/ kernel 2.2.11.  It
is an HP Kayak XU dual Pentium III Xeon w/ 256M RAM.  I have three nics in this
box: a 3c59x (eth0), a DEC Tulip (eth1), and a D-Link with the via-rhine chipset
(eth2).  All are at 100mbps.

eth0 and eth1 behave properly, but eth2 (the via-rhine) spits out "Something
Wicked has happened" into the syslog.  I turned on verbose mode and captured
about 20k of data, including three instances of the "Wickedness".  I looked
through docs and the source (via-rhine.c) and couldn't find any mention of
failure due to multiple nics or SMP.

This behaved the same way on 2.2.10 and 2.2.5(stock Redhat SMP).  I've taken
the interface down for now, so I can play with it if you need me to.  I just
can't take the machine down.

A copy of the ifconfig is located at:
http://www.mattshouse.com/via-rhine/ifconfig.html

A copy of the 20k of verbose output is available at:
http://www.mattshouse.com/via-rhine/wicked.html

The wickedness is towards the bottom, highlighted in red.

Can someone tell me what's going on?

 --

To segfault is human, to blue screen is moronic...
~~~~~~~~~~~~
Matthew 
matthew@mattshouse.com
http://www.mattshouse.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:06:19 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA13655
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:06:15 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02709
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:06:42 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:21817 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S9315AbPHLBOh>;
	Thu, 12 Aug 1999 04:14:37 +0300
Received:  by vger.rutgers.edu via listexpand id <S154544AbPHLBFG>;
	Wed, 11 Aug 1999 21:05:06 -0400
Received:  by vger.rutgers.edu id <S153980AbPHLA5p>;
	Wed, 11 Aug 1999 20:57:45 -0400
Received: from mailc.telia.com ([194.22.190.4]:1401 "EHLO mailc.telia.com")
	by vger.rutgers.edu with ESMTP id <S154053AbPHLAfV>;
	Wed, 11 Aug 1999 20:35:21 -0400
Received: from d1o43.telia.com (root@d1o43.telia.com [194.22.195.241])
	by mailc.telia.com (8.8.8/8.8.8) with ESMTP id CAA18225;
	Thu, 12 Aug 1999 02:35:15 +0200 (CEST)
Received: from skelleftea.mail.telia.com (t3o43p31.telia.com [194.22.195.151])
	by d1o43.telia.com (8.8.8/8.8.5) with ESMTP id CAA08418;
	Thu, 12 Aug 1999 02:35:13 +0200 (CEST)
Message-ID: <37B21467.732B5C3@skelleftea.mail.telia.com>
Date:   Thu, 12 Aug 1999 02:25:11 +0200
From: Roger Larsson <roger.larsson@skelleftea.mail.telia.com>
Reply-To: Roger Larsson <nra02596@norran.net>
X-Mailer: Mozilla 4.6 [en] (Win95; I)
X-Accept-Language: sv,en
MIME-Version: 1.0
To: "Tom M. Kroeger" <tmk@cse.ucsc.edu>
CC: linux-kernel@vger.rutgers.edu
Subject: Re: Help: prefetching taking too long
References: <a4u2q63zhp.fsf@gilgamesh.cse.ucsc.edu>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

Hi Tom,

You are in the same kernel code region as have been patched to improve
audio latency. There are several too long execution paths in today's
kernels... (like looping through all page descriptions...)

I am not sure that applying the patches would help in your case
since your program is one that has to finish (not intercepting)
execution before continuing - the patches are being worked
on by Ingo Mjolnar.

But I think that this program should fit well into the
test suit for those patches.

Check out.
  http://www.gardena.net/benno/linux/audio/

You should be running with Bus Master / DMA transfers since
it does not handle the non Bus Master case well.

/RogerL

"Tom M. Kroeger" wrote:
> 
> - - -
> 
> To measure page read times I instrumented async page I/O by measuring
> the time between brw_page calling ll_rw_block and end_buffer_io_async
> getting called.  To test the inter-file prefetching, I wrote a simple
> best case program that goes though a non-changing list of 500 file
> names opening each file, reading the first 32k of the file and
> sleeping for a second in-between each read.
> 
> In a normal kernel (without inter-file prefetching enabled) this
> program spends an average of 4ms on each page read (a histogram below
> shows the distribution).  Then to test inter-file prefetching I enable
> prefetching; run the program once to let the system learn the pattern
> in which the files are accessed; clear the I/O caches with a program
> that calls malloc until memory exhausts, evicting almost all cached
> I/O data.  Finally I re-run the test program and the inter-file
> prefetching is able to predict the next file a do a prefetch on the
> first 32k of the predicted file.  My problem is that in this case this
> prefetching has an average page read time of around 300ms (again
> distribution below).  The code called to prefetch the first 32K of a
> file is below.  I'm calling try_to_read_ahead() which calls the same
> routines that are used to do the read for the non-prefetching case, so
> I'm quite puzzled as to why the same read calls are taking about 10
> time longer than when they are called by sys_read. (BTW - 2.2.9
> kernel, ext2fs, and ide disk).
> 
> Is it possible that I'm over filling the device que, if so then why doesn't
> this happen when sys_read calls to read exactly the same data, just on
> user demand vice as a prefetch.
> 
> In any case, any ideas, thoughts or sudden rays of bright light would
> be greatly appreciated. Thanks for your time,
> 
>                                tmk
> 
> int prefetch_file_data(struct inode * inode, unsigned long max_ahead)
> {
>         struct dentry * dentry;
>         struct file * f;
>         int ahead,error;
>         unsigned long page_cache;
> 
>         if (max_ahead > inode->i_size)
>                 max_ahead = inode->i_size;
>         debug (4,"    prefetching data %ld bytes\n",max_ahead);
> 
>         error = -ENFILE;
>         f = get_empty_filp();
>         if (!f)
>                 return 0;
>         dentry = list_entry(inode->i_dentry.next, struct dentry, d_alias);
>         f->f_dentry = dentry;
>         f->f_pos = 0;
>         f->f_reada = 0;
>         f->f_op = NULL;
>         if (inode->i_op)
>                 f->f_op = inode->i_op->default_file_ops;
> #if 0/1  /* tried both with and without this */
>         if (f->f_op && f->f_op->open) {
>                 error = f->f_op->open(inode,f);
>                 if (error)
>                         put_filp(f);
>                         return 0;
>         }
> #endif
> 
>         ahead = 0;
>         while (ahead < max_ahead) {
>                 debug (2,"PREFETCHING 0x%0x %lu offset %lu\n",
>                        inode->i_dev, inode->i_ino,ahead);
>                 page_cache = try_to_read_ahead(f, ahead,0);
>                 ahead += PAGE_CACHE_SIZE;
>         }
> 
>         put_filp(f);
>         return max_ahead;
> }
> 
> Page read distributions for readnSleep without prefetching:
> times in usecs
> log_prefetch Hist:     8118 event      3890 mean  263 min    253458 max
> <       1:    0
> <       2:    0
> <       4:    0
> <       8:    0
> <      16:    0
> <      32:    0
> <      64:    0
> <     128:    0
> <     256:    0
> <     512:   23
> <    1024: 1461
> <    2048: 5586
> <    4096:   77
> <    8192:   97
> <   16384:  253
> <   32768:  511
> <   65536:   74
> <  131072:   31
> <  262144:
> <  524288:    0
> < 1048576:    0
> < 2097152:    0
> 
> Page read distributions for readnSleep with inter-file prefetching
> log_prefetch Hist:     2508 event    299952 mean  209 min   1005362 max 0 negs
> <       1:    0
> <       2:    0
> <       4:    0
> <       8:    0
> <      16:    0
> <      32:    0
> <      64:    0
> <     128:    0
> <     256:    1
> <     512:    7
> <    1024:  626
> <    2048:   12
> <    4096:    0
> <    8192:    8
> <   16384:   95
> <   32768:  133
> <   65536:   83
> <  131072:  162
> <  262144:  303
> <  524288:  413
> < 1048576:  665
> < 2097152:    0
> 
> --
> 
>                        tmk
> 
> -----------------------------------------------------------------------
> Tom M. Kroeger                           Pray for wind
> Graduate Student, UC Santa Cruz      \    Pray for waves
> e-mail: tmk@cs.ucsc.edu              |\    and Pray it's your day off!
> http://www.cse.ucsc.edu/~tmk         |~\
> (831) 459-4458                       |__\
> (831) 426-9055 home                 ,----+--
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/

-- 

The Internet interprets Windows as damage, 
             and routes around it.

Roger Larsson
Skellefte
Sweden


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:06:21 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA13735
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:06:21 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02723
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:06:45 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:21817 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S10157AbPHLBRg>;
	Thu, 12 Aug 1999 04:17:36 +0300
Received:  by vger.rutgers.edu via listexpand id <S155203AbPHLBFM>;
	Wed, 11 Aug 1999 21:05:12 -0400
Received:  by vger.rutgers.edu id <S153953AbPHLA5w>;
	Wed, 11 Aug 1999 20:57:52 -0400
Received: from mailg.telia.com ([194.22.194.26]:4965 "EHLO mailg.telia.com")
	by vger.rutgers.edu with ESMTP id <S154260AbPHLAfZ>;
	Wed, 11 Aug 1999 20:35:25 -0400
Received: from d1o43.telia.com (root@d1o43.telia.com [194.22.195.241])
	by mailg.telia.com (8.8.5/8.8.8) with ESMTP id CAA05775;
	Thu, 12 Aug 1999 02:35:12 +0200 (CEST)
Received: from skelleftea.mail.telia.com (t3o43p31.telia.com [194.22.195.151])
	by d1o43.telia.com (8.8.8/8.8.5) with ESMTP id CAA08413;
	Thu, 12 Aug 1999 02:35:10 +0200 (CEST)
Message-ID: <37B211A3.4440A21A@skelleftea.mail.telia.com>
Date:   Thu, 12 Aug 1999 02:13:23 +0200
From: Roger Larsson <roger.larsson@skelleftea.mail.telia.com>
Reply-To: nra02596@norran.net
X-Mailer: Mozilla 4.6 [en] (Win95; I)
X-Accept-Language: sv,en
MIME-Version: 1.0
To: Mike Ricketts <rickettm@ox.compsoc.net>
CC: linux-kernel@vger.rutgers.edu, Wakko Warner <wakko@animx.eu.org>,
        Jonathan Masters <mastersj@periscope-systems.freeserve.co.uk>
Subject: Re: hdd & sound
References: <Pine.LNX.4.10.9908112011350.1973-100000@oakley.keble.ox.ac.uk>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

Hi all,

All of you that are having this problem. Could you reply to me with:
a) type of ISA cards (as specific as possible, especially SCSI and
sound)
b) verify that you do not run SCSI/EIDE in non bus master mode.
c) attach a output from vmstat 2 > vmstat.out 
   (play sound, start this command, wait 5 secs, start disk activity,
    wait 5 secs, stop vmstat with ^C

    This was checked on Wakkos machine, and it indicated that no bus
    mastering / DMA was used.
    Note: my SB16SCSI II does not have DMA enabled by default... and
          ISA cards can not do bus mastering on their own.)
   
[I will make a summary]


PS.

I do think that this is related (until proven otherwise)

Check out
  http://www.gardena.net/benno/linux/audio/

But make sure that you are using Bus Master EIDE / dma transfers since
it does not handle that yet !

/RogerL

Mike wrote:
> 
> On Sat, 7 Aug 1999, Wakko Warner wrote:
> 
> > I'm noticing this one one of my machines.  When writing to a hard drive, the
> > sound drags.  The machine I'm on has piix4 ide and an isa scsi card.  I'm
> > playing sounds from the drive on the scsi card (aha1510 I think is the scsi
> > card).  I tried writing to both an ide and scsi drive, both drag the sound.
> > Sound card is an SB16 pnp /w ide port (not disablable unfortunately).  I had
> > a similar problem on an isa ide card playing sounds off of the hard drive
> > (like 44k 16bit 2ch sound off the drive, sound card was an ess card).  My
> > home box that this is happneing on is 2.2.7.  The one with the isa ide is no
> > longer active, but it was running 2.0.36.
> >
> I see much the same thing under (extremely) heavy disk load, both on
> onboard piix4 ide, and on an onboard aic7??? scsi.
> 
> Things it isn't:
>   hardware - too many people are seeing the same thing for that
>   driver specific - it happens on both ide and scsi, and with both sb and
>                     ess cards
>   anything blindingly obvious
> 
> Currently I suspect something evil either in sound_core.c or sound_timer.c
> or (more likely) something scheduler related, but this is wild guessing.  Any
> ideas?
> 
> --
> Mike <rickettm@ox.compsoc.net>
> 
> Q:      What's yellow, and equivalent to the Axiom of Choice?
> A:      Zorn's Lemon.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/

-- 

The Internet interprets Windows as damage, 
             and routes around it.

Roger Larsson
Skellefte
Sweden



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:06:25 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA13780
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:06:25 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02744
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:06:53 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:28016 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S9647AbPHLBZR>;
	Thu, 12 Aug 1999 04:25:17 +0300
Received:  by vger.rutgers.edu via listexpand id <S154777AbPHLBSG>;
	Wed, 11 Aug 1999 21:18:06 -0400
Received:  by vger.rutgers.edu id <S154019AbPHLBKD>;
	Wed, 11 Aug 1999 21:10:03 -0400
Received: from mail4.svr.pol.co.uk ([195.92.193.211]:17018 "EHLO
        mail4.svr.pol.co.uk") by vger.rutgers.edu with ESMTP
	id <S154180AbPHLA7m>; Wed, 11 Aug 1999 20:59:42 -0400
Received: from modem-32.ruthenium.dialup.pol.co.uk
	([62.136.21.160] helo=periscope.localdomain ident=root)
	by mail4.svr.pol.co.uk with esmtp (Exim 2.12 #2)
	id 11EjDX-0000th-00; Thu, 12 Aug 1999 01:59:40 +0100
Received: from periscope-systems.freeserve.co.uk (IDENT:mastersj@periscope.localdomain [192.168.0.1])
	by periscope.localdomain (8.9.3/8.8.7) with ESMTP id AAA24620;
	Thu, 12 Aug 1999 00:53:30 +0100
Message-ID: <37B20CFA.73D27CEB@periscope-systems.freeserve.co.uk>
Date:   Thu, 12 Aug 1999 00:53:30 +0100
From: Jonathan Masters <mastersj@periscope-systems.freeserve.co.uk>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Homme R. Bitter" <homme@vuurwerk.nl>, linux-kernel@vger.rutgers.edu,
        linux-admin@vger.rutgers.edu
Subject: Re: Gates of Hell
References: <Pine.LNX.4.10.9908112221500.983-100000@pc-homme.vuurwerk.nl>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

The worst of it is - the site ***********filters*********** by OS type. This
means that you can't access it if you're running Linux. Actually, that brings
up a question: I have a barclays online banking account, but barclays also
filter by OS type (at least what they get from the browser) - they claim
Linux/UNIX is "less secure than windows " (3.1 , 95, 98 AND NT!!!!!!!!! -
they said this when I spoke to them) - I have made excessive threats to them
about legal action and have several people investigating whether what they
are doing is legal, but until then, is there an easy way to get ns to lie
about os/browser version, or can some of us write some kind of proxy which
lies about os, etc...?? Thanx.

"Homme R. Bitter" wrote:

> This person is obviously applying for a collection of coredums in his/her
> email box....
> Is there a way to make this list more closed ?
>
> Cheers,
>
> --
> Homme R. Bitter
>
> Anything that talks to you from inside the fridge should be discarded.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/

--
Jonathan C. Masters                     (jonathan@oxlug.org)
                                        PGP: www.brookes.ac.uk/~95227860/KEY

           "Upon this rock I will build my church,
            and the gates of hell shall not prevail against it".

                 -- Matthew 16, 17-18




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:06:29 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA13830
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:06:28 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02754
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:06:56 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:6526 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S10100AbPHLB3l>;
	Thu, 12 Aug 1999 04:29:41 +0300
Received:  by vger.rutgers.edu via listexpand id <S154303AbPHLBU5>;
	Wed, 11 Aug 1999 21:20:57 -0400
Received:  by vger.rutgers.edu id <S154034AbPHLBRu>;
	Wed, 11 Aug 1999 21:17:50 -0400
Received: from mail9.svr.pol.co.uk ([195.92.193.22]:25624 "EHLO
        mail9.svr.pol.co.uk") by vger.rutgers.edu with ESMTP
	id <S155216AbPHLBFS>; Wed, 11 Aug 1999 21:05:18 -0400
Received: from modem-32.ruthenium.dialup.pol.co.uk
	([62.136.21.160] helo=periscope.localdomain ident=root)
	by mail9.svr.pol.co.uk with esmtp (Exim 2.12 #2)
	id 11EjIx-00051j-00; Thu, 12 Aug 1999 02:05:15 +0100
Received: from periscope-systems.freeserve.co.uk (IDENT:mastersj@periscope.localdomain [192.168.0.1])
	by periscope.localdomain (8.9.3/8.8.7) with ESMTP id BAA25144;
	Thu, 12 Aug 1999 01:38:45 +0100
Message-ID: <37B21795.B57EE332@periscope-systems.freeserve.co.uk>
Date:   Thu, 12 Aug 1999 01:38:45 +0100
From: Jonathan Masters <mastersj@periscope-systems.freeserve.co.uk>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-kernel@vger.rutgers.edu, linux-admin@vger.rutgers.edu
Subject: Re: Mount
References: <D53173D574D6D211945500A0C9E95BEB279E6B@xsj02.sj.hp.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

Neither of you got my *point* the filesystem is READ ONLY - hence the reason
why I clearly stated that it was a CDROM. Thanks, although  I had realised
both of these two tactics, and yes, I would have done both on a RW
filesystem, but the point was I needed a way to do it without burning a new
cd.

This question has now been answered. The syntax required was "mount -o
check=r /dev/cdrom /mnt/cdrom"

Jon.

"WANG,YIDING (HP-SanJose,ex1)" wrote:

> Here is a script you can use to convert all file name:
>
> 1, upper2lower:
>         for file in `ls`
>         do
>                 newname=`echo $file | tr "[A-Z] "[a-z]"
>                 mv $file $newname
>         done
>
> 2, lower2upper:
>         for file in `ls`
>         do
>                 newname=`echo $file | tr "[a-z] "[A-Z]"
>                 mv $file $newname
>         done
>
> -eddie
> -----Original Message-----
> From: Marc Mutz [mailto:Marc@Mutz.com]
> Sent: Wednesday, August 11, 1999 2:35 PM
> To: Jonathan Masters
> Cc: linux-kernel@vger.rutgers.edu; linux-admin@vger.rutgers.edu
> Subject: Re: Mount
>
> Jonathan Masters wrote:
> >
> > Hi,
> >     I've just received a cd which is written in the standard iso9660
> > format. However the stupid author, wrote some of the file names (in his
> > html) in upper case and some in lower case. Since the majority are in
> > upper case and since linux seems to mount the device by default so that
> > files appear in lower case, I must ask - how do I mount a cdrom such
> > that all files appear as upper case rather than lower case. Thanks. (The
> > CD has 1000s of small files which are linked to so it isn't realistic to
> > fix by hand - there must be an easier way anyway.... Thanks again.
> >
> > Oh, one more while I'm here, I tried putting an rc6 ext2fs on a cd but
> > it simply refuses to mount (yes I did create the image correctly and
> > pass mount the right options). Any ideas? <interrupted>
> >
> Have you tried the following:
> #setup
> losetup -e rc6 /dev/loop0 /dev/cdrom
> mke2fs /dev/loop0
> losetup -d /dev/loop0
> #mounting
> mount -t ext2 /dev/cdrom /mnt/crypto-cd -o loop,encryption=rc6
>
> or did you something different?
>
> > I'm also waiting for the li
> > patch for 2.2.11
> You don't need to :-)
> patch-int-2.2.10-4 applies fairly cleanly to 2.2.11. Just on reject for
> loop.c that can be most easily done by hand (just remove the lines
> marked with '-' in drivers/block/loop.c.rej and add lines marked with
> '+' to loop.c)
>
> Marc
>
> --
> Marc Mutz <Marc@Mutz.com>                   http://marc.mutz.com/
> University of Bielefeld, Dep. of Mathematics / Dep. of Physics
>
> PGP-keyID's:   0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH)
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/

--
Jonathan C. Masters                     (jonathan@oxlug.org)
                                        PGP: www.brookes.ac.uk/~95227860/KEY

           "Upon this rock I will build my church,
            and the gates of hell shall not prevail against it".

                 -- Matthew 16, 17-18




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:06:32 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA13864
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:06:31 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02768
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:06:59 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:18955 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S10112AbPHLBeb>;
	Thu, 12 Aug 1999 04:34:31 +0300
Received:  by vger.rutgers.edu via listexpand id <S154406AbPHLBa7>;
	Wed, 11 Aug 1999 21:30:59 -0400
Received:  by vger.rutgers.edu id <S153846AbPHLBZb>;
	Wed, 11 Aug 1999 21:25:31 -0400
Received: from aleph.net.uniovi.es ([156.35.11.1]:3024 "EHLO
        aleph.net.uniovi.es") by vger.rutgers.edu with ESMTP
	id <S153941AbPHLBT0>; Wed, 11 Aug 1999 21:19:26 -0400
Received: from pinon.ccu.uniovi.es by aleph.net.uniovi.es (PMDF V5.1-11 #30226)
 with ESMTP id <01JENYGYFIC400CX7V@aleph.net.uniovi.es> for
 linux-kernel@vger.rutgers.edu; Thu, 12 Aug 1999 03:19:11 +0200 (MET)
Received: (from german@localhost) by pinon.ccu.uniovi.es (8.9.2/8.9.2)
 id DAA17015; Thu, 12 Aug 1999 03:19:09 +0200 (METDST)
Date:   Thu, 12 Aug 1999 03:19:08 +0200 (METDST)
From: German Jose Gomez Garcia <german@pinon.ccu.uniovi.es>
Subject: devfs ??
To: Mailing List Linux Kernel <linux-kernel@vger.rutgers.edu>
Message-id: <Pine.HPP.3.91.990812031623.16938A-100000@pinon.ccu.uniovi.es>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

	What happened to devfs? It seems that the 2.2.x series has been 
interrupted, and it is getting really painful to apply 99.4 to 2.2.11+.
	And well, I know it has being asked a thousand times but, when (if 
we will) will we see it in the kernel?

	Thanks

	- german

<>-------------------------------------+-----------------------------------<>
   One O.S. to rule them all,          |  German Gomez Garcia
      One O.S. to find them.           |  german@pinon.ccu.uniovi.es
   One O.S. to bring them all          |
      and in the darkness bind them.   |  "Wur Qanar Wur Stilor Wur Kas"
<>-------------------------------------+-----------------------------------<>


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:06:40 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA13944
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:06:38 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02776
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:07:02 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:18955 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S44403AbPHLBiv>;
	Thu, 12 Aug 1999 04:38:51 +0300
Received:  by vger.rutgers.edu via listexpand id <S154549AbPHLBbs>;
	Wed, 11 Aug 1999 21:31:48 -0400
Received:  by vger.rutgers.edu id <S153953AbPHLBbS>;
	Wed, 11 Aug 1999 21:31:18 -0400
Received: from [202.99.59.94] ([202.99.59.94]:41018 "EHLO fw.talentit.com.cn")
	by vger.rutgers.edu with ESMTP id <S154079AbPHLB2l>;
	Wed, 11 Aug 1999 21:28:41 -0400
Received: (from smtppxy@localhost)
	by fw.talentit.com.cn (8.8.7/8.8.7) id JAA00440
	for <linux-kernel@vger.rutgers.edu>; Thu, 12 Aug 1999 09:26:19 +0800
X-Authentication-Warning: fw.talentit.com.cn: smtppxy set sender to <wu_yb@263.net> using -f
Message-ID: <37B2232B.14360484@263.net>
Date:   Thu, 12 Aug 1999 09:28:11 +0800
From: wu_yb <wu_yb@263.net>
X-Mailer: Mozilla 4.6 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-kernel@vger.rutgers.edu
Subject: initfunc
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

A newbie question.
In kernel 2.2.x, many functions are declared as __initfunc(),
such as __initfunc(void setup_arch(xxx)), does __initfunc()
means that after this function called, the mem occupied can
be freed ?

Thanks !!!


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:06:43 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA13987
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:06:41 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02792
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:07:09 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:40251 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S42724AbPHLBwm>;
	Thu, 12 Aug 1999 04:52:42 +0300
Received:  by vger.rutgers.edu via listexpand id <S154846AbPHLBtX>;
	Wed, 11 Aug 1999 21:49:23 -0400
Received:  by vger.rutgers.edu id <S153874AbPHLBtB>;
	Wed, 11 Aug 1999 21:49:01 -0400
Received: from tmmi196-012.telusvelocity.net ([209.115.196.12]:1317 "EHLO
        Wakko.deltatee.com") by vger.rutgers.edu with ESMTP
	id <S153844AbPHLBsv>; Wed, 11 Aug 1999 21:48:51 -0400
Received: from localhost (Wakko.deltatee.com) [127.0.0.1] (jgg)
	by Wakko.deltatee.com with smtp (Exim 2.11 #1)
	id 11EjyV-0001wG-00 (Debian); Wed, 11 Aug 1999 19:48:11 -0600
Date:   Wed, 11 Aug 1999 19:48:11 -0600 (MDT)
From: Jason Gunthorpe <jgg@ualberta.ca>
X-Sender: jgg@Wakko.deltatee.com
To: Matthew <matthew@mattshouse.com>
cc: linux-kernel@vger.rutgers.edu, becker@cesdis.edu
Subject: Re: via-rhine nic crazyness on PIII Xeon SMP running 2.2.5 - 2.2.11
In-Reply-To: <99081118321500.05912@matthew.linuxnet>
Message-ID: <Pine.LNX.3.96.990811194526.2211M-100000@Wakko.deltatee.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig


On Wed, 11 Aug 1999, Matthew wrote:

> eth0 and eth1 behave properly, but eth2 (the via-rhine) spits out "Something
> Wicked has happened" into the syslog.  I turned on verbose mode and captured
> about 20k of data, including three instances of the "Wickedness".  I looked
> through docs and the source (via-rhine.c) and couldn't find any mention of
> failure due to multiple nics or SMP.

I see this as well on my machine with dual via-rhine (dlink) cards. One
card doesn't even have a cable pluggined in however.

via-rhine.c:v1.00 9/5/98  Written by Donald Becker
  http://cesdis.gsfc.nasa.gov/linux/drivers/via-rhine.html
via-rhine.c:v1.00 9/5/98  Written by Donald Becker
  http://cesdis.gsfc.nasa.gov/linux/drivers/via-rhine.html
eth0: VIA VT3043 Rhine at 0x7f80, 00:80:c8:e1:69:fb, IRQ 11.
eth0: MII PHY found at address 8, status 0x782d advertising 05e1 Link 0000.
eth1: VIA VT3043 Rhine at 0x7f00, 00:80:c8:e2:ce:89, IRQ 10.
eth1: MII PHY found at address 8, status 0x7809 advertising 05e1 Link 0000.

eth0: Oversized Ethernet frame c009b010 vs c009b010.
eth0: Oversized Ethernet frame spanned multiple buffers, entry 0x1f04c
length 0 status 0600!
eth0: Oversized Ethernet frame c009b0c0 vs c009b0c0.
eth0: Something Wicked happened! 2008.
eth0: Something Wicked happened! 2008.
eth0: Something Wicked happened! 2008.
eth0: Something Wicked happened! 2008.
eth0: Something Wicked happened! 2008.
eth0: Something Wicked happened! 2008.
eth0: Oversized Ethernet frame spanned multiple buffers, entry 0x39898
length 0 status 0600!
eth0: Oversized Ethernet frame c009b080 vs c009b080.
eth0: Oversized Ethernet frame spanned multiple buffers, entry 0x3989b
length 0 status 0600!

My network here is very noisy, but non of the other linux boxes with
tulips or ne2k's print anything at all like this. The kernel is 2.2.9

This machine is totally idle, I can futz with it however.

Jason


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:06:45 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA14028
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:06:44 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02801
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:07:12 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:18000 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S42189AbPHLB7z>;
	Thu, 12 Aug 1999 04:59:55 +0300
Received:  by vger.rutgers.edu via listexpand id <S154843AbPHLB4t>;
	Wed, 11 Aug 1999 21:56:49 -0400
Received:  by vger.rutgers.edu id <S153846AbPHLB42>;
	Wed, 11 Aug 1999 21:56:28 -0400
Received: from lrcpc22.epfl.ch ([128.178.156.58]:4368 "EHLO lrcpc22.epfl.ch")
	by vger.rutgers.edu with ESMTP id <S153844AbPHLB4U>;
	Wed, 11 Aug 1999 21:56:20 -0400
Received: (from almesber@localhost)
	by lrcpc22.epfl.ch (8.8.7/ICA.Lc1) id DAA05171;
	Thu, 12 Aug 1999 03:23:56 +0200
Date:   Thu, 12 Aug 1999 03:23:56 +0200
From: Werner Almesberger <almesber@lrc.di.epfl.ch>
To: "Bradley D. LaRonde" <brad@ltc.com>
Cc: linux-kernel@vger.rutgers.edu
Subject: Re: initrd broken (was Re: 2.3.9+ and initrd)
Message-ID: <19990812032355.A5130@lrc.di.epfl.ch>
References: <000f01bee3ac$4037a060$b8119526@ltc.com> <005101bee444$0c310200$b8119526@ltc.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.6i
In-Reply-To: <005101bee444$0c310200$b8119526@ltc.com>; from Bradley D. LaRonde on Wed, Aug 11, 1999 at 05:54:12PM -0400
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

Bradley D. LaRonde wrote:
> What happened back then that broke the the filesystems?

The introduction of the page cache broke RAM disks, which of course
also broke initrd. With a little luck, initrd should start to work
again automagically once RAM disks are fixed. (I'm not quite sure
what the status is there.)

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, ICA, EPFL, CH       werner.almesberger@ica.epfl.ch /
/_IN_R_131__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:06:49 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA14082
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:06:49 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02811
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:07:15 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:53595 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S9684AbPHLCFZ>;
	Thu, 12 Aug 1999 05:05:25 +0300
Received:  by vger.rutgers.edu via listexpand id <S154962AbPHLCBG>;
	Wed, 11 Aug 1999 22:01:06 -0400
Received:  by vger.rutgers.edu id <S153846AbPHLCAy>;
	Wed, 11 Aug 1999 22:00:54 -0400
Received: from mail1.svr.pol.co.uk ([195.92.193.18]:31514 "EHLO
        mail1.svr.pol.co.uk") by vger.rutgers.edu with ESMTP
	id <S153854AbPHLCAg>; Wed, 11 Aug 1999 22:00:36 -0400
Received: from modem-98.uranium.dialup.pol.co.uk
	([62.136.45.226] helo=periscope.localdomain ident=root)
	by mail1.svr.pol.co.uk with esmtp (Exim 2.12 #2)
	id 11EkAR-0007pz-00; Thu, 12 Aug 1999 03:00:31 +0100
Received: from periscope-systems.freeserve.co.uk (IDENT:mastersj@periscope.localdomain [192.168.0.1])
	by periscope.localdomain (8.9.3/8.8.7) with ESMTP id CAA27563;
	Thu, 12 Aug 1999 02:59:20 +0100
Message-ID: <37B22A77.C2454B61@periscope-systems.freeserve.co.uk>
Disposition-Notification-To: Jonathan Masters <mastersj@periscope-systems.freeserve.co.uk>
Date:   Thu, 12 Aug 1999 02:59:19 +0100
From: Jonathan Masters <mastersj@periscope-systems.freeserve.co.uk>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: nra02596@norran.net, linux-kernel@vger.rutgers.edu,
        linux-sound@vger.rutgers.edu, linux-admin@vger.rutgers.edu
Subject: Re: hdd & sound
References: <Pine.LNX.4.10.9908112011350.1973-100000@oakley.keble.ox.ac.uk> <37B211A3.4440A21A@skelleftea.mail.telia.com>
Content-Type: multipart/mixed;
 boundary="------------9AE9CA3CA812B68FB974C4B0"
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

This is a multi-part message in MIME format.
--------------9AE9CA3CA812B68FB974C4B0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by periscope.localdomain id CAA27563

Roger Larsson wrote:

> Hi all,
>
> All of you that are having this problem. Could you reply to me with:
> a) type of ISA cards (as specific as possible, especially SCSI and
> sound)
>

My machine has a single ISA card which is a SB 64 AWE GOLD. The HDDs are =
running of
the motherboard controller. I have two hdds on one controller, two cd-rom=
s (1
reader, 1 rewriter) on the other. This test was performed when ripping th=
e Britney
Spears Sometimes single to create a wav file. cdrecord produces some inte=
ruption, I
used cdparanoia becausethat seems to be much worse so that you can seethe=
 effects.
This also occurs when I write cd-roms, but I don't want to waste a couple=
 of cds
unless you think it's useful in which case I will.



> b) verify that you do not run SCSI/EIDE in non bus master mode.
>

As far as I am aware they are in Bus master mode. The machine was built b=
y myself
and is less than 1 year old (PII 400 Mhz 128Mb RAM, 256 MbSWAP (128Mb on =
each of
the two hdds). I did not adjust this setting so I assume that it is using=
 Bus
mastering mode which is normal on all modern machines.


> c) attach a output from vmstat 2 > vmstat.out
>    (play sound, start this command, wait 5 secs, start disk activity,
>     wait 5 secs, stop vmstat with ^C
>

I already had sound playing, started the command, waited 5 secs, started =
ripping,
continued until ripping finished, waited a couple of secs (I think 5) and=
 then
stopped vmstat. During the ripping there was a horrible "slow motiony slo=
w down" of
the music, like when you hold a tape and physically slow it down as it mo=
ves inside
a tape player. Also, it often "cut's out" for several seconds at a time a=
s it did
once or twice here.


>
>     This was checked on Wakkos machine, and it indicated that no bus
>     mastering / DMA was used.
>     Note: my SB16SCSI II does not have DMA enabled by default... and
>           ISA cards can not do bus mastering on their own.)
>

I assume you are refering to the sbs which have a hdd controller onboard?=
 Mine are
on the motherboard separate from the sb64.

If you want any further info, just tell me what you need and you've got i=
t
yesturday.


>
> [I will make a summary]
>
> PS.
>
> I do think that this is related (until proven otherwise)
>
> Check out
>   http://www.gardena.net/benno/linux/audio/
>
> But make sure that you are using Bus Master EIDE / dma transfers since
> it does not handle that yet !
>
> /RogerL
>
> Mike wrote:
> >
> > On Sat, 7 Aug 1999, Wakko Warner wrote:
> >
> > > I'm noticing this one one of my machines.  When writing to a hard d=
rive, the
> > > sound drags.  The machine I'm on has piix4 ide and an isa scsi card=
.  I'm
> > > playing sounds from the drive on the scsi card (aha1510 I think is =
the scsi
> > > card).  I tried writing to both an ide and scsi drive, both drag th=
e sound.
> > > Sound card is an SB16 pnp /w ide port (not disablable unfortunately=
).  I had
> > > a similar problem on an isa ide card playing sounds off of the hard=
 drive
> > > (like 44k 16bit 2ch sound off the drive, sound card was an ess card=
).  My
> > > home box that this is happneing on is 2.2.7.  The one with the isa =
ide is no
> > > longer active, but it was running 2.0.36.
> > >
> > I see much the same thing under (extremely) heavy disk load, both on
> > onboard piix4 ide, and on an onboard aic7??? scsi.
> >
> > Things it isn't:
> >   hardware - too many people are seeing the same thing for that
> >   driver specific - it happens on both ide and scsi, and with both sb=
 and
> >                     ess cards
> >   anything blindingly obvious
> >
> > Currently I suspect something evil either in sound_core.c or sound_ti=
mer.c
> > or (more likely) something scheduler related, but this is wild guessi=
ng.  Any
> > ideas?
> >
> > --
> > Mike <rickettm@ox.compsoc.net>
> >
> > Q:      What's yellow, and equivalent to the Axiom of Choice?
> > A:      Zorn's Lemon.
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kerne=
l" in
> > the body of a message to majordomo@vger.rutgers.edu
> > Please read the FAQ at http://www.tux.org/lkml/
>
> --
>
> The Internet interprets Windows as damage,
>              and routes around it.
>
> Roger Larsson
> Skellefte=E5
> Sweden
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel"=
 in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/

--
Jonathan C. Masters                     (jonathan@oxlug.org)
                                        PGP: www.brookes.ac.uk/~95227860/=
KEY

           "Upon this rock I will build my church,
            and the gates of hell shall not prevail against it".

                 -- Matthew 16, 17-18



--------------9AE9CA3CA812B68FB974C4B0
Content-Type: text/plain; charset=us-ascii;
 name="vmstat.out"
Content-Disposition: inline;
 filename="vmstat.out"
Content-Transfer-Encoding: 7bit

   procs                      memory    swap          io     system         cpu
 r  b  w   swpd   free   buff  cache  si  so    bi    bo   in    cs  us  sy  id
 1  0  0  29248   2996  34524  23732   1   0    72    45  170   148  15   4  82
 1  0  0  29248   3044  34520  23684   0   0    38     1  880  1931   2   4  94
 1  0  0  29248   3180  34480  23596   0   0     0     7  816  1901   2   4  94
 2  0  0  29248   1832  34236  23584   0   0     0     4  821  1775   4   7  89
 2  0  0  29248   3136  32876  23484   0   0    39   281  784  1704   7  12  81
 0  0  0  29248   3168  32624  23480   0   0     0     0  842  1861  10   8  82
 1  0  0  29248   3140  32392  23532   0   0    38     0  799  1894   7  12  81
 2  0  1  29248   3708  32304  23492   0   0     0     0  746  1695  10  10  80
 3  0  1  29248   3580  32304  23492   0   0     0   642  767  1748  11   9  80
 2  0  1  29248   3368  32304  23568   0   0    38     0  756  1725  11  10  79
 2  0  1  29248   3112  32304  23568   0   0     0     0  768  1826   6  12  82
 1  0  1  29248   3772  32304  23260   0   0    38  1130  794  1841   8  11  81
 2  0  1  29248   3696  32304  23260   0   0     0     0  774  1860   9   9  82
 1  0  1  29248   3948  32304  23260   0   0     1   729  792  1765  10  10  80
 2  0  0  29248   3596  32304  23336   0   0    39     7  752  1679   7  10  83
 1  0  0  29248   3404  32304  23336   0   0     0     0  768  1819   7   6  87
 2  0  0  29248   3792  32304  23336   0   0     1  1023  791  1737   8   9  83
 2  0  0  29248   3600  32304  23412   0   0    38     0  769  1704  10   9  80
 3  0  1  29248   3244  32304  23412   0   0     0  1015  828  1771   9  12  79
 5  0  1  29248   3644  30276  23512 176   0   341   500  935  2358  35  18  47
 2  0  1  29248   3024  30020  23944   0   0   190   250  831  2017  34  18  47
   procs                      memory    swap          io     system         cpu
 r  b  w   swpd   free   buff  cache  si  so    bi    bo   in    cs  us  sy  id
 3  0  0  29248   3476  29900  23936   0   0     9   266  791  1754  13   6  81
 3  0  0  29248   3140  29900  24012   0   0    39     0  756  1700  11  11  78
 2  0  1  29248   3456  29780  24004   0   0     0  1347  821  1727  10  13  77
 3  0  0  29248   3264  29780  24004   0   0     0     0  762  1696  11   7  82
 2  0  0  29248   3596  29780  24080   0   0    38     0  758  1716  31  18  51
 1  0  1  29248   5564  29536  24152   0   0    45  1016  771  1734  15  10  75
 3  0  1  29248   5208  29536  24228   0   0    38     0  798  1958   6  11  82
 2  0  0  29248   5368  29536  24228   0   0     0   769  766  1788  10  12  78
 3  0  1  29248   5212  29536  24228   0   0     0     0  789  1885   9   8  83
 3  0  0  29248   5460  29536  24304   0   0    39     0  766  1869  10   8  82
 3  0  0  29248   5204  29536  24304   0   0     0  1016  773  1822  11   9  80
 3  0  1  29248   5464  29536  24304   0   0     0     0  772  1860   8  12  80
 2  0  1  29248   5056  29536  24380   0   0    38  1012  784  1808  10   9  80
 1  0  0  29248   5320  29536  24380   0   0     0     0  759  1863  10   7  83
 1  0  1  29248   4984  29536  24456   0   0    38  1014  833  1977  10  12  78
 2  0  0  29248   5308  29536  24456   0   0     0     0  769  1797  10  11  79
 3  0  1  29248   5120  29536  24456   0   0     0     0  760  1763   7  10  82
 3  0  1  29248   5300  29536  24532   0   0    38  1014  775  1722  11  13  77
 2  0  1  29248   4900  29740  24532   0   0     0     0  756  1717  10   9  80
 4  0  0  29248   4164  30672  24532   0   0     0  1015  768  1749  14  10  76
 2  0  1  29248   3076  31424  24608   0   0    39     0  758  1791   6  11  83
   procs                      memory    swap          io     system         cpu
 r  b  w   swpd   free   buff  cache  si  so    bi    bo   in    cs  us  sy  id
 3  0  1  29492   3356  32252  24052   0 122     0   781  894  2059  12  14  74
 5  0  0  29492   2860  33004  23512   0   0    52   515  784  2033  23  13  64
 4  0  0  29492   3196  33840  22512   0   0    26   500  762  1877   8  10  82
 3  0  1  29492   2852  33912  22500   0   0    38   653  765  1843  11  11  79
 2  0  1  29492   2936  34048  22476   0   0    39   500  834  1981  14  10  76
 3  0  1  29492   2728  34356  22024   0   0     0     0  750  1987   9  12  79
 4  0  1  29492   3052  34660  21632   0   0     0   517  774  1876  11  12  78
 3  0  1  29492   2528  35056  21420   0   0    38   500  766  1879  11   9  80
 2  0  0  29492   2800  35232  21232   0   0     0   266  768  1919  11  13  76
 2  0  1  29492   2872  35700  20928   0   0     0     0  750  1853   9  11  79
 2  0  1  29492   2896  35420  20884   0   0    38     0  753  1812  11  11  78
 2  0  0  29492   5076  35620  20740   0   0     0  1052  771  1804  13  11  76
 3  0  1  29492   4988  35624  20816   0   0    39     0  889  2107   2   3  94
 2  0  0  29492   4988  35624  20816   0   0     0  1012  822  1889   3   4  93
 1  0  0  29492   4988  35624  20816   0   0     0     0  836  1925   2   3  95

--------------9AE9CA3CA812B68FB974C4B0--


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:06:54 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA14126
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:06:52 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02820
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:07:20 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:5744 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S9516AbPHLCK5>;
	Thu, 12 Aug 1999 05:10:57 +0300
Received:  by vger.rutgers.edu via listexpand id <S155071AbPHLCG3>;
	Wed, 11 Aug 1999 22:06:29 -0400
Received:  by vger.rutgers.edu id <S154328AbPHLCGL>;
	Wed, 11 Aug 1999 22:06:11 -0400
Received: from lilith.dpo.uab.edu ([138.26.1.128]:3886 "EHLO
        lilith.dpo.uab.edu") by vger.rutgers.edu with ESMTP
	id <S153846AbPHLCF5>; Wed, 11 Aug 1999 22:05:57 -0400
Received: from cis.uab.edu (liberty.cis.uab.edu [138.26.65.34])
	by lilith.dpo.uab.edu (8.9.3/8.9.3) with SMTP id VAA03063;
	Wed, 11 Aug 1999 21:05:54 -0500
Received: from crafty by cis.uab.edu (SMI-8.6/SMI-SVR4)
	id VAA15672; Wed, 11 Aug 1999 21:05:53 -0500
Date:   Wed, 11 Aug 1999 20:59:47 -0500 (CDT)
From: "Robert M. Hyatt" <hyatt@cis.uab.edu>
To: joeja@mindspring.com
cc: linux-smp@vger.rutgers.edu, linux-kernel@vger.rutgers.edu
Subject: Re: double include of a header file
In-Reply-To: <19990810154547.28624.rocketmail@web501.yahoomail.com>
Message-ID: <Pine.LNX.4.10.9908112059060.7936-100000@crafty.cis.uab.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig


Shouldn't cause any problems if the header file is written correctly.
Most check and if it has been included once, the second inclusion does
nothing.  Ought to be removed of course...  but it doesn't hurt anything.


Robert Hyatt                    Computer and Information Sciences
hyatt@cis.uab.edu               University of Alabama at Birmingham
(205) 934-2213                  115A Campbell Hall, UAB Station 
(205) 934-5473 FAX              Birmingham, AL 35294-1170

On Tue, 10 Aug 1999, Joe wrote:

> Hi,
>     I am not a C expert so can someone tell me what the benifits
> / disadvantages of the following lines of code are if there are
> any? The reason I am writning these lists is that I found this
> code in the kernel..
> 
> #include <asm/irq.h>
> #include <asm/system.h>
> #include <asm/irq.h>
> 
> Joe
> _____________________________________________________________
> Do You Yahoo!?
> Bid and sell for free at http://auctions.yahoo.com
> 
> -
> Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/mentre/smp-faq/
> To Unsubscribe: send "unsubscribe linux-smp" to majordomo@vger.rutgers.edu
> 


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:06:56 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA14174
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:06:56 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02837
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:07:24 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:1910 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S42603AbPHLCNm>;
	Thu, 12 Aug 1999 05:13:42 +0300
Received:  by vger.rutgers.edu via listexpand id <S155250AbPHLCGb>;
	Wed, 11 Aug 1999 22:06:31 -0400
Received:  by vger.rutgers.edu id <S153874AbPHLCGD>;
	Wed, 11 Aug 1999 22:06:03 -0400
Received: from [38.149.17.171] ([38.149.17.171]:1249 "HELO ltc.com")
	by vger.rutgers.edu with SMTP id <S154079AbPHLCDB>;
	Wed, 11 Aug 1999 22:03:01 -0400
Received: from PREFECT (PREFECT [38.149.17.184]) by ltc.com (NTMail 3.03.0017/1.afdd) with ESMTP id ca309870 for <linux-kernel@vger.rutgers.edu>; Wed, 11 Aug 1999 22:08:10 -0400
Message-ID: <01c601bee466$627aba80$b8119526@ltc.com>
From: "Bradley D. LaRonde" <brad@ltc.com>
To: "Werner Almesberger" <almesber@lrc.di.epfl.ch>
Cc: <linux-kernel@vger.rutgers.edu>
References: <000f01bee3ac$4037a060$b8119526@ltc.com> <005101bee444$0c310200$b8119526@ltc.com> <19990812032355.A5130@lrc.di.epfl.ch>
Subject: Re: initrd broken (was Re: 2.3.9+ and initrd)
Date:   Wed, 11 Aug 1999 21:59:59 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig


From: Werner Almesberger <almesber@lrc.di.epfl.ch>
> Bradley D. LaRonde wrote:
> > What happened back then that broke the the filesystems?
>
> The introduction of the page cache broke RAM disks, which of course
> also broke initrd. With a little luck, initrd should start to work
> again automagically once RAM disks are fixed. (I'm not quite sure
> what the status is there.)

Thanks for the info.

How did the page cache break things?  I'm asking because I am willing to
work on getting RAM disks working again, but I would like to know where to
start.

Regards,
Brad


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:07:00 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA14217
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:06:59 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02850
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:07:27 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:18443 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S9537AbPHLCSb>;
	Thu, 12 Aug 1999 05:18:31 +0300
Received:  by vger.rutgers.edu via listexpand id <S155265AbPHLCPG>;
	Wed, 11 Aug 1999 22:15:06 -0400
Received:  by vger.rutgers.edu id <S153846AbPHLCOQ>;
	Wed, 11 Aug 1999 22:14:16 -0400
Received: from lacrosse.corp.redhat.com ([207.175.42.154]:3746 "EHLO
        lacrosse.corp.redhat.com") by vger.rutgers.edu with ESMTP
	id <S155912AbPHLCNb>; Wed, 11 Aug 1999 22:13:31 -0400
Received: from aic-cvs.devel.redhat.com (dledford.corp.redhat.com [10.0.0.25])
	by lacrosse.corp.redhat.com (8.9.3/8.9.3) with ESMTP id WAA06015;
	Wed, 11 Aug 1999 22:13:28 -0400
Received: from redhat.com (IDENT:dledford@localhost [127.0.0.1])
	by aic-cvs.devel.redhat.com (8.9.3/8.9.3) with ESMTP id WAA01100;
	Wed, 11 Aug 1999 22:16:47 -0400
Message-ID: <37B22E8F.BE7033C1@redhat.com>
Date:   Wed, 11 Aug 1999 22:16:47 -0400
From: Doug Ledford <dledford@redhat.com>
Organization: Red Hat, Inc.
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.5-22 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Steve Davies <steve@one47.demon.co.uk>
CC: linux-kernel@vger.rutgers.edu
Subject: Re: 2.2.11 and aic7xxx
References: <37B1D158.71F641DD@one47.demon.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

Steve Davies wrote:
> 
> Hi,
> 
> I've just skipped from 2.2.9 to 2.2.11 (I didn't like some of the problem
> reports I saw for 2.2.10), and now I get LOADS of the following messages at
> boot time:
> 
> (scsi1:0:1:0) Data overrun detected in Data-In phase, tag 1;
>   Have seen Data Phase. Length=255, NumSGs=1.
>      sg[0] - Addr 0xffc8480 : Length 255
> (scsi1:0:1:0) Data overrun detected in Data-In phase, tag 1;
>   Have seen Data Phase. Length=255, NumSGs=1.
>      sg[0] - Addr 0xffc8480 : Length 255
> 
> Looking at the 2.2.11 patch, it updates aic7xxx, so I guess that's where the
> version change happened.
> 
> The strange thing is that if I wait long enough, it eventually resets itself
> into a peaceful state and gets on with life. Something like this seems to
> happen every couple of releases/updates of the aic7xxx driver! I guess I chose
> the wrong hardware :-(
> 
> To be more accurate the hardware is: Dual AIC-7895 Ultra, with Tagged queueing
> enabled in the driver (Version 5.1.19/3.2.4)
> 
> Same setup for the previous driver has no problems. I've never foung any clues
> in the READMEs (Yes I DO read them when I get problems :-)

I've already been informed about this by someone else.  You probably have
Western Digital Enterprise drive(s) on that SCSI bus or other similar drives. 
Disabling target initiated Sync/Wide negotiation makes the errors all but
disappear.  I'm working on getting one of these drives that do the target
initiated Sync/Wide negotiation so I can get this taken care of for 5.1.20.

-- 
  Doug Ledford   <dledford@redhat.com>
   Opinions expressed are my own, but
      they should be everybody's.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:07:04 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA14271
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:07:04 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02866
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:07:31 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:54545 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S42152AbPHLCVY>;
	Thu, 12 Aug 1999 05:21:24 +0300
Received:  by vger.rutgers.edu via listexpand id <S155332AbPHLCPJ>;
	Wed, 11 Aug 1999 22:15:09 -0400
Received:  by vger.rutgers.edu id <S154025AbPHLCOX>;
	Wed, 11 Aug 1999 22:14:23 -0400
Received: from [206.152.126.99] ([206.152.126.99]:4545 "EHLO mattshouse.com")
	by vger.rutgers.edu with ESMTP id <S155305AbPHLCIy>;
	Wed, 11 Aug 1999 22:08:54 -0400
Received: from matthew.linuxnet (IDENT:root@matthew.linuxnet [192.168.1.5])
	by mattshouse.com (8.9.1/8.9.1) with SMTP id UAA26431
	for <linux-kernel@vger.rutgers.edu>; Wed, 11 Aug 1999 20:03:07 -0500
From: Matthew <matthew@mattshouse.com>
Reply-To: matthew@mattshouse.com
Organization: Mattshouse
To: linux-kernel@vger.rutgers.edu
Subject: cat /proc/meminfo nutyness, or is it my ignorance
Date:   Wed, 11 Aug 1999 21:01:47 -0500
X-Mailer: KMail [version 1.0.17]
Content-Type: 	text/plain; charset=US-ASCII
MIME-Version: 1.0
Message-Id: <99081121081800.06075@matthew.linuxnet>
Content-Transfer-Encoding: 7BIT
X-KMail-Mark: 
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig


This is just to ease my conscience, I hope.  I run a large production
Oracle database  on kernel 2.2.11 and get some strange meminfo numbers.  

total:    used:    free:  shared: buffers:  cached:
Mem:  264110080 262406144  1703936 2211295232 21000192 36835328
Swap: 814178304  6352896 807825408
MemTotal:    257920 kB
MemFree:       1664 kB
MemShared:  2159468 kB   <------------------- crazyness?
Buffers:      20508 kB
Cached:       35972 kB
SwapTotal:   795096 kB
SwapFree:    788892 kB

I have 256M memory and 800M swap.  This is a stock kernel.  Should memshared
really be > 2 Gig?  Perhaps I just don't know what memshared means.  Enlighten.

BTW, here's an ipcs:

------ Shared Memory Segments --------
key       shmid     owner     perms     bytes     nattch    status
0x00000000 0         oradba    640       49152     81
0x00000000 1         oradba    640       28672000  81
0x00000000 2         oradba    640       21504000  81
0x00000000 3         oradba    640       32260096  81
0x00000000 4         oradba    640       32251904  81
0xe6ed9ca0 5         oradba    640       18010112  81

------ Semaphore Arrays --------
key       semid     owner     perms     nsems     status
0x00000000 0         oradba    640       32
0x00000000 129       oradba    640       32
0x00000000 130       oradba    640       32
0x00000000 131       oradba    640       32
0x00000000 132       oradba    640       32
0x00000000 133       oradba    640       32
0x00000000 134       oradba    640       32
0x00000000 135       oradba    640       32
0x00000000 136       oradba    640       32
0x00000000 137       oradba    640       32
0x00000000 138       oradba    640       32
0x00000000 139       oradba    640       32
0x00000000 140       oradba    640       16 

--

To segfault is human, to blue screen is moronic...
~~~~~~~~~~~~
Matthew 
matthew@mattshouse.com
http://www.mattshouse.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:07:07 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA14314
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:07:07 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02872
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:07:35 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:54545 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S9727AbPHLCYR>;
	Thu, 12 Aug 1999 05:24:17 +0300
Received:  by vger.rutgers.edu via listexpand id <S155592AbPHLCPM>;
	Wed, 11 Aug 1999 22:15:12 -0400
Received:  by vger.rutgers.edu id <S154078AbPHLCOa>;
	Wed, 11 Aug 1999 22:14:30 -0400
Received: from [38.149.17.171] ([38.149.17.171]:1284 "HELO ltc.com")
	by vger.rutgers.edu with SMTP id <S155954AbPHLCNw>;
	Wed, 11 Aug 1999 22:13:52 -0400
Received: from PREFECT (PREFECT [38.149.17.184]) by ltc.com (NTMail 3.03.0017/1.afdd) with ESMTP id ea309872 for <linux-kernel@vger.rutgers.edu>; Wed, 11 Aug 1999 22:18:58 -0400
Message-ID: <01d001bee467$e4ffb400$b8119526@ltc.com>
From: "Bradley D. LaRonde" <brad@ltc.com>
To: "wu_yb" <wu_yb@263.net>, <linux-kernel@vger.rutgers.edu>
References: <37B2232B.14360484@263.net>
Subject: Re: initfunc
Date:   Wed, 11 Aug 1999 22:10:48 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

From: wu_yb <wu_yb@263.net>
> A newbie question.
> In kernel 2.2.x, many functions are declared as __initfunc(),
> such as __initfunc(void setup_arch(xxx)), does __initfunc()
> means that after this function called, the mem occupied can
> be freed ?
>
> Thanks !!!

Yup.

It puts those functions into the .text.init section.  The linker then puts
that section (and .data.init) between the nicely aligned symbols
__init_begin and __init_end.  Then free_initmem() frees up all of those
pages, which is called from init() before execve'ing /sbin/init.

Regards,
Brad


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:07:11 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA14351
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:07:10 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02881
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:07:38 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:44320 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S42688AbPHLCaZ>;
	Thu, 12 Aug 1999 05:30:25 +0300
Received:  by vger.rutgers.edu via listexpand id <S155279AbPHLCZE>;
	Wed, 11 Aug 1999 22:25:04 -0400
Received:  by vger.rutgers.edu id <S154296AbPHLCYs>;
	Wed, 11 Aug 1999 22:24:48 -0400
Received: from mb06.swip.net ([193.12.122.210]:48240 "EHLO mb06.swip.net")
	by vger.rutgers.edu with ESMTP id <S153854AbPHLCQZ>;
	Wed, 11 Aug 1999 22:16:25 -0400
Received: from swipnet.se (dialup85-3-3.swipnet.se [130.244.85.35]) 
          by mb06.swip.net (8.8.8/8.8.8) with ESMTP 
          id EAA13467 for <linux-kernel@vger.rutgers.edu>; 
          Thu, 12 Aug 1999 04:16:22 +0200 (MET DST)
Message-ID: <37B22F91.CF260ED@swipnet.se>
Date:   Thu, 12 Aug 1999 04:21:05 +0200
From: David Olofson <audiality@swipnet.se>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10-RTL_BETA10 i686)
X-Accept-Language: sv, en
MIME-Version: 1.0
To: linux-kernel@vger.rutgers.edu
Subject: Re: Gates of Hell
References: <Pine.LNX.4.10.9908112221500.983-100000@pc-homme.vuurwerk.nl>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

"Homme R. Bitter" wrote:
> This person is obviously applying for a collection of coredums in his/her
> email box....

Yep... At least posting a link to a site that is BROWSABLE with
something that runs on LINUX would be a lot better!

Not the way to go... :-(


//David

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:07:15 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA14398
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:07:14 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02891
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:07:41 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:40749 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S42194AbPHLCdM>;
	Thu, 12 Aug 1999 05:33:12 +0300
Received:  by vger.rutgers.edu via listexpand id <S155642AbPHLCZH>;
	Wed, 11 Aug 1999 22:25:07 -0400
Received:  by vger.rutgers.edu id <S154549AbPHLCYj>;
	Wed, 11 Aug 1999 22:24:39 -0400
Received: from mercury.Sun.COM ([192.9.25.1]:35240 "EHLO mercury.Sun.COM")
	by vger.rutgers.edu with ESMTP id <S154777AbPHLCV2>;
	Wed, 11 Aug 1999 22:21:28 -0400
Received: from eastmail2.East.Sun.COM ([129.148.1.241])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA01625;
	Wed, 11 Aug 1999 19:21:25 -0700 (PDT)
Received: from hpc-450-4.East.Sun.COM (hpc-450-4.East.Sun.COM [129.148.224.64])
	by eastmail2.East.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id WAA08625;
	Wed, 11 Aug 1999 22:21:22 -0400 (EDT)
Received: (from nils@localhost)
	by hpc-450-4.East.Sun.COM (8.8.8+Sun/8.8.8) id WAA21647;
	Wed, 11 Aug 1999 22:21:22 -0400 (EDT)
Message-ID: <19990811222122.00515@east.sun.com>
Date:   Wed, 11 Aug 1999 22:21:22 -0400
From: Nils Nieuwejaar - Sun High Performance Computing          <nils@hpc-450-4.East.Sun.COM>
To: Jonathan Masters <mastersj@periscope-systems.freeserve.co.uk>,
        "Homme R. Bitter" <homme@vuurwerk.nl>, linux-kernel@vger.rutgers.edu,
        linux-admin@vger.rutgers.edu
Subject: Re: Gates of Hell
References: <Pine.LNX.4.10.9908112221500.983-100000@pc-homme.vuurwerk.nl> <37B20CFA.73D27CEB@periscope-systems.freeserve.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.89.1
In-Reply-To: <37B20CFA.73D27CEB@periscope-systems.freeserve.co.uk>; from Jonathan Masters on Thu, Aug 12, 1999 at 12:53:30AM +0100
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

On Thu, Aug 12, 1999 at 12:53:30AM +0100, Jonathan Masters wrote:
> are doing is legal, but until then, is there an easy way to get ns to lie
> about os/browser version, or can some of us write some kind of proxy which
> lies about os, etc...?? Thanx.

This is _way_ off topic for linux-kernel, but... look at junkbuster (at
http://www.junkbusters.com).  

One of the many cool things it can do is send a different User-agent
string, which I'm guessing is where they get your OS information.

For whatever reason, junkbuster will identify you as a Mac user by
default: "Mozilla/3.01Gold (Macintosh; I; 68K)".  You can change that to
anything else you like: a different OS, pure gibberish, or nothing at all.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:07:17 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA14431
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:07:16 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02902
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:07:44 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:54329 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S9462AbPHLCje>;
	Thu, 12 Aug 1999 05:39:34 +0300
Received:  by vger.rutgers.edu via listexpand id <S155930AbPHLCfl>;
	Wed, 11 Aug 1999 22:35:41 -0400
Received:  by vger.rutgers.edu id <S153874AbPHLCeL>;
	Wed, 11 Aug 1999 22:34:11 -0400
Received: from ip-216-178.insightexpress.com ([206.165.216.178]:2390 "EHLO
        wahoo.localdomain") by vger.rutgers.edu with ESMTP
	id <S153854AbPHLCZy>; Wed, 11 Aug 1999 22:25:54 -0400
Received: from primenet.com (IDENT:bigbiff@localhost [127.0.0.1])
	by wahoo.localdomain (8.9.3/8.8.7) with ESMTP id WAA08058;
	Wed, 11 Aug 1999 22:23:11 -0400
Message-Id: <199908120223.WAA08058@wahoo.localdomain>
Date:   Wed, 11 Aug 1999 22:23:11 -0400 (EDT)
From: mcrites@primenet.com
Reply-To: mcrites@primenet.com
To: shirsch@adelphia.net
cc: linux-kernel@vger.rutgers.edu
MIME-Version: 1.0
Content-Type: TEXT/plain; CHARSET=US-ASCII
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

Thank you very much for fixing this problem! I was having a lot of
problems with this, and was hoping that I could use the new kernel.
Thanks again.
-- 
Thanks,
Matthew Crites
mcrites@primenet.com
http://www.infinet.com/~mcrites


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:07:21 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA14488
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:07:21 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02913
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:07:48 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:6468 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S9500AbPHLCnj>;
	Thu, 12 Aug 1999 05:43:39 +0300
Received:  by vger.rutgers.edu via listexpand id <S156083AbPHLCft>;
	Wed, 11 Aug 1999 22:35:49 -0400
Received:  by vger.rutgers.edu id <S154078AbPHLCeV>;
	Wed, 11 Aug 1999 22:34:21 -0400
Received: from borg.denalics.net ([209.112.170.15]:1162 "HELO convert rfc822-to-8bit
        borg.denalics.net") by vger.rutgers.edu with SMTP
	id <S155956AbPHLC1N>; Wed, 11 Aug 1999 22:27:13 -0400
Received: from borg.denalics.net (borg.denalics.net [209.112.170.15])
	by borg.denalics.net (Postfix) with ESMTP
	id 9056D48898; Wed, 11 Aug 1999 18:26:10 -0800 (AKDT)
Date:   Wed, 11 Aug 1999 18:26:10 -0800 (AKDT)
From: "Christopher E. Brown" <cbrown@denalics.net>
To: Bernhard Kaindl <bk@suse.de>
Cc: linux-kernel@vger.rutgers.edu, Alan Cox <alan@lxorguk.ukuu.org.uk>,
        becker@cesdis1.gsfc.nasa.gov
Subject: Re: 2.2.11 and tulip.c issues
In-Reply-To: <Pine.LNX.4.10.9908120155370.419-100000@hay.suse.de>
Message-ID: <Pine.LNX.4.10.9908111821330.237-100000@borg.denalics.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN
Content-Transfer-Encoding: 8BIT
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

On Thu, 12 Aug 1999, Bernhard Kaindl wrote:

> On Wed, 11 Aug 1999, Christopher E. Brown wrote:

> Here, NFS stops after a while with 0.89H 75% of my cards are affected,
> like yours.
> 
> As said, a test with 0.89H gave same results here: On 7 from 9
> Systems, a network install of a default Linux system was not possible.
> NFS halted here. 0.90 worked well on all these systems.
> 
> In case you dont have 0.90, it is in 2.0.37 and Ishould have diff for
> 2.2.11 at ftp://ftp.suse.com/pub/people/bk/kernel/for-2.2.11/tulip-0.90.diff
> within 24 hours.
> 
> Also, there is a 0.91g tulip.c, which is quite good hidden in the second
> part of a link on the tulip development page. 
> http://cesdis.gsfc.nasa.gov/linux/drivers/test/tulip.c


	There are 2 problems, 

The driver included in ALL kernels does not work with newer cards and
need to be updated. 

2.2.11 breaks ALL tulip drivers, both the included 89H version (that
is useless with a new card anyway) *AND* 91.  I can cope with
switching out 89 or 91 when I use a newer card, but none of the tulip
drivers are woring with 2.2.11.

	I have not yet tried the latest 91x yet, but flat 91 is known
to work fine with the cards, the breakage seems to come with 2.2.11

Thanks

---- First Law of System Requirements:
     "Anything is possible if you don't know what you're talking about..."


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:07:27 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA14533
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:07:24 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02933
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:07:51 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:16210 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S9230AbPHLCti>;
	Thu, 12 Aug 1999 05:49:38 +0300
Received:  by vger.rutgers.edu via listexpand id <S156111AbPHLCoW>;
	Wed, 11 Aug 1999 22:44:22 -0400
Received:  by vger.rutgers.edu id <S154078AbPHLCoI>;
	Wed, 11 Aug 1999 22:44:08 -0400
Received: from mail1.svr.pol.co.uk ([195.92.193.18]:2128 "EHLO
        mail1.svr.pol.co.uk") by vger.rutgers.edu with ESMTP
	id <S155929AbPHLCnt>; Wed, 11 Aug 1999 22:43:49 -0400
Received: from modem-105.gallium.dialup.pol.co.uk
	([62.136.15.105] helo=periscope.localdomain ident=root)
	by mail1.svr.pol.co.uk with esmtp (Exim 2.12 #2)
	id 11EkqH-0000mm-00; Thu, 12 Aug 1999 03:43:46 +0100
Received: from periscope-systems.freeserve.co.uk (IDENT:mastersj@periscope.localdomain [192.168.0.1])
	by periscope.localdomain (8.9.3/8.8.7) with ESMTP id DAA01569;
	Thu, 12 Aug 1999 03:43:30 +0100
Message-ID: <37B234D1.7835B30B@periscope-systems.freeserve.co.uk>
Date:   Thu, 12 Aug 1999 03:43:30 +0100
From: Jonathan Masters <mastersj@periscope-systems.freeserve.co.uk>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.11 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Benson <sysadmin@ocean.com.au>, linux-admin@vger.rutgers.edu,
        linux-kernel@vger.rutgers.edu
Subject: Re: Gates of Hell
References: <Pine.LNX.4.10.9908112221500.983-100000@pc-homme.vuurwerk.nl> <37B20CFA.73D27CEB@periscope-systems.freeserve.co.uk> <37B22382.82CFF11B@ocean.com.au>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

But will squid/ junkbuster actually do that?

Jonathan Benson wrote:

> You could go via a HTTP-anonymyzer thingie.  Ie proxy and have it report itself
> as being Win 95.
>
> Squid or Junkbuster come to mind.
>
> Jonathan Masters wrote:
>
> > The worst of it is - the site ***********filters*********** by OS type. This
> > means that you can't access it if you're running Linux. Actually, that brings
> > up a question: I have a barclays online banking account, but barclays also
> > filter by OS type (at least what they get from the browser) - they claim
> > Linux/UNIX is "less secure than windows " (3.1 , 95, 98 AND NT!!!!!!!!! -
> > they said this when I spoke to them) - I have made excessive threats to them
> > about legal action and have several people investigating whether what they
> > are doing is legal, but until then, is there an easy way to get ns to lie
> > about os/browser version, or can some of us write some kind of proxy which
> > lies about os, etc...?? Thanx.
>
> --
> Jonathan Benson
> Systems Administrator
> Ocean Internet
> http://www.ocean.com.au/

--
Jonathan C. Masters                     (jonathan@oxlug.org)
                                        PGP: www.brookes.ac.uk/~95227860/KEY

           "Upon this rock I will build my church,
            and the gates of hell shall not prevail against it".

                 -- Matthew 16, 17-18




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:07:31 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA14611
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:07:30 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02971
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:07:58 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:46433 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S10030AbPHLC4z>;
	Thu, 12 Aug 1999 05:56:55 +0300
Received:  by vger.rutgers.edu via listexpand id <S156394AbPHLCuK>;
	Wed, 11 Aug 1999 22:50:10 -0400
Received:  by vger.rutgers.edu id <S154025AbPHLCtu>;
	Wed, 11 Aug 1999 22:49:50 -0400
Received: from mail2.svr.pol.co.uk ([195.92.193.210]:4683 "EHLO
        mail2.svr.pol.co.uk") by vger.rutgers.edu with ESMTP
	id <S156394AbPHLCsx>; Wed, 11 Aug 1999 22:48:53 -0400
Received: from modem-105.gallium.dialup.pol.co.uk
	([62.136.15.105] helo=periscope.localdomain ident=root)
	by mail2.svr.pol.co.uk with esmtp (Exim 2.12 #2)
	id 11EkvB-00060r-00; Thu, 12 Aug 1999 03:48:50 +0100
Received: from periscope-systems.freeserve.co.uk (IDENT:mastersj@periscope.localdomain [192.168.0.1])
	by periscope.localdomain (8.9.3/8.8.7) with ESMTP id DAA01637;
	Thu, 12 Aug 1999 03:48:24 +0100
Message-ID: <37B235F8.4ED75FEA@periscope-systems.freeserve.co.uk>
Date:   Thu, 12 Aug 1999 03:48:24 +0100
From: Jonathan Masters <mastersj@periscope-systems.freeserve.co.uk>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.11 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Benson <sysadmin@ocean.com.au>, linux-kernel@vger.rutgers.edu,
        linux-admin@vger.rutgers.edu
Subject: Re: [Fwd: hdd & sound]
References: <37B1D4A9.971344A2@periscope-systems.freeserve.co.uk> <37B224A6.53D8D68D@ocean.com.au>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

On freshmeat.net get the SMART disc utils. Run them to test your hdd. I have a very
similar problem which occurs when I attempt to activate UDMA on my second hdd. I have
two FUJITSUs, one 6.4, one 10.8. The 6.4 uses UDMA 2 and works fine, but the 10.8 uses
UDMA 4 and doesn't can someone help me with this as my older 6.4 has a 12Mb/sec access
and my 10.8 has 5Mb/sec and it's brand new!!!!

Jonathan Benson wrote:

> I get problems similar to this but suspect it's my HD dying or my motherboards IDE
> controller as I get messages like this:
> Aug 12 11:17:03 orpheus kernel: hda: lost interrupt
> Aug 12 11:17:03 orpheus kernel: hda: read_intr: status=0x50 { DriveReady
> SeekComplete }
> Aug 12 11:29:08 orpheus kernel: hda: status timeout: status=0x90 { Busy }
> Aug 12 11:29:08 orpheus kernel: hda: drive not ready for command
> Aug 12 11:29:13 orpheus kernel: ide0: reset: success
> Aug 12 11:29:57 orpheus kernel: hda: lost interrupt
> Aug 12 11:29:57 orpheus kernel: hda: read_intr: status=0x50 { DriveReady
> SeekComplete }
> Aug 12 11:30:07 orpheus kernel: hda: lost interrupt
> Aug 12 11:30:07 orpheus kernel: hda: read_intr: status=0x50 { DriveReady
> SeekComplete }
>
> And the problem seems to be getting worse.  It also happens (as the above did)
> when I'm not playing any sounds apart from the Gnome ones perhaps.
>
> Any comments?  Is this similar to what your seeing?
>
> Jonathan Masters wrote:
>
> > --
> > Jonathan C. Masters                     (jonathan@oxlug.org)
> >                                         PGP: www.brookes.ac.uk/~95227860/KEY
> >
> >            "Upon this rock I will build my church,
> >             and the gates of hell shall not prevail against it".
> >
> >                  -- Matthew 16, 17-18
> >
> >   ------------------------------------------------------------------------
> >
> > Subject: Re: hdd & sound
> > Date: Wed, 11 Aug 1999 20:51:55 +0100
> > From: Jonathan Masters <mastersj@periscope-systems.freeserve.co.uk>
> > To: Mike Ricketts <rickettm@ox.compsoc.net>
> > References: <Pine.LNX.4.10.9908112011350.1973-100000@oakley.keble.ox.ac.uk>
> >
> > Has Mr Gates been at the kernel source? (well you did say "evil"). Seriously
> > though, it's scheduler related. Someone please fix this as writing a cd now makes
> > my 2.2.10 system *UNUSEABLE* since I must have sound to work. Music keeps me
> > happy. Besides, when this happens, the processor load is all of 4% or so - hardly
> > enough to cause problems - since it happens on PCI hardware too - it aint my ISA
> > soundcard (SB 64 AWE Gold) - interestingly, it haoppens when ripping cd's too -
> > but cdrecord causes less than cdparanoia (my hdds are on one controller, the
> > cd-writer/cdrom are on the other.). I've already posted my machine specs but more
> > is available in someone wants. Howz about Alan/Linus comments on this so we know
> > once and for all? Thanx.
> >
> > Mike wrote:
> >
> > > On Sat, 7 Aug 1999, Wakko Warner wrote:
> > >
> > > > I'm noticing this one one of my machines.  When writing to a hard drive, the
> > > > sound drags.  The machine I'm on has piix4 ide and an isa scsi card.  I'm
> > > > playing sounds from the drive on the scsi card (aha1510 I think is the scsi
> > > > card).  I tried writing to both an ide and scsi drive, both drag the sound.
> > > > Sound card is an SB16 pnp /w ide port (not disablable unfortunately).  I had
> > > > a similar problem on an isa ide card playing sounds off of the hard drive
> > > > (like 44k 16bit 2ch sound off the drive, sound card was an ess card).  My
> > > > home box that this is happneing on is 2.2.7.  The one with the isa ide is no
> > > > longer active, but it was running 2.0.36.
> > > >
> > > I see much the same thing under (extremely) heavy disk load, both on
> > > onboard piix4 ide, and on an onboard aic7??? scsi.
> > >
> > > Things it isn't:
> > >   hardware - too many people are seeing the same thing for that
> > >   driver specific - it happens on both ide and scsi, and with both sb and
> > >                     ess cards
> > >   anything blindingly obvious
> > >
> > > Currently I suspect something evil either in sound_core.c or sound_timer.c
> > > or (more likely) something scheduler related, but this is wild guessing.  Any
> > > ideas?
> > >
> > > --
> > > Mike <rickettm@ox.compsoc.net>
> > >
> > > Q:      What's yellow, and equivalent to the Axiom of Choice?
> > > A:      Zorn's Lemon.
> >
> > --
> > Jonathan C. Masters                     (jonathan@oxlug.org)
> >                                         PGP: www.brookes.ac.uk/~95227860/KEY
> >
> >            "Upon this rock I will build my church,
> >             and the gates of hell shall not prevail against it".
> >
> >                  -- Matthew 16, 17-18
>
> --
> Jonathan Benson
> Systems Administrator
> Ocean Internet
> http://www.ocean.com.au/

--
Jonathan C. Masters                     (jonathan@oxlug.org)
                                        PGP: www.brookes.ac.uk/~95227860/KEY

           "Upon this rock I will build my church,
            and the gates of hell shall not prevail against it".

                 -- Matthew 16, 17-18




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 08:07:31 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id IAA14600
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 08:07:30 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id GAA02951
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 06:07:55 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:16210 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S10153AbPHLCxG>;
	Thu, 12 Aug 1999 05:53:06 +0300
Received:  by vger.rutgers.edu via listexpand id <S156155AbPHLCt5>;
	Wed, 11 Aug 1999 22:49:57 -0400
Received:  by vger.rutgers.edu id <S153854AbPHLCtn>;
	Wed, 11 Aug 1999 22:49:43 -0400
Received: from dt062n89.san.rr.com ([204.210.38.137]:1689 "HELO spoke.nols.com")
	by vger.rutgers.edu with SMTP id <S154025AbPHLCpR>;
	Wed, 11 Aug 1999 22:45:17 -0400
Received: (qmail 13974 invoked from network); 12 Aug 1999 02:44:54 -0000
Received: from unknown (HELO forty) (qmailr@10.0.0.99)
  by dt062n89.san.rr.com with SMTP; 12 Aug 1999 02:44:54 -0000
Received: (qmail 849 invoked by uid 516); 12 Aug 1999 02:44:53 -0000
Date:   Wed, 11 Aug 1999 19:44:53 -0700
From: David Rees <dbr@spoke.nols.com>
To: linux-kernel@vger.rutgers.edu
Subject: Re: via-rhine nic crazyness on PIII Xeon SMP running 2.2.5 - 2.2.11
Message-ID: <19990811194453.B636@spoke.nols.com>
References: <99081118321500.05912@matthew.linuxnet>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.6us
In-Reply-To: <99081118321500.05912@matthew.linuxnet>; from Matthew on Wed, Aug 11, 1999 at 06:15:11PM -0500
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

On Wed, Aug 11, 1999 at 06:15:11PM -0500, Matthew wrote:
> 
> eth0 and eth1 behave properly, but eth2 (the via-rhine) spits out "Something
> Wicked has happened" into the syslog.  I turned on verbose mode and captured
> about 20k of data, including three instances of the "Wickedness".  I looked
> through docs and the source (via-rhine.c) and couldn't find any mention of
> failure due to multiple nics or SMP.

It seems to be related to SMP, I get the same messages with the via-rhine
card and my SMP system.  Works great in my SingleCPU machine, with it and
a PCI NE2K card.

-Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 19:04:21 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id TAA21170
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 19:04:16 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id RAA13044
	for <tony@tesla.rcub.bg.ac.yu>; Wed, 11 Aug 1999 17:48:19 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:29781 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S42428AbPHKRnQ>;
	Wed, 11 Aug 1999 20:43:16 +0300
Received:  by vger.rutgers.edu via listexpand id <S156788AbPHKQXB>;
	Wed, 11 Aug 1999 12:23:01 -0400
Received:  by vger.rutgers.edu id <S154371AbPHKPOF>;
	Wed, 11 Aug 1999 11:14:05 -0400
Received: from draal.apex.net.au ([203.37.38.10]:5481 "EHLO draal.apex.net.au")
	by vger.rutgers.edu with ESMTP id <S156111AbPHKOXR>;
	Wed, 11 Aug 1999 10:23:17 -0400
Received: from kleptog (kleptog@ppp5-112.apex.net.au [210.9.66.112])
	by draal.apex.net.au (8.9.3/8.9.3) with SMTP id AAA08639;
	Thu, 12 Aug 1999 00:22:35 +1000
Message-ID: <37B18716.128FF1AF@student.anu.edu.au>
Date:   Thu, 12 Aug 1999 00:22:14 +1000
From: Martijn van Oosterhout <s3100411@student.anu.edu.au>
X-Mailer: Mozilla 3.04 (X11; I; Linux 2.2.9 i586)
MIME-Version: 1.0
To: linux kernel <linux-kernel@vger.rutgers.edu>
CC: Bjorn Wesen <bjorn@sparta.lu.se>
Subject: Re: filehandle passing
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

>short question: does linux do filehandle passing like any of the examples
>in stevens "advanced unix programming" ? (he describes how it's done on
>sys v and bsd, methinks)
>
>/bjorn

yes it does..

Consider lots of software relies on it, it'd be hard not to. It
works with unix domain sockets.

Martijn van Oosterhout
Australia

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 19:04:24 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id TAA21177
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 19:04:22 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id SAA13520
	for <tony@tesla.rcub.bg.ac.yu>; Wed, 11 Aug 1999 18:04:33 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:29781 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S43974AbPHKRyJ>;
	Wed, 11 Aug 1999 20:54:09 +0300
Received:  by vger.rutgers.edu via listexpand id <S157118AbPHKQuj>;
	Wed, 11 Aug 1999 12:50:39 -0400
Received:  by vger.rutgers.edu id <S155294AbPHKPoo>;
	Wed, 11 Aug 1999 11:44:44 -0400
Received: from phobos.fachschaften.tu-muenchen.de ([129.187.176.43]:4016 "EHLO
        phobos.fachschaften.tu-muenchen.de") by vger.rutgers.edu with ESMTP
	id <S154425AbPHKPX2>; Wed, 11 Aug 1999 11:23:28 -0400
Received: from geier by phobos.fachschaften.tu-muenchen.de with local-smtp (Exim 2.05 #1 (Debian))
	id 11EHfl-0007E5-00; Tue, 10 Aug 1999 21:34:57 +0200
Date:   Tue, 10 Aug 1999 21:34:55 +0200 (CEST)
From: Simon Richter <geier@phobos.fachschaften.tu-muenchen.de>
Reply-To: Simon Richter <geier@phobos.fachschaften.tu-muenchen.de>
To: Matthew Wilcox <Matthew.Wilcox@genedata.com>
cc: linux-kernel@vger.rutgers.edu
Subject: Re: More file flags
In-Reply-To: <19990810193940.L25966@mencheca.ch.genedata.com>
Message-ID: <Pine.LNX.3.96.990810213320.26257B-100000@phobos.fachschaften.tu-muenchen.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

On Tue, 10 Aug 1999, Matthew Wilcox wrote:

> You'd have to disallow them access to the raw block device too -- libe2fs
> makes it quite easy to run through the filesystem and get the data.

AFAIK you should not be able to access block devices in securelevel 2
directly (says the definition). If this is still possible, I think this is
a bug.

   Simon

PGP public key available from ftp://phobos.fs.tum.de/pub/pgp/geier.asc
 Fingerprint: 10 62 F6 F5 C0 5D 9E D8  47 05 1B 8A 22 E5 4E C1



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 19:04:25 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id TAA21181
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 19:04:24 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id SAA13506
	for <tony@tesla.rcub.bg.ac.yu>; Wed, 11 Aug 1999 18:03:49 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:29781 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S42439AbPHKRxf>;
	Wed, 11 Aug 1999 20:53:35 +0300
Received:  by vger.rutgers.edu via listexpand id <S155906AbPHKQ2D>;
	Wed, 11 Aug 1999 12:28:03 -0400
Received:  by vger.rutgers.edu id <S154167AbPHKQIb>;
	Wed, 11 Aug 1999 12:08:31 -0400
Received: from dial249.pm3abing3.abingdonpm.naxs.com ([216.98.75.249]:1120
        "EHLO ani.animx.eu.org") by vger.rutgers.edu with ESMTP
	id <S154228AbPHKOsv>; Wed, 11 Aug 1999 10:48:51 -0400
Received: from wakko by ani.animx.eu.org with local
	(Exim 2.05 #1 (Debian) Bug?  What bug /\oo/\)
	id 11EE5D-0000a1-00; Tue, 10 Aug 1999 11:44:59 -0400
Date:   Tue, 10 Aug 1999 11:44:59 -0400
From: Wakko Warner <wakko@animx.eu.org>
To: bella <bella@ltavatv.poltava.ua>
Cc: linux-kernel@vger.rutgers.edu
Subject: Re: Patch failed 2.2.10 -> 2.2.11
Message-ID: <19990810114459.A2223@animx.eu.org>
References: <19990810072830.D971@animx.eu.org> <Pine.LNX.4.05.9908101548390.15836-100000@ltavatv.poltava.ua>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.3i
In-Reply-To: <Pine.LNX.4.05.9908101548390.15836-100000@ltavatv.poltava.ua>; from bella on Tue, Aug 10, 1999 at 03:49:25PM +0300
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

> > patching file `drivers/scsi/aha152x.c'
> > Hunk #8 FAILED at 425.
> > Hunk #11 FAILED at 533.
> > 2 out of 25 hunks FAILED -- saving rejects to drivers/scsi/aha152x.c.rej
> 
> 	Upgrade your patch program to patch-2.5

You just assumed that my patch was old eh?  It wasn't, I found out that this
one file had been modified before the patch was applied...  Sorry guys

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Thu Aug 12 19:04:29 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id TAA21191
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 12 Aug 1999 19:04:27 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id TAA15854
	for <tony@tesla.rcub.bg.ac.yu>; Wed, 11 Aug 1999 19:21:32 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:25674 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S42056AbPHKTVQ>;
	Wed, 11 Aug 1999 22:21:16 +0300
Received:  by vger.rutgers.edu via listexpand id <S160136AbPHKSQU>;
	Wed, 11 Aug 1999 14:16:20 -0400
Received:  by vger.rutgers.edu id <S156050AbPHKQvx>;
	Wed, 11 Aug 1999 12:51:53 -0400
Received: from [194.65.187.146] ([194.65.187.146]:1125 "EHLO
        localhost.localdomain") by vger.rutgers.edu with ESMTP
	id <S156084AbPHKPwd>; Wed, 11 Aug 1999 11:52:33 -0400
Received: from grad.physics.sunysb.edu (IDENT:rsousa@localhost.localdomain [127.0.0.1])
	by localhost.localdomain (8.9.3/8.8.7) with ESMTP id QAA09571;
	Wed, 11 Aug 1999 16:53:20 +0100
Message-ID: <37B19C70.2512E272@grad.physics.sunysb.edu>
Date:   Wed, 11 Aug 1999 16:53:20 +0100
From: Rui Sousa <rsousa@grad.physics.sunysb.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.11 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-kernel@vger.rutgers.edu
CC: linux-sound@vger.rutgers.edu, alan@lxorguk.ukuu.org.uk
Subject: [PATCH] MAD16 module
Content-Type: multipart/mixed;
 boundary="------------A689E0AC59CC3F9CE4810AF2"
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

This is a multi-part message in MIME format.
--------------A689E0AC59CC3F9CE4810AF2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Patch to correct the problem I mentioned before.
Now the cdrom controller gets properly initialized and
for the people not using the cdrom controller (like me)
things don't get messed up.



-- 
Rui Sousa
--------------A689E0AC59CC3F9CE4810AF2
Content-Type: text/plain; charset=us-ascii;
 name="mad16.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="mad16.patch"

diff -ur linux-2.2/Documentation/sound/MAD16 linux-2.2.new/Documentation/sound/MAD16
--- linux-2.2/Documentation/sound/MAD16	Thu Apr 29 19:53:41 1999
+++ linux-2.2.new/Documentation/sound/MAD16	Wed Aug 11 16:23:09 1999
@@ -32,3 +32,22 @@
 options mad16 io=0x530 irq=7 dma=0 dma16=1 mpu_io=816 mpu_irq=5 && /usr/local/bin/aumix -w 15 -p 20 -m 0 -1 0 -2 0 -3 0 -i 0
 
 The addition of the "mpu_io=816 mpu_irq=5" to the mad16 options line is
+
+------------------------------------------------------------------------
+The mad16 module in addition supports the following options:
+
+option:			meaning:			default:
+joystick=0,1 		disabled, enabled 		disabled
+cdtype=0x00,0x02,0x04,	disabled, Sony CDU31A,		disabled
+       0x06,0x08,0x0a   Mitsumi, Panasonic,
+			Secondary IDE, Primary IDE 
+cdport=0x340,0x320,					0x340
+       0x330,0x360
+cdirq=0,3,5,7,9,10,11 	disabled, IRQ3, ... 		disabled
+cddma=0,5,6,7 		disabled, DMA5, ... 		DMA5 for Mitsumi or IDE
+cddma=0,1,2,3 		disabled, DMA1, ... 		DMA3 for Sony or Panasonic
+opl4=0,1 		OPL3, OPL4 			OPL3	
+
+for more details see linux/drivers/sound/mad16.c
+
+Rui Sousa
diff -ur linux-2.2/drivers/sound/mad16.c linux-2.2.new/drivers/sound/mad16.c
--- linux-2.2/drivers/sound/mad16.c	Tue Aug 10 14:42:26 1999
+++ linux-2.2.new/drivers/sound/mad16.c	Wed Aug 11 16:04:55 1999
@@ -889,7 +889,7 @@
 int             cdtype = 0;
 int             cdirq = 0;
 int             cdport = 0x340;
-int             cddma = 3;
+int             cddma = -1;
 int             opl4 = 0;
 int             joystick = 0;
 
@@ -949,23 +949,28 @@
 			break;
 		case 0x02:
 			printk("Sony CDU31A");
-			dmatype = 2;
+			dmatype = 1;
+			if(cddma == -1) cddma = 3;
 			break;
 		case 0x04:
 			printk("Mitsumi");
-			dmatype = 1;
+			dmatype = 0;
+			if(cddma == -1) cddma = 5;
 			break;
 		case 0x06:
 			printk("Panasonic Lasermate");
-			dmatype = 2;
+			dmatype = 1;
+			if(cddma == -1) cddma = 3;
 			break;
 		case 0x08:
 			printk("Secondary IDE");
-			dmatype = 1;
+			dmatype = 0;
+			if(cddma == -1) cddma = 5;
 			break;
 		case 0x0A:
 			printk("Primary IDE");
-			dmatype = 1;
+			dmatype = 0;
+			if(cddma == -1) cddma = 5;
 			break;
 		default:
 			printk("\n");
@@ -973,8 +978,16 @@
 			return -EINVAL;
 	}
 
-	if (dmatype)
-	{
+ 	/*
+         *    Build the config words
+         */
+
+        mad16_conf = (joystick ^ 1) | cdtype;
+	mad16_cdsel = 0;
+        if (opl4)
+                mad16_cdsel |= 0x20;
+
+	if(cdtype){
 		if (cddma > 7 || cddma < 0 || dma_map[dmatype][cddma] == -1)
 		{
 			printk("\n");
@@ -985,58 +998,51 @@
 			printk(", DMA %d", cddma);
 		else
 			printk(", no DMA");
-	}
-	if (cdtype && !cdirq)
-		printk(", no IRQ");
-	else if (cdirq < 0 || cdirq > 15 || irq_map[cdirq] == -1)
-	{
-		  printk(", invalid IRQ (disabling)");
-		  cdirq = 0;
-	}
-	else printk(", IRQ %d", cdirq);
-
-	printk(".\n");
-	printk(KERN_INFO "Joystick port ");
-	if (joystick == 1)
-		printk("enabled.\n");
-	else
-	{
-		joystick = 0;
-		printk("disabled.\n");
-	}
 
-	/*
-	 *    Build the config words
-	 */
+		if (!cdirq)
+			printk(", no IRQ");
+		else if (cdirq < 0 || cdirq > 15 || irq_map[cdirq] == -1)
+		{
+		  	printk(", invalid IRQ (disabling)");
+		  	cdirq = 0;
+		}
+		else printk(", IRQ %d", cdirq);
 
-	mad16_conf = (joystick ^ 1) | cdtype;
-	mad16_cdsel = 0;
-	if (opl4)
-		mad16_cdsel |= 0x20;
-	mad16_cdsel |= dma_map[dmatype][cddma];
+		mad16_cdsel |= dma_map[dmatype][cddma];
 
-	if (cdtype < 0x08)
-	{
-		switch (cdport)
+		if (cdtype < 0x08)
 		{
-			case 0x340:
-				mad16_cdsel |= 0x00;
-				break;
-			case 0x330:
-				mad16_cdsel |= 0x40;
-				break;
-			case 0x360:
-				mad16_cdsel |= 0x80;
-				break;
-			case 0x320:
-				mad16_cdsel |= 0xC0;
-				break;
-			default:
-				printk(KERN_ERR "Unknown CDROM I/O base %d\n", cdport);
-				return -EINVAL;
+			switch (cdport)
+			{
+				case 0x340:
+					mad16_cdsel |= 0x00;
+					break;
+				case 0x330:
+					mad16_cdsel |= 0x40;
+					break;
+				case 0x360:
+					mad16_cdsel |= 0x80;
+					break;
+				case 0x320:
+					mad16_cdsel |= 0xC0;
+					break;
+				default:
+					printk(KERN_ERR "Unknown CDROM I/O base %d\n", cdport);
+					return -EINVAL;
+			}
 		}
+		mad16_cdsel |= irq_map[cdirq];
 	}
-	mad16_cdsel |= irq_map[cdirq];
+
+	printk(".\n");
+        printk(KERN_INFO "Joystick port ");
+        if (joystick == 1)
+                printk("enabled.\n");
+        else
+        {
+                joystick = 0;
+                printk("disabled.\n");
+        }
 
 	config.io_base = io;
 	config.irq = irq;
Only in linux-2.2.new: log

--------------A689E0AC59CC3F9CE4810AF2--


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Tue Aug 31 18:51:24 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id SAA24115
	for <tony@tesla.rcub.bg.ac.yu>; Tue, 31 Aug 1999 18:50:54 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id QAA02217
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 5 Aug 1999 16:45:49 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:19564 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S42020AbPHEQbv>;
	Thu, 5 Aug 1999 19:31:51 +0300
Received:  by vger.rutgers.edu via listexpand id <S156390AbPHEQaZ>;
	Thu, 5 Aug 1999 12:30:25 -0400
Received:  by vger.rutgers.edu id <S155073AbPHEQV1>;
	Thu, 5 Aug 1999 12:21:27 -0400
Received: from usr3-ip050-grr.wmis.net ([209.176.193.100]:1718 "HELO
        usr3-ip050-grr.wmis.net") by vger.rutgers.edu with SMTP
	id <S155586AbPHEQRX>; Thu, 5 Aug 1999 12:17:23 -0400
Received: (qmail 2129 invoked by uid 501); 5 Aug 1999 16:17:18 -0000
Date:   Thu, 5 Aug 1999 12:17:18 -0400
From: Aaron Tiensivu <mojomofo@ctechnix.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>,
        Linux Kernel Digest <linux-kernel@vger.rutgers.edu>
Subject: Re: patch-2.2.10-ac12
Message-ID: <19990805121718.C2102@ctechnix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/0.96.3i
In-Reply-To: <no.id>; from Alan Cox <alan@lxorguk.ukuu.org.uk> on Thu, Aug 05, 1999 at 12:20:08PM +0100
X-OS:   Linux 2.2.10-ac12 AXP 
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

> The -ac patch is only aimed at x86. Various folks feed me alpha patches for
> it as well as pre11. For non x86 architectures pre11 is the only one that
> is (hopefully) working

-ac12 works fine under Alpha..

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Tue Aug 31 18:51:27 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id SAA24146
	for <tony@tesla.rcub.bg.ac.yu>; Tue, 31 Aug 1999 18:51:24 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id PAA02167
	for <tony@tesla.rcub.bg.ac.yu>; Sat, 7 Aug 1999 15:35:44 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:29552 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S46620AbPHGPeV>;
	Sat, 7 Aug 1999 18:34:21 +0300
Received:  by vger.rutgers.edu via listexpand id <S157108AbPHGPbO>;
	Sat, 7 Aug 1999 11:31:14 -0400
Received:  by vger.rutgers.edu id <S156238AbPHGPaw>;
	Sat, 7 Aug 1999 11:30:52 -0400
Received: from lightning.swansea.uk.linux.org ([194.168.151.1]:11625 "EHLO
        the-village.bc.nu") by vger.rutgers.edu with ESMTP
	id <S155111AbPHGPaf>; Sat, 7 Aug 1999 11:30:35 -0400
Received: from alan by the-village.bc.nu with local (Exim 2.12 #1)
	id 11D8Nc-00001F-00; Sat, 7 Aug 1999 16:27:29 +0100
Subject: Re: 2.2.11pre5 compile error in hfmodem
To: aba@casema.net (Joop Stakenborg)
Date:   Sat, 7 Aug 1999 16:27:25 +0100 (BST)
Cc: linux-kernel@vger.rutgers.edu
In-Reply-To: <19990807171613.A10789@1dyn190.utr.casema.net> from "Joop Stakenborg" at Aug 7, 99 05:16:13 pm
Content-Type: text
Message-Id: <E11D8Nc-00001F-00@the-village.bc.nu>
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

> refclock.c:136: fixed or forbidden register 0 (ax) was spilled for class AREG.
> refclock.c:137: Invalid `asm' statement:
> refclock.c:137: fixed or forbidden register 0 (ax) was spilled for class AREG.
> make[4]: *** [refclock.o] Error 1
> 
> $ gcc -v
> Reading specs from /usr/lib/gcc-lib/i386-linux/2.95/specs
> gcc version 2.95 19990728 (release)

Use an older compiler I guess. It does build with egcs-1.1.2

Alan


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Tue Aug 31 18:51:30 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id SAA24159
	for <tony@tesla.rcub.bg.ac.yu>; Tue, 31 Aug 1999 18:51:28 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id PAA02129
	for <tony@tesla.rcub.bg.ac.yu>; Sat, 7 Aug 1999 15:35:31 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:45663 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S44281AbPHGOlT>;
	Sat, 7 Aug 1999 17:41:19 +0300
Received:  by vger.rutgers.edu via listexpand id <S157082AbPHGOiH>;
	Sat, 7 Aug 1999 10:38:07 -0400
Received:  by vger.rutgers.edu id <S155432AbPHGOhS>;
	Sat, 7 Aug 1999 10:37:18 -0400
Received: from minus.inr.ac.ru ([193.233.7.97]:1045 "HELO ms2.inr.ac.ru")
	by vger.rutgers.edu with SMTP id <S155076AbPHGOhI>;
	Sat, 7 Aug 1999 10:37:08 -0400
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id SAA09688; Sat, 7 Aug 1999 18:36:50 +0400
From: kuznet@ms2.inr.ac.ru
Message-Id: <199908071436.SAA09688@ms2.inr.ac.ru>
Subject: Re: 2.2: data loss after socket close
To: andrea@suse.DE (Andrea Arcangeli)
Date:   Sat, 7 Aug 1999 18:36:50 +0400 (MSK DST)
Cc: linux-kernel@vger.rutgers.edu
In-Reply-To: <Pine.LNX.4.10.9908071540100.1543-100000@laser.random> from "Andrea Arcangeli" at Aug 7, 99 06:14:02 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

Hello!

> >I tried to get around this problem with SOL_LINGER (which is 
> >actually used in NT only). It did not change anything.
> 
> I think this patch I found some time ago into the ac patches should fix
> your problem.

Lingering does not solve any problems.

It is only goal is to force blocking until protocol
close to prevent resource consumption by parentless sockets.
It is never (or very rarely) good idea, because we get
whole process hanging instead of small socketlet 8)

Alexey

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Tue Aug 31 18:51:37 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id SAA24169
	for <tony@tesla.rcub.bg.ac.yu>; Tue, 31 Aug 1999 18:51:31 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id QAA02469
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 5 Aug 1999 16:51:12 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:14094 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S42864AbPHEPwM>;
	Thu, 5 Aug 1999 18:52:12 +0300
Received:  by vger.rutgers.edu via listexpand id <S156303AbPHEPpj>;
	Thu, 5 Aug 1999 11:45:39 -0400
Received:  by vger.rutgers.edu id <S155242AbPHEPpV>;
	Thu, 5 Aug 1999 11:45:21 -0400
Received: from ORION.SAS.UPENN.EDU ([165.123.26.31]:40758 "EHLO
        orion.sas.upenn.edu") by vger.rutgers.edu with ESMTP
	id <S156282AbPHEPnn>; Thu, 5 Aug 1999 11:43:43 -0400
Received: from mail1.sas.upenn.edu (vdergach@MAIL1.SAS.UPENN.EDU [165.123.26.32])
	by orion.sas.upenn.edu (8.9.3/8.9.3/SAS.05) with ESMTP id LAA14885;
	Thu, 5 Aug 1999 11:43:40 -0400 (EDT)
Date:   Thu, 5 Aug 1999 11:43:39 -0400 (EDT)
From: Vladimir Dergachev <vdergach@sas.upenn.edu>
To: Andi Kleen <ak@muc.de>
cc: Linux Kernel list <linux-kernel@vger.rutgers.edu>
Subject: Re: More linker magic.. - offtopic
In-Reply-To: <19990803123335.A2586@fred.muc.de>
Message-ID: <Pine.GSO.4.10.9908051136500.15111-100000@mail1.sas.upenn.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig



On Tue, 3 Aug 1999, Andi Kleen wrote:

> 
> Can't the Mathematicans express all that in a single number ? @)
> 

We can, but computers don't work with numbers. 

I bet you won't get too excited about a scheme to assign a prime number to
each module and make the priority the product of prime numbers assigned to
required modules.

If you want we can continue this discussion off-list.

                     Vladimir Dergachev


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Tue Aug 31 18:51:41 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id SAA24179
	for <tony@tesla.rcub.bg.ac.yu>; Tue, 31 Aug 1999 18:51:37 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id QAA02234
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 5 Aug 1999 16:45:54 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:12915 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S42480AbPHEQfH>;
	Thu, 5 Aug 1999 19:35:07 +0300
Received:  by vger.rutgers.edu via listexpand id <S156380AbPHEQYB>;
	Thu, 5 Aug 1999 12:24:01 -0400
Received:  by vger.rutgers.edu id <S155127AbPHEQVP>;
	Thu, 5 Aug 1999 12:21:15 -0400
Received: from usr3-ip050-grr.wmis.net ([209.176.193.100]:1715 "HELO
        usr3-ip050-grr.wmis.net") by vger.rutgers.edu with SMTP
	id <S155067AbPHEQPd>; Thu, 5 Aug 1999 12:15:33 -0400
Received: (qmail 2117 invoked by uid 501); 5 Aug 1999 16:15:23 -0000
Date:   Thu, 5 Aug 1999 12:15:23 -0400
From: Aaron Tiensivu <mojomofo@ctechnix.com>
To: "Dr. Michael Weller" <eowmob@exp-math.uni-essen.de>,
        Linux Kernel Digest <linux-kernel@vger.rutgers.edu>
Subject: Re: Is hdparm safe to run under some disk load?
Message-ID: <19990805121522.B2102@ctechnix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/0.96.3i
In-Reply-To: <no.id>; from "Dr. Michael Weller" <eowmob@exp-math.uni-essen.de> on Thu, Aug 05, 1999 at 12:25:05PM +0200
X-OS:   Linux 2.2.10-ac12 AXP 
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

> So: 1) Can/should 'hdparm -c' be run while there is disk activity?

You should be ok.
Off the top of my head, here are my parameters:

/sbin/hdparm -A1 -c1 -d1 -m32 -u1 -W1 -Z /dev/hda

This is on an older Seagate drive and it makes a world of difference.
Make sure you have the appropriate chipset support compiled in.

>     2) How good are the guesses of 'hdparm -c'? Or, how likely is it
>        to misdetect some feature which is then enabled and crashes the
>        machine.

Real good in my experiences..
The one that bites you in the ass the most is '-u1', but I only saw that
on an anchient '386.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Tue Aug 31 18:51:43 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id SAA24187
	for <tony@tesla.rcub.bg.ac.yu>; Tue, 31 Aug 1999 18:51:41 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id PAA02152
	for <tony@tesla.rcub.bg.ac.yu>; Sat, 7 Aug 1999 15:35:40 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:6229 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S46502AbPHGPYO>;
	Sat, 7 Aug 1999 18:24:14 +0300
Received:  by vger.rutgers.edu via listexpand id <S157098AbPHGPVJ>;
	Sat, 7 Aug 1999 11:21:09 -0400
Received:  by vger.rutgers.edu id <S155430AbPHGPUq>;
	Sat, 7 Aug 1999 11:20:46 -0400
Received: from fenrus.demon.nl ([212.238.78.16]:39452 "EHLO fenrus.demon.nl")
	by vger.rutgers.edu with ESMTP id <S155262AbPHGPUg>;
	Sat, 7 Aug 1999 11:20:36 -0400
Received: from amadeus.home.nl [10.1.2.4] (arjan)
	by fenrus.demon.nl with esmtp (Exim 2.05 #1 (Debian))
	id 11D8Gv-0001BI-00; Sat, 7 Aug 1999 17:20:33 +0200
Date:   Sat, 7 Aug 1999 17:20:32 +0200 (CEST)
From: Arjan van de Ven <arjan@fenrus.demon.nl>
To: linux-kernel@vger.rutgers.edu
Subject: Re: 2.2: data loss after socket close
Message-ID: <Pine.LNX.4.05.9908071719510.4533-100000@fenrus.demon.nl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

In-Reply-To: <37AC2B2B.6861AA68@actis.de>

In article <37AC2B2B.6861AA68@actis.de> you wrote:
> Hello,

> after porting an application to Linux i have found a bug
> in 2.2's socket close() code for TCP connections (LINUX 2.0 is OK):

> The sender writes some bytes and closes the socket.
> The receiver waits in select() until there is something
> to read, calls recv() and gets ECONNRESET ("Connection reset by peer")
> instead of the last bytes written by the sender.

I expirienced something similar, and the cause (in my case) was that at the
time of the close(), some data was in the _RECEIVE_ queue. DaveM explained
me that closing a socket in this situation is an error and the socket is
closed as such (ie no flush).

In other words: you have to make _sure_ there is no incomming data pending.

Greetings,  
   Arjan van de Ven


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Tue Aug 31 18:52:00 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id SAA24199
	for <tony@tesla.rcub.bg.ac.yu>; Tue, 31 Aug 1999 18:51:46 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id QAA02465
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 5 Aug 1999 16:51:09 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:25200 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S42132AbPHEPnu>;
	Thu, 5 Aug 1999 18:43:50 +0300
Received:  by vger.rutgers.edu via listexpand id <S156279AbPHEPkF>;
	Thu, 5 Aug 1999 11:40:05 -0400
Received:  by vger.rutgers.edu id <S156375AbPHEPj2>;
	Thu, 5 Aug 1999 11:39:28 -0400
Received: from neon-best.transmeta.com ([206.184.214.10]:4180 "EHLO
        neon.transmeta.com") by vger.rutgers.edu with ESMTP
	id <S155221AbPHEPga>; Thu, 5 Aug 1999 11:36:30 -0400
Received: from deepthought.transmeta.com (mailhost.transmeta.com [10.1.1.15])
	by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id IAA13971;
	Thu, 5 Aug 1999 08:36:14 -0700
Received: from penguin.transmeta.com (root@penguin.transmeta.com [10.1.2.202])
	by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id IAA21815;
	Thu, 5 Aug 1999 08:36:14 -0700 (PDT)
Received: from localhost (torvalds@localhost) by penguin.transmeta.com (8.9.3/8.7.3) with ESMTP id IAA01610; Thu, 5 Aug 1999 08:37:04 -0700
X-Authentication-Warning: penguin.transmeta.com: torvalds owned process doing -bs
Date:   Thu, 5 Aug 1999 08:37:04 -0700 (PDT)
From: Linus Torvalds <torvalds@transmeta.com>
To: Chris Wedgwood <cw@ix.net.nz>
cc: linux-kernel@vger.rutgers.edu
Subject: Re: More linker magic..
In-Reply-To: <19990805213123.A10822@caffeine.ix.net.nz>
Message-ID: <Pine.LNX.4.10.9908050835580.1592-100000@penguin.transmeta.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig



On Thu, 5 Aug 1999, Chris Wedgwood wrote:
> 
> OK, I've built gcc-2.95 and it now works. I don't see anything
> anywhere that says gcc-2.7.2.3 should no longer work, but for me it
> apparently doesn't.

2.7.3 is more picky about exactly where you put your attributes, and I
have it fixed now (so yes, 2.7.3 will be supported still, it's just that I
hadn't been too careful..)

		Linus


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Tue Aug 31 18:57:16 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id SAA24441
	for <tony@tesla.rcub.bg.ac.yu>; Tue, 31 Aug 1999 18:57:15 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id PAA02160
	for <tony@tesla.rcub.bg.ac.yu>; Sat, 7 Aug 1999 15:35:42 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:19044 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S42789AbPHGP2y>;
	Sat, 7 Aug 1999 18:28:54 +0300
Received:  by vger.rutgers.edu via listexpand id <S157114AbPHGPZw>;
	Sat, 7 Aug 1999 11:25:52 -0400
Received:  by vger.rutgers.edu id <S156212AbPHGPYl>;
	Sat, 7 Aug 1999 11:24:41 -0400
Received: from smtpc.casema.net ([195.96.96.200]:62716 "HELO smtpc.casema.net")
	by vger.rutgers.edu with SMTP id <S157122AbPHGPYI>;
	Sat, 7 Aug 1999 11:24:08 -0400
Received: (qmail 22780 invoked by uid 0); 7 Aug 1999 15:24:02 -0000
Received: from 1dyn190.utr.casema.net (mail@195.96.106.190)
  by smtpc.casema.net with SMTP; 7 Aug 1999 15:24:02 -0000
Received: from aba by 1dyn190.utr.casema.net with local (Exim 3.03 #1 (Debian))
	id 11D8Cj-0002oI-00; Sat, 07 Aug 1999 17:16:13 +0200
Date:   Sat, 7 Aug 1999 17:16:13 +0200
From: Joop Stakenborg <aba@casema.net>
To: linux-kernel@vger.rutgers.edu
Subject: 2.2.11pre5 compile error in hfmodem
Message-ID: <19990807171613.A10789@1dyn190.utr.casema.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.6i
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

make[4]: Entering directory `/usr/src/linux/drivers/char/hfmodem'
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 
-fomit-frame-pointer -fno-strict-aliasing -pipe -fno-strength-reduce -m486 
-malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=586 -DMODULE 
-DMODVERSIONS -include /usr/src/linux/include/linux/modversions.h   -c -o 
refclock.o refclock.c
refclock.c: In function `hfmodem_refclock_current':
refclock.c:136: Invalid `asm' statement:
refclock.c:136: fixed or forbidden register 0 (ax) was spilled for class AREG.
refclock.c:137: Invalid `asm' statement:
refclock.c:137: fixed or forbidden register 0 (ax) was spilled for class AREG.
make[4]: *** [refclock.o] Error 1

$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-linux/2.95/specs
gcc version 2.95 19990728 (release)

$ ls -al /lib/libc.so.6
lrwxrwxrwx   1 root     root           13 Aug  7 11:50 /lib/libc.so.6 -> 
libc-2.1.2.so


Thanks,
Joop
-- 

 Joop Stakenborg PA4TU, ex-PA3ABA 
      <pa3aba@debian.org>
 Linux Amateur Radio Software Database
    http://radio.linux.org.au


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Tue Aug 31 18:57:28 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id SAA24445
	for <tony@tesla.rcub.bg.ac.yu>; Tue, 31 Aug 1999 18:57:16 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id QAA02552
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 5 Aug 1999 16:54:37 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:21040 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S42270AbPHEQy1>;
	Thu, 5 Aug 1999 19:54:27 +0300
Received:  by vger.rutgers.edu via listexpand id <S156033AbPHEQoC>;
	Thu, 5 Aug 1999 12:44:02 -0400
Received:  by vger.rutgers.edu id <S154777AbPHEQnm>;
	Thu, 5 Aug 1999 12:43:42 -0400
Received: from ns.tasking.nl ([195.193.207.2]:1533 "EHLO ns.tasking.nl")
	by vger.rutgers.edu with ESMTP id <S155430AbPHEQiA>;
	Thu, 5 Aug 1999 12:38:00 -0400
Received: (from root@localhost) by ns.tasking.nl (8.9.1a/8.6.12) id SAA03824; Thu, 5 Aug 1999 18:37:57 +0200 (MET DST)
Received: by ns.tasking.nl via smap (V1.3)
	id sma003602; Thu, 5 Aug 99 18:36:30 +0200
Received: from espoo.tasking.nl by empoli.tasking.nl; (5.65v3.2/1.1.8.2/23Dec97-1135AM)
	id AA17565; Thu, 5 Aug 1999 18:35:44 +0200
Received: (from fvm@localhost) by espoo.tasking.nl (8.8.7/8.6.9) id SAA06439; Thu, 5 Aug 1999 18:35:44 +0200
Message-Id: <19990805183544.G5564@tasking.nl>
Date:   Thu, 5 Aug 1999 18:35:44 +0200
From: Frank van Maarseveen <fvm@tasking.nl>
To: trond.myklebust@fys.uio.no
Cc: linux-kernel@vger.rutgers.edu
Subject: Re: 2.2.10-ac<x> / 2.2.11-pre<x> NFS client problem & bugfix
Reply-To: frank_van_maarseveen@tasking.com
References: <19990805140508.C5564@tasking.nl> <14249.33909.217912.967239@susy.uio.no> <19990805151613.E5564@tasking.nl> <14249.36693.982457.519720@susy.uio.no> <19990805181725.F5564@tasking.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.93.2i (Linux)
In-Reply-To: <19990805181725.F5564@tasking.nl>; from Frank van Maarseveen on Thu, Aug 05, 1999 at 06:17:25PM +0200
Organization: TASKING, Inc.
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

On Thu, Aug 05, 1999 at 06:17:25PM +0200, Frank van Maarseveen wrote:
> Regarding the caching of attributes for regular files I noticed the
> following. On the server the command "ls >notfound" is repeatedly
> executed (<1 sec loop). On the client "repstat notfound" is executed
> (C source attached) and the mtime it reports changes with the following
> interval (just tested, same mount options):
> 
> 	client version
> 	2.2.10-ac11	1 sec
> 	2.2.11-pre4	1 sec
PS: This appears to be undeterministic behavior because now it is suddenly
a much longer time for both these kernels.

-- 
Frank

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Tue Aug 31 18:57:31 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id SAA24458
	for <tony@tesla.rcub.bg.ac.yu>; Tue, 31 Aug 1999 18:57:28 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id QAA02187
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 5 Aug 1999 16:45:39 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:4168 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S42364AbPHEQUt>;
	Thu, 5 Aug 1999 19:20:49 +0300
Received:  by vger.rutgers.edu via listexpand id <S156305AbPHEQMv>;
	Thu, 5 Aug 1999 12:12:51 -0400
Received:  by vger.rutgers.edu id <S155242AbPHEQMD>;
	Thu, 5 Aug 1999 12:12:03 -0400
Received: from golf.dax.net ([193.216.69.103]:63582 "EHLO golf.dax.net")
	by vger.rutgers.edu with ESMTP id <S156436AbPHEQIY>;
	Thu, 5 Aug 1999 12:08:24 -0400
Received: from monster (mp-217-226-81.daxnet.no [193.217.226.81])
	by golf.dax.net (8.9.3/8.9.3) with ESMTP id SAA04842
	for <linux-kernel@vger.rutgers.edu>; Thu, 5 Aug 1999 18:08:25 +0200 (MET DST)
Received: from monster (c2i.net) [127.0.0.1] (helge)
	by monster with esmtp (Exim 2.05 #1 (Debian))
	id 11CQ9C-0000SA-00; Thu, 5 Aug 1999 18:13:38 +0200
X-Mailer: exmh version 2.0.2 2/24/98 (debian) 
To: linux-kernel@vger.rutgers.edu
Subject: Re: First WinModem for Linux 
In-Reply-To: Message from "Carlo M. Arenas Belon" <carenas@chasqui.LaRed.net.pe> 
   of "Wed, 04 Aug 1999 10:14:50 EDT." <Pine.LNX.4.02.9908040826310.3791-100000@chasqui.LaRed.net.pe> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Thu, 05 Aug 1999 18:13:38 +0200
From: Helge Hafting <helge.hafting@c2i.net>
Message-Id: <E11CQ9C-0000SA-00@monster>
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig


> actually, generic function CPUs were born as a way to handle different
> tasks on the same hardware device.
> 
> this would make implementing "especial" features easier since all this
> features should be done giving instructions for a single multi purpose
> hardware, for sure Software was born.
> 
> the problem here is not on the paradigm design, but on the fact that 
> current microprocessor architectures don't scale.
> 
> that is why specialized DSPs are used for, a "Software DSP" is not an
> efficient design because of the flaws of current hardware.
> 
A software modem DSP is bad because it is very timing-sensitive,
no matter how powerful the cpu is.  The very sensitive stuff is
better left to dedicated hardware.  Use the cpu for less critical stuff,
such as running generic programs and tossing bytes/pages to the
dedicated hardware.  
IDE used to be a cpu-intensive cheap disk interface.  They have
implemented DMA now in order to offload the cpu - guess why?
The same applies to winmodems.  (Can you even run several winmodems
in one machine?)

A cheaper modem with compression & the hayes command interface in 
software might make sense.  Putting DSP jobs like echo cancelling and such in
software is just broken.

Helge Hafting


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Tue Aug 31 18:57:44 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id SAA24471
	for <tony@tesla.rcub.bg.ac.yu>; Tue, 31 Aug 1999 18:57:31 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id FAA02155
	for <tony@tesla.rcub.bg.ac.yu>; Mon, 9 Aug 1999 05:45:20 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:15402 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S9550AbPHIFQw>;
	Mon, 9 Aug 1999 08:16:52 +0300
Received:  by vger.rutgers.edu via listexpand id <S156068AbPHIFMV>;
	Mon, 9 Aug 1999 01:12:21 -0400
Received:  by vger.rutgers.edu id <S154582AbPHIFLu>;
	Mon, 9 Aug 1999 01:11:50 -0400
Received: from node9.frontiernet.net ([209.130.129.194]:52638 "EHLO
        frontiernet.net") by vger.rutgers.edu with ESMTP id <S155102AbPHIFL3>;
	Mon, 9 Aug 1999 01:11:29 -0400
Received: from globalcenter.net (lorax.erkkila.org [209.130.187.53])
	by frontiernet.net (8.8.8a/8.8.8) with ESMTP id BAA204036;
	Mon, 9 Aug 1999 01:11:29 -0400
Message-ID: <37AE62C5.A5795E3E@globalcenter.net>
Date:   Mon, 09 Aug 1999 01:10:29 -0400
From: "Paul E. Erkkila" <pee@globalcenter.net>
X-Mailer: Mozilla 4.61 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: joeja@mindspring.com
CC: linux-kernel@vger.rutgers.edu
Subject: Re: bezerko mouse
References: <19990806125423.17139.rocketmail@web503.yahoomail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig



"Me Too" :)

2.2.9 SMP, serial logitech mouse..

I have never lost keyboard control, and a switch to
text mode and back is a quick fix.

-pee


Joe wrote:

> Jos and all,
>
>     well I have found out that this bezerko mouse behavior is
> not SMP exclusive,
> and it is not fixable by changing to XT-PIC or noapic,  it
> just occured on my
> machine and I am using XT-PIC for the mouse.
>
>     I also recieved an email from someone that said that they
> have 20 machines
> both SMP and non that experience this problem.  It is not
> serial or PS/2
> exclusive and it can affect your keyboard.
>
>     The current fix or workaround "if your keyboard is still
> working" is to
> switch to a console   Alt-Ctrl-F1 then back to X by
> Alt-Ctrl-F7
>
>     It seems that we are getting bad data to the mouse somehow
> and and when this
> data gets corrupted it must be reset.  I do not think it is in
> serial code cause
> it effect PS/2 mice also,  it is not in the APIC code either
> as it affects non
> SMP machines also.
>
>     I do not think it is hardware related, as it has hit
> various hardware
> systems, and it was not present on my machine under 2.0.x.
>
> just thought you all should know that it can occur to anyone
> on any machine
>
> --
> Joseph Acosta ........ SMP Linux 2.2.10 / RedHat 6.0 / SMP
> Windows NT 4.0
> home: joeja@mindspring.com
> http://www.mindspring.com/~joeja
> alias: josepha48@yahoo.com
>
> _____________________________________________________________
> Do You Yahoo!?
> Free instant messaging and more at http://messenger.yahoo.com
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Tue Aug 31 18:57:52 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id SAA24483
	for <tony@tesla.rcub.bg.ac.yu>; Tue, 31 Aug 1999 18:57:45 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id QAA02242
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 5 Aug 1999 16:45:57 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:5896 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S42207AbPHEQmB>;
	Thu, 5 Aug 1999 19:42:01 +0300
Received:  by vger.rutgers.edu via listexpand id <S156351AbPHEQis>;
	Thu, 5 Aug 1999 12:38:48 -0400
Received:  by vger.rutgers.edu id <S154956AbPHEQeh>;
	Thu, 5 Aug 1999 12:34:37 -0400
Received: from mons.uio.no ([129.240.130.14]:47419 "HELO mons.uio.no")
	by vger.rutgers.edu with SMTP id <S156006AbPHEQd7>;
	Thu, 5 Aug 1999 12:33:59 -0400
Received: from mons.uio.no (actually mons.uio.no [129.240.130.14]) by mons.uio.no with SMTP (PP); Thu, 5 Aug 1999 18:33:56 +0200
Received: from susy.uio.no ([129.240.86.35]) by mons.uio.no with esmtp (Exim 2.12 #6) id 11CQSp-0004Ql-00;
          Thu, 5 Aug 1999 18:33:55 +0200
Received: from trondmy by susy.uio.no with local (Exim 2.12 #1) id 11CQSr-0000kB-00; Thu, 5 Aug 1999 18:33:57 +0200
Date:   Thu, 5 Aug 1999 18:33:57 +0200 (CEST)
To: Jamie Lokier <lkd@tantalophile.demon.co.uk>
Cc: Trond Myklebust <trond.myklebust@fys.uio.no>,
        Alexander Viro <viro@math.psu.edu>, linux-kernel@vger.rutgers.edu
Subject: Re: 2.3 SMP overlapping writes and NFS
In-Reply-To: <19990805164706.B4590@pcep-jamie.cern.ch>
References: <19990805052720.A4173@pcep-jamie.cern.ch> <Pine.GSO.4.10.9908051014520.26448-100000@weyl.math.psu.edu> <14249.40939.641682.139500@susy.uio.no> <19990805164706.B4590@pcep-jamie.cern.ch>
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid
Message-ID: <14249.47259.96723.171931@susy.uio.no>
Reply-To: trond.myklebust@fys.uio.no
From: Trond Myklebust <trond.myklebust@fys.uio.no>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

>>>>> " " == Jamie Lokier <lkd@tantalophile.demon.co.uk> writes:

     > Trond Myklebust wrote:
    >> As long as we violate the synchronicity assumption strict
    >> adherence to the rule of atomicity of writes becomes a largely
    >> academic issue.

     > They're different things.

If you cannot guarantee stability of writes, then surely atomicity
cannot be guaranteed either. What if the server crashes after sending
the NFS_OK, but before the data is committed?

     > Regardless of committing to stable storage, write atomicity can
     > be used for database synchronisation between clients.  Of
     > course any sensible client would synchronise on a single
     > byte... I don't know if any real applications depend on atomic
     > writes.

As long as the operation read+write is not atomic, can you really
implement such a scheme? 
As Alan pointed out, link() and mkdir() are more useful for this sort
of thing.

    >> For NFSv3, things are of course different, since there the
    >> NFS_COMMIT instruction exists in order to trigger the flushing
    >> to disk.

     > And atomicity isn't specified for NFSv3 either.

Only if you specify stable writes (FILE_SYNC) in which case the NFSv2
rules are supposed to apply.

Cheers,
  Trond

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Tue Aug 31 18:58:05 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id SAA24495
	for <tony@tesla.rcub.bg.ac.yu>; Tue, 31 Aug 1999 18:57:55 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id QAA02226
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 5 Aug 1999 16:45:52 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:12915 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S42224AbPHEQdu>;
	Thu, 5 Aug 1999 19:33:50 +0300
Received:  by vger.rutgers.edu via listexpand id <S156343AbPHEQXL>;
	Thu, 5 Aug 1999 12:23:11 -0400
Received:  by vger.rutgers.edu id <S155036AbPHEQVG>;
	Thu, 5 Aug 1999 12:21:06 -0400
Received: from liberty.uc.wlu.edu ([137.113.192.101]:1347 "EHLO
        liberty.uc.wlu.edu") by vger.rutgers.edu with ESMTP
	id <S156340AbPHEQTg>; Thu, 5 Aug 1999 12:19:36 -0400
Received: from WISDOM.UC.WLU.EDU (wisdom.uc.wlu.edu [137.113.192.113])
	by liberty.uc.wlu.edu (8.8.6/8.8.6) with SMTP id MAA06620
	for <linux-kernel@vger.rutgers.edu>; Thu, 5 Aug 1999 12:19:34 -0400 (EDT)
Received: from WluD-Message_Server by WISDOM.UC.WLU.EDU
	with Novell_GroupWise; Thu, 05 Aug 1999 12:23:17 -0400
Message-Id: <s7a98235.077@WISDOM.UC.WLU.EDU>
X-Mailer: Novell GroupWise 5.5.2
Date:   Thu, 05 Aug 1999 12:23:16 -0400
From: "Cliff Woolley" <JWOOLLEY@wlu.edu>
To: <buytenh@dsv.nl>
Cc: <linux-kernel@vger.rutgers.edu>
Subject: Re: tracing ports open by kernel modules
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig


>>> "Lennert Buytenhek" <buytenh@dsv.nl> 08/05/99 10:16AM >>>

>>That's the same problem again... Digging in /proc/net/[tcp|udp], I
*do*
>>find the ports in question, and an inode that they belong to... but
I
>>can't seem go glean anything useful from the inode number.  Thoughts?

>>What exactly does it represent?
>The inodes are just sequentially assigned. Every file in an ordinary
>file system has an inode number (sort of an index). So do sockets.
[snip]
>You can find in /proc/<pid>/fd/ which 'inode' a socket
>fd links to, and then you can find in /proc/net/tcp or /proc/net/udp
which
>socket it is by comparing the inodes. (This is what fuser does then).
So
>really, there is nothing magical to the inode numbers.

Hmm... as I suspected.  So much for that idea.

>To be able to do what you want you could add a field to each socket
>(creating_pid for example) which remembers the creating pid. This
>is also tricky in a sense, in that the creating pid might have
already
>died (and sockets are passed on through fork() and you can also
>pass socket fd's over pipes, some of the lesser known and used
>features of *nix). The trouble is that this will 1. require a patched
>kernel and 2. will never be approved by Linus. I assume your app
>was intended to be a general thingy?

True on both accounts.  It works great, except it leaves a few blanks
where it knows the port/proto combination, but can't figure out what
process it is.  Maybe I just have to punt and hardcode in a message that
says "[maybe kernel-based]" if all else fails?  Or do I make dangerous
and not-portable assumptions about what ports might be what?  That'd
probably be better left in a readme.  So maybe something along the lines
of "[maybe kernel, see docs]".  That kind of takes the fun (and the
functionality) out of it.  :-/

-Cliff

Cliff Woolley
Central Systems Software Administrator
Washington and Lee University
http://www.wlu.edu/~jwoolley/

Work: (540) 463-8089
Pager: (540) 462-3472

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Tue Aug 31 18:58:15 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id SAA24519
	for <tony@tesla.rcub.bg.ac.yu>; Tue, 31 Aug 1999 18:58:06 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id QAA02151
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 5 Aug 1999 16:45:18 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:5910 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S42459AbPHEP5B>;
	Thu, 5 Aug 1999 18:57:01 +0300
Received:  by vger.rutgers.edu via listexpand id <S156262AbPHEPwp>;
	Thu, 5 Aug 1999 11:52:45 -0400
Received:  by vger.rutgers.edu id <S155021AbPHEPw2>;
	Thu, 5 Aug 1999 11:52:28 -0400
Received: from neon-best.transmeta.com ([206.184.214.10]:12563 "EHLO
        neon.transmeta.com") by vger.rutgers.edu with ESMTP
	id <S156309AbPHEPpp>; Thu, 5 Aug 1999 11:45:45 -0400
Received: from deepthought.transmeta.com (mailhost.transmeta.com [10.1.1.15])
	by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id IAA14134;
	Thu, 5 Aug 1999 08:45:06 -0700
Received: from penguin.transmeta.com (root@penguin.transmeta.com [10.1.2.202])
	by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id IAA22248;
	Thu, 5 Aug 1999 08:45:05 -0700 (PDT)
Received: from localhost (torvalds@localhost) by penguin.transmeta.com (8.9.3/8.7.3) with ESMTP id IAA01617; Thu, 5 Aug 1999 08:45:55 -0700
X-Authentication-Warning: penguin.transmeta.com: torvalds owned process doing -bs
Date:   Thu, 5 Aug 1999 08:45:55 -0700 (PDT)
From: Linus Torvalds <torvalds@transmeta.com>
To: Carsten Paeth <calle@calle.in-berlin.de>
cc: i4ldeveloper@listserv.isdn4linux.de,
        Kernel Mailing List <linux-kernel@vger.rutgers.edu>
Subject: Re: no driver change for 2.4?
In-Reply-To: <19990805122357.A3718@calle.in-berlin.de>
Message-ID: <Pine.LNX.4.10.9908050838260.1592-100000@penguin.transmeta.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig



On Thu, 5 Aug 1999, Carsten Paeth wrote:
> 
> I have a 2.3.12 running with the current isdn4linux cvs tree.
> I will get crasy if my work again will not find the way into
> the main stream kernel.
> 
> Why is it a problem to put this stuff into the kernel ?

I don't know why the ISDN people just do not ever GET IT.

I refuse to get huge patches every time two weeks before a feature freeze.
How hard is that to understand?

I will continue to ignore the ISDN CVS tree. If the ISDN people cannot get
their act together and actually start sending their fixes to the standard
kernel in a timely manner, I cannot be bothered with it. This has
continued for something like five years now, and every time I explain it
to people my explanation gets lost or ignored. 

> What is the actual way to put changes into the actual kernel
> for isdn4linux ?
> What can I do to fix that problems ?
> Should I sent a patch to 2.3.12 to you or someone else ?

It's not about sending "a patch".

It's about being a responsible programmer, and making sure I get MORE than
just a patch every f*cing time I anounce a code freeze. I should have been
getting patches for the last half year, and I have gotten ZERO. And I'm
irritated at the ISDN peopl, because this is not the first time. In fact,
I have never EVER gotten a single responsible ISDN developer that stands
up and says "ok, I'll be the maintainer of this, and I'll make sure it
gets fed to Linus in a timely manner".

You still wonder why ISDN is not there? Do you still wonder why I'm fed up
with ISDN people who think they they can just force-feed me one huge patch
and completely avoid any QA in the meantime?

WHY, oh why, is the ONLY time I ever hear from ISDN people when I have
publically announced a code-freeze? Explain that,

		Linus


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Tue Aug 31 18:59:15 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id SAA24570
	for <tony@tesla.rcub.bg.ac.yu>; Tue, 31 Aug 1999 18:59:11 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id QAA02178
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 5 Aug 1999 16:45:37 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:8763 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S42108AbPHEQKQ>;
	Thu, 5 Aug 1999 19:10:16 +0300
Received:  by vger.rutgers.edu via listexpand id <S156454AbPHEQIp>;
	Thu, 5 Aug 1999 12:08:45 -0400
Received:  by vger.rutgers.edu id <S156369AbPHEQB6>;
	Thu, 5 Aug 1999 12:01:58 -0400
Received: from neon-best.transmeta.com ([206.184.214.10]:25071 "EHLO
        neon.transmeta.com") by vger.rutgers.edu with ESMTP
	id <S155243AbPHEPxl>; Thu, 5 Aug 1999 11:53:41 -0400
Received: from deepthought.transmeta.com (mailhost.transmeta.com [10.1.1.15])
	by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id IAA14297;
	Thu, 5 Aug 1999 08:53:01 -0700
Received: from penguin.transmeta.com (root@penguin.transmeta.com [10.1.2.202])
	by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id IAA22743;
	Thu, 5 Aug 1999 08:53:01 -0700 (PDT)
Received: from localhost (torvalds@localhost) by penguin.transmeta.com (8.9.3/8.7.3) with ESMTP id IAA01625; Thu, 5 Aug 1999 08:53:51 -0700
X-Authentication-Warning: penguin.transmeta.com: torvalds owned process doing -bs
Date:   Thu, 5 Aug 1999 08:53:51 -0700 (PDT)
From: Linus Torvalds <torvalds@transmeta.com>
To: "Petr Vandrovec Ing. VTEI" <VANDROVE@vc.cvut.cz>
cc: linux-kernel@vger.rutgers.edu
Subject: Re: New resources - pls, explain :-(
In-Reply-To: <77566443F1@vcnet.vc.cvut.cz>
Message-ID: <Pine.LNX.4.10.9908050846100.1592-100000@penguin.transmeta.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig



On Thu, 5 Aug 1999, Petr Vandrovec Ing. VTEI wrote:
> these my questions, I'll be very happy.
>   (1) There is something wrong with /proc/iomem on my kernel :-(
> readdir shows it, but open/stat says ENOENT :-( I did not find any change
> which could cause this; but it is side issue for me currently

It's because I forgot to update the length field of the /proc entry.
It's fixed in my current stuff, I'll make a new release.

>   (2) What should I do with this resource? From your code it seems that
>      (a) resource is already plugged into resource tree, so no
>          {request,release}_resource should be in driver
>      (b) start contain base, end end address and flags some ids (maybe
>          there should be some additional macros - it is not clear whether
>          MMIO region is detected as !(flags & PCI_BASE_ADDRESS_SPACE_IO) or
>          by something else.
>          Probably IS_PCI_SPACE_IO() & IS_PCI_SPACE_MMIO() should be invented
>          (otherwise I'll ignore these flags - hardware manual says, that
>          region 0 for my matrox is always MMIO, so why bother with check)

You don't =have= to do anything with the resource. Many drivers can just
do

	mmio_base = dev->resource[0].start;

because for those drivers the driver documentation says that it's always
the first aperture, and it's always a memory region. So you don't have to
use the flags if you don't want to.

There are other drivers where different chip versions have different
apertures (it's actually fairly uncommon, but it happens, and PCI
obviously gives enough information that it can be worked around), and
those drivers might for example search through each of the six resources
to find the one tey are interested in.

So the code might look something like this:

	int find_io_base(struct pci_dev * dev)
	{
		for (i = 0; i < 6; i++) {
			if (dev->resource[i].flags & PCI_BASE_ADDRESS_SPACE_IO)
				return dev->resource[i].start;
		}
		return -1;
	}

but that's usually not actually needed.		

>   (3) check_region currently returns already allocated (so I have to comment
>       out check_region checks from ide-dma.c & de4x5.c). And (2a) implies
>       that there is no way to tell kernel that device (or resource) is
>       allocated now. Did I oversight something or is there planned
>       {request,release,check}_pci_dev(struct pci_dev*) for 2.3.13-pre6?

There's a planned fix for check_region() and friends coming soon, so this
will just work again. None of the drivers I needed had a problem with it,
because they were either pure PCI anddin't bother with check-region at
all, or they were old ISA-like and didn't show up in the PCI address space
allocations anyway.

Expect a update later today,

		Linus


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Tue Aug 31 18:59:18 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id SAA24587
	for <tony@tesla.rcub.bg.ac.yu>; Tue, 31 Aug 1999 18:59:16 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id QAA02157
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 5 Aug 1999 16:45:28 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:2338 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S41980AbPHEQBs>;
	Thu, 5 Aug 1999 19:01:48 +0300
Received:  by vger.rutgers.edu via listexpand id <S156327AbPHEPxE>;
	Thu, 5 Aug 1999 11:53:04 -0400
Received:  by vger.rutgers.edu id <S156305AbPHEPwt>;
	Thu, 5 Aug 1999 11:52:49 -0400
Received: from gate.mvhi.com ([194.205.184.34]:61328 "EHLO
        server.axiom.internal") by vger.rutgers.edu with ESMTP
	id <S156331AbPHEPv6>; Thu, 5 Aug 1999 11:51:58 -0400
Received: from devel4.axiom.internal ([10.0.1.6])
	by server.axiom.internal with esmtp (Exim 1.90 #1)
	id 11CPoB-00037B-00; Thu, 5 Aug 1999 16:51:55 +0100
Received: from wjl by devel4.axiom.internal with local (Exim 1.90 #1)
	id 11CPoA-0000UY-00; Thu, 5 Aug 1999 16:51:54 +0100
From: Will Lockhart <will.lockhart@bigfoot.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date:   Thu,  5 Aug 1999 16:51:54 +0100 (BST)
To: linux-kernel@vger.rutgers.edu
Cc: alan@redhat.com
Subject: [patch] Cirrus Logic CS89x0 bug fixes
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <14249.44698.376792.984237@devel4.axiom.internal>
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

Couple of patches for the Crystal Semi (now Cirrus Logic) ethernet
chipset. A couple of the constants in the header file are wrong
(obvious by inspection from the data sheet, available at
http://www.cirrus.com/ftp/pubs/8900a.pdf). The net result of this is
that although the driver detects transmit underrun and attempts to
disable pipelined transmit, it never actually manages to turn it off
completely.

Also, the code that handles transmit underrun doesn't treat the
condition as it should i.e. transmit complete but failed, so when it
happens you had to wait for the upper layers to time out before the
frame gets retransmitted.

Both of these are probably only issues on machines with slow and/or
broken buses, so I doubt anybody has actually been affected by either
problem.

Oh, and fixed a couple of spelling mistakes, and bumped the minor
version number by 1.

Patches against 2.2.10.

--- /homes/wjl/linux/linux/drivers/net/cs89x0.c	Tue Jun  8 00:19:58 1999
+++ drivers/net/cs89x0.c	Thu Aug  5 16:30:29 1999
@@ -30,7 +30,7 @@
 */
 
 static char *version =
-"cs89x0.c:v1.02 11/26/96 Russell Nelson <nelson@crynwr.com>\n";
+"cs89x0.c:v1.03 11/26/96 Russell Nelson <nelson@crynwr.com>\n";
 
 /* ======================= configure the driver here ======================= */
 
@@ -306,7 +306,7 @@
 	else if (get_eeprom_data(dev, START_EEPROM_DATA,CHKSUM_LEN,eeprom_buff) < 0) {
 		printk("\ncs89x0: EEPROM read failed, relying on command line.\n");
         } else if (get_eeprom_cksum(START_EEPROM_DATA,CHKSUM_LEN,eeprom_buff) < 0) {
-                printk("\ncs89x0: EEPROM checksum bad, relyong on command line\n");
+                printk("\ncs89x0: EEPROM checksum bad, relying on command line\n");
         } else {
                 /* get transmission control word  but keep the autonegotiation bits */
                 if (!lp->auto_neg_cnf) lp->auto_neg_cnf = eeprom_buff[AUTO_NEG_CNF_OFFSET/2];
@@ -843,6 +843,13 @@
                                 lp->send_underrun++;
                                 if (lp->send_underrun == 3) lp->send_cmd = TX_AFTER_381;
                                 else if (lp->send_underrun == 6) lp->send_cmd = TX_AFTER_ALL;
+				/* transmit cycle is done, although
+				   frame wasn't transmitted - this
+				   avoids having to wait for the upper
+				   layers to timeout on us, in the
+				   event of a tx underrun */
+				dev->tbusy = 0;
+				mark_bh(NET_BH);	/* Inform upper layers. */
                         }
 			break;
 		case ISQ_RX_MISS_EVENT:

--- /homes/wjl/linux/linux/drivers/net/cs89x0.h	Sun Feb  2 13:18:36 1997
+++ drivers/net/cs89x0.h	Thu Aug  5 16:19:06 1999
@@ -319,8 +319,8 @@
 #define TX_FRAME_PORT RX_FRAME_PORT
 #define TX_CMD_PORT	0x0004
 #define TX_NOW		0x0000       /*  Tx packet after   5 bytes copied */
-#define TX_AFTER_381	0x0020       /*  Tx packet after 381 bytes copied */
-#define TX_AFTER_ALL	0x0060       /*  Tx packet after all bytes copied */
+#define TX_AFTER_381	0x0040       /*  Tx packet after 381 bytes copied */
+#define TX_AFTER_ALL	0x00c0       /*  Tx packet after all bytes copied */
 #define TX_LEN_PORT	0x0006
 #define ISQ_PORT	0x0008
 #define ADD_PORT	0x000A

Will

-- 
Will Lockhart, System Developer, Axiom (Cambridge) Ltd.
http://www.mvhi.com/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Tue Aug 31 18:59:33 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id SAA24592
	for <tony@tesla.rcub.bg.ac.yu>; Tue, 31 Aug 1999 18:59:18 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id PAA02145
	for <tony@tesla.rcub.bg.ac.yu>; Sat, 7 Aug 1999 15:35:38 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:26884 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S46124AbPHGPM5>;
	Sat, 7 Aug 1999 18:12:57 +0300
Received:  by vger.rutgers.edu via listexpand id <S157084AbPHGPJ4>;
	Sat, 7 Aug 1999 11:09:56 -0400
Received:  by vger.rutgers.edu id <S155998AbPHGPJg>;
	Sat, 7 Aug 1999 11:09:36 -0400
Received: from penguin.e-mind.com ([195.223.140.120]:18977 "EHLO
        penguin.e-mind.com") by vger.rutgers.edu with ESMTP
	id <S156264AbPHGPJT>; Sat, 7 Aug 1999 11:09:19 -0400
Received: from laser.random (isdn44-imo.e-mind.com [195.223.140.54])
	by penguin.e-mind.com (8.9.1a/8.9.1/Debian/GNU) with ESMTP id RAA10519;
	Sat, 7 Aug 1999 17:12:40 +0200
Received: from localhost (andrea@localhost)
	by laser.random (8.8.8/8.8.8) with ESMTP id RAA08109;
	Sat, 7 Aug 1999 17:08:32 +0200
Date:   Sat, 7 Aug 1999 17:08:32 +0200 (CEST)
From: Andrea Arcangeli <andrea@suse.de>
X-Sender: andrea@laser.random
To: Linus Torvalds <torvalds@transmeta.com>,
        "Stephen C. Tweedie" <sct@redhat.com>
cc: linux-kernel@vger.rutgers.edu, linux-mm@kvack.org
Subject: [patch] 2.3.12 persistence of dirty pages on the swap space
Message-ID: <Pine.LNX.4.10.9908071700240.7637-100000@laser.random>
X-Public-Key-URL: http://e-mind.com/~andrea/aa.asc
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

As just said some time ago there's a simple way to swapout the swapped-in
dirty pages always on the same location on disk (so avoiding swap
fragmentation and taking the swapped out data contigous on disk).

We have the swap-entry information cached in the page->offset field all
the time after the first swapin. It will stay uptodate also after removing
the page from the swap cache in the do_wp_page fault.

We only need to know when the entry is uptodate and I take care of that
with a per-page bitflag (PG_swap_entry).

Here it is the simple patch against 2.3.12:

diff -ur 2.3.12/include/linux/mm.h 2.3.12-swap_entry/include/linux/mm.h
--- 2.3.12/include/linux/mm.h	Wed Aug  4 12:28:17 1999
+++ 2.3.12-swap_entry/include/linux/mm.h	Sat Aug  7 16:59:12 1999
@@ -152,6 +152,7 @@
 #define PG_Slab			 8
 #define PG_swap_cache		 9
 #define PG_skip			10
+#define PG_swap_entry		11
 				/* bits 21-30 unused */
 #define PG_reserved		31
 
diff -ur 2.3.12/mm/memory.c 2.3.12-swap_entry/mm/memory.c
--- 2.3.12/mm/memory.c	Sun Aug  1 18:11:22 1999
+++ 2.3.12-swap_entry/mm/memory.c	Sat Aug  7 16:51:49 1999
@@ -990,6 +990,7 @@
 
 	pte = mk_pte(page_address(page), vma->vm_page_prot);
 
+	set_bit(PG_swap_entry, &page->flags);
 	if (write_access && !is_page_shared(page)) {
 		delete_from_swap_cache(page);
 		pte = pte_mkwrite(pte_mkdirty(pte));
diff -ur 2.3.12/mm/swap_state.c 2.3.12-swap_entry/mm/swap_state.c
--- 2.3.12/mm/swap_state.c	Tue Jul 13 02:02:10 1999
+++ 2.3.12-swap_entry/mm/swap_state.c	Sat Aug  7 16:53:51 1999
@@ -274,6 +274,8 @@
 	}
 	UnlockPage(page);
 	
+	clear_bit(PG_swap_entry, &page->flags);
+
 	__free_page(page);
 }
 
diff -ur 2.3.12/mm/swapfile.c 2.3.12-swap_entry/mm/swapfile.c
--- 2.3.12/mm/swapfile.c	Thu Jul 22 01:07:28 1999
+++ 2.3.12-swap_entry/mm/swapfile.c	Sat Aug  7 16:55:21 1999
@@ -157,6 +157,35 @@
 	goto out;
 }
 
+/* needs the big kernel lock */
+int reacquire_swap_entry(unsigned long entry)
+{
+	struct swap_info_struct * p;
+	unsigned long offset, type;
+	int retval = 0;
+
+	if (!entry)
+		goto out;
+	type = SWP_TYPE(entry);
+	if (type & SHM_SWP_TYPE)
+		goto out;
+	if (type >= nr_swapfiles)
+		goto out;
+	p = type + swap_info;
+	if ((p->flags & SWP_WRITEOK) != SWP_WRITEOK)
+		goto out;
+	offset = SWP_OFFSET(entry);
+	if (offset >= p->max)
+		goto out;
+	if (!p->swap_map[offset])
+	{
+		retval = p->swap_map[offset] = 1;
+		nr_swap_pages--;
+	}
+out:
+	return retval;
+}
+
 /*
  * The swap entry has been read in advance, and we return 1 to indicate
  * that the page has been used or is no longer needed.
diff -ur 2.3.12/mm/vmscan.c 2.3.12-swap_entry/mm/vmscan.c
--- 2.3.12/mm/vmscan.c	Thu Jul 22 01:07:28 1999
+++ 2.3.12-swap_entry/mm/vmscan.c	Sat Aug  7 16:57:00 1999
@@ -153,9 +153,16 @@
 	 * we have the swap cache set up to associate the
 	 * page with that swap entry.
 	 */
+	if (test_and_clear_bit(PG_swap_entry, &page->flags))
+	{
+		entry = page->offset;
+		if (reacquire_swap_entry(entry))
+			goto swap_entry_reacquired;
+	}
 	entry = get_swap_page();
 	if (!entry)
 		goto out_failed; /* No swap space left */
+ swap_entry_reacquired:
 		
 	vma->vm_mm->rss--;
 	tsk->nswap++;


When I benchmarked it on 2.2.x long ago it was a very nice improvement.

Andrea


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Tue Aug 31 19:17:05 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id TAA25511
	for <tony@tesla.rcub.bg.ac.yu>; Tue, 31 Aug 1999 19:17:05 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id QAA02198
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 5 Aug 1999 16:45:42 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:19564 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S42292AbPHEQai>;
	Thu, 5 Aug 1999 19:30:38 +0300
Received:  by vger.rutgers.edu via listexpand id <S155598AbPHEQVW>;
	Thu, 5 Aug 1999 12:21:22 -0400
Received:  by vger.rutgers.edu id <S155033AbPHEQU6>;
	Thu, 5 Aug 1999 12:20:58 -0400
Received: from ns.tasking.nl ([195.193.207.2]:1498 "EHLO ns.tasking.nl")
	by vger.rutgers.edu with ESMTP id <S156355AbPHEQUA>;
	Thu, 5 Aug 1999 12:20:00 -0400
Received: (from root@localhost) by ns.tasking.nl (8.9.1a/8.6.12) id SAA02057; Thu, 5 Aug 1999 18:19:57 +0200 (MET DST)
Received: by ns.tasking.nl via smap (V1.3)
	id sma001927; Thu, 5 Aug 99 18:18:30 +0200
Received: from espoo.tasking.nl by empoli.tasking.nl; (5.65v3.2/1.1.8.2/23Dec97-1135AM)
	id AA17981; Thu, 5 Aug 1999 18:17:26 +0200
Received: (from fvm@localhost) by espoo.tasking.nl (8.8.7/8.6.9) id SAA06397; Thu, 5 Aug 1999 18:17:26 +0200
Message-Id: <19990805181725.F5564@tasking.nl>
Date:   Thu, 5 Aug 1999 18:17:25 +0200
From: Frank van Maarseveen <fvm@tasking.nl>
To: trond.myklebust@fys.uio.no
Cc: linux-kernel@vger.rutgers.edu
Subject: Re: 2.2.10-ac<x> / 2.2.11-pre<x> NFS client problem & bugfix
Reply-To: frank_van_maarseveen@tasking.com
References: <19990805140508.C5564@tasking.nl> <14249.33909.217912.967239@susy.uio.no> <19990805151613.E5564@tasking.nl> <14249.36693.982457.519720@susy.uio.no>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="kXdP64Ggrk/fb43R"
X-Mailer: Mutt 0.93.2i (Linux)
In-Reply-To: <14249.36693.982457.519720@susy.uio.no>; from Trond Myklebust on Thu, Aug 05, 1999 at 03:33:59PM +0200
Organization: TASKING, Inc.
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig


--kXdP64Ggrk/fb43R
Content-Type: text/plain; charset=us-ascii

On Thu, Aug 05, 1999 at 03:33:59PM +0200, Trond Myklebust wrote:
> >>>>> " " == Frank van Maarseveen <fvm@tasking.nl> writes:
> 
>      > 2.2.6-ac3 and other prior versions did not have this behavior
>      > and to my knowledge no other UNIX client currently does (AFAIK
>      > only OSF/1 3.2 NFS did something which is even more evil,
>      > rendering it *completely* useless).
> 
> 2.2.7 and below had a permanent 5second delay. This is worse behaviour
> than the 1 second delay.
That is not the case for 2.2.6-ac3 and 2.0.36 which have zero second
delays. Notice this excerpt from 2.2.6-ac3/fs/nfs/dir.c:

static int nfs_lookup_revalidate(struct dentry * dentry)
{
	struct dentry * parent = dentry->d_parent;
	struct inode * inode = dentry->d_inode;
	int error;
	struct nfs_fh fhandle;
	struct nfs_fattr fattr;

	/*
	 * If we don't have an inode, let's just assume
	 * a 5-second "live" time for negative dentries.
	 */
	if (!inode)
		goto do_lookup;

The comment says 5 second but it clearly doesn't.

> With your test I see both the 30second delay (if you don't access the
> parent directory in any way) and the 1 second delay. No persistent
> negative dentries.
mount options: rw,nodev,rsize=8192,wsize=8192,nolock,retry=-1
	client version	result
	2.0.36		ok ("nolock" is ignored)
	2.2.6-ac3	ok
	2.2.10-ac11	>60 sec persistence when <1sec loop
	2.2.11-pre4	12..25 sec persistence when <1sec loop

Regarding pre4 you seem to be correct though I cannot reproduce the 30
seconds (I did 5 experiments). Still, I think it is questionable behavior
to lenghten the lifetime of a negative dentry when it is hit. Also, this
negative dentry caching makes it difficult (a bit undeterministic
and at least very slow) to signal a remote process by placing a marker
file on NFS. Yes, I know that that is silly programming but there are
a lot of silly programmers out there and in some situations it might
actually make sense to do it this way.

Regarding the caching of attributes for regular files I noticed the
following. On the server the command "ls >notfound" is repeatedly
executed (<1 sec loop). On the client "repstat notfound" is executed
(C source attached) and the mtime it reports changes with the following
interval (just tested, same mount options):

	client version
	2.0.36		3..4 sec conform the default for acregmin
	2.2.6-ac3	1 sec
	2.2.10-ac11	1 sec
	2.2.11-pre4	1 sec

Another pre4 problem is that ls -l sometimes doesn't show one specific
file whereas stat() says otherwise. In this case ls -l was correct.

There are some other strange behaviors in 2.2.10-ac11 (incorrect
ESTALE for minutes, old versions of files being cached entirely)
but mostly they appear undeterministic because of little tweaks
in the kernel e.g. the mtime of the parent directory being older
than 15 mins (still present in pre4 fs/nfs/dir.c):

static inline int nfs_dentry_force_reval(struct dentry *dentry, int flags)
{
	struct inode *inode = dentry->d_inode;
	unsigned long timeout = NFS_ATTRTIMEO(inode);

	/*
	 * If it's the last lookup in a series, we use a stricter
	 * cache consistency check by looking at the parent mtime.
	 *
	 * If it's been modified in the last hour, be really strict.
	 * (This still means that we can avoid doing unnecessary
	 * work on directories like /usr/share/bin etc which basically
	 * never change).
	 */
	if (!(flags & LOOKUP_CONTINUE)) {
		long diff = CURRENT_TIME - dentry->d_parent->d_inode->i_mtime;

		if (diff < 15*60)
			timeout = 0;
	}
	
	return time_after(jiffies,dentry->d_time + timeout);
}

In this case the comment contains a bug: it's not an hour but
only 15 minutes. When I have something reproducible for pre4
I'll mail it to the list.

> If this is a major problem, I suggest rather that we fine-tune the
> delays, not that we remove support for negative dentry caching. Linus'
> typical example was an NFS-shared /usr/share partition (or any NFSroot
> system): if you have several users searching for a file in such a
> tree, turning off caching of negative dentries can lead to storms of
> unnecessary NFS_LOOKUP calls.
To me this appears as a no win situation. I wonder if one second really
helps that much. On the other hand more than a few seconds is likely
to hurt in many situations. So, why not making this configurable and
creating something like a /proc/sys/nfs/neg-dentry-timeout to set it or
disable it? The least which could be done is to disable negative dentry
caching entirely for NFS when acregmin is set to zero (disabling acreg).

Regards,

-- 
Frank

--kXdP64Ggrk/fb43R
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="repstat.c"

#include	<stdio.h>
#include	<time.h>
#include	<string.h>
#include	<stdlib.h>
#include	<errno.h>
#include	<unistd.h>
#include	<sys/types.h>
#include	<sys/stat.h>
#include	<sys/file.h>

void main(int argc, char *argv[])
{
	char *file;
	unsigned long us;
	struct stat st;

	if ((argc > 1 && argv[1][0] == '-') || argc > 3)
	{
		printf("Usage: repstat [file [micro-seconds-delay]]\n");
		printf("       default delay = 700000 us.\n");
		exit(0);
	}
	file = argc >= 2 ? argv[1] : ".";
	us = argc == 3 ? atol(argv[2]) : 700000;
	while (1)
	{
		if (stat(file, &st) == -1)
		{
			printf("%s: %s\n", file, strerror(errno));
		}
		else
		{
			printf("%s: %s", file, ctime(&st.st_mtime));
		}
		usleep(us);
	}
}

--kXdP64Ggrk/fb43R--

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Tue Aug 31 19:17:12 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id TAA25515
	for <tony@tesla.rcub.bg.ac.yu>; Tue, 31 Aug 1999 19:17:06 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id QAA02473
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 5 Aug 1999 16:51:14 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:43297 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S42776AbPHEQuz>;
	Thu, 5 Aug 1999 19:50:55 +0300
Received:  by vger.rutgers.edu via listexpand id <S156426AbPHEQlI>;
	Thu, 5 Aug 1999 12:41:08 -0400
Received:  by vger.rutgers.edu id <S156308AbPHEQfU>;
	Thu, 5 Aug 1999 12:35:20 -0400
Received: from xenon.ah.nl ([141.93.32.61]:46257 "EHLO xenon.ah.nl")
	by vger.rutgers.edu with ESMTP id <S156304AbPHEQZs>;
	Thu, 5 Aug 1999 12:25:48 -0400
Received: from waterstof.wau.mis.ah.nl (root@waterstof.wau.mis.ah.nl [141.93.32.89]) by xenon.ah.nl (8.9.0/8.6.12) with ESMTP id SAA09465; Thu, 5 Aug 1999 18:23:56 +0200 (MET DST)
Received: from p1imwe29.wau.mis.ah.nl ([141.93.34.60] helo=pcpaul.wau.mis.ah.nl)
	by waterstof.wau.mis.ah.nl with esmtp (Exim 3.02 #3)
	id 11CQJ9-00055t-00; Thu, 05 Aug 1999 18:23:55 +0200
Received: from paul by pcpaul.wau.mis.ah.nl with local (Exim 2.05 #1 (Debian))
	id 11CQJ9-0007Vq-00; Thu, 5 Aug 1999 18:23:55 +0200
Date:   Thu, 5 Aug 1999 18:23:55 +0200
From: Paul Slootman <paul@wau.mis.ah.nl>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: Carsten Paeth <calle@calle.in-berlin.de>,
        i4ldeveloper@listserv.isdn4linux.de,
        Kernel Mailing List <linux-kernel@vger.rutgers.edu>
Subject: ISDN and the feature freeze (was: no driver change for 2.4?)
Message-ID: <19990805182355.C28243@wau.mis.ah.nl>
Mail-Followup-To: Linus Torvalds <torvalds@transmeta.com>,
	Carsten Paeth <calle@calle.in-berlin.de>,
	i4ldeveloper@listserv.isdn4linux.de,
	Kernel Mailing List <linux-kernel@vger.rutgers.edu>
References: <19990805122357.A3718@calle.in-berlin.de> <Pine.LNX.4.10.9908050838260.1592-100000@penguin.transmeta.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.3i
In-Reply-To: <Pine.LNX.4.10.9908050838260.1592-100000@penguin.transmeta.com> from "Linus Torvalds" on 1999/08/05 08:45 -0700
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

On Thu 05 Aug 1999, Linus Torvalds wrote:
> On Thu, 5 Aug 1999, Carsten Paeth wrote:
> > 
> > I have a 2.3.12 running with the current isdn4linux cvs tree.
> > I will get crasy if my work again will not find the way into
> > the main stream kernel.
> > 
> > Why is it a problem to put this stuff into the kernel ?
> 
> I don't know why the ISDN people just do not ever GET IT.
> 
> I refuse to get huge patches every time two weeks before a feature freeze.
> How hard is that to understand?

Well, it's happened just once AFAIK, with the 2.2.0 release. It it also
happened with 2.0, apologies, I barely knew what ISDN was at that time.

> I will continue to ignore the ISDN CVS tree. If the ISDN people cannot get
> their act together and actually start sending their fixes to the standard
> kernel in a timely manner, I cannot be bothered with it. This has
> continued for something like five years now, and every time I explain it
> to people my explanation gets lost or ignored. 

As this has gone on for such a long time, at some point there isn't much
alternative to biting the bullet at some stage, and actually _having_ to
accept a major patch.  Way too much has been changed since the time
2.1 was branched off 2.0 (which is basically the state of the existing
ISDN code in 2.3.x as I understand it, if you ignore a couple of pretty
minor patches. Feel free to enlighten me if I got that wrong)>

> > What is the actual way to put changes into the actual kernel
> > for isdn4linux ?
> > What can I do to fix that problems ?
> > Should I sent a patch to 2.3.12 to you or someone else ?
> 
> It's not about sending "a patch".
> 
> It's about being a responsible programmer, and making sure I get MORE than
> just a patch every f*cing time I anounce a code freeze. I should have been
> getting patches for the last half year, and I have gotten ZERO. And I'm
> irritated at the ISDN peopl, because this is not the first time. In fact,
> I have never EVER gotten a single responsible ISDN developer that stands
> up and says "ok, I'll be the maintainer of this, and I'll make sure it
> gets fed to Linus in a timely manner".

OK. About biting the bullet: I've been slowly getting into the ISDN
development over the last year. I don't consider myself much of an
expert on the internals of the ISDN state machine etc, but I think I'm
competent enough to be able to generate patches that have a chance of
working.  Would you consider me as your sole contact with the ISDN
developers? If so, I'm afraid that we'll have to start off with you
accepting a megapatch at some stage (perhaps it's best to simply start
off with a completely new drivers/isdn tree).  Once that has been done,
I can take care of feeding you incremental patches whenever there's a
stable state in the CVS.

> You still wonder why ISDN is not there? Do you still wonder why I'm fed up
> with ISDN people who think they they can just force-feed me one huge patch

I'm with you there. However, you yourself mention ISDN in your message
<Pine.LNX.4.10.9908031348480.825-100000@penguin.transmeta.com>, and give
the impression that they (the ISDN people) have the chance to do just that
(as long as they don't "futz around").

> and completely avoid any QA in the meantime?

I have to disagree there. QA is *not* being completely avoided. In fact,
I think that the majority of people using ISDN in kernels later than
2.0.36 are using the CVS code. SuSE for example have it in their
standard kernel; the rest find out they need it when the existing code
simply doesn't work for them.  Hence IMHO the "CVS" code (or at least
certain snapshots of it) has been tested quite thoroughly. I use it at
work to control a dial-on-demand link to the internet, and offer
callback links from home to about 10 people. It's been up since I booted
2.2.9-ac4 + ISDN CVS code 59 days ago now, it's made 2674 calls with 302
hours of connect time since then.  I'd say it's pretty stable :-)

BTW, have you considered completely *removing* all the current ISDN
code?  IMHO that would be better than including the outdated stuff...

> WHY, oh why, is the ONLY time I ever hear from ISDN people when I have
> publically announced a code-freeze? Explain that,

My opinion is: All the core ISDN developers are german, and are perhaps
not that fluent in english.  That may be the reason why they're
hesistant to contact you directly; understandable, I have a mental block
to overcome whenever I have to write a german email, for example.
When you announce a code-freeze, urgency overcomes their hesitance.
Don't see this as an attempt to excuse it, however.  It should have been
avoided.  On the other hand, I hadn't quite expected the code-freeze for
a couple of months... (I haven't been able to keep up with linux-kernel
the last month, so apologies if you've reasoned your timing in some
thread elsewhere).


In conclusion, I understand your frustation at the situation (and thus
at the people involved). However, would you for this one time consider
accepting a jumbopatch (or a new drivers/isdn tree) to bootstrap a
period of hopefully happy cooperation?


Paul Slootman
-- 
home:   paul@wurtel.demon.nl http://www.wurtel.demon.nl/
debian: paul@debian.org   isdn4linux: paul@isdn4linux.de
work:   paul@murphy.nl    Murphy Software, Enschede,  NL

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Tue Aug 31 19:20:26 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id TAA25696
	for <tony@tesla.rcub.bg.ac.yu>; Tue, 31 Aug 1999 19:20:13 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id FAA02367
	for <tony@tesla.rcub.bg.ac.yu>; Mon, 9 Aug 1999 05:54:35 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:23137 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S42705AbPHIFy1>;
	Mon, 9 Aug 1999 08:54:27 +0300
Received:  by vger.rutgers.edu via listexpand id <S156891AbPHIFvW>;
	Mon, 9 Aug 1999 01:51:22 -0400
Received:  by vger.rutgers.edu id <S155174AbPHIFvL>;
	Mon, 9 Aug 1999 01:51:11 -0400
Received: from synflood.is.a.bofh.at.sick.cl ([206.49.221.5]:61652 "EHLO
        endor.sick.cl") by vger.rutgers.edu with ESMTP id <S154940AbPHIFvA>;
	Mon, 9 Aug 1999 01:51:00 -0400
Received: (from synflood@localhost)
	by endor.sick.cl (8.8.7/8.8.7) id BAA01726
	for linux-kernel@vger.rutgers.edu; Mon, 9 Aug 1999 01:50:52 -0400
Date:   Mon, 9 Aug 1999 01:50:52 -0400
From: Marcelo Bartsch AKA synFlood <synflood@endor.sick.cl>
To: linux-kernel@vger.rutgers.edu
Subject: Problems Compiling 2.2.10-ac12 on SparcStation4 (sun4m)
Message-ID: <19990809015052.A1587@endor.sick.cl>
Mail-Followup-To: linux-kernel@vger.rutgers.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.5i
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig

Hello!

i was trying to compile 2.2.10-ac12 under a sun4m box, and i'm getting the
next error... AFAIK -ac series are more i386 specific. but i think is worst
a comment about this problem..

compiling using:
make :  3.76.1,
gcc  :  gcc version egcs-2.90.29 980515 (egcs-1.0.3 release)

if you need more info,please letme know... sorry for my poor english...


make[3]: Entering directory `/var/compile/linux-ac/drivers/block'
gcc -D__KERNEL__ -I/var/compile/linux-ac/include -Wall -Wstrict-prototypes -O2
-fomit-frame-pointer  -m32 -pipe -mno-fpu -fcall-used-g5 -fcall-used-g7
-DEXPORT_SYMTAB -c xor.c
xor.c: In function `xor_block_SPARC':
xor.c:957: `dest' undeclared (first use this function)
xor.c:957: (Each undeclared identifier is reported only once
xor.c:957: for each function it appears in.)
xor.c:960: `source' undeclared (first use this function)
make[3]: *** [xor.o] Error 1
make[3]: Leaving directory `/var/compile/linux-ac/drivers/block'
make[2]: *** [first_rule] Error 2
make[2]: Leaving directory `/var/compile/linux-ac/drivers/block'
make[1]: *** [_subdir_block] Error 2
make[1]: Leaving directory `/var/compile/linux-ac/drivers'
make: *** [_dir_drivers] Error 2

there is the .config file used for this compilation:

#
# Automatically generated by make menuconfig: don't edit
#

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODVERSIONS=y
CONFIG_KMOD=y

#
# General setup
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
# CONFIG_AP1000 is not set
# CONFIG_SMP is not set
# CONFIG_SUN4 is not set
# CONFIG_PCI is not set

#
# Console drivers
#
CONFIG_PROM_CONSOLE=y
CONFIG_FB=y
CONFIG_DUMMY_CONSOLE=y
CONFIG_FB_SBUS=y
CONFIG_FB_CGSIX=y
CONFIG_FB_BWTWO=y
CONFIG_FB_CGTHREE=y
CONFIG_FB_TCX=y
CONFIG_FB_CGFOURTEEN=y
CONFIG_FB_LEO=y
# CONFIG_FB_VIRTUAL is not set
# CONFIG_FBCON_ADVANCED is not set
CONFIG_FBCON_MFB=y
CONFIG_FBCON_CFB8=y
CONFIG_FBCON_FONTWIDTH8_ONLY=y
CONFIG_FONT_SUN8x16=y
# CONFIG_FBCON_FONTS is not set
CONFIG_SBUS=y
CONFIG_SBUSCHAR=y
CONFIG_SUN_MOUSE=y
CONFIG_SERIAL=y
CONFIG_SUN_SERIAL=y
CONFIG_SERIAL_CONSOLE=y
CONFIG_SUN_KEYBOARD=y
CONFIG_SUN_CONSOLE=y
CONFIG_SUN_AUXIO=y
CONFIG_SUN_IO=y
CONFIG_SUN_OPENPROMIO=m
CONFIG_SUN_MOSTEK_RTC=y
# CONFIG_SUN_BPP is not set
# CONFIG_SUN_VIDEOPIX is not set
CONFIG_SUN_AURORA=m
CONFIG_SPARCAUDIO=m
CONFIG_SPARCAUDIO_AMD7930=m
CONFIG_SPARCAUDIO_CS4231=m
CONFIG_SPARCAUDIO_DBRI=m
CONFIG_SPARCAUDIO_DUMMY=m
CONFIG_SUN_OPENPROMFS=m
CONFIG_NET=y
CONFIG_SYSVIPC=y
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=m
CONFIG_BINFMT_JAVA=m

#
# Floppy, IDE, and other block devices
#
CONFIG_BLK_DEV_FD=y
CONFIG_BLK_DEV_MD=y
CONFIG_MD_LINEAR=m
CONFIG_MD_STRIPED=m
CONFIG_MD_MIRRORING=m
CONFIG_MD_RAID5=m
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_NBD=m

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_NETLINK=y
# CONFIG_RTNETLINK is not set
# CONFIG_NETLINK_DEV is not set
CONFIG_FIREWALL=y
CONFIG_FILTER=y
CONFIG_UNIX=y
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
# CONFIG_IP_PNP is not set
CONFIG_IP_FIREWALL=y
# CONFIG_IP_FIREWALL_NETLINK is not set
# CONFIG_IP_ALWAYS_DEFRAG is not set
# CONFIG_IP_ROUTER is not set
CONFIG_NET_IPIP=m
CONFIG_NET_IPGRE=m
CONFIG_IP_ALIAS=y
CONFIG_SYN_COOKIES=y
CONFIG_INET_RARP=m
CONFIG_SKB_LARGE=y
CONFIG_IPV6=m
# CONFIG_IPV6_EUI64 is not set
# CONFIG_IPV6_NETLINK is not set
CONFIG_IPX=m
# CONFIG_IPX_INTERN is not set
# CONFIG_SPX is not set
CONFIG_ATALK=m
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_BRIDGE is not set
# CONFIG_LLC is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_FASTROUTE is not set
# CONFIG_NET_HW_FLOWCONTROL is not set
# CONFIG_CPU_IS_SLOW is not set

#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set

#
# ISDN subsystem
#
# CONFIG_ISDN is not set

#
# SCSI support
#
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=y
CONFIG_CHR_DEV_ST=y
CONFIG_BLK_DEV_SR=y
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_CHR_DEV_SG=m
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y

#
# SCSI low-level drivers
#
CONFIG_SCSI_SUNESP=y
CONFIG_SCSI_QLOGICPTI=m

#
# Fibre Channel support
#
CONFIG_FC4=m
CONFIG_FC4_SOC=m
CONFIG_FC4_SOCAL=m
CONFIG_SCSI_PLUTO=m
CONFIG_SCSI_FCAL=m

#
# Network device support
#
CONFIG_NETDEVICES=y
CONFIG_DUMMY=m
CONFIG_PPP=m
CONFIG_SLIP=m
CONFIG_SLIP_COMPRESSED=y
CONFIG_SLIP_SMART=y
# CONFIG_SLIP_MODE_SLIP6 is not set
CONFIG_SUNLANCE=y
CONFIG_HAPPYMEAL=m
CONFIG_SUNBMAC=m
CONFIG_SUNQE=m
CONFIG_MYRI_SBUS=m

#
# Unix98 PTY support
#
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=256

#
# Filesystems
#
CONFIG_QUOTA=y
CONFIG_AUTOFS_FS=m
# CONFIG_ADFS_FS is not set
CONFIG_AFFS_FS=m
# CONFIG_HFS_FS is not set
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
# CONFIG_UMSDOS_FS is not set
CONFIG_VFAT_FS=m
CONFIG_ISO9660_FS=m
# CONFIG_JOLIET is not set
CONFIG_MINIX_FS=m
# CONFIG_NTFS_FS is not set
CONFIG_HPFS_FS=m
CONFIG_PROC_FS=y
CONFIG_DEVPTS_FS=y
# CONFIG_QNX4FS_FS is not set
CONFIG_ROMFS_FS=m
CONFIG_EXT2_FS=y
CONFIG_SYSV_FS=m
CONFIG_UFS_FS=m
CONFIG_UFS_FS_WRITE=y
# CONFIG_EFS_FS is not set

#
# Network File Systems
#
CONFIG_CODA_FS=m
CONFIG_NFS_FS=y
CONFIG_NFSD=m
CONFIG_NFSD_SUN=y
CONFIG_SUNRPC=y
CONFIG_LOCKD=y
CONFIG_SMB_FS=m
CONFIG_NCP_FS=m
# CONFIG_NCPFS_PACKET_SIGNING is not set
# CONFIG_NCPFS_IOCTL_LOCKING is not set
# CONFIG_NCPFS_STRONG is not set
# CONFIG_NCPFS_NFS_NS is not set
# CONFIG_NCPFS_OS2_NS is not set
# CONFIG_NCPFS_MOUNT_SUBDIR is not set
# CONFIG_NCPFS_NLS is not set
# CONFIG_NCPFS_EXTRAS is not set

#
# Partition Types
#
CONFIG_BSD_DISKLABEL=y
# CONFIG_MAC_PARTITION is not set
CONFIG_SMD_DISKLABEL=y
CONFIG_SOLARIS_X86_PARTITION=y
# CONFIG_UNIXWARE_DISKLABEL is not set
CONFIG_AMIGA_PARTITION=y
CONFIG_NLS=y

#
# Native Language Support
#
# CONFIG_NLS_CODEPAGE_437 is not set
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_1 is not set
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set

#
# Watchdog
#
CONFIG_SOFT_WATCHDOG=m

#
# Kernel hacking
#
CONFIG_MAGIC_SYSRQ=y

-- 

SynFl00d

email : synflood@endor.sick.cl
Efax Number : (815) 366-3177
ICQ : 6994327

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

From owner-linux-kernel-outgoing@vger.rutgers.edu  Tue Aug 31 19:20:13 1999
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
Received: from afrodita.rcub.bg.ac.yu (root@afrodita.rcub.bg.ac.yu [147.91.1.129])
	by Tesla.rcub.bg.ac.yu (8.9.3/8.9.3) with ESMTP id TAA25615
	for <tony@tesla.rcub.bg.ac.yu>; Tue, 31 Aug 1999 19:19:01 +0200
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by afrodita.rcub.bg.ac.yu (8.9.3/8.9.1) with ESMTP id QAA02160
	for <tony@tesla.rcub.bg.ac.yu>; Thu, 5 Aug 1999 16:45:30 GMT
Received: from vger.rutgers.edu ([128.6.190.2]:8763 "EHLO vger.rutgers.edu")
	by nic.funet.fi with ESMTP id <S42059AbPHEQIi>;
	Thu, 5 Aug 1999 19:08:38 +0300
Received:  by vger.rutgers.edu via listexpand id <S156368AbPHEQB4>;
	Thu, 5 Aug 1999 12:01:56 -0400
Received:  by vger.rutgers.edu id <S156340AbPHEP5B>;
	Thu, 5 Aug 1999 11:57:01 -0400
Received: from vanuata.dcs.gla.ac.uk ([130.209.240.50]:46252 "HELO
        vanuata.dcs.gla.ac.uk") by vger.rutgers.edu with SMTP
	id <S156302AbPHEPwr>; Thu, 5 Aug 1999 11:52:47 -0400
Received: from bathurst by vanuata with SMTP DCS (MMTA);
          Thu, 5 Aug 1999 16:52:03 +0100
Received: from localhost by bathurst;
          (5.65v3.2/1.1.8.2/19Apr96-0202PM)	id AA24462;
          Thu, 5 Aug 1999 16:51:58 +0100
Message-Id: <9908051551.AA24462@bathurst>
X-Mailer: exmh version 2.0.2 2/24/98
X-Exmh-Isig-Comptype: repl
X-Exmh-Isig-Folder: my-kit
To: "Stephen C. Tweedie" <sct@redhat.com>
To: Keith Owens <kaos@ocs.com.au>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Richard Black <rjb@dcs.gla.ac.uk>, linux-kernel@vger.rutgers.edu
Subject: Re: PROBLEM: 2.2.5 unstable on Dell PC, 2.0.36 is stable 
In-Followup-To: The message of Wed, 04 Aug 99 11:22:50 +0100.             
                <9908041022.AA25302@bathurst> 
Date:   Thu, 05 Aug 99 16:51:57 +0100
From: Richard Black <rjb@dcs.gla.ac.uk>
X-Mts:  smtp
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig


I think I may have managed to get a useful oops dump out of it on this
occasion; it looks like either a bug in the 3c59x driver, or a bug in
interrupt handling causing the networking code to be inappropriately
re-entered.

This is with my modified trap.c to print things sensibly and then I
add the screen-real-estate wasteing <[<[]> stuff after I type it in to
keep ksymoops happy.

I get the following:

easter:/grasp_tmp9/linux-2.2.10> ksymoops < ~/tmp/oops3.txt
ksymoops 0.7c on i686 2.2.10.  Options used
     -V (default)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.2.10/ (default)
     -m /usr/src/linux/System.map (default)

Warning: You did not tell me where to find symbol information.  I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc.  ksymoops -h explains the options.

No modules in ksyms, skipping objects
current->tss.cr3 = 00101000, %cr3 = 00101000
Oops: 0002
Stack:       [<00000000>] [<00000013>] [<c9b65004>] [<0000001f>]
Call Trace:  [<d08823ff>] [<c0109e1d>] [<c010e96e>] [<c0109f8f>]
[<c0107b08>] [<c017ae18>] [<c016546f>] [<c01146db>] [<c01658d6>]
[<c0176113>] [<c0160769>] [<c01190b5>] [<c0109fa6>] [<c0107b08>]
[<c0106251>] [<c0106000>] [<c0106000>] [<c01001b1>]
Code: f0 ff 49 70 0f 94 44 24 24 8b 5c 24 34 66 83 c3 1c 80 7c 24
Using defaults from ksymoops -t elf32-i386 -a i386

Trace; d08823ff <END_OF_CODE+105f979b/????>
Trace; c0109e1d <handle_IRQ_event+55/88>
Trace; c010e96e <do_level_ioapic_IRQ+62/a0>
Trace; c0109f8f <do_IRQ+3b/5c>
Trace; c0107b08 <ret_from_intr+0/20>
Trace; c017ae18 <fn_hash_lookup+8c/d4>
Trace; c016546f <ip_route_input_slow+15f/4c4>
Trace; c01146db <printk+17f/18c>
Trace; c01658d6 <ip_route_input+102/128>
Trace; c0176113 <arp_rcv+157/32c>
Trace; c0160769 <net_bh+191/1f4>
Trace; c01190b5 <do_bottom_half+81/a0>
Trace; c0109fa6 <do_IRQ+52/5c>
Trace; c0107b08 <ret_from_intr+0/20>
Trace; c0106251 <cpu_idle+41/54>
Trace; c0106000 <get_options+0/74>
Trace; c0106000 <get_options+0/74>
Trace; c01001b1 <L6+0/2>
Code;  00000000 Before first symbol
00000000 <_EIP>:
Code;  00000000 Before first symbol
   0:   f0 ff 49 70               lock decl 0x70(%ecx)
Code;  00000004 Before first symbol
   4:   0f 94 44 24 24            sete   0x24(%esp,1)
Code;  00000009 Before first symbol
   9:   8b 5c 24 34               movl   0x34(%esp,1),%ebx
Code;  0000000d Before first symbol
   d:   66 83 c3 1c               addw   $0x1c,%bx
Code;  00000011 Before first symbol
  11:   80 7c 24 00 00            cmpb   $0x0,0x0(%esp,1)

CPU: 0
EFLAGS: 00010202
Aieee, killing interrupt handler
Kernel panic: Attempted to kill the idle task!
In swapper task - not syncing

1 warning issued.  Results may not be reliable.



Now note that the very top level of the backtrace is in a module, and
that ksymoops can't cope with modules.  But I know from /proc/modules
that the only module loaded is 3c59x.o and sure enough that "code"
sequence occurs precisely once in 3c59x.o

So what I did was to tediously reverse engineer the make system so I
could rebuild just 3c59x.c without changing anything else except to
add -g (the make system likes to fiddle with various header files
every time it runs) with:

$ gcc -D__KERNEL__ -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer
-D__SMP__ -pipe -fno-strength-reduce -m486 -malign-loops=2
-malign-jumps=2 -malign-functions=2 -DCPU=686 -DMODULE -DMODVERSIONS
-include /export/grasp_tmp9/linux-2.2.10/include/linux/modversions.h
-I/export/grasp_tmp9/linux-2.2.10/include -g -c 3c59x.c

and then I use objdump --disassemble --source --line-numbers to look
at the source around the bit where the code sequence where the crash
is:

/export/grasp_tmp9/linux-2.2.10/drivers/net/3c59x.c:1634
    24d8:       8b 54 24 30             movl   0x30(%esp,1),%edx
    24dc:       f6 c6 01                testb  $0x1,%dh
    24df:       74 6f                   je     2550 <vortex_interrupt+0x398>
/export/grasp_tmp9/linux-2.2.10/drivers/net/3c59x.c:1635
    24e1:       8b 4c 24 34             movl   0x34(%esp,1),%ecx
    24e5:       83 c1 0c                addl   $0xc,%ecx
/export/grasp_tmp9/linux-2.2.10/include/asm/io.h:81
#define RETURN_TYPE unsigned char
__IN(b,"")
#undef RETURN_TYPE
#define RETURN_TYPE unsigned short
__IN(w,"")
    24e8:       89 ca                   movl   %ecx,%edx
    24ea:       66 ed                   inw    (%dx),%ax
/export/grasp_tmp9/linux-2.2.10/drivers/net/3c59x.c:1635
    24ec:       f6 c4 10                testb  $0x10,%ah
    24ef:       74 5f                   je     2550 <vortex_interrupt+0x398>
/export/grasp_tmp9/linux-2.2.10/include/asm/io.h:88
__IN(l,"")
#undef RETURN_TYPE

__OUT(b,"b",char)
__OUT(w,"w",short)
    24f1:       b8 00 10 00 00          movl   $0x1000,%eax
    24f6:       66 ef                   outw   %ax,(%dx)
/export/grasp_tmp9/linux-2.2.10/include/linux/skbuff.h:175
        return (list->next == (struct sk_buff *) list);
}

extern __inline__ void kfree_skb(struct sk_buff *skb)
{
    24f8:       8b 54 24 38             movl   0x38(%esp,1),%edx
    24fc:       8b 8a 34 04 00 00       movl   0x434(%edx),%ecx
/export/grasp_tmp9/linux-2.2.10/include/asm/atomic.h:69
static __inline__ int atomic_dec_and_test(volatile atomic_t *v)
{
        unsigned char c;

        __asm__ __volatile__(
    2502:       f0 ff 49 70             lock decl 0x70(%ecx)
    2506:       0f 94 44 24 24          sete   0x24(%esp,1)
/export/grasp_tmp9/linux-2.2.10/include/linux/skbuff.h:176
}

extern __inline__ void kfree_skb(struct sk_buff *skb)
{
        if (atomic_dec_and_test(&skb->users))
    250b:       8b 5c 24 34             movl   0x34(%esp,1),%ebx
    250f:       66 83 c3 1c             addw   $0x1c,%bx
    2513:       80 7c 24 24 00          cmpb   $0x0,0x24(%esp,1)


So it looks to me like 3c59x line 1637 did a DEV_FREE_SKB on a NULL
tx_skb causing a crash in the locked "users" decrement.


Is this detailed enough for you to look into?

Richard.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------------
 Please visit our web site      http://www.bg.ac.yu/ 
 or one of our mirror sites     http://ubg-mirror.iccs.ntua.gr/ 
                                http://www.blueprintit.com/ubg-mirror/ 

