Re: IRQ 255?

owner-linux-kernel-digest-outgoing@vger.rutgers.edu
Wed, 28 Jan 98 19:23:26 -0700


***** UNDELIVERABLE MAIL sent to andy, being returned by maxwell!andy *****
mail: Error # 8 'Invalid recipient' encountered on system maxwell

Received: from entropy.muc.muohio.edu by maxwell.la.asu.edu via SMTP (920330.SGI/920502.SGI)
for andy id AA00256; Wed, 28 Jan 98 19:23:19 -0700
Received: from vger.rutgers.edu (root@vger.rutgers.edu [128.6.190.2])
by entropy.muc.muohio.edu (8.8.7/8.8.7) with ESMTP id UAA25694;
Wed, 28 Jan 1998 20:50:49 -0500
Received: by vger.rutgers.edu id <971482-232>; Wed, 28 Jan 1998 20:13:41 -0500
From: owner-linux-kernel-digest@vger.rutgers.edu
To: linux-kernel-digest@vger.rutgers.edu
Subject: linux-kernel-digest V1 #1539
Reply-To: linux-kernel@vger.rutgers.edu
Errors-To: owner-linux-kernel-digest@vger.rutgers.edu
Precedence: bulk
Message-Id: <19980129014840Z971482-232+1190@vger.rutgers.edu>
Date: Wed, 28 Jan 1998 20:13:41 -0500

linux-kernel-digest Wednesday, 28 January 1998 Volume 01 : Number 1539

In this issue:

Patch: 2.1.82 IP_MASQ no modules patch
Re: Performance dropout in recent 2.1.x kernels
Re: OFFTOPIC: Linux Penguin hawking Apple Quicktime?!?
Re: OFFTOPIC: GGI and alternative GUIs and windowing systems in Linux
Network performance in 2.1.82 (cont)
Re: Packet Scheduling
2.1.82
Re: Kernel treads vs. kernel processes
Re: Packet Scheduling
Re: token ring driver lacks byte counts
Re: Suspend broken on a thinkpad
Re: OFFTOPIC: Linux Penguin hawking Apple Quicktime?!?
Re: Network performance in 2.1.82 (cont)
Re: SUMMARY: pcmcia-cs-2.9.12 +glibc
Re: Request for help with cdrecord and HP7100
Re: IRQ 255?
Re: Suspend broken on a thinkpad
Re: IP tunnel not working...
Re: 2.1.82 - umsdos broken & will stay that way :-(
Re: Contiguous files and I/O buffered
Re: Where has all the printing gone???
Re: 2.1.82 boot failure
Re: Contiguous files and I/O buffered
Re: OFFTOPIC: Linux Penguin hawking Apple Quicktime?!?
Re: 2.1.82: still freezing
Re: ext2 corruption in 2.0.33
Re: Where has all the printing gone???
[patch for fs/buffer.c] Re: 2.1.82
Extra per-inode data
Re: pcmcia-cs-2.9.12 +glibc
Re: Suspend broken on a thinkpad
Re: Packet Scheduling
Re: warning: `cpu_data' redefined
Re: PCI probing problem
Re: IRQ 255?

See the end of the digest for information on subscribing to the linux-kernel
or linux-kernel-digest mailing lists.

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

From: Adam Heath <adam@brainiac.egr.msu.edu>
Date: Wed, 28 Jan 1998 13:55:42 -0500 (EST)
Subject: Patch: 2.1.82 IP_MASQ no modules patch

This patch allows the ip_masq helper apps to be compiled directly into the
kernel, no longer needing to be modules. Support is there for adding
non-standard ports for each app on the kernel command line. Read the
Configure.help text to find out.

Here is a line I use in lilo for testing this feature.
append="reboot=warm \
ip_masq=+quake,1001 \
ip_masq=+ftp,1002 \
ip_masq=+vdolive,1003 \
ip_masq=+raudio,1004 \
ip_masq=+cuseeme,1005 \
ip_masq=+irc,1006 \
"
This says to add the mentioned ports to the ones already defined for the
app. If the plus wasn't there, then the mentioned port[s] would replace
the ones already defined.

diff -ruN 2.1.82-pure/Documentation/Configure.help 2.1.82/Documentation/Configure.help
- --- 2.1.82-pure/Documentation/Configure.help Wed Jan 28 13:26:29 1998
+++ 2.1.82/Documentation/Configure.help Wed Jan 28 13:01:42 1998
@@ -1630,6 +1630,54 @@
tracert program.
If you want this, say Y.

+IP: masquerading
+CONFIG_IP_MASQUERADE_FTP
+ This enables support for masquerading FTP connections. If compiled
+ as a module, then ports are specified with insmod as "ports=port,
+ port,...". Otherwise, they are specified on the kernel command
+ line, as "ip_masq=[+]ftp,port,port,..." If "+" is given, then
+ "port,port,..." is added to current list of ports.
+
+IP: masquerading
+CONFIG_IP_MASQUERADE_IRC
+ This enables support for masquerading IRC connections. If compiled
+ as a module, then ports are specified with insmod as "ports=port,
+ port,...". Otherwise, they are specified on the kernel command
+ line, as "ip_masq=[+]irc,port,port,..." If "+" is given, then
+ "port,port,..." is added to current list of ports.
+
+IP: masquerading
+CONFIG_IP_MASQUERADE_QUAKE
+ This enables support for masquerading Quake connections. If compiled
+ as a module, then ports are specified with insmod as "ports=port,
+ port,...". Otherwise, they are specified on the kernel command
+ line, as "ip_masq=[+]quake,port,port,..." If "+" is given, then
+ "port,port,..." is added to current list of ports.
+
+IP: masquerading
+CONFIG_IP_MASQUERADE_VDOLIVE
+ This enables support for masquerading VDOLIVE connections. If compiled
+ as a module, then ports are specified with insmod as "ports=port,
+ port,...". Otherwise, they are specified on the kernel command
+ line, as "ip_masq=[+]vdolive,port,port,..." If "+" is given, then
+ "port,port,..." is added to current list of ports.
+
+IP: masquerading
+CONFIG_IP_MASQUERADE_RAUDIO
+ This enables support for masquerading RAUDIO connections. If compiled
+ as a module, then ports are specified with insmod as "ports=port,
+ port,...". Otherwise, they are specified on the kernel command
+ line, as "ip_masq=[+]raudio,port,port,..." If "+" is given, then
+ "port,port,..." is added to current list of ports.
+
+IP: masquerading
+CONFIG_IP_MASQUERADE_CUSEEME
+ This enables support for masquerading CUSEEME connections. If compiled
+ as a module, then ports are specified with insmod as "ports=port,
+ port,...". Otherwise, they are specified on the kernel command
+ line, as "ip_masq=[+]cuseeme,port,port,..." If "+" is given, then
+ "port,port,..." is added to current list of ports.
+
IP: ipautofw masquerade support
CONFIG_IP_MASQUERADE_IPAUTOFW (Experimental)
ipautofw is a program by Richard Lynch allowing additional support
diff -ruN 2.1.82-pure/include/net/ip_masq_app.h 2.1.82/include/net/ip_masq_app.h
- --- 2.1.82-pure/include/net/ip_masq_app.h Wed Dec 31 19:00:00 1969
+++ 2.1.82/include/net/ip_masq_app.h Wed Jan 28 11:09:32 1998
@@ -0,0 +1,10 @@
+#ifndef _IP_MASQ_APP_H
+#define _IP_MASQ_APP_H
+
+struct ip_masq_app_setup {
+ const char * appname;
+ int * array;
+ int (*init) (void);
+};
+
+#endif _IP_MASQ_APP_H_
diff -ruN 2.1.82-pure/include/net/ip_masq_apphelp.h 2.1.82/include/net/ip_masq_apphelp.h
- --- 2.1.82-pure/include/net/ip_masq_apphelp.h Wed Dec 31 19:00:00 1969
+++ 2.1.82/include/net/ip_masq_apphelp.h Wed Jan 28 11:56:06 1998
@@ -0,0 +1,58 @@
+#ifdef MODULE
+ EXPORT_NO_SYMBOLS;
+ #define IPM_INIT_MODULE_HEADER(name) int init_module(void)
+ #define IPM_INIT_MODULE_RET return j ? -EIO : 0
+ #define IPM_END_MODULE_HEADER(name) void cleanup_module(void)
+ #define IPM_END_MODULE_RET \
+ if (k) IP_MASQ_DEBUG(1-debug, "text: can't remove module");
+#else
+ #define IPM_INIT_MODULE_HEADER(name) __initfunc(int ip_masq_ ## name ## _init(void))
+ #define IPM_INIT_MODULE_RET return j
+ #define IPM_END_MODULE_HEADER(name) int ip_masq_ ## name ## _done(void)
+ #define IPM_END_MODULE_RET return k;
+#endif
+
+#define IPM_INIT_MODULE(name,proto,text) \
+IPM_INIT_MODULE_HEADER(name)\
+{\
+ int i, j=0;\
+ for (i=0; (i<MAX_MASQ_APP_PORTS); i++) {\
+ if (PORTS[i]) {\
+ if ((INCARNATIONS[i] = kmalloc(sizeof(struct ip_masq_app),\
+ GFP_KERNEL)) == NULL) {\
+ j = -ENOMEM;\
+ break;\
+ }\
+ memcpy(INCARNATIONS[i], &ip_masq_ ## name, sizeof(struct ip_masq_app));\
+ if ((j = register_ip_masq_app(INCARNATIONS[i],\
+ proto,\
+ PORTS[i])))\
+ break;\
+ IP_MASQ_DEBUG(1-debug, "text: loaded support on port[%d] = %d\n",\
+ i, PORTS[i]);\
+ } else {\
+ /* To be safe, force the incarnation table entry to NULL */\
+ INCARNATIONS[i] = NULL;\
+ }\
+ }\
+ IPM_INIT_MODULE_RET;\
+}
+#define IPM_END_MODULE(name,text) \
+IPM_END_MODULE_HEADER(name)\
+{\
+ int i, j, k;\
+ k=0;\
+ for (i=0; (i<MAX_MASQ_APP_PORTS); i++) {\
+ if (INCARNATIONS[i]) {\
+ if ((j = unregister_ip_masq_app(INCARNATIONS[i]))) {\
+ k = j;\
+ } else {\
+ kfree(INCARNATIONS[i]);\
+ INCARNATIONS[i] = NULL;\
+ IP_MASQ_DEBUG(1-debug, "Ftp: unloaded support on port[%d] = %d\n",\
+ i, PORTS[i]);\
+ }\
+ }\
+ }\
+ IPM_END_MODULE_RET;\
+}
diff -ruN 2.1.82-pure/init/main.c 2.1.82/init/main.c
- --- 2.1.82-pure/init/main.c Wed Jan 28 13:26:33 1998
+++ 2.1.82/init/main.c Tue Jan 27 20:00:52 1998
@@ -277,7 +277,9 @@
#ifdef CONFIG_FTAPE
extern void ftape_setup(char *str, int *ints);
#endif
- -
+#ifdef CONFIG_IP_MASQUERADE
+extern void ip_masq_app_setup(char *str, int *ints);
+#endif
#if defined(CONFIG_SYSVIPC) || defined(CONFIG_KERNELD)
extern void ipc_init(void);
#endif
@@ -492,6 +494,9 @@
#endif
#ifdef CONFIG_INET
{ "ether=", eth_setup },
+#endif
+#ifdef CONFIG_IP_MASQUERADE
+ { "ip_masq=", ip_masq_app_setup },
#endif
#ifdef CONFIG_ARCNET_COM20020
{ "com20020=", com20020_setup },
diff -ruN 2.1.82-pure/net/ipv4/Config.in 2.1.82/net/ipv4/Config.in
- --- 2.1.82-pure/net/ipv4/Config.in Thu Jan 15 17:33:07 1998
+++ 2.1.82/net/ipv4/Config.in Tue Jan 27 20:00:52 1998
@@ -39,9 +39,13 @@
bool 'IP: accounting' CONFIG_IP_ACCT
bool 'IP: masquerading' CONFIG_IP_MASQUERADE
if [ "$CONFIG_IP_MASQUERADE" != "n" ]; then
- - comment 'Protocol-specific masquerading support will be built as modules.'
+ dep_tristate 'IP_MASQ: FTP protocol support' CONFIG_IP_MASQUERADE_FTP $CONFIG_IP_MASQUERADE
+ dep_tristate 'IP_MASQ: Internet Relay Chat protocol support' CONFIG_IP_MASQUERADE_IRC $CONFIG_IP_MASQUERADE
+ dep_tristate 'IP_MASQ: Real Audio protocol support' CONFIG_IP_MASQUERADE_RAUDIO $CONFIG_IP_MASQUERADE
+ dep_tristate 'IP_MASQ: CuSeeMe protocol support' CONFIG_IP_MASQUERADE_CUSEEME $CONFIG_IP_MASQUERADE
+ dep_tristate 'IP_MASQ: VdoLive protocol support' CONFIG_IP_MASQUERADE_VDOLIVE $CONFIG_IP_MASQUERADE
+ dep_tristate 'IP_MASQ: Quake protocol support' CONFIG_IP_MASQUERADE_QUAKE $CONFIG_IP_MASQUERADE
bool 'IP: ICMP masquerading' CONFIG_IP_MASQUERADE_ICMP
- - comment 'Protocol-specific masquerading support will be built as modules.'
if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
tristate 'IP: ipautofw masq support (EXPERIMENTAL)' CONFIG_IP_MASQUERADE_IPAUTOFW
tristate 'IP: ipportfw masq support (EXPERIMENTAL)' CONFIG_IP_MASQUERADE_IPPORTFW
diff -ruN 2.1.82-pure/net/ipv4/Makefile 2.1.82/net/ipv4/Makefile
- --- 2.1.82-pure/net/ipv4/Makefile Wed Dec 10 12:45:16 1997
+++ 2.1.82/net/ipv4/Makefile Wed Jan 28 11:38:35 1998
@@ -56,7 +56,55 @@
endif

ifeq ($(CONFIG_IP_MASQUERADE),y)
- -IPV4X_OBJS += ip_masq.o ip_masq_mod.o ip_masq_app.o
+
+ IPV4X_OBJS += ip_masq.o ip_masq_mod.o ip_masq_app.o
+ ifeq ($(CONFIG_IP_MASQUERADE_FTP),y)
+ IPV4X_OBJS += ip_masq_ftp.o
+ else
+ ifeq ($(CONFIG_IP_MASQUERADE_FTP),m)
+ M_OBJS += ip_masq_ftp.o
+ endif
+ endif
+
+ ifeq ($(CONFIG_IP_MASQUERADE_IRC),y)
+ IPV4X_OBJS += ip_masq_irc.o
+ else
+ ifeq ($(CONFIG_IP_MASQUERADE_IRC),m)
+ M_OBJS += ip_masq_irc.o
+ endif
+ endif
+
+ ifeq ($(CONFIG_IP_MASQUERADE_RAUDIO),y)
+ IPV4X_OBJS += ip_masq_raudio.o
+ else
+ ifeq ($(CONFIG_IP_MASQUERADE_RAUDIO),m)
+ M_OBJS += ip_masq_raudio.o
+ endif
+ endif
+
+ ifeq ($(CONFIG_IP_MASQUERADE_CUSEEME),y)
+ IPV4X_OBJS += ip_masq_cuseeme.o
+ else
+ ifeq ($(CONFIG_IP_MASQUERADE_CUSEEME),m)
+ M_OBJS += ip_masq_cuseeme.o
+ endif
+ endif
+
+ ifeq ($(CONFIG_IP_MASQUERADE_VDOLIVE),y)
+ IPV4X_OBJS += ip_masq_vdolive.o
+ else
+ ifeq ($(CONFIG_IP_MASQUERADE_VDOLIVE),m)
+ M_OBJS += ip_masq_vdolive.o
+ endif
+ endif
+
+ ifeq ($(CONFIG_IP_MASQUERADE_QUAKE),y)
+ IPV4X_OBJS += ip_masq_quake.o
+ else
+ ifeq ($(CONFIG_IP_MASQUERADE_QUAKE),m)
+ M_OBJS += ip_masq_quake.o
+ endif
+ endif

ifeq ($(CONFIG_IP_MASQUERADE_IPAUTOFW),y)
IPV4_OBJS += ip_masq_autofw.o
@@ -74,8 +122,6 @@
endif
endif

- -M_OBJS += ip_masq_ftp.o ip_masq_irc.o ip_masq_raudio.o ip_masq_quake.o
- -M_OBJS += ip_masq_vdolive.o ip_masq_cuseeme.o
endif

ifeq ($(CONFIG_SYN_COOKIES),y)
diff -ruN 2.1.82-pure/net/ipv4/ip_masq_app.c 2.1.82/net/ipv4/ip_masq_app.c
- --- 2.1.82-pure/net/ipv4/ip_masq_app.c Wed Dec 10 12:45:16 1997
+++ 2.1.82/net/ipv4/ip_masq_app.c Tue Jan 27 20:00:52 1998
@@ -31,6 +31,7 @@
#include <linux/in.h>
#include <linux/ip.h>
#include <linux/init.h>
+#include <linux/ctype.h>
#include <net/protocol.h>
#include <net/tcp.h>
#include <net/udp.h>
@@ -38,6 +39,7 @@
#include <linux/stat.h>
#include <linux/proc_fs.h>
#include <net/ip_masq.h>
+#include <net/ip_masq_app.h>

#define IP_MASQ_APP_TAB_SIZE 16 /* must be power of 2 */

@@ -57,6 +59,69 @@

struct ip_masq_app *ip_masq_app_base[IP_MASQ_APP_TAB_SIZE];

+#ifdef CONFIG_IP_MASQUERADE_FTP
+ extern int ip_masq_ftp_ports[MAX_MASQ_APP_PORTS];
+ extern int ip_masq_ftp_init(void);
+#endif
+#ifdef CONFIG_IP_MASQUERADE_IRC
+ extern int ip_masq_irc_ports[MAX_MASQ_APP_PORTS];
+ extern int ip_masq_irc_init(void);
+#endif
+#ifdef CONFIG_IP_MASQUERADE_QUAKE
+ extern int ip_masq_quake_ports[MAX_MASQ_APP_PORTS];
+ extern int ip_masq_quake_init(void);
+#endif
+#ifdef CONFIG_IP_MASQUERADE_CUSEEME
+ extern int ip_masq_cuseeme_ports[MAX_MASQ_APP_PORTS];
+ extern int ip_masq_cuseeme_init(void);
+#endif
+#ifdef CONFIG_IP_MASQUERADE_VDOLIVE
+ extern int ip_masq_vdolive_ports[MAX_MASQ_APP_PORTS];
+ extern int ip_masq_vdolive_init(void);
+#endif
+#ifdef CONFIG_IP_MASQUERADE_RAUDIO
+ extern int ip_masq_raudio_ports[MAX_MASQ_APP_PORTS];
+ extern int ip_masq_raudio_init(void);
+#endif
+
+struct ip_masq_app_setup ip_masq_app_info[] = {
+
+#ifdef CONFIG_IP_MASQUERADE_FTP
+ { "ftp", ip_masq_ftp_ports,
+ ip_masq_ftp_init,
+ },
+#endif
+#ifdef CONFIG_IP_MASQUERADE_IRC
+ { "irc", ip_masq_irc_ports,
+ ip_masq_irc_init,
+ },
+#endif
+#ifdef CONFIG_IP_MASQUERADE_QUAKE
+ { "quake", ip_masq_quake_ports,
+ ip_masq_quake_init,
+ },
+#endif
+#ifdef CONFIG_IP_MASQUERADE_CUSEEME
+ { "cuseeme", ip_masq_cuseeme_ports,
+ ip_masq_cuseeme_init,
+ },
+#endif
+#ifdef CONFIG_IP_MASQUERADE_RAUDIO
+ { "raudio", ip_masq_raudio_ports,
+ ip_masq_raudio_init,
+ },
+#endif
+#ifdef CONFIG_IP_MASQUERADE_VDOLIVE
+ { "vdolive", ip_masq_vdolive_ports,
+ ip_masq_vdolive_init,
+},
+#endif
+
+ { NULL, NULL, NULL }
+};
+
+
+
/*
* ip_masq_app registration routine
* port: host byte order.
@@ -487,6 +552,9 @@

__initfunc(int ip_masq_app_init(void))
{
+ int p;
+ for (p=0;ip_masq_app_info[p].init;p++)
+ ip_masq_app_info[p].init();
#ifdef CONFIG_PROC_FS
proc_net_register(&proc_net_ip_masq_app);
#endif
@@ -602,3 +670,39 @@
}
return n_skb;
}
+
+
+#ifndef MODULE /* MODULE */
+void ip_masq_app_setup(char *str, int *ints)
+{
+ int p=0,i=0;
+ char *app=str,*sptr=NULL;
+
+ if((sptr=strchr(str,',')))
+ *sptr='\0',str=sptr+1;
+
+ if(!strncmp(app,"+",1))
+ app++,i=1;
+
+ for(p=0;ip_masq_app_info[p].appname;p++)
+ if(!strcmp(app,ip_masq_app_info[p].appname)){
+ char *cur;
+ int *pts=NULL;
+
+ pts=ip_masq_app_info[p].array;
+ if(i) for(i=0;pts[i];i++);
+
+ cur=str;
+ while (cur && isdigit(*cur) && i <= MAX_MASQ_APP_PORTS) {
+ pts[i++]=simple_strtoul(cur,NULL,0);
+ if ((cur = strchr(cur,',')) != NULL) cur++;
+ }
+ while (i <= MAX_MASQ_APP_PORTS)
+ pts[i++]=0;
+
+ break;
+ }
+ return;
+}
+
+#endif /* MODULE */
diff -ruN 2.1.82-pure/net/ipv4/ip_masq_cuseeme.c 2.1.82/net/ipv4/ip_masq_cuseeme.c
- --- 2.1.82-pure/net/ipv4/ip_masq_cuseeme.c Wed Dec 10 12:45:16 1997
+++ 2.1.82/net/ipv4/ip_masq_cuseeme.c Wed Jan 28 11:57:21 1998
@@ -49,6 +49,7 @@
#include <linux/init.h>
#include <net/protocol.h>
#include <net/udp.h>
+#include <net/ip_masq_apphelp.h>

/* #define IP_MASQ_NDEBUG */
#include <net/ip_masq.h>
@@ -88,15 +89,22 @@
* List of ports (up to MAX_MASQ_APP_PORTS) to be handled by helper
* First port is set to the default port.
*/
- -static int ports[MAX_MASQ_APP_PORTS] = {7648}; /* I rely on the trailing items being set to zero */
- -struct ip_masq_app *masq_incarnations[MAX_MASQ_APP_PORTS];
+#ifdef MODULE
+ #define PORTS ports
+ #define INCARNATIONS incarnations
+#else
+ #define PORTS ip_masq_cuseeme_ports
+ #define INCARNATIONS ip_masq_cuseeme_incarnations
+#endif
+int PORTS[MAX_MASQ_APP_PORTS]={7648}; /* I rely on the trailing items being set to zero */
+struct ip_masq_app *INCARNATIONS[MAX_MASQ_APP_PORTS];

/*
* Debug level
*/
static int debug=0;

- -MODULE_PARM(ports, "1-" __MODULE_STRING(MAX_MASQ_APP_PORTS) "i");
+MODULE_PARM(PORTS, "1-" __MODULE_STRING(MAX_MASQ_APP_PORTS) "i");
MODULE_PARM(debug, "i");

static int
@@ -188,74 +196,5 @@
};


- -/*
- - * ip_masq_cuseeme initialization
- - */
- -
- -__initfunc(int ip_masq_cuseeme_init(void))
- -{
- - int i, j;
- -
- - for (i=0; (i<MAX_MASQ_APP_PORTS); i++) {
- - if (ports[i]) {
- - if ((masq_incarnations[i] = kmalloc(sizeof(struct ip_masq_app),
- - GFP_KERNEL)) == NULL)
- - return -ENOMEM;
- - memcpy(masq_incarnations[i], &ip_masq_cuseeme, sizeof(struct ip_masq_app));
- - if ((j = register_ip_masq_app(masq_incarnations[i],
- - IPPROTO_UDP,
- - ports[i]))) {
- - return j;
- - }
- -#if DEBUG_CONFIG_IP_MASQ_CUSEEME
- - IP_MASQ_DEBUG(1-debug, "CuSeeMe: loaded support on port[%d] = %d\n",
- - i, ports[i]);
- -#endif
- - } else {
- - /* To be safe, force the incarnation table entry to NULL */
- - masq_incarnations[i] = NULL;
- - }
- - }
- - return 0;
- -}
- -
- -/*
- - * ip_masq_cuseeme fin.
- - */
- -
- -int ip_masq_cuseeme_done(void)
- -{
- - int i, j, k;
- -
- - k=0;
- - for (i=0; (i<MAX_MASQ_APP_PORTS); i++) {
- - if (masq_incarnations[i]) {
- - if ((j = unregister_ip_masq_app(masq_incarnations[i]))) {
- - k = j;
- - } else {
- - kfree(masq_incarnations[i]);
- - masq_incarnations[i] = NULL;
- - IP_MASQ_DEBUG(1-debug, "CuSeeMe: unloaded support on port[%d] = %d\n", i, ports[i]);
- - }
- - }
- - }
- - return k;
- -}
- -
- -#ifdef MODULE
- -EXPORT_NO_SYMBOLS;
- -
- -int init_module(void)
- -{
- - if (ip_masq_cuseeme_init() != 0)
- - return -EIO;
- - return 0;
- -}
- -
- -void cleanup_module(void)
- -{
- - if (ip_masq_cuseeme_done() != 0)
- - IP_MASQ_DEBUG(1-debug, "ip_masq_cuseeme: can't remove module");
- -}
- -
- -#endif /* MODULE */
+IPM_INIT_MODULE(cuseeme,IPPROTO_UDP,CuSeeMe);
+IPM_END_MODULE(cuseeme,ip_masq_cuseeme);
diff -ruN 2.1.82-pure/net/ipv4/ip_masq_ftp.c 2.1.82/net/ipv4/ip_masq_ftp.c
- --- 2.1.82-pure/net/ipv4/ip_masq_ftp.c Wed Dec 10 12:45:16 1997
+++ 2.1.82/net/ipv4/ip_masq_ftp.c Wed Jan 28 11:57:01 1998
@@ -48,6 +48,7 @@
#include <linux/init.h>
#include <net/protocol.h>
#include <net/tcp.h>
+#include <net/ip_masq_apphelp.h>

/* #define IP_MASQ_NDEBUG */
#include <net/ip_masq.h>
@@ -57,15 +58,22 @@
* List of ports (up to MAX_MASQ_APP_PORTS) to be handled by helper
* First port is set to the default port.
*/
- -static int ports[MAX_MASQ_APP_PORTS] = {21}; /* I rely on the trailing items being set to zero */
- -struct ip_masq_app *masq_incarnations[MAX_MASQ_APP_PORTS];
+#ifdef MODULE
+ #define PORTS ports
+ #define INCARNATIONS incarnations
+#else
+ #define PORTS ip_masq_ftp_ports
+ #define INCARNATIONS ip_masq_ftp_incarnations
+#endif
+int PORTS[MAX_MASQ_APP_PORTS]={21}; /* I rely on the trailing items being set to zero */
+struct ip_masq_app *INCARNATIONS[MAX_MASQ_APP_PORTS];

/*
* Debug level
*/
static int debug=0;

- -MODULE_PARM(ports, "1-" __MODULE_STRING(MAX_MASQ_APP_PORTS) "i");
+MODULE_PARM(PORTS, "1-" __MODULE_STRING(MAX_MASQ_APP_PORTS) "i");
MODULE_PARM(debug, "i");

/* Dummy variable */
@@ -319,73 +327,6 @@
masq_ftp_in, /* pkt_in */
};

- -/*
- - * ip_masq_ftp initialization
- - */
- -
- -__initfunc(int ip_masq_ftp_init(void))
- -{
- - int i, j;
- -
- - for (i=0; (i<MAX_MASQ_APP_PORTS); i++) {
- - if (ports[i]) {
- - if ((masq_incarnations[i] = kmalloc(sizeof(struct ip_masq_app),
- - GFP_KERNEL)) == NULL)
- - return -ENOMEM;
- - memcpy(masq_incarnations[i], &ip_masq_ftp, sizeof(struct ip_masq_app));
- - if ((j = register_ip_masq_app(masq_incarnations[i],
- - IPPROTO_TCP,
- - ports[i]))) {
- - return j;
- - }
- - IP_MASQ_DEBUG(1-debug, "Ftp: loaded support on port[%d] = %d\n",
- - i, ports[i]);
- - } else {
- - /* To be safe, force the incarnation table entry to NULL */
- - masq_incarnations[i] = NULL;
- - }
- - }
- - return 0;
- -}
- -
- -/*
- - * ip_masq_ftp fin.
- - */
- -
- -int ip_masq_ftp_done(void)
- -{
- - int i, j, k;
- -
- - k=0;
- - for (i=0; (i<MAX_MASQ_APP_PORTS); i++) {
- - if (masq_incarnations[i]) {
- - if ((j = unregister_ip_masq_app(masq_incarnations[i]))) {
- - k = j;
- - } else {
- - kfree(masq_incarnations[i]);
- - masq_incarnations[i] = NULL;
- - IP_MASQ_DEBUG(1-debug, "Ftp: unloaded support on port[%d] = %d\n",
- - i, ports[i]);
- - }
- - }
- - }
- - return k;
- -}
- -
- -#ifdef MODULE
- -EXPORT_NO_SYMBOLS;
- -
- -int init_module(void)
- -{
- - if (ip_masq_ftp_init() != 0)
- - return -EIO;
- - return 0;
- -}
- -
- -void cleanup_module(void)
- -{
- - if (ip_masq_ftp_done() != 0)
- - printk(KERN_INFO "ip_masq_ftp: can't remove module");
- -}

- -#endif /* MODULE */
+IPM_INIT_MODULE(ftp,IPPROTO_TCP,File Transfer Protocol);
+IPM_END_MODULE(ftp,ip_masq_ftp);
diff -ruN 2.1.82-pure/net/ipv4/ip_masq_irc.c 2.1.82/net/ipv4/ip_masq_irc.c
- --- 2.1.82-pure/net/ipv4/ip_masq_irc.c Wed Dec 10 12:45:16 1997
+++ 2.1.82/net/ipv4/ip_masq_irc.c Wed Jan 28 11:58:05 1998
@@ -53,20 +53,30 @@
#include <net/protocol.h>
#include <net/tcp.h>
#include <net/ip_masq.h>
+#include <net/ip_masq_apphelp.h>


/*
* List of ports (up to MAX_MASQ_APP_PORTS) to be handled by helper
* First port is set to the default port.
*/
- -int ports[MAX_MASQ_APP_PORTS] = {6667}; /* I rely on the trailing items being set to zero */
- -struct ip_masq_app *masq_incarnations[MAX_MASQ_APP_PORTS];
+#ifdef MODULE
+ #define PORTS ports
+ #define INCARNATIONS incarnations
+#else
+ #define PORTS ip_masq_irc_ports
+ #define INCARNATIONS ip_masq_irc_incarnations
+#endif
+int PORTS[MAX_MASQ_APP_PORTS]={6667}; /* I rely on the trailing items being set to zero */
+struct ip_masq_app *INCARNATIONS[MAX_MASQ_APP_PORTS];
+
+
/*
* Debug level
*/
static int debug=0;

- -MODULE_PARM(ports, "1-" __MODULE_STRING(MAX_MASQ_APP_PORTS) "i");
+MODULE_PARM(PORTS, "1-" __MODULE_STRING(MAX_MASQ_APP_PORTS) "i");
MODULE_PARM(debug, "i");


@@ -294,75 +304,5 @@
NULL /* pkt_in */
};

- -/*
- - * ip_masq_irc initialization
- - */
- -
- -__initfunc(int ip_masq_irc_init(void))
- -{
- - int i, j;
- -
- - for (i=0; (i<MAX_MASQ_APP_PORTS); i++) {
- - if (ports[i]) {
- - if ((masq_incarnations[i] = kmalloc(sizeof(struct ip_masq_app),
- - GFP_KERNEL)) == NULL)
- - return -ENOMEM;
- - memcpy(masq_incarnations[i], &ip_masq_irc, sizeof(struct ip_masq_app));
- - if ((j = register_ip_masq_app(masq_incarnations[i],
- - IPPROTO_TCP,
- - ports[i]))) {
- - return j;
- - }
- - IP_MASQ_DEBUG(1-debug,
- - "Irc: loaded support on port[%d] = %d\n",
- - i, ports[i]);
- - } else {
- - /* To be safe, force the incarnation table entry to NULL */
- - masq_incarnations[i] = NULL;
- - }
- - }
- - return 0;
- -}
- -
- -/*
- - * ip_masq_irc fin.
- - */
- -
- -int ip_masq_irc_done(void)
- -{
- - int i, j, k;
- -
- - k=0;
- - for (i=0; (i<MAX_MASQ_APP_PORTS); i++) {
- - if (masq_incarnations[i]) {
- - if ((j = unregister_ip_masq_app(masq_incarnations[i]))) {
- - k = j;
- - } else {
- - kfree(masq_incarnations[i]);
- - masq_incarnations[i] = NULL;
- - IP_MASQ_DEBUG(1-debug, "Irc: unloaded support on port[%d] = %d\n",
- - i, ports[i]);
- - }
- - }
- - }
- - return k;
- -}
- -
- -
- -#ifdef MODULE
- -EXPORT_NO_SYMBOLS;
- -
- -int init_module(void)
- -{
- - if (ip_masq_irc_init() != 0)
- - return -EIO;
- - return 0;
- -}
- -
- -void cleanup_module(void)
- -{
- - if (ip_masq_irc_done() != 0)
- - printk(KERN_INFO "ip_masq_irc: can't remove module");
- -}
- -
- -#endif /* MODULE */
+IPM_INIT_MODULE(irc,IPPROTO_TCP,Internet Relay Chat);
+IPM_END_MODULE(irc,ip_masq_irc);
diff -ruN 2.1.82-pure/net/ipv4/ip_masq_quake.c 2.1.82/net/ipv4/ip_masq_quake.c
- --- 2.1.82-pure/net/ipv4/ip_masq_quake.c Wed Dec 10 12:45:16 1997
+++ 2.1.82/net/ipv4/ip_masq_quake.c Wed Jan 28 11:56:40 1998
@@ -21,7 +21,6 @@
*
*/

- -#include <linux/config.h>
#include <linux/module.h>
#include <asm/system.h>
#include <linux/types.h>
@@ -33,6 +32,7 @@
#include <net/protocol.h>
#include <net/udp.h>
#include <net/ip_masq.h>
+#include <net/ip_masq_apphelp.h>

#define DEBUG_CONFIG_IP_MASQ_QUAKE 0

@@ -47,6 +47,20 @@
/* Have we seen a client connect message */
char cl_connect;
};
+#ifdef MODULE
+ #define PORTS ports
+ #define INCARNATIONS incarnations
+#else
+ #define PORTS ip_masq_quake_ports
+ #define INCARNATIONS ip_masq_quake_incarnations
+#endif
+int PORTS[MAX_MASQ_APP_PORTS]={26000,27000}; /* I rely on the trailing items being set to zero */
+struct ip_masq_app *INCARNATIONS[MAX_MASQ_APP_PORTS];
+
+static int debug=0;
+
+MODULE_PARM(PORTS, "1-" __MODULE_STRING(MAX_MASQ_APP_PORTS) "i");
+MODULE_PARM(debug, "i");

static int
masq_quake_init_1 (struct ip_masq_app *mapp, struct ip_masq *ms)
@@ -282,42 +296,6 @@
masq_quake_in /* pkt_in */
};

- -/*
- - * ip_masq_quake initialization
- - */
- -
- -__initfunc(int ip_masq_quake_init(void))
- -{
- - return (register_ip_masq_app(&ip_masq_quake, IPPROTO_UDP, 26000) +
- - register_ip_masq_app(&ip_masq_quakenew, IPPROTO_UDP, 27000));
- -}
- -
- -/*
- - * ip_masq_quake fin.
- - */
- -
- -int ip_masq_quake_done(void)
- -{
- - return (unregister_ip_masq_app(&ip_masq_quake) +
- - unregister_ip_masq_app(&ip_masq_quakenew));
- -}
- -
- -#ifdef MODULE
- -EXPORT_NO_SYMBOLS;
- -
- -int init_module(void)
- -{
- - if (ip_masq_quake_init() != 0)
- - return -EIO;
- - return 0;
- -}
- -
- -void cleanup_module(void)
- -{
- - if (ip_masq_quake_done() != 0)
- - printk("ip_masq_quake: can't remove module");
- -}
- -
- -#endif /* MODULE */
- -
+IPM_INIT_MODULE(quake,IPPROTO_UDP,Quake);
+IPM_END_MODULE(quake,ip_masq_quake);

diff -ruN 2.1.82-pure/net/ipv4/ip_masq_raudio.c 2.1.82/net/ipv4/ip_masq_raudio.c
- --- 2.1.82-pure/net/ipv4/ip_masq_raudio.c Wed Dec 10 12:45:16 1997
+++ 2.1.82/net/ipv4/ip_masq_raudio.c Wed Jan 28 11:57:41 1998
@@ -75,6 +75,7 @@
#include <net/protocol.h>
#include <net/tcp.h>
#include <net/ip_masq.h>
+#include <net/ip_masq_apphelp.h>

/*
#ifndef DEBUG_CONFIG_IP_MASQ_RAUDIO
@@ -105,8 +106,15 @@
* List of ports (up to MAX_MASQ_APP_PORTS) to be handled by helper
* First port is set to the default port.
*/
- -int ports[MAX_MASQ_APP_PORTS] = {554, 7070, 0}; /* I rely on the trailing items being set to zero */
- -struct ip_masq_app *masq_incarnations[MAX_MASQ_APP_PORTS];
+#ifdef MODULE
+ #define PORTS ports
+ #define INCARNATIONS incarnations
+#else
+ #define PORTS ip_masq_raudio_ports
+ #define INCARNATIONS ip_masq_raudio_incarnations
+#endif
+int PORTS[MAX_MASQ_APP_PORTS]={554,7070}; /* I rely on the trailing items being set to zero */
+struct ip_masq_app *INCARNATIONS[MAX_MASQ_APP_PORTS];

/*
* Debug level
@@ -508,69 +516,5 @@
* ip_masq_raudio initialization
*/

- -__initfunc(int ip_masq_raudio_init(void))
- -{
- - int i, j;
- -
- - for (i=0; (i<MAX_MASQ_APP_PORTS); i++) {
- - if (ports[i]) {
- - if ((masq_incarnations[i] = kmalloc(sizeof(struct ip_masq_app),
- - GFP_KERNEL)) == NULL)
- - return -ENOMEM;
- - memcpy(masq_incarnations[i], &ip_masq_raudio, sizeof(struct ip_masq_app));
- - if ((j = register_ip_masq_app(masq_incarnations[i],
- - IPPROTO_TCP,
- - ports[i]))) {
- - return j;
- - }
- - IP_MASQ_DEBUG(1-debug, "RealAudio: loaded support on port[%d] = %d\n",
- - i, ports[i]);
- - } else {
- - /* To be safe, force the incarnation table entry to NULL */
- - masq_incarnations[i] = NULL;
- - }
- - }
- - return 0;
- -}
- -
- -/*
- - * ip_masq_raudio fin.
- - */
- -
- -int ip_masq_raudio_done(void)
- -{
- - int i, j, k;
- -
- - k=0;
- - for (i=0; (i<MAX_MASQ_APP_PORTS); i++) {
- - if (masq_incarnations[i]) {
- - if ((j = unregister_ip_masq_app(masq_incarnations[i]))) {
- - k = j;
- - } else {
- - kfree(masq_incarnations[i]);
- - masq_incarnations[i] = NULL;
- - IP_MASQ_DEBUG(1-debug, "RealAudio: unloaded support on port[%d] = %d\n",
- - i, ports[i]);
- - }
- - }
- - }
- - return k;
- -}
- -
- -#ifdef MODULE
- -EXPORT_NO_SYMBOLS;
- -
- -int init_module(void)
- -{
- - if (ip_masq_raudio_init() != 0)
- - return -EIO;
- - return 0;
- -}
- -
- -void cleanup_module(void)
- -{
- - if (ip_masq_raudio_done() != 0)
- - printk(KERN_INFO "ip_masq_raudio: can't remove module");
- -}
- -
- -#endif /* MODULE */
+IPM_INIT_MODULE(raudio,IPPROTO_TCP,Real Audio);
+IPM_END_MODULE(raudio,ip_masq_raudio);
diff -ruN 2.1.82-pure/net/ipv4/ip_masq_vdolive.c 2.1.82/net/ipv4/ip_masq_vdolive.c
- --- 2.1.82-pure/net/ipv4/ip_masq_vdolive.c Wed Dec 10 12:45:16 1997
+++ 2.1.82/net/ipv4/ip_masq_vdolive.c Wed Jan 28 11:58:44 1998
@@ -33,6 +33,7 @@
#include <net/protocol.h>
#include <net/tcp.h>
#include <net/ip_masq.h>
+#include <net/ip_masq_apphelp.h>

struct vdolive_priv_data {
/* Ports used */
@@ -46,15 +47,23 @@
* List of ports (up to MAX_MASQ_APP_PORTS) to be handled by helper
* First port is set to the default port.
*/
- -static int ports[MAX_MASQ_APP_PORTS] = {7000}; /* I rely on the trailing items being set to zero */
- -struct ip_masq_app *masq_incarnations[MAX_MASQ_APP_PORTS];
+#ifdef MODULE
+ #define PORTS ports
+ #define INCARNATIONS incarnations
+#else
+ #define PORTS ip_masq_vdolive_ports
+ #define INCARNATIONS ip_masq_vdolive_incarnations
+#endif
+int PORTS[MAX_MASQ_APP_PORTS]={7000}; /* I rely on the trailing items being set to zero */
+struct ip_masq_app *INCARNATIONS[MAX_MASQ_APP_PORTS];
+

/*
* Debug level
*/
static int debug=0;

- -MODULE_PARM(ports, "1-" __MODULE_STRING(MAX_MASQ_APP_PORTS) "i");
+MODULE_PARM(PORTS, "1-" __MODULE_STRING(MAX_MASQ_APP_PORTS) "i");
MODULE_PARM(debug, "i");

static int
@@ -220,72 +229,6 @@
NULL /* pkt_in */
};

- -/*
- - * ip_masq_vdolive initialization
- - */
- -
- -__initfunc(int ip_masq_vdolive_init(void))
- -{
- - int i, j;
- -
- - for (i=0; (i<MAX_MASQ_APP_PORTS); i++) {
- - if (ports[i]) {
- - if ((masq_incarnations[i] = kmalloc(sizeof(struct ip_masq_app),
- - GFP_KERNEL)) == NULL)
- - return -ENOMEM;
- - memcpy(masq_incarnations[i], &ip_masq_vdolive, sizeof(struct ip_masq_app));
- - if ((j = register_ip_masq_app(masq_incarnations[i],
- - IPPROTO_TCP,
- - ports[i]))) {
- - return j;
- - }
- - IP_MASQ_DEBUG(1-debug, "RealAudio: loaded support on port[%d] = %d\n", i, ports[i]);
- - } else {
- - /* To be safe, force the incarnation table entry to NULL */
- - masq_incarnations[i] = NULL;
- - }
- - }
- - return 0;
- -}
- -
- -/*
- - * ip_masq_vdolive fin.
- - */
- -
- -int ip_masq_vdolive_done(void)
- -{
- - int i, j, k;
- -
- - k=0;
- - for (i=0; (i<MAX_MASQ_APP_PORTS); i++) {
- - if (masq_incarnations[i]) {
- - if ((j = unregister_ip_masq_app(masq_incarnations[i]))) {
- - k = j;
- - } else {
- - kfree(masq_incarnations[i]);
- - masq_incarnations[i] = NULL;
- - IP_MASQ_DEBUG(1-debug,"VDOlive: unloaded support on port[%d] = %d\n", i, ports[i]);
- - }
- - }
- - }
- - return k;
- -}
- -
- -
- -#ifdef MODULE
- -EXPORT_NO_SYMBOLS;
- -
- -int init_module(void)
- -{
- - if (ip_masq_vdolive_init() != 0)
- - return -EIO;
- - return 0;
- -}
- -
- -void cleanup_module(void)
- -{
- - if (ip_masq_vdolive_done() != 0)
- - IP_MASQ_DEBUG(1-debug, "ip_masq_vdolive: can't remove module");
- -}
+IPM_INIT_MODULE(vdolive,IPPROTO_TCP,RealAudio);
+IPM_END_MODULE(vdolive,ip_masq_vdolive);

- -#endif /* MODULE */

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

From: Zlatko Calusic <Zlatko.Calusic@CARNet.hr>
Date: 28 Jan 1998 19:56:31 +0100
Subject: Re: Performance dropout in recent 2.1.x kernels

Mark Hemment <markhe@nextd.demon.co.uk> writes:

> This message is in MIME format. The first part should be readable text,
> while the remaining parts are likely unreadable without MIME-aware tools.
> Send mail to mime@docserver.cac.washington.edu for more info.
>
> ---1734428081-924026288-885980764=:91
> Content-Type: TEXT/PLAIN; charset=US-ASCII
>
> Hi,
>
> On 27 Jan 1998, Zlatko Calusic wrote:
> > -#define SLAB_MIN_OBJS_PER_SLAB 4
> > +#define SLAB_MIN_OBJS_PER_SLAB 1
> >
> > -#define SLAB_BREAK_GFP_ORDER 2
> > +#define SLAB_BREAK_GFP_ORDER 1
>
> Yes, being the author for the SLAB allocator, I've mentioned this
> work-around several times. The change to SLAB_BREAK_GFP_ORDER (the only
> one which really needs changing) was part of a patch I posted to linux-mm
> last week - which received zero feed-back. The change to SLAB_MIN_OBJS
> _PER_SLAB can hurt the slab's performance quite badly for some slab sizes,
> but it will help those who suffer from numerious networking allocation
> failures.

Yes, I agree.
With unchanged 2.1.x kernels, memory is being fragmented heavily with
ethernet network traffic. I saw it like this:

MTU = 1500
Max packet + sk_buff private data ~ 1700
First >= object size = 2048
GFP order for that object size =2 -> 16384 (4 pages!)

So effectively, to receive packets from ethernet Linux is allocating
and deallocating blocks of four pages!

Changing SLAB_BREAK_GFP_ORDER to 1, reduces this to 2 pages (if I
recall it correctly).

What I wanted is that network buffers fit in only one page.
1700 * 2 < 4096! Simple mathematics. :)

Now, I believe that this killed performance a bit, but really, I
didn't tested it, and I'm very satisfied with 3.8MB/s to disk transfer
rate. At least I was in 2.1.78. I'm still running 2.1.82. :)

Maybe allocating only one page at a time even speeds things a little?
Who knows. When current problems with networking gets solved I'll
benchmark it all and report results.

> (For those who missed this patch, I've attached a description of changes
> and placed the patch on my homepage; http://www.nextd.demon.co.uk/ It
> reduces 'reserved' memory, and reduces the need to re-check the page-cache
> after a possible blocking operation, along with a few other bits and
> pieces - no rocket science).
>

I tried it, but had some problems with startup. Machine did boot, but
had problems with arguments to startup scripts. Eventually I ended in
state something like singleuser, while I was really booting to
multiuser. Also I saw some messages I have never seen in my life,
coming from login process probably. :)

Nevertheless, you incorporated some great ideas in it.

Breaking files_struct is IMHO the greatest one. I assume you have read
my proposition I made month or two ago. Unfortunately I just couldn't
get enough time to work on that, so it's still on my TODO list. I've
been very busy lately.

In the end, one question for you Mark.
I've been thinking lately lot about one idea.

What do you think about changing slab allocator so it calls
get_free_pages directly if request is >= PAGE_SIZE? Second
modification would be to use simple page splitting for requests that
are bigger than PAGE_SIZE/8 and smaller than PAGE_SIZE (with off-slab
bufctls), and small requests (< PAGE_SIZE/8) would be served
unchanged.

It's been bothering me a lot recently, so I would like to hear your
opinion, as you're the Linux SLAB guy. :)

Keep up the good work!
- --
Posted by Zlatko Calusic E-mail: <Zlatko.Calusic@CARNet.hr>
- ---------------------------------------------------------------------
"640K ought to be enough for anybody." Bill Gates '81

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

From: Rob Hagopian <hagopiar@vu.union.edu>
Date: Wed, 28 Jan 1998 14:05:26 -0500 (EST)
Subject: Re: OFFTOPIC: Linux Penguin hawking Apple Quicktime?!?

That's not a clone really. It's just another penguin. Who's to say they
haven't been using it as an internal mascot for years? Anyone rember
Clarus the Dog Cow?
-Rob

On Tue, 27 Jan 1998, Mathew Burrack wrote:

> D. For those looking for this supposed 'clone' of the Linux penguin, just
> visit the QuickTime website (www.quicktime.apple.com brings you right
> there). It should be on the first page, or somewhere near it.

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

From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Wed, 28 Jan 1998 19:14:10 +0000 (GMT)
Subject: Re: OFFTOPIC: GGI and alternative GUIs and windowing systems in Linux

> Everytime I display an image using xv I think to myself "Why doesn't
> xv use XIE if available?"

Because its faster to do it yourself in software than use XIE...

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

From: Zlatko Calusic <Zlatko.Calusic@CARNet.hr>
Date: 28 Jan 1998 20:18:58 +0100
Subject: Network performance in 2.1.82 (cont)

Hi Andi.

I just saw something that *could* be a clue in solving network speed
problems.

lo Link encap:Local Loopback
inet addr:127.0.0.1 Bcast:0.0.0.0 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:3584 Metric:1
RX packets:8677 error:0 dropped:0 over:0 frame:0
TX packets:8677 error:0 dropped:0 over:0 carrier:0 coll:0

eth0 Link encap:Ethernet HWaddr 00:00:F8:03:A9:9D
inet addr:XXX.XX.XXX.XXX Bcast:XXX.XX.XXX.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:133380 error:0 dropped:0 over:0 frame:0
TX packets:133155 error:0 dropped:0 over:0 carrier:0 coll:0
Interrupt:11 Base address:0xe880

Number of eth0 RX/TX packets is suspiciously similar.

I tried downloading a big file, and numbers kept tracking each
other. Same applies to "lo" interface, as you can see.

Hope it helps.
- --
Posted by Zlatko Calusic E-mail: <Zlatko.Calusic@CARNet.hr>
- ---------------------------------------------------------------------
The 3 biggest disasters: Hiroshima 45, Tchernobyl 86, Windows 95.

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

From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Wed, 28 Jan 1998 19:17:34 +0000 (GMT)
Subject: Re: Packet Scheduling

> Couldn't some use of TCP's flow control be used to throttle the remote
> sender?

Thats what I said - throw some away - see below....

> > > Delaying incoming packets doesnt change the speed of the link. You need
> > > to throw a few away.

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

From: Tim Waugh <tim@cyberelk.demon.co.uk>
Date: Wed, 28 Jan 1998 14:24:25 +0000 (GMT)
Subject: 2.1.82

Hi,

In a struct page, page->buffers->p_this_page is supposed to be a circular
list. I got an oops because one of the pointers in the list was NULL.

Tim.
*/

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

From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Wed, 28 Jan 1998 19:58:36 +0000 (GMT)
Subject: Re: Kernel treads vs. kernel processes

> How do I determine if a PID is a normal process or a lightweight process
> (kernel thread)?

There is no difference in Linux. A process is merely a thread with its own
file memory and signals.

Alan

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

From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Wed, 28 Jan 1998 19:40:39 +0000 (GMT)
Subject: Re: Packet Scheduling

> But we can only throw them away when they have already been transfered,
> so I guess it doesn't make a difference.

Not so - read the TCP flow control papers. If we throw frames away the other
end doesnt see an ACK (we threw it before our tcp layer saw it) and deduces
its sending too fast and hit congestion. Its just this is software powered
congestion

Alan

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

From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Wed, 28 Jan 1998 19:57:32 +0000 (GMT)
Subject: Re: token ring driver lacks byte counts

> tr0: 0 18070328 0 9 0 0 0 3671525 0 0 0
> ^ ^
> missing missing

Nobody has submitted a byte count patch for the token ring drivers yet

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

From: Dean Gaudet <dgaudet-list-linux-kernel@arctic.org>
Date: Wed, 28 Jan 1998 12:13:21 -0800 (PST)
Subject: Re: Suspend broken on a thinkpad

Visit <http://www.arctic.org/~dgaudet/tp560/linux-apm.patch>.
Depending on what thinkpad bios version you have (no I don't have a
list of numbers) you may need my patch to get suspend to work properly.
I just learned recently that a brand new 560X seems to suspend just fine
with the stock kernel. So maybe IBM changed their apm bios behaviour.

Incidentally, the bug I'm working around here is quite arguably a bug
in drivers/char/apm_bios.c. apm_bios.c treats the APM bios as a source
of asynchronous events, and queries it regularly. Whereas IBM's bios
appears to behave as if it were synchronous -- it doesn't expect you to
query it again while you're supposedly busy suspending. What ends up
happening is that the tiny 20 element event queues overflow, and there's
no overflow detection.

But your problem sounds different from the problems I've had with my
older 560.

Dean

On 28 Jan 1998, Jan Rychter wrote:

> >>>>> "John" == John Goerzen <jgoerzen@southwind.net>:
> John> Hi, I just got a new Thinkpad 310ED (133 MMX). Of course, I
> John> quickly took Windows down to size and installed Linux.
>
> John> I've installed the pcmcia utilties and got them working without
> John> problems.
>
> John> But the power management features don't seem to work under Linux,
> John> but they do under Windows 95.
>
> John> Specifically, the suspend feature (write all memory to disk and
> John> shut off) doesn't work. The LCD will briefly turn off, and then
> John> will beep and turn right back on and cause some hard disk
> John> activity for a bit.
>
> On my TP560 I had one thing bugging me for a long time -- if IRQ 9 was
> made available to the pcmcia-cs package, then at some point machine
> refused to hibernate. Not really predictable, e.g. it would happily
> hibernate 20 times and then suddenly refuse. Usually just when I was in
> *real* hurry :-)
>
> So, you might take a look at that.
>
> And BTW, for the ThinkPad 560 owners: anybody got suspend to work (not
> hibernation, not standby, SUSPEND == fn-f4) ? My machine w/Linux happily
> suspends and then never wakes up. I can open&close the screen, tap the
> keys, etc, no go. Nada. Have to disconnect AC and remove the batteries.
>
> --J.
>

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

From: "David Schwartz" <davids@webmaster.com>
Date: Wed, 28 Jan 1998 15:23:08 -0500
Subject: Re: OFFTOPIC: Linux Penguin hawking Apple Quicktime?!?

My 2.1.82 system compiled with egcs-1.0.1, compiled with SMP=1 but on a
uniprocessor K6 machine, just outputted an 'Ugh at c0112376', which is in
setup_IO_APIC_irqs. Should I worry?

DS

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

From: ketil@ii.uib.no
Date: 28 Jan 1998 21:38:24 +0100
Subject: Re: Network performance in 2.1.82 (cont)

Zlatko Calusic <Zlatko.Calusic@CARNet.hr> writes:

> I tried downloading a big file, and numbers kept tracking each
> other. Same applies to "lo" interface, as you can see.

I wouldn't worry about that last thing, if I were you. (Hint: "lo" is
the loopback device :-)

~kzm
- --
If I haven't seen further, it is by standing in the footprints of giants

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

From: Alessandro Suardi <asuardi@uninetcom.it>
Date: Wed, 28 Jan 1998 21:44:12 +0100
Subject: Re: SUMMARY: pcmcia-cs-2.9.12 +glibc

John Kennedy wrote:
>
> I grabbed "pcmcia-cs.16-Jan-98.tar.gz" (which untars itself as 3.0.0)
> and it compiled up just fine for me under 2.1.82 and in a native
> glibc-2.0.6 environment. If an instance of "pci_irq" hadn't escaped a
> CONFIG_CARDBUS #ifdef I wouldn't have had to touch the code at all.
>
> I haven't seen it trip over any kernel problems yet, but time will tell.
>

As another datapoint, 16-Jan-98 compiles and works under libc5, kernel
2.1.80 and .82; I personally said Y to experimental cardbus32 support
to avoid touching the code and my laptop is happy as well.
(I run a RH4.1 base and will upgrade to glibc when a 2.2-based RedHat
distribution comes out...)

- --alessandro <asuardi@uninetcom.it> <asuardi@it.oracle.com>

Linux 2.0.33/2.1.82 libc-5.4.38 gcc-2.7.2.3 binutils-2.8.1.0.15

"There's a bit of magic in everything
and then some loss to even things out" -- Lou Reed

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

From: "Grant R. Guenther" <grant@torque.net>
Date: Wed, 28 Jan 1998 16:23:26 -0500 (EST)
Subject: Re: Request for help with cdrecord and HP7100

Thanks, Gadi, for the excellent summary of the ATAPI CDB translation
issues. As far as the design of the 'pg' driver goes, it would certainly
be cleaner to do no translation and assume that the application can
distinguish between ATAPI and SCSI devices. If I read between the lines
correctly, cdrecord, in particular, should work without the translation.

So, I propose, for the sake of argument, that 'pg' will not do
any translation.

> As suggested by Joerg, it would be best to add a method which will allow us
> to disable the layer, at least for access through the /dev/sg driver. The
> last patch implemented the following translation options:
>
> - No translation.
>
> - Enabling the ATAPI->SCSI translation layer just for the
> kernel (sr, sd, etc).
>
> - Enabling the ATAPI->SCSI translation layer for both
> the kernel and for access through /dev/sg.

Given that 'pg' is _not_ intended to be a full emulation of SCSI via
parallel port ATAPI, but rather a generic way of delivering CDBs to
specific devices (that the application almost certainly needs to know
are ATAPI) is there any reason to implement translation at all in pg ?

At this stage I have no idea whether the HP 7100e will work with
PARIDE, so I want to expend the least amount of energy to make something
that people with these drives can test :-(

- --------------------------------------------------------------------------
Grant R. Guenther grant@torque.net
- --------------------------------------------------------------------------

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

From: Ian Eure <ieure@peninsula.wednet.edu>
Date: Thu, 29 Jan 1998 01:33:57 -0800
Subject: Re: IRQ 255?

Does anyone know what the advantages/disadvantages of having an irq for a video
card are?

Pawel S. Veselov wrote:

> Hello, Bernhard!
>
> On Tue, 27 Jan 1998, Bernhard Rosenkraenzer wrote:
>
> >> Bus 0, device 2, function 0:
> >> VGA compatible controller: Cirrus Logic GD 7548 (rev 0).
> >> Fast devsel. IRQ 255.
> >>
> >> Note that the video device is on IRQ 255. Is this possibly a bug somewhere?
> >
> >IRQ 255 doesn't exist, but it looks like a (unsigned char) -1.
> >My guess is that your VGA card doesn't use an IRQ, and IRQ 255 is the PCI
> >driver's way to display this.
>
> PCI controller sets -1 ( 255 ) IRQ in two cases :
> a) The PCI device doesn't need an IRQ.
> b) There is no available IRQ to assign to this device.
>
> Bye.
> --
> Natural laws have no pity.
>
> --
> With best of best regards, Pawel S. Veselov (aka Black Angel)
> internet : vps@unicorn.niimm.spb.su ( mail,finger,talk )
> Web page : http://www.niimm.spb.su/~vps/
> ICQ : 5252265

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

From: "Manuel J. Galan" <manolow@step.es>
Date: Wed, 28 Jan 1998 21:32:21 +0000 (WET)
Subject: Re: Suspend broken on a thinkpad

- ---1849616000-1804289383-886023152=:13877
Content-Type: TEXT/plain; CHARSET=US-ASCII

On 28 Jan, Dean Gaudet wrote:
> Visit <http://www.arctic.org/~dgaudet/tp560/linux-apm.patch>.
> Depending on what thinkpad bios version you have (no I don't have a
> list of numbers) you may need my patch to get suspend to work properly.
> I just learned recently that a brand new 560X seems to suspend just fine
> with the stock kernel. So maybe IBM changed their apm bios behaviour.
>
> Incidentally, the bug I'm working around here is quite arguably a bug
> in drivers/char/apm_bios.c. apm_bios.c treats the APM bios as a source
> of asynchronous events, and queries it regularly. Whereas IBM's bios
> appears to behave as if it were synchronous -- it doesn't expect you to
> query it again while you're supposedly busy suspending. What ends up
> happening is that the tiny 20 element event queues overflow, and there's
> no overflow detection.
>
> But your problem sounds different from the problems I've had with my
> older 560.
>
> Dean
>
> On 28 Jan 1998, Jan Rychter wrote:
>
>> >>>>> "John" == John Goerzen <jgoerzen@southwind.net>:
>> John> Hi, I just got a new Thinkpad 310ED (133 MMX). Of course, I
>> John> quickly took Windows down to size and installed Linux.
>>
>> John> I've installed the pcmcia utilties and got them working without
>> John> problems.
>>
>> John> But the power management features don't seem to work under Linux,
>> John> but they do under Windows 95.
>>
>> John> Specifically, the suspend feature (write all memory to disk and
>> John> shut off) doesn't work. The LCD will briefly turn off, and then
>> John> will beep and turn right back on and cause some hard disk
>> John> activity for a bit.
>>
>> On my TP560 I had one thing bugging me for a long time -- if IRQ 9 was
>> made available to the pcmcia-cs package, then at some point machine
>> refused to hibernate. Not really predictable, e.g. it would happily
>> hibernate 20 times and then suddenly refuse. Usually just when I was in
>> *real* hurry :-)
>>
>> So, you might take a look at that.
>>
>> And BTW, for the ThinkPad 560 owners: anybody got suspend to work (not
>> hibernation, not standby, SUSPEND == fn-f4) ? My machine w/Linux happily
>> suspends and then never wakes up. I can open&close the screen, tap the
>> keys, etc, no go. Nada. Have to disconnect AC and remove the batteries.
>>
>> --J.
>>

Just for the record my 760XD suspends/redisafe (Fn-F4) and hybernates
(Fn-F12) OK with stock 2.0.33 ...It seems that not all thinkpads are
born equal ;-)

- --
- --
Manuel J. Galan
manolow@step.es

- ---1849616000-1804289383-886023152=:13877
Content-Type: APPLICATION/pgp-signature

- -----BEGIN PGP MESSAGE-----
Version: 2.6.3in
Comment: Requires PGP version 2.6 or later.

iQEVAwUBNM+j6WD+APAfXUYjAQHdZQf9Fw8DCGM+jQJhvPKBGsdG8/eO51eoFDZ0
UkAkuwG8PHyWtXcHJbQDFuD8wKMgSd2NmkomJVy/kguySso1PCPNN/UPbgTW6cXn
jOIl/Uth/Un8k7pm7eh3v03esROXUwxwOs4IE5JV2H5pAYOrjiFRQgPSVN+J2fqb
jbIEVYyeBB9SpDVs3J2mbo0XEP2U8xKvjOozXPhhJs9YFQ6wkdI+jQDtsNfPK+LD
sG5sjiY4ZHrlNly82GkSyWRPfBLT+01F/wViS1B64YiC7VwT5hbfr8J3NYT/EaD6
VPKmK6QuMYegzJ2Jy6nbfuUFLFX974rWgWyTO8hOo8vBB6+C4Ke3qg==
=D1eC
- -----END PGP MESSAGE-----

- ---1849616000-1804289383-886023152=:13877--

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

From: Pavel Machek <pavel@elf.ucw.cz>
Date: Wed, 28 Jan 1998 10:41:16 +0100
Subject: Re: IP tunnel not working...

> Hi,
>
> Does anyone know why ip tunnel has stopped working from 2.0.xx to 2.1.xx ?
> Whenever I try to configure the tunl0 device, it does not recognize it as
> the pointopoint device. (tried with 2.1.82)

Get utility 'ip', and create tunl1 with it, and work with that
one. tunl0 is a bit special.
Pavel

- --
I'm really pavel@atrey.karlin.mff.cuni.cz. Pavel
Look at http://atrey.karlin.mff.cuni.cz/~pavel/ ;-).

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

From: Pavel Machek <pavel@elf.ucw.cz>
Date: Wed, 28 Jan 1998 10:40:29 +0100
Subject: Re: 2.1.82 - umsdos broken & will stay that way :-(

Hi!

> I just compiled 2.1.82, hoping to find UMSDOS repaired, but it wasn't...
> please, please get it repaired..

I took a look, and repairing umsdos is a bit non-trivial as it knows
nothing about dentries. (So umsdos is untouched from about .42). As I
do not use it myself, I will not do that....
Pavel

- --
I'm really pavel@atrey.karlin.mff.cuni.cz. Pavel
Look at http://atrey.karlin.mff.cuni.cz/~pavel/ ;-).

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

From: Pavel Machek <pavel@elf.ucw.cz>
Date: Wed, 28 Jan 1998 10:47:28 +0100
Subject: Re: Contiguous files and I/O buffered

Hi!

> When executing fflush(..) and setbuf(.., NULL) to obtain
> unbuffered I/O, does the system really avoid buffering? For example,
> let us consider the two code fragments:

No. setvbuf() forces C library not to buffer. Currenlty, there's no
way to force kernel not to buffer.
Pavel

- --
I'm really pavel@atrey.karlin.mff.cuni.cz. Pavel
Look at http://atrey.karlin.mff.cuni.cz/~pavel/ ;-).

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

From: Pavel Machek <pavel@elf.ucw.cz>
Date: Wed, 28 Jan 1998 10:26:17 +0100
Subject: Re: Where has all the printing gone???

Hi!

> After a long happy time with the stable kernel, I finally decided to try
> the Beta kernel series to enable me to see the NTFS logical drives on the
> NT side of the box. I had kept some logical drives as HPFS to make them
> visible, but I think that NTFS is much better for my use.
>
> Anyways, I built 1.3.80-pre4 and today I built 1.3.82. In general
> they

You must surely mean 2.1.82, do you?

> both seemed to work, but today I finally got around to trying to print
> something and nada... I have a printing utility (written LONG ago under
> DOS but ported to Linux when I first started with it several years ago).
> It formats the file for printing and then pipes it to the printer. It has
> worked nicely for several years. When I tried running it under the Beta
> kernel, the stuff went in here, it went around and around, and it did NOT
> come out there. Looking at the queue with lpq, the missing files are
> there but there is a nastygram about waiting for lp to be ready and an
> (offline??) thingie at the end of that. Similarly with 1.3.82, except
> that it talks of mp [????] rather than lp (What is mp???). The printer
> itself and the printer port hardware are fine. The printer port is part
> of an Intel chipset on a Micronics system board in a Micron Millenia 100
> machine. It is configured as a PS/2 (i.e. bidirectional) port.

I'm afraid that lp0 became lp1 in development series or something like
that.

> O.K. The BIG question; what am I doing wrong? I ___DID___ face east and
> bow down three times before I built the kernel. I felt that sacrificing a
> virgin was a bit extreme, so I skipped that step. But why are the Gods
> angry with me and my printer? Thanks for any enlightenment.

;-)))
Pavel

- --
I'm really pavel@atrey.karlin.mff.cuni.cz. Pavel
Look at http://atrey.karlin.mff.cuni.cz/~pavel/ ;-).

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

From: tim <police@police.tas.gov.au>
Date: Thu, 29 Jan 1998 08:44:23 +0000 (GMT)
Subject: Re: 2.1.82 boot failure

On Wed, 28 Jan 1998, Myrdraal wrote:

> On Wed, Jan 28, 1998 at 11:22:46AM +0100, Andreas Schwab wrote:
> Hi,
> > Otel Florian-Daniel <otel@ce.chalmers.se> writes:
> > |> I just tried to fire up 2.1.82. Bare, no fancy modules. When it
> > |> boots it block. The only relevant message seems to be:
> > |> Ocuh, no kerneld for message 2147418113
> > |> Any idea ?
> > Reconfigure and enable CONFIG_UNIX (not as a module).
> I don't think you should have to do that... It works just fine as a
> module for me:
> "Module Size Used by
> unix 12180 28 (autoclean)"
> -Myrdraal

It works fine for me too, but on boot up, even though kerneld IS running,
I still get "Ouch, no kerneld for message xxxxxxxxxx"
(CONFIG_UNIX is a module)

I'm sure when I complied unix domain sockets in, I didn't get this. Why
would we be getting this message though, when kerneld IS running??

Is it something to do with the modprobe: can't locate module ^X>7 errors?

Tim

<My email address is tim@police.tas.gov.au>

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

From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Wed, 28 Jan 1998 22:23:31 +0000 (GMT)
Subject: Re: Contiguous files and I/O buffered

> No. setvbuf() forces C library not to buffer. Currenlty, there's no
> way to force kernel not to buffer.

Open the file O_SYNC.

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

From: Mathew Burrack <neville@vm.sc.edu>
Date: Wed, 28 Jan 1998 17:28:50 -0500
Subject: Re: OFFTOPIC: Linux Penguin hawking Apple Quicktime?!?

Rob Hagopian wrote:

> That's not a clone really. It's just another penguin. Who's to say they
> haven't been using it as an internal mascot for years? Anyone rember
> Clarus the Dog Cow?

The DogCow (ONE word, not two!) lives!

MooF!

Mathew Burrack

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

From: "Andrew J. Scott" <A.J.Scott@casdn.neu.edu>
Date: Wed, 28 Jan 1998 17:33:26 EDT
Subject: Re: 2.1.82: still freezing

On 28 Jan 98 at 14:30, Jamie Lokier wrote:

> Date: Wed, 28 Jan 1998 14:30:41 +0000
> From: Jamie Lokier <lkd@tantalophile.demon.co.uk>
> To: linux-kernel@vger.rutgers.edu
> Subject: 2.1.82: still freezing

> But enough about the weather around here...
>
> According to my logs, I've now tried kernels:
>
> 2.1.70
> 2.1.72
> 2.1.80
> 2.1.82
>
> These are the only 2.1 kernels I've tried so far.
>
> _All_ of them freeze up on my machine after some random amount of time,
> usually measured in hours.
>
> With 2.1.80 and 2.1.82, I tried Magic-SysRq. It does _not_ work after
> the computer has crashed.
> ....................................snip......................
> I've not seen any console messages, but then I run X all the time.
> Nothing ever makes it to the log files. (In fact, occasionally the
> formatting of the log files is a bit messed up around the crash time).
>
> So, who else has this problem?

First time I've tried a development kernel. 2.182 on an alpha udb.
Compiled just fine, after I commented out smp=1. Ran all night, ran this
morning until I ran X. Simply froze. Keyboard gone. Caps and numlock
lights wouldn't switch. I'll look at it later without running X and see if
it crashes. Much more responsive than 2.0.x kernels on the alpha, when
under a heavy load, I thought.

- --------------------Mailed via Pegasus 2.53 & Mercury 1.30-----------------
A.J.Scott@casdn.neu.edu Fax (617)373-2942
Andrew Scott Tel (617)373-5278 _
Northeastern University--138 Meserve Hall / \ /
College of Arts & Sciences-Deans Office http://www.casdn.neu.edu / \ \ /
Boston, Ma. 02115 / \_/

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

From: Benny Amorsen <amorsen@sscnet.com>
Date: 28 Jan 1998 23:32:33 +0100
Subject: Re: ext2 corruption in 2.0.33

>>>>> "IN" == Ivan Nejgebauer <ian@uns.ns.ac.yu> writes:

IN> First time the emacs binary got corrupted, and cmp'ing it with a
IN> good copy revealed a single almost contiguous 3 kbyte range which
IN> had any differences -- looks like a single page. I restored the
IN> binary, then two days later the same thing happend to perl. This
IN> time I replaced the kernel with one which had Triton support, and
IN> did hdparm -u 1. No problems since.

IN> There were some reports of "hda IRQ timeout" in the logs at the
IN> time. Filesystem structure was okay; fsck didn't complain.

Are you using power saving on the hard drive?

I've seen similar corruption in Windows 95 when a disk was too slow at
spinning up. Now admittedly that doesn't apply to linux, but it could
be hardware.

The machine in question has an ASUS XP55T2P4 (Triton HX) mainboard and
(among others) a Quantum Bigfoot disk. Disabling power saving "solved"
the problem.

Benny

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

From: "Manuel J. Galan" <manolow@step.es>
Date: Wed, 28 Jan 1998 22:47:51 +0000 (WET)
Subject: Re: Where has all the printing gone???

Maybe reading the header of linux/drivers/char/lp.c could be of some
help...

- --
- --
Manuel J. Galan
manolow@step.es

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

From: "Dr. Werner Fink" <werner@suse.de>
Date: Thu, 29 Jan 1998 00:18:37 +0100
Subject: [patch for fs/buffer.c] Re: 2.1.82

>
> Hi,
>
> In a struct page, page->buffers->p_this_page is supposed to be a circular
> list. I got an oops because one of the pointers in the list was NULL.
>
> Tim.
> */

Maybe the appended patch may solve/reduce this sort of oops. This one also
contains a simple speed up by a smarter handling of reuse_list ... (s.b. has
told me that xchg in recover_reusable_buffer_heads is expensive for alpha :)
Nevertheless at the end of create_buffers() the schedule() is only necessary
if reuse_list and unused_list is empty (no unused asynch buffer heads).

Werner

- ---------------------------------------------------------------------------
diff -ur linux-2.1.82/fs/buffer.c linux/fs/buffer.c
- --- linux-2.1.82/fs/buffer.c Fri Jan 16 06:01:04 1998
+++ linux/fs/buffer.c Thu Jan 29 00:05:15 1998
@@ -1190,7 +1190,8 @@
{
struct buffer_head * bh;

- - recover_reusable_buffer_heads();
+ if (reuse_list)
+ recover_reusable_buffer_heads();
if (nr_unused_buffer_heads > NR_RESERVED) {
bh = unused_list;
unused_list = bh->b_next_free;
@@ -1307,8 +1308,9 @@
*/
add_wait_queue(&buffer_wait, &wait);
current->state = TASK_UNINTERRUPTIBLE;
+ if (!unused_list && !reuse_list)
+ schedule();
recover_reusable_buffer_heads();
- - schedule();
remove_wait_queue(&buffer_wait, &wait);
current->state = TASK_RUNNING;
goto try_again;
@@ -1486,14 +1488,16 @@
* and unlock_buffer(). */
} else {
unsigned long flags;
- - clear_bit(PG_locked, &page->flags);
- - set_bit(PG_uptodate, &page->flags);
- - wake_up(&page->wait);
save_flags(flags);
cli();
free_async_buffers(bh);
restore_flags(flags);
+ clear_bit(PG_locked, &page->flags);
+ set_bit(PG_uptodate, &page->flags);
+ wake_up(&page->wait);
after_unlock_page(page);
+ if (waitqueue_active(&buffer_wait))
+ wake_up(&buffer_wait);
}
++current->maj_flt;
return 0;

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

From: Martin Mares <mj@ucw.cz>
Date: Wed, 28 Jan 1998 14:06:23 +0100
Subject: Extra per-inode data

Hi,

I'm now playing with some filesystem capable of >4G files and I need to
store lot of data (approx. 1K) per inode, so I decided to use the inode->u.generic_ip
field to point to my local data instead of putting it directly to the inode structure.
But it seems that there is no way to free such data when the inode gets flushed
out of the inode cache (it can be still reused after super_ops->put_inode gets called).

The only solution I see is to introduce a new super_op called from clear_inode
to free such auxiliary data (see the patch below). Does anybody have a better idea?

Have a nice fortnight
- --
Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
"Windows Error: 002 - No error yet ..."

- --- ./fs/inode.c.xx Wed Jan 28 13:56:06 1998
+++ ./fs/inode.c Wed Jan 28 13:58:38 1998
@@ -225,6 +225,8 @@
wait_on_inode(inode);
if (IS_QUOTAINIT(inode))
DQUOT_DROP(inode);
+ if (inode->i_sb && inode->i_sb->s_op && inode->i_sb->s_op->clear_inode)
+ inode->i_sb->s_op->clear_inode(inode);

inode->i_state = 0;
}
- --- ./include/linux/fs.h.xx Wed Jan 28 13:56:14 1998
+++ ./include/linux/fs.h Wed Jan 28 13:56:30 1998
@@ -612,6 +612,7 @@
void (*write_super) (struct super_block *);
int (*statfs) (struct super_block *, struct statfs *, int);
int (*remount_fs) (struct super_block *, int *, char *);
+ void (*clear_inode) (struct inode *);
};

struct dquot_operations {

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

From: Benny Amorsen <amorsen@sscnet.com>
Date: 29 Jan 1998 00:26:13 +0100
Subject: Re: pcmcia-cs-2.9.12 +glibc

>>>>> "CSA" == C Scott Ananian <cananian@lcs.mit.edu> writes:

CSA> I'm not *positive* David Hinds has made 3.0.0 glibc-friendly, but
CSA> if you still can't get it to work after downloading the most
CSA> recent version, try emailing him (<dhinds@hyper.stanford.edu>).

It works great. Well actually the 08-Jan-1998 snapshot works better
than 16-Jan-1998 for me, the latter segmentation faults once in a
while when doing cardctl eject etc. But overall it works great.

Benny

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

From: Bob Lorenzini <hwm@netcom.com>
Date: Wed, 28 Jan 1998 15:54:40 -0800 (PST)
Subject: Re: Suspend broken on a thinkpad

On 28 Jan 1998, John Goerzen wrote:

> But the power management features don't seem to work under Linux, but
> they do under Windows 95.
>
One of the things that can cause this is the atrun line in crontab. I
have to kill ax25 networking and gpm also before suspend. The latest
kernels ~2.1.7+ are also giving me a problem but I have not had a chance
to track it down. You can try killing processes until it works.

Bob

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

From: linux kernel account <linker@nightshade.z.ml.org>
Date: Wed, 28 Jan 1998 19:11:23 -0500 (EST)
Subject: Re: Packet Scheduling

cant we also shrink the windows before being so drastic as tossing the
packet..

On Wed, 28 Jan 1998, Alan Cox wrote:

> > But we can only throw them away when they have already been transfered,
> > so I guess it doesn't make a difference.
>
> Not so - read the TCP flow control papers. If we throw frames away the other
> end doesnt see an ACK (we threw it before our tcp layer saw it) and deduces
> its sending too fast and hit congestion. Its just this is software powered
> congestion
>
> Alan
>

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

From: Michael Elizabeth Chastain <mec@shout.net>
Date: Wed, 28 Jan 1998 18:16:25 -0600
Subject: Re: warning: `cpu_data' redefined

George with no last name writes:

> In file included from /var/src/linux-2.1.82/include/linux/sched.h:73,
> from signal.c:10:
> /var/src/linux-2.1.82/include/asm/processor.h:52: warning: `cpu_data' redefined
> /var/src/linux-2.1.82/include/linux/modules/i386_ksyms.ver:48: warning: this is the location of the previous definition

I bet that you ran 'make dep', and then at a later point changed the
setting of the __SMP__ flag, and then did not run 'make dep' again.

cpu_data is a real variable in SMP, and a macro in the non-smp case.
And the .ver files do not get remade automatically every time they
need to be (although they sure get remade a lot when they don't).

I have no patch for this one. I would very much like to have a brand
new CONFIG_MODVERSIONS facility before 2.2.0 though. Communicating
type signatures via .ver files is fucked up from the word go.

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

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

From: mlord <mlord@pobox.com>
Date: Wed, 28 Jan 1998 19:21:10 -0500
Subject: Re: PCI probing problem

Zlatko Calusic wrote:
>
> kernel@dotd.dyn.ml.org writes:
>
> > Upon boot of a 2.1.80 kernel (egcs 1.0.1) I get the following:
> >
> > PCI_IDE: unknown IDE controller on PCI bus 0 function 88, VID=10b9, DID=5229
> > PCI_IDE: not 100% native mode: will probe irqs later
> > PCI_IDE: simplex device: DMA disabled
> > ide0: PCI_IDE Bus-Master DMA disabled (BIOS), pcicmd=0x0005, ccode=0x101fa20, dma_base=0x0000
> > PCI_IDE: simplex device: DMA disabled
> > ide1: PCI_IDE Bus-Master DMA disabled (BIOS), pcicmd=0x0005, ccode=0x101fa20, dma_base=0x0000

The problem here is that this IDE interface claims to be "simplex only",
meaning that DMA can only be used on a single channel at a time.

As that is kind of oddball in the modern world, and also somewhat tricky
to manage correctly, Linux IDE just plain refuses to do DMA on simplex
chipsets. It tries to configure this one, but gives up when it sees
the
simplex flag.
\
- --
mlord@pobox.com
The Linux IDE guy

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

From: Kurt Garloff <garloff@kg1.ping.de>
Date: Thu, 29 Jan 1998 00:59:07 +0100 (CET)
Subject: Re: IRQ 255?

On Thu, 29 Jan 1998, Ian Eure wrote:

> Does anyone know what the advantages/disadvantages of having an irq for a video
> card are?

In general: No advantage. Most of the time, the video card justs listens
to what is written into its framebuffer and displays it. More advanced
cards do accept simple commands that they can perform itself. (Draw lines,
fill polygons, etc.) Very advanced cards do fullfill complicated tasks and
signal that they are ready and wait for new tasks/data by an interrupt. 3D
chips can be considered as very advanced.
I have no idea, if some of the accelerated XFree86 servers make use of
interrupts, but I guess so. The Glide library and maybe also the MesaGL
(OpenGL clone) could profit, too. But as Unix software tends to be
portable and interrupts aren't, I'm not sure.

Kurt Garloff, Dortmund
<K.Garloff@ping.de>
PGP key on http://www.student.physik.uni-dortmund.de/homepages/garloff

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

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

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

subscribe linux-kernel-digest

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

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

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