All of lore.kernel.org
 help / color / mirror / Atom feed
* 2.5.44-ac3 oops (usb related?)
From: Stefan Schwandter @ 2002-10-26  9:39 UTC (permalink / raw)
  To: linux-kernel

[-- Attachment #1: Type: text/plain, Size: 161 bytes --]

Hi!


reboot segfaults with 2.5.44-ac3 (and 2.5.44 vanilla). I've appended
ksymoops output (from -ac3).


regards, Stefan

-- 
----> http://www.shockfrosted.org

[-- Attachment #2: oops.txt --]
[-- Type: text/plain, Size: 4729 bytes --]

ksymoops 2.4.6 on i686 2.5.44-ac3.  Options used
     -V (default)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.5.44-ac3/ (default)
     -m /boot/System.map-2.5.44-ac3 (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.

Oct 26 11:10:31 TK150122 kernel: Machine check exception polling timer started.
Oct 26 11:10:31 TK150122 kernel:  WARNING: unexpected IO-APIC, please mail
Oct 26 11:10:31 TK150122 kernel: 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html
Oct 26 11:30:26 TK150122 kernel: c0237335
Oct 26 11:30:26 TK150122 kernel: Oops: 0000
Oct 26 11:30:26 TK150122 kernel: CPU:    0
Oct 26 11:30:26 TK150122 kernel: EIP:    0060:[driver_detach+53/80]    Not tainted
Oct 26 11:30:26 TK150122 kernel: EFLAGS: 00010246
Oct 26 11:30:26 TK150122 kernel: eax: 00000000   ebx: c523fcd0   ecx: c0430170   edx: 00000000
Oct 26 11:30:26 TK150122 kernel: esi: 00000000   edi: e08cea40   ebp: e08ba000   esp: de8cdf4c
Oct 26 11:30:26 TK150122 kernel: ds: 0068   es: 0068   ss: 0068
Oct 26 11:30:26 TK150122 kernel: Stack: e08ceaa0 e08cea40 e08ceaa4 c0237558 e08cea40 e08cea40 e08ceaa0 df185000 
Oct 26 11:30:26 TK150122 kernel:        c0237958 e08cea40 e08cea40 e08ba000 c02379fb e08cea40 fffffff0 e08bb453 
Oct 26 11:30:26 TK150122 kernel:        e08cea40 c011a2b7 fffffff0 e08ba000 df185000 bfffeda8 c0119510 e08ba000 
Oct 26 11:30:26 TK150122 kernel: Call Trace:
Oct 26 11:30:26 TK150122 kernel:  [<e08ceaa0>] usb_bus_type+0x0/0x80 [usbcore]
Oct 26 11:30:26 TK150122 kernel:  [<e08cea40>] usb_generic_driver+0x0/0x60 [usbcore]
Oct 26 11:30:26 TK150122 kernel:  [<e08ceaa4>] usb_bus_type+0x4/0x80 [usbcore]
Oct 26 11:30:26 TK150122 kernel:  [<e08cea40>] usb_generic_driver+0x0/0x60 [usbcore]
Oct 26 11:30:26 TK150122 kernel:  [<e08cea40>] usb_generic_driver+0x0/0x60 [usbcore]
Oct 26 11:30:26 TK150122 kernel:  [<e08ceaa0>] usb_bus_type+0x0/0x80 [usbcore]
Oct 26 11:30:26 TK150122 kernel:  [<e08cea40>] usb_generic_driver+0x0/0x60 [usbcore]
Oct 26 11:30:26 TK150122 kernel:  [<e08cea40>] usb_generic_driver+0x0/0x60 [usbcore]
Oct 26 11:30:26 TK150122 kernel:  [<e08cea40>] usb_generic_driver+0x0/0x60 [usbcore]
Oct 26 11:30:26 TK150122 kernel:  [<e08bb453>] usb_exit+0x13/0x30 [usbcore]
Oct 26 11:30:26 TK150122 kernel:  [<e08cea40>] usb_generic_driver+0x0/0x60 [usbcore]
Oct 26 11:30:26 TK150122 kernel: Code: 8b 32 8d 47 28 39 c2 75 d5 5b 5e 5f c3 8d b4 26 00 00 00 00 
Using defaults from ksymoops -t elf32-i386 -a i386


>>ebx; c523fcd0 <_end+4d80518/203d78a8>
>>ecx; c0430170 <kbd_sysrq_xlate+30/80>
>>edi; e08cea40 <[ehci-hcd].data.end+1/1621>
>>ebp; e08ba000 <[usbcore]usb_create_driverfs_intf_files+30/40>
>>esp; de8cdf4c <_end+1e40e794/203d78a8>

Trace; e08ceaa0 <[ehci-hcd].data.end+61/1621>
Trace; e08cea40 <[ehci-hcd].data.end+1/1621>
Trace; e08ceaa4 <[ehci-hcd].data.end+65/1621>
Trace; e08cea40 <[ehci-hcd].data.end+1/1621>
Trace; e08cea40 <[ehci-hcd].data.end+1/1621>
Trace; e08ceaa0 <[ehci-hcd].data.end+61/1621>
Trace; e08cea40 <[ehci-hcd].data.end+1/1621>
Trace; e08cea40 <[ehci-hcd].data.end+1/1621>
Trace; e08cea40 <[ehci-hcd].data.end+1/1621>
Trace; e08bb453 <[usbcore]proc_bulk+1d3/220>
Trace; e08cea40 <[ehci-hcd].data.end+1/1621>

Code;  00000000 Before first symbol
00000000 <_EIP>:
Code;  00000000 Before first symbol
   0:   8b 32                     mov    (%edx),%esi
Code;  00000002 Before first symbol
   2:   8d 47 28                  lea    0x28(%edi),%eax
Code;  00000005 Before first symbol
   5:   39 c2                     cmp    %eax,%edx
Code;  00000007 Before first symbol
   7:   75 d5                     jne    ffffffde <_EIP+0xffffffde>
Code;  00000009 Before first symbol
   9:   5b                        pop    %ebx
Code;  0000000a Before first symbol
   a:   5e                        pop    %esi
Code;  0000000b Before first symbol
   b:   5f                        pop    %edi
Code;  0000000c Before first symbol
   c:   c3                        ret    
Code;  0000000d Before first symbol
   d:   8d b4 26 00 00 00 00      lea    0x0(%esi,1),%esi

Oct 26 11:32:46 TK150122 kernel: Machine check exception polling timer started.
Oct 26 11:32:46 TK150122 kernel:  WARNING: unexpected IO-APIC, please mail
Oct 26 11:32:46 TK150122 kernel: 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html

1 warning issued.  Results may not be reliable.

^ permalink raw reply

* Re: possible use-after-free in 2.5.44 scsi changes
From: Jens Axboe @ 2002-10-26  9:29 UTC (permalink / raw)
  To: James Bottomley
  Cc: Badari Pulavarty, Andrew Morton, linux-scsi@vger.kernel.org,
	Martin J. Bligh, Doug Ledford
In-Reply-To: <200210260013.g9Q0DP105454@localhost.localdomain>

On Fri, Oct 25 2002, James Bottomley wrote:
> pbadari@us.ibm.com said:
> > I Just tried the patch. No Luck. I get same panic as before... I am
> > using qla2x00src-v6.03.00b6 driver on qla2200 fc controllers. 
> 
> Well, yours may be a qla bug.
> 
> However, I've tracked down my hang problem:  If a command is pushed back into 
> the block queue as a REQ_SPECIAL using the blk_insert_request() API, it never 
> has REQ_CMD cleared.  Eventually it comes back into scsi_request_fn() with 
> both REQ_CMD and REQ_SPECIAL set.  This causes the I/O to be initialised again.
> 
> The fix is to clear REQ_CMD in blk_insert_request().

Irk no, you cannot just clear valid information! This is _not_ a fix,
it's a hack.

Use a different flag, or maybe use REQ_DONTPREP or similar.

-- 
Jens Axboe


^ permalink raw reply

* [PATCH] fusion scsi fixup
From: Peter Chubb @ 2002-10-26  9:34 UTC (permalink / raw)
  To: linux-kernel; +Cc: Alan Cox


Hi, for those who have to use the Fusion fibrechannel driver, here's a
fix for 2.5.44.  It seems to work, but I have no idea if it's really
correct...  Alan, you said you intended to look into this.  Maybe this
patch will help.

--- linux-2.5.44/drivers/message/fusion/mptscsih.c	2002-10-26 19:31:03.000000000 +1000
+++ linux-2.5-ia64/drivers/message/fusion/mptscsih.c	2002-10-26 19:31:04.000000000 +1000
@@ -1295,10 +1295,6 @@
 #endif
 				sh->this_id = this->pfacts[portnum].PortSCSIID;
 
-				/* OS entry to allow host drivers to force
-				 * a queue depth on a per device basis.
-				 */
-				sh->select_queue_depths = mptscsih_select_queue_depths;
 				/* Required entry.
 				 */
 				sh->unique_id = this->id;
@@ -3668,23 +3664,15 @@
  *	Called once per device the bus scan. Use it to force the queue_depth
  *	member to 1 if a device does not support Q tags.
  */
-void
-mptscsih_select_queue_depths(struct Scsi_Host *sh, Scsi_Device *sdList)
+int
+mptscsih_slave_attach(Scsi_Device *device)
 {
-	struct scsi_device	*device;
+	struct Scsi_Host	*host = device->host;
 	VirtDevice		*pTarget;
 	MPT_SCSI_HOST		*hd;
 	int			 ii, max;
 
-	for (device = sdList; device != NULL; device = device->next) {
-
-		if (device->host != sh)
-			continue;
-
-		hd = (MPT_SCSI_HOST *) sh->hostdata;
-		if (hd == NULL)
-			continue;
-
+	hd = (MPT_SCSI_HOST *)host->hostdata;
 		if (hd->Targets != NULL) {
 			if (hd->is_spi)
 				max = MPT_MAX_SCSI_DEVICES;
@@ -3694,11 +3682,11 @@
 			for (ii=0; ii < max; ii++) {
 				pTarget = hd->Targets[ii];
 				if (pTarget && !(pTarget->tflags & MPT_TARGET_FLAGS_Q_YES)) {
-					device->queue_depth = 1;
-				}
+				scsi_adjust_queue_depth(device, 0, 1);
 			}
 		}
 	}
+	return 0;
 }
 
 /*=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=*/
--- linux-2.5.44/drivers/message/fusion/mptscsih.h	2002-10-26 19:31:42.000000000 +1000
+++ linux-2.5-ia64/drivers/message/fusion/mptscsih.h	2002-10-26 19:31:42.000000000 +1000
@@ -206,11 +206,11 @@
 #define x_scsi_dev_reset	mptscsih_dev_reset
 #define x_scsi_host_reset	mptscsih_host_reset
 #define x_scsi_bios_param	mptscsih_bios_param
-#define x_scsi_select_queue_depths	mptscsih_select_queue_depths
 
 #define x_scsi_taskmgmt_bh	mptscsih_taskmgmt_bh
 #define x_scsi_old_abort	mptscsih_old_abort
 #define x_scsi_old_reset	mptscsih_old_reset
+#define x_scsi_slave_attach	mptscsih_slave_attach
 
 /*=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=*/
 /*
@@ -234,8 +234,8 @@
 #else
 extern	int		 x_scsi_bios_param(Disk *, kdev_t, int *);
 #endif
-extern	void		 x_scsi_select_queue_depths(struct Scsi_Host *, Scsi_Device *);
 extern	void		 x_scsi_taskmgmt_bh(void *);
+extern	int		 x_scsi_slave_attach(Scsi_Device *);
 
 #if LINUX_VERSION_CODE < KERNEL_VERSION(2,3,0)
 #define PROC_SCSI_DECL
@@ -248,53 +248,45 @@
 #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,5,1)
 
 #define MPT_SCSIHOST {						\
-	next:				NULL,			\
 	PROC_SCSI_DECL						\
-	name:				"MPT SCSI Host",	\
-	detect:				x_scsi_detect,		\
-	release:			x_scsi_release,		\
-	info:				x_scsi_info,		\
-	command:			NULL,			\
-	queuecommand:			x_scsi_queuecommand,	\
-	eh_strategy_handler:		NULL,			\
-	eh_abort_handler:		x_scsi_abort,		\
-	eh_device_reset_handler:	x_scsi_dev_reset,	\
-	eh_bus_reset_handler:		x_scsi_bus_reset,	\
-	eh_host_reset_handler:		x_scsi_host_reset,	\
-	bios_param:			x_scsi_bios_param,	\
-	can_queue:			MPT_SCSI_CAN_QUEUE,	\
-	this_id:			-1,			\
-	sg_tablesize:			MPT_SCSI_SG_DEPTH,	\
-	max_sectors:			MPT_SCSI_MAX_SECTORS,   \
-	cmd_per_lun:			MPT_SCSI_CMD_PER_LUN,	\
-	unchecked_isa_dma:		0,			\
-	use_clustering:			ENABLE_CLUSTERING,	\
+	.name				= "MPT SCSI Host",	\
+	.detect				= x_scsi_detect,	\
+	.release			= x_scsi_release,	\
+	.info				= x_scsi_info,		\
+	.queuecommand			= x_scsi_queuecommand,	\
+	.slave_attach			= x_scsi_slave_attach,	\
+	.eh_abort_handler		= x_scsi_abort,		\
+	.eh_device_reset_handler	= x_scsi_dev_reset,	\
+	.eh_bus_reset_handler		= x_scsi_bus_reset,	\
+	.eh_host_reset_handler		= x_scsi_host_reset,	\
+	.bios_param			= x_scsi_bios_param,	\
+	.can_queue			= MPT_SCSI_CAN_QUEUE,	\
+	.this_id			= -1,			\
+	.sg_tablesize			= MPT_SCSI_SG_DEPTH,	\
+	.max_sectors			= MPT_SCSI_MAX_SECTORS,	\
+	.cmd_per_lun			= MPT_SCSI_CMD_PER_LUN,	\
+	.use_clustering			= ENABLE_CLUSTERING,	\
 }
 
 #else  /* LINUX_VERSION_CODE >= KERNEL_VERSION(2,5,1) */
 
 #define MPT_SCSIHOST {						\
-	next:				NULL,			\
 	PROC_SCSI_DECL						\
-	name:				"MPT SCSI Host",	\
-	detect:				x_scsi_detect,		\
-	release:			x_scsi_release,		\
-	info:				x_scsi_info,		\
-	command:			NULL,			\
-	queuecommand:			x_scsi_queuecommand,	\
-	eh_strategy_handler:		NULL,			\
-	eh_abort_handler:		x_scsi_abort,		\
-	eh_device_reset_handler:	x_scsi_dev_reset,	\
-	eh_bus_reset_handler:		x_scsi_bus_reset,	\
-	eh_host_reset_handler:		NULL,			\
-	bios_param:			x_scsi_bios_param,	\
-	can_queue:			MPT_SCSI_CAN_QUEUE,	\
-	this_id:			-1,			\
-	sg_tablesize:			MPT_SCSI_SG_DEPTH,	\
-	cmd_per_lun:			MPT_SCSI_CMD_PER_LUN,	\
-	unchecked_isa_dma:		0,			\
-	use_clustering:			ENABLE_CLUSTERING,	\
-	use_new_eh_code:		1			\
+	.name				= "MPT SCSI Host",	\
+	.detect				= x_scsi_detect,	\
+	.release			= x_scsi_release,	\
+	.info				= x_scsi_info,		\
+	.queuecommand			= x_scsi_queuecommand,	\
+	.eh_abort_handler		= x_scsi_abort,		\
+	.eh_device_reset_handler	= x_scsi_dev_reset,	\
+	.eh_bus_reset_handler		= x_scsi_bus_reset,	\
+	.bios_param			= x_scsi_bios_param,	\
+	.can_queue			= MPT_SCSI_CAN_QUEUE,	\
+	.this_id			= -1,			\
+	.sg_tablesize			= MPT_SCSI_SG_DEPTH,	\
+	.cmd_per_lun			= MPT_SCSI_CMD_PER_LUN,	\
+	.use_clustering			= ENABLE_CLUSTERING,	\
+	.use_new_eh_code		= 1			\
 }
 
 #endif /* LINUX_VERSION_CODE >= KERNEL_VERSION(2,5,1) */
@@ -302,23 +294,20 @@
 #else /* MPT_SCSI_USE_NEW_EH */
 
 #define MPT_SCSIHOST {						\
-	next:				NULL,			\
 	PROC_SCSI_DECL						\
-	name:				"MPT SCSI Host",	\
-	detect:				x_scsi_detect,		\
-	release:			x_scsi_release,		\
-	info:				x_scsi_info,		\
-	command:			NULL,			\
-	queuecommand:			x_scsi_queuecommand,	\
-	abort:				x_scsi_old_abort,	\
-	reset:				x_scsi_old_reset,	\
-	bios_param:			x_scsi_bios_param,	\
-	can_queue:			MPT_SCSI_CAN_QUEUE,	\
-	this_id:			-1,			\
-	sg_tablesize:			MPT_SCSI_SG_DEPTH,	\
-	cmd_per_lun:			MPT_SCSI_CMD_PER_LUN,	\
-	unchecked_isa_dma:		0,			\
-	use_clustering:			ENABLE_CLUSTERING	\
+	.name				= "MPT SCSI Host",	\
+	.detect				= x_scsi_detect,	\
+	.release			= x_scsi_release,	\
+	.info				= x_scsi_info,		\
+	.queuecommand			= x_scsi_queuecommand,	\
+	.abort				= x_scsi_old_abort,	\
+	.reset				= x_scsi_old_reset,	\
+	.bios_param			= x_scsi_bios_param,	\
+	.can_queue			= MPT_SCSI_CAN_QUEUE,	\
+	.this_id			= -1,			\
+	.sg_tablesize			= MPT_SCSI_SG_DEPTH,	\
+	.cmd_per_lun			= MPT_SCSI_CMD_PER_LUN,	\
+	.use_clustering			= ENABLE_CLUSTERING	\
 }
 #endif  /* MPT_SCSI_USE_NEW_EH */
 

^ permalink raw reply

* possible patch regarding problems parsing /etc/protocols
From: Per Jessen @ 2002-10-26  9:26 UTC (permalink / raw)
  To: linux-diald

[-- Attachment #1: Type: text/plain, Size: 578 bytes --]

All,
I'm sure there is a reason why utils.c isn't using the getservent/getprotoent services from netdb.h - 
maybe platform related ? I don't know - but here is a patch that 1) uses those services for accessing
/etc/protocols and /etc/services, and thereby fixes the minor problem with comments in either file.
At least it works on Linux. 

http://mitglied.lycos.de/pjessen/patches/patch-diald-1.0-utils

-- 

regards,
Per Jessen, Zurich
http://www.enidan.com - home of the J1 serial console.

Genius may have its limitations, but stupidity is not thus handicapped.

[-- Attachment #2: patch-diald-1.0-utils --]
[-- Type: text/x-diff, Size: 1060 bytes --]

--- diald-1.0/utils.c	Sat Jun 16 21:51:39 2001
+++ diald-1.0.pj/utils.c	Sat Oct 26 10:50:57 2002
@@ -2,6 +2,7 @@
 
 #include <diald.h>
 
+#include <netdb.h>
 
 /* Grumble. Attempt to generate a nicely formatted ascii date without
  * a built in newline.
@@ -35,6 +36,35 @@
     return i;
 }
 
+int getprotocol(const char *name)
+{
+        struct protoent *p;
+
+        return  NULL!=(p=getprotobyname(name)) ? p->p_proto : 0;
+}
+
+char *getprotonumber(int proto)
+{
+        static char buf[16];
+        struct protoent *p;
+
+        if ( NULL!=(p=getprotobynumber(proto)) )
+                strcpy(buf,p->p_name);
+        else
+                sprintf(buf, "%d", proto);
+
+        return buf;
+}
+
+
+int getservice(const char *name, const char *proto)
+{
+        struct servent *service;
+
+        return  NULL!=(service=getservbyname( name, proto)) ? ntohs(service->s_port) : 0;
+}
+
+#if 0
 struct proto {
 	char *name;
 	int proto;
@@ -151,6 +181,7 @@
         }
     return 0;
 }
+#endif
 
 #if 0
 /* Stuff needed because to keep checker happy,

^ permalink raw reply

* Re: loadlin with 2.5.?? kernels
From: Eric W. Biederman @ 2002-10-26  9:24 UTC (permalink / raw)
  To: Mike Galbraith; +Cc: robert w hall, Thomas Molina, linux-kernel
In-Reply-To: <5.1.0.14.2.20021026073915.00b55008@pop.gmx.net>

Mike Galbraith <efault@gmx.de> writes:

> At 11:20 PM 10/25/2002 -0600, Eric W. Biederman wrote:
> >Mike Galbraith <efault@gmx.de> writes:
> >
> > > I went back and double-checked my loadlin version, and it turned out I was
> > > actually using 1.6a due to a fat finger.  Version 1.6c booted fine (only one
> 
> > > kernel tested) without Eric's help.  1.6a definitely needs Eric's help to
> > boot.
> >
> >Darn.  I guess the arguments for my patch may not be quite as good,
> >but I still think it may be worth while.
> 
> Well, cleanup is always a pretty fine argument.  Since there only seem to be two
> 
> of us loadlin users, you probably didn't loose much argument wise ;-) The other
> 
> loadlin user reported failure at .38, so maybe your patch is needed sometimes
> even with loadlin-1.6c.  (other loadlin user listening?)

Robert thanks for your reply.

I just looked at what the loadlin 1.6c code does, and it's heuristic
is just slightly more reliable.  It assumes %ds is %cs+8....  That
happens to work but there is nothing in the kernel keeping that from
being broken.  So in practice it looks to be worthwhile to stabilize 
this interface.  So loadlin, and other bootloaders can work by design
and not by chance.

Eric

^ permalink raw reply

* can't compile simple netfilter hook
From: Bogdan DUMITRIU @ 2002-10-26  9:03 UTC (permalink / raw)
  To: netfilter

[-- Attachment #1: Type: text/plain, Size: 4538 bytes --]

I have tried to compile the following netfilter hook (found in one of the documents listed in the documentation area at www.netfilter.org) and I just can't make it.

Here's how I tried to compile it:

gcc -c -I/lib/modules/`uname -r`/build/include ./netmod.c -Wall

Here's the error I got:

In file included from ./netfmod.c:4:
/lib/modules/2.4.18-4GB/build/include/linux/netfilter_ipv4.h:53: `INT_MIN' undeclared here (not in a function)
/lib/modules/2.4.18-4GB/build/include/linux/netfilter_ipv4.h:53: enumerator value for `NF_IP_PRI_FIRST' not integer constant
/lib/modules/2.4.18-4GB/build/include/linux/netfilter_ipv4.h:59: `INT_MAX' undeclared here (not in a function)
/lib/modules/2.4.18-4GB/build/include/linux/netfilter_ipv4.h:59: enumerator value for `NF_IP_PRI_LAST' not integer constant
./netfmod.c:12: warning: `struct net_device' declared inside parameter list
./netfmod.c:12: warning: its scope is only this definition or declaration, which is probably not what you want.
./netfmod.c:12: warning: `struct sk_buff' declared inside parameter list
./netfmod.c: In function `stupid_hook':
./netfmod.c:14: dereferencing pointer to incomplete type
./netfmod.c: At top level:
./netfmod.c:21: variable `stupid_ops' has initializer but incomplete type
./netfmod.c:21: extra brace group at end of initializer
./netfmod.c:21: (near initialization for `stupid_ops')
./netfmod.c:21: `NULL' undeclared here (not in a function)
./netfmod.c:21: `NULL' undeclared here (not in a function)
./netfmod.c:21: warning: excess elements in struct initializer
./netfmod.c:21: warning: (near initialization for `stupid_ops')
./netfmod.c:21: warning: excess elements in struct initializer
./netfmod.c:21: warning: (near initialization for `stupid_ops')
./netfmod.c:21: `PF_INET' undeclared here (not in a function)
./netfmod.c:21: warning: excess elements in struct initializer
./netfmod.c:21: warning: (near initialization for `stupid_ops')
./netfmod.c:21: warning: excess elements in struct initializer
./netfmod.c:21: warning: (near initialization for `stupid_ops')
./netfmod.c:21: warning: excess elements in struct initializer
./netfmod.c:21: warning: (near initialization for `stupid_ops')
./netfmod.c:23: parse error before `init'
./netfmod.c:24: warning: return-type defaults to `int'
./netfmod.c: In function `init':
./netfmod.c:25: warning: implicit declaration of function `nf_register_hook'
./netfmod.c: At top level:
./netfmod.c:28: parse error before `fini'
./netfmod.c:29: warning: return-type defaults to `int'
./netfmod.c: In function `fini':
./netfmod.c:30: warning: implicit declaration of function `nf_unregister_hook'
./netfmod.c:30: `linuxmag_ops' undeclared (first use in this function)
./netfmod.c:30: (Each undeclared identifier is reported only once
./netfmod.c:30: for each function it appears in.)
./netfmod.c:31: warning: control reaches end of non-void function
./netfmod.c: At top level:
./netfmod.c:33: warning: type defaults to `int' in declaration of `module_init'
./netfmod.c:33: warning: parameter names (without types) in function declaration
./netfmod.c:33: warning: data definition has no type or storage class
./netfmod.c:34: warning: type defaults to `int' in declaration of `module_exit'
./netfmod.c:34: warning: parameter names (without types) in function declaration
./netfmod.c:34: warning: data definition has no type or storage class 

Here is the code in netmod.c:

/* Rusty's Dumb netfilter hook example */
#include <linux/config.h>
#include <linux/module.h>
#include <linux/netfilter_ipv4.h>
#include <linux/ip.h>

/* The work comes in here from netfilter.c. */
static unsigned int
stupid_hook(unsigned int hook,
           struct sk_buff **pskb,
           const struct net_device *indev,
           const struct net_device *outdev,
           int (*okfn)(struct sk_buff *))
{
       if ((*pskb)->len == 200)
               return NF_DROP;

       return NF_ACCEPT;
}

static struct nf_hook_ops stupid_ops
= { { NULL, NULL }, stupid_hook, PF_INET, NF_IP_POST_ROUTING, 0 };

static int __init init(void)
{
        return nf_register_hook(&stupid_ops);
}

static void __exit fini(void)
{
        nf_unregister_hook(&linuxmag_ops);
}

module_init(init);
module_exit(fini);

I run a SuSE 8.0 Linux, kernel version 2.4.18, gcc version 2.95.3.

Please help with this as I need it for a school project and I can't get to actually doing what I have to do because I just can't make this work.

Thanks.
Bogdan.

[-- Attachment #2: Type: text/html, Size: 6452 bytes --]

^ permalink raw reply

* Re: highres timers question...
From: george anzinger @ 2002-10-26  9:07 UTC (permalink / raw)
  To: landley; +Cc: jim.houston, linux-kernel
In-Reply-To: <200210251353.58577.landley@trommello.org>

Rob Landley wrote:
> 
> I'm guessing that of the patches here:
> 
> http://sourceforge.net/projects/high-res-timers
> 
> The -posix one adds posix support on top of the base high-res timers patch?
> 
> (Did I guess right?)

Uh, no.  We made the command decision that even IF he does
not let in the high-res stuff we would like the POSIX API in
the kernel.  Thus the patches are structured to require the
POSIX patch first.  This can be changed if need be, but that
is the way it is now.
> 
> Rob
> 
> --
> http://penguicon.sf.net - Terry Pratchett, Eric Raymond, Pete Abrams, Illiad,
> CmdrTaco, liquid nitrogen ice cream, and caffienated jello.  Well why not?

-- 
George Anzinger   george@mvista.com
High-res-timers: 
http://sourceforge.net/projects/high-res-timers/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml

^ permalink raw reply

* Re: "mount" bug
From: jb1 @ 2002-10-26  8:55 UTC (permalink / raw)
  To: Harry Kalogirou; +Cc: Linux-8086
In-Reply-To: <1035545532.5491.4.camel@cool>

On 25 Oct 2002, Harry Kalogirou wrote:

> > /dev/fd1 seems to mount, but be inaccessible.
> > 
> > After booting ELKS 0.1.1 from a 3-1/2" diskette in /dev/fd0, "mkdir /mnt",
> > "ls -l /" shows 2 hard links and a 32-byte size for mnt.
> > 
> > "mount /dev/fd1 /mnt", when /dev/fd1 contains a 5-1/4" ELKS diskette,
> > shows:
> > fd: probing disc in /dev/fd1
> > fd: /dev/fd1 probably has 15 sectors and 80 cylinders
> > MINIX-fs: mounting unchecked file system, running fsck is recommended.
> > 
> > "ls -l /" now shows 10 hard links and a 160-byte size for mnt.
> > 
> > "ls /mnt" now shows:
> > /mnt:
> > /mnt/in/sh
> > : No such file or directory
> > 
> > After this point, "meminfo" shows *more* free and the system rapidly
> > deteriorates ("Cannot fork", a blank commandline prompt, a garbage 
> > commandline prompt, etc.)
> > 
> > Changing /mnt's permissions, owner and group don't help. Interchanging the 
> > 3-1/2" and 5-1/4" drives didn't help, although there were more error 
> > messages from mount. Using 5-1/4" drives for both /dev/fd0 and /dev/fd1 
> > (with an ELKS 0.1.0 diskette in /dev/fd1) didn't help.
> > 
> 
> I tried it on my machine, but with 2 3-1/2 drives and it works fine.

This was my fault; since the machine was happily using both floppy drives 
under Windows 95 I didn't bother to run the BIOS Setup program. While 
checking the "impossible" I discovered that it was set up for only for a 
1.2M first drive. After correcting this to 1.44M first drive and 1.2M 
second drive, it worked.

This leads to an interesting question: is the fact the floppy mounted, but 
was otherwise inaccessible a bug or a feature? If ELKS should be handling 
all possible low-level functions then it's a bug in the mount() function 
(presumably in the kernel). If mount invokes the ROM BIOS to reduce the 
size of the kernel then it's a feature, and perhaps it could be reduced 
further by using the ROM BIOS for more of the diskette-handling (which 
might have made the diskette accessible despite my incorrect settings).

I now think the "Cannot fork", reduced free memory and deteriorating
system are *not* diagnostic of an incorrect BIOS setup, but rather a
hardware incompatibility and maybe an ELKS bug revealed by the
incompatibility. The system on which this occurred has a VL-Bus/EISA
motherboard and a "bootable" EISA SCSI card. I noticed that when I
repeated "ps" its process ID jumped by large amounts, and the problems
occurred when the process ID was displayed as a negative number, after
which the init process disappeared entirely; I also saw two "init" entries
once. I suspect the hardware is somehow spawning, then killing new init
processes frequently, and that when the process ID is negative (or maybe
when it rolls over to positive again) killing the second init also kills
the first. "Cannot fork" seems to appear when there's no active init
process. I'll investigate further, but these should have their own threads
in the mailing list.


^ permalink raw reply

* cpufreq: Intel(R) SpeedStep(TM) for this processor not (yet) available
From: Marc Giger @ 2002-10-26  8:56 UTC (permalink / raw)
  To: linux-kernel

Hi list, Hi Dominik

Why is cpufreq on my laptop not available? I know it works with window$.
My laptop has an Intel P3 speedstep cpu which supports 600Mhz and 500Mhz clock frequency. Will it be supported in the future?

Some additional infos:

cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 8
model name      : Pentium III (Coppermine)
stepping        : 3
cpu MHz         : 595.577
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr sse
bogomips        : 1189.47


lspci -v
00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 03)
        Subsystem: Sony Corporation: Unknown device 806f
        Flags: bus master, medium devsel, latency 64
        Memory at 40000000 (32-bit, prefetchable) [size=16M]
        Capabilities: [a0] AGP version 1.0

00:01.0 PCI bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 03) (prog-if 00 [Normal decode])
        Flags: bus master, 66Mhz, medium devsel, latency 128
        Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
        Memory behind bridge: fe800000-fecfffff
        Prefetchable memory behind bridge: fd000000-fdffffff

00:07.0 ISA bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 02)
        Flags: bus master, medium devsel, latency 0

00:07.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01) (prog-if 80 [Master])
        Flags: bus master, medium devsel, latency 64
        I/O ports at fc90 [size=16]

00:07.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01) (prog-if 00 [UHCI])
        Flags: bus master, medium devsel, latency 64, IRQ 9
        I/O ports at fca0 [size=32]

00:07.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 03)
        Flags: medium devsel, IRQ 9

00:08.0 FireWire (IEEE 1394): Sony Corporation CXD3222 i.LINK Controller (rev 02) (prog-if 10 [OHCI])
        Subsystem: Sony Corporation: Unknown device 8071
        Flags: bus master, medium devsel, latency 64, IRQ 9
        Memory at fedf7000 (32-bit, non-prefetchable) [size=2K]
        Memory at fedf7c00 (32-bit, non-prefetchable) [size=512]
        Expansion ROM at <unassigned> [disabled] [size=64K]
        Capabilities: [dc] Power Management version 1

00:09.0 Multimedia audio controller: Yamaha Corporation YMF-744B [DS-1S Audio Controller] (rev 02)
        Subsystem: Sony Corporation: Unknown device 8072
        Flags: bus master, medium devsel, latency 64, IRQ 9
        Memory at fedf8000 (32-bit, non-prefetchable) [size=32K]
        I/O ports at fcc0 [size=64]
        I/O ports at fc8c [size=4]
        Capabilities: [50] Power Management version 1

00:0a.0 Communication controller: Conexant HSF 56k Data/Fax Modem (Mob WorldW SmartDAA) (rev 01)
        Subsystem: Sony Corporation Modem
        Flags: medium devsel, IRQ 9
        Memory at fede0000 (32-bit, non-prefetchable) [size=64K]
        I/O ports at fc78 [size=8]
        Capabilities: [40] Power Management version 2

00:0c.0 CardBus bridge: Ricoh Co Ltd RL5c478 (rev 80)
        Subsystem: Sony Corporation: Unknown device 8073
        Flags: bus master, medium devsel, latency 168, IRQ 9
        Memory at 10000000 (32-bit, non-prefetchable) [size=4K]
        Bus: primary=00, secondary=02, subordinate=05, sec-latency=176
        Memory window 0: 10400000-107ff000 (prefetchable)
        Memory window 1: 10800000-10bff000
        I/O window 0: 00004000-000040ff
        I/O window 1: 00004400-000044ff
        16-bit legacy interface ports at 0001

00:0c.1 CardBus bridge: Ricoh Co Ltd RL5c478 (rev 80)
        Subsystem: Sony Corporation: Unknown device 8073
        Flags: bus master, medium devsel, latency 168, IRQ 9
        Memory at 10001000 (32-bit, non-prefetchable) [size=4K]
        Bus: primary=00, secondary=06, subordinate=09, sec-latency=176
        Memory window 0: 10c00000-10fff000 (prefetchable)
        Memory window 1: 11000000-113ff000
        I/O window 0: 00004800-000048ff
        I/O window 1: 00004c00-00004cff
        16-bit legacy interface ports at 0001

01:00.0 VGA compatible controller: Neomagic Corporation [MagicMedia 256AV+] (rev 30) (prog-if 00 [VGA])
        Subsystem: Sony Corporation: Unknown device 80a2
        Flags: bus master, fast Back2Back, medium devsel, latency 128, IRQ 9
        Memory at fd000000 (32-bit, prefetchable) [size=16M]
        Memory at fe800000 (32-bit, non-prefetchable) [size=4M]
        Memory at fec00000 (32-bit, non-prefetchable) [size=1M]
        Capabilities: [dc] Power Management version 1

06:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
        Subsystem: Realtek Semiconductor Co., Ltd. RT8139
        Flags: bus master, medium devsel, latency 64, IRQ 9
        I/O ports at 4800 [size=256]
        Memory at 11000000 (32-bit, non-prefetchable) [size=512]
        Capabilities: [50] Power Management version 2

Thank you

Kind regards

Marc

^ permalink raw reply

* Re: Crunch time -- the musical.  (2.5 merge candidate list 1.5)
From: george anzinger @ 2002-10-26  8:45 UTC (permalink / raw)
  To: landley; +Cc: jim.houston, linux-kernel
In-Reply-To: <200210251458.21284.landley@trommello.org>

Rob Landley wrote:
> 
> On Thursday 24 October 2002 19:25, Jim Houston wrote:
> > Hi Rob,
> >
> > The Posix timers entry in your list is confused.  I don't know how
> > my patch got the name Google.
> 
> Sorry, misread "George's version" as "Google's version" at 5 am one morning.
> Lot of late nights recently... :)
> 
> > I think Dan Kegel misunderstood George's answer to my previous
> > announcement.  George might be picking up some of my changes, but there
> > will still be two patches for Linus to choose from.  You included the URL to
> > George's answer which quoted my patch, rather than the URL I sent you.
> 
> Had it in, then took it out.  I'm trying to collate down the list wherever I
> can.
> 
> > Here is the URL for an archived copy of my latest patch:
> >      Jim Houston's  [PATCH] alternate Posix timer patch3
> >      http://marc.theaimsgroup.com/?l=linux-kernel&m=103549000027416&w=2
> 
> It's back now.
> 
> > I would be happy to see either version go into 2.5.
> 
> So what exactly is the difference between them?

First, to answer your question about the order of things in
my patches.  The 4 patches should be applied in this order:

First, the posix patch.  It introduces the POSIX clocks &
timers to the system.  It is not high res and stands alone. 
The rest of the patches are all about doing the high res
timers:

The 3 parts to the high res timers are:
 core           The core kernel (i.e. platform independent)
changes
 i386           The high-res changes for the i386 (x86)
platform
 posixhr        The changes to the POSIX clocks & timers
patch to
use high-res timers

This last is almost entirely contained to the one file
(.../kernel/posix_timers.c).  The "almost" is because it
adds a member to the posix timers structure which is defined
in sched.h.

Now, as to the differences between my patches and Jim's. 
Jim's patch is an alternate for the first or "posix" patch
only.  Since I picked up a variation on his id allocator,
thus removing the configuration option for the maximum
number of timers, the principle difference is that Jim keeps
the posix timers in a separate list, where as, my patch puts
them in the same list (i.e. the add_timer list) as all other
timers.  I assume (not having looked in detail at his latest
patch) that he uses the systems add_timers to drive the
timers in this list, and thus has a two stage expiry
algorithm (a. the add_timer pop which then, b. causes a
check of this new list).

Jim has also attempted to address the clock_nanosleep()
interaction with signals problem.  In short, the standard
says that signals that do not actually cause a handler in
the user code to run are NOT supposed to interrupt a sleep. 
The straight forward way to do this is to interrupt the
sleep on the signal, call do_signal() to deliver the signal
and check the return to see if it invoked a user handler (it
returns 1 in this case, else 0) and either continue the
sleep or return.  The problem is that do_signal() requires
&regs as a parameter and this is passed in different ways,
in the various platforms, to system calls.  ALL other system
calls that call do_signal() reside in platform dependent
code, most likely for this reason.

My solution for this problem is to provide a couple of
macros in linux/signal.h and linux/asm-i386/signal.h to
define the entry sequence for clock_nanosleep (and nanosleep
as it is now just a call to clock_nanosleep).  The macros in
linux/signal.h are general purpose and do NOT actually solve
the problem, but they do allow other platforms to work,
although, without the standard required signal handling. 
These are only defined if the asm/signal.h does not supply
an alternative.  This allows each platform to customize the
entry to clock_nanosleep() to pass in regs in what ever way
works for that platform.  I fully admit that this is a VERY
messy bit of code, BUT at the same time, it works.  I am
fully prepared to change to a cleaner solution should one
arise.

Jim has NOT provided high res timers as yet, and thus does
not have any code to replace the 3 high res patches.  I
don't know if he is attempting to do this code.  I suspect
he is not, but he did indicate that he wants to expand his
posix timers to be high res.  If he does this, I suspect
that it would be his version of the "hrposix" patch.
> 
> > The URLs for George's patches are incomplete.  I believe this is the
> > most recent (it's from Oct 18).  The Sourceforge.net reference has the
> > user space library and test programs, but I did not see 2.5 kernel
> > patches.
> >
> >   [PATCH ] POSIX clocks & timers take 3 (NOT HIGH RES)
> >      http://marc.theaimsgroup.com/?l=linux-kernel&m=103489669622397&w=2
> 
> He's up to version 4 now.

As I said in another post, don't trust these archives, they
truncate long posts to less than what the lklm allows.  In
particular, they have truncated my patches.  The full set of
4 patches are available here:

 http://sourceforge.net/projects/high-res-timers/

or, to save a few clicks:

http://sourceforge.net/project/showfiles.php?group_id=20460&release_id=118345

Please do read the notes, they tell about the order of
application, which is fixed, i.e.:
hrtimers-posix  The posix clock/ timers interface, low res.
hrtimers-core   The core system high res patch.
hrtimers-i386   The high res code for the i386 platform.
hrtimers-hrposix The patch to move the low res posix patch
                 to high res.


-- 
George Anzinger   george@mvista.com
High-res-timers: 
http://sourceforge.net/projects/high-res-timers/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml

^ permalink raw reply

* Occasional TCP checksum errors with qdisc
From: Chris Edwards @ 2002-10-26  8:43 UTC (permalink / raw)
  To: linux-kernel

Hi,

I've been developing a kernel module which acts as a queuing discipline,
and modifies TCP packets to include an extra option. This obviously
involves updating the checksums. It looked like it was all working fine,
but occasionally packets get the wrong TCP checksum! I've only been able to
reproduce this when talking to a remote solaris 8 machine. Running gigs
of data against local Linux machines produces nothing! The IP checksum
is always correct, even though it too is modified.

Most of the code was taken from the ipt_TCPMSS module, which performs a
similar task. I've included the relevant bit of code below:. I can send
the full module if that helps. 

Also, I've tried performing a full checksum on the packet and that
seemed to produce the same checksums as the code below, and obviously
that didn't work!

Any help would be greatly appreciated!! I suspect something happens with
qdiscs which I don't know about. The strange thing is that it very
rarely causes problems.

Chris


        if (skb_tailroom(skb) >= TCPOLEN_QSIZE &&
                        skb->len <= (sch->dev->mtu - TCPOLEN_QSIZE)) {
                struct tcphdr *tcph;
                struct iphdr *iph;
                u_int16_t tcplen, newtotlen, oldval;
                u_int16_t pofq;

                u_int8_t *opt;

                iph = skb->nh.iph;
                tcplen = skb->len - iph->ihl * 4;

                tcph = (void *) iph + iph->ihl * 4;

                skb_put(skb, TCPOLEN_QSIZE);

                opt = (u_int8_t *) tcph + sizeof(struct tcphdr);
                memmove(opt + TCPOLEN_QSIZE, opt,
                                tcplen - sizeof(struct tcphdr));

                tcph->check = cheat_check(htons(tcplen) ^ 0xFFFF,
                                htons(tcplen + TCPOLEN_QSIZE),
                        tcph->check);

                tcplen += TCPOLEN_QSIZE;

                /* Fill the extra 4 bytes with our option. */
                opt[0] = TCPO_QSIZE;
                opt[1] = TCPOLEN_QSIZE;

                pofq = evaluatepq(sch);
                opt[2] = (pofq & 0xff00) >> 8;
                opt[3] = (pofq & 0x00ff);

                tcph->check = cheat_check(~0, *((u_int32_t *) opt),
                                tcph->check);

                oldval = ((u_int16_t *) tcph)[6];
                tcph->doff += TCPOLEN_QSIZE / 4; 

                tcph->check = cheat_check(oldval ^ 0xFFFF,
                                ((u_int16_t *) tcph)[6], tcph->check);

                newtotlen = htons(ntohs(iph->tot_len) + 4);
                iph->check = cheat_check(iph->tot_len ^ 0xFFFF,
                                newtotlen, iph->check);
                iph->tot_len = newtotlen;

                /* We need to invalidate the existing checksum, in case
                the
                 * hardware has already produced one. */
                skb->ip_summed = CHECKSUM_NONE;

                return skb;
        }

--
Chris Edwards <chris@edwards.mine.nu>

hippo 18:32:01 up 7 days, 22:47,  6 users,  load average: 0.00, 0.00, 0.00

^ permalink raw reply

* RE: Regarding the resize_reiserfs
From: Narasimha_Subban @ 2002-10-26  8:33 UTC (permalink / raw)
  To: Asheesh Laroia, Narasimha_Subban; +Cc: reiserfs-list

HI,
  Thanks for ur suggestions. In our requirement i shouldn't reboot the
system at any cost. I would appreciate any better way to do without
rebooting the system. 

Thanks and Rgds
Narasimha Subban K.V

> -----Original Message-----
> From:	Asheesh Laroia [SMTP:asheesh@asheesh.org]
> Sent:	Saturday, October 26, 2002 12:18 PM
> To:	Narasimha_Subban
> Cc:	reiserfs-list@namesys.com
> Subject:	Re: [reiserfs-list] Regarding the resize_reiserfs
> 
> Under Linux, you may need to restart your computer to have the new
> partition size show up for /dev/hd*.  (At least, I know we had to do that
> back in the 2.2.x days.)
> 
> So, try restarting (and I mean re-initializing the kernel, not just going
> to single-user mode) and trying this; that may fix it.
> 
> -- Asheesh.
> 
> On Sat, 26 Oct 2002, Narasimha_Subban wrote:
> 
> > Hi,
> >    I am using the reiserfs-3.6.3 version on Linux-2.4.7-10 kernel
> version. I
> > need some information on resize_reiserfs command.
> > I have a partition (assume /dev/hda8 with 1000 blocks) having reiserfs
> > filesystem.
> > I increased the partition size (Now /dev/hda8 with 2000 blocks) in the
> > partition table using the fdisk command. Now i tried to resize the
> > filesystem using (resize_reiserfs -s+xxM  /dev/hda8) so that increased
> > partition size in partition table is reflected in filesystem. The error
> is
> > as below
> > /dev/hda8 is of XXXXXX blocks size only with reiserfs of XXXXXX blocks
> size
> > on it. You are trying to expant reiserfs up to YYYYYY size. You probably
> > forgot to expand your partition size.
> > But i shouldnot delete the partition bcoz the contents shouldn't be
> lost.
> >    It will be great if anyone gives some ideas to make resize_reiserfs
> work.
> >
> >
> > Thanks and Rgds
> > Narasimha Subban K.V
************************************************************************** 
This email (including any attachments) is intended for the sole use of the
intended recipient/s and may contain material that is CONFIDENTIAL AND
PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or
distribution or forwarding of any or all of the contents in this message is
STRICTLY PROHIBITED. If you are not the intended recipient, please contact
the sender by email and delete all copies; your cooperation in this regard
is appreciated.
**************************************************************************

^ permalink raw reply

* Re: problem with iplimit
From: Romp @ 2002-10-26  8:26 UTC (permalink / raw)
  To: netfilter-devel
In-Reply-To: <03c501c27ad4$9e5ac740$060110ac@localdomain>

> The problem appears every time I try to use this module.
> if I set --limit-above to 2 and try to open third connection, system will drop it (ok).
> But if I try to open this connection again (while previous 2 connections are still active), system will accept it (!).
> Since, almost every connection will be accepted (!).
> Note that if I close all connections, and try to make described test again, all will happen again.
>

the problem (and fix) is also described at
http://lists.netfilter.org/pipermail/netfilter-devel/2002-May/007818.html

unfortunately, the patch provided does not solve the problem (at least for
me)

romp

^ permalink raw reply

* Re: [LARTC] shaping marked packets
From: Stef Coene @ 2002-10-26  8:19 UTC (permalink / raw)
  To: lartc
In-Reply-To: <marc-lartc-103558480315330@msgid-missing>

On Saturday 26 October 2002 00:25, Axel Loewe wrote:
> hi,
>
> i want to decrease the upload-bandwith used by a user with the uid xyz
> (only one programm running under this user), so i mark the packets with
> iptables by adding the following rule:
> iptables -A OUTPUT -t mangle -m owner --uid-owner xxx -j MARK --set-mark 1
> now my problem is what to do after this ;) catch all the packets in an
> extra table but what then? to me it doesn't matter wheter to use cbq or
> htb, but htb seems easier to me ;) how do i add a qdisc that only
> applies to the packets in this special table?
Add a qdisc, add 2 classes (one for the user and one for the rest), give the 
first class less bandwdith, use the fw filter to catch the marked packets and 
put them in the first class, use a second filter (or in case of htb, make the 
second class the default class) to put all other packets in the second class.
If you do that, you can control the traffic of the user like you want.  You 
can even let it use all available bandwidth, but if someone else wants to do 
it, he has to wait.

More info about shaping can be found on www.lartc.org and www.docum.org.  You 
need the fw fitler and cbq or htb to create the qdisc and classes.

Stef

-- 

stef.coene@docum.org
 "Using Linux as bandwidth manager"
     http://www.docum.org/
     #lartc @ irc.oftc.net

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

^ permalink raw reply

* Re: VBox
From: Peter @ 2002-10-26  8:19 UTC (permalink / raw)
  To: linux-newbie
In-Reply-To: <5.1.0.14.1.20021025073755.0218a360@celine>

Thnaks Ray!

ray@comarre.com said:
>  You might also see if the  "respawn" message is preceded in the logs
> by any more specific message  about the process ... such messages
> usually are.

In /var/log/messages I get the following

Oct 25 14:39:29 philonline modprobe: modprobe: Can't locate module 
char-major-43
Oct 25 14:44:30 philonline last message repeated 10 times
Oct 25 14:49:31 philonline last message repeated 10 times
Oct 25 14:54:32 philonline last message repeated 10 times
Oct 25 14:59:33 philonline last message repeated 10 times

when I5:2345:respawn:/usr/sbin/vboxgetty -d /dev/ttyI5
is enabled in inittab.

ray@comarre.com said:
> Does vboxd run  directly as a daemon or through inetd? If the first,
> is it actually  running? If the second, is inetd.conf configured
> proprely? Does either  vboxd or inetd log anything in connection with
> these failed attempts?

The instructions say that vboxd can only be used with inetd for which reason I 
put the following in /etc/inetd.conf:
vboxd  stream  tcp  nowait  root  /usr/sbin/tcpd  /usr/sbin/vboxd
as per instructions.

I have
vbox version 2.0.0BETA5 (17-NOV-98)
and run RH7.2

ray@comarre.com said:
> This URL -- http://www.linuxnetmag.com/en/issue2/m2vbox1.html --
> (found in  2 minutes using Google) has some troubleshooting advice for
> vboxgetty  and  vboxd


I checked this out and tail vboxgetty-ttyI5.log gives

26-Oct 16:04:46 <D> Opening modem port "/dev/ttyI5"...
26-Oct 16:04:46 <F> Can't open modem port "/dev/ttyI5"

after /usr/sbin/vboxgetty -d /dev/ttyI5.

So that what it is. The modem port can't be opened. Then where do we go from 
here?

Regards


-- 
Peter

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

^ permalink raw reply

* Re: loadlin with 2.5.?? kernels
From: robert w hall @ 2002-10-26  8:22 UTC (permalink / raw)
  To: linux-kernel
In-Reply-To: <m13cqtn5cm.fsf@frodo.biederman.org>

In article <m13cqtn5cm.fsf@frodo.biederman.org>, Eric W. Biederman
<ebiederm@xmission.com> writes
>Mike Galbraith <efault@gmx.de> writes:
>I wonder what the change in 1.6b was....
>
>Eric

IIRC - kernel_cs & kernel_ds are taken at runtime rather than from the
header file (segment.h?).
(because win4lin bumps them up from their old default values)

(Wine went to using a similar trick I think)
this is all from fading memory - but it's in the README for 1.6b I think

Bob

-- 
robert w hall

^ permalink raw reply

* Re: running 2.4.2 kernel under 4MB Ram
From: Rogier Wolff @ 2002-10-26  8:13 UTC (permalink / raw)
  To: Alan Cox; +Cc: Amol Kumar Lad, Linux Kernel Mailing List, linux-mm
In-Reply-To: <1035301164.31917.78.camel@irongate.swansea.linux.org.uk>

On Tue, Oct 22, 2002 at 04:39:24PM +0100, Alan Cox wrote:
> On Wed, 2002-10-23 at 01:31, Amol Kumar Lad wrote:
> > It means that I _cannot_ run 2.4.2 on a 4MB box. 
> > Actually my embedded system already has 2.4.2 running on a 16Mb. I was
> > looking for a way to run it in 4Mb. 
> > So Is upgrade to 2.4.19 the only option ??
> 
> You should move to a later kernel anyway 2.4.2 has a lot of bugs
> including some security ones.

If the "embedded system" just brews his coffee, then there are not
many security issues he cares about. It gets the job done. 

Amol, Just add a "mem=4M" to the kernel commandline and see what 
happens. It depends a lot on what and how many applications you run
on that system. 

But still, Alan is right. You might run into odd problems that are
simply fixed if you upgrade. (My workstation was "pretty good" at 
staying up under 2.4.2 (about a month at a time), and I didn't want 
to upgrade, for fear of it getting worse. I upgraded and now get
much better uptimes (until my colleague types "reboot -n -f" into 
the wrong window)). 

		Roger.	

-- 
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* The Worlds Ecosystem is a stable system. Stable systems may experience *
* excursions from the stable situation. We are currently in such an      * 
* excursion: The stable situation does not include humans. ***************
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

^ permalink raw reply

* Re: The return of the return of crunch time (2.5 merge candidate list 1.6)
From: Andreas Dilger @ 2002-10-26  8:13 UTC (permalink / raw)
  To: Andi Kleen; +Cc: Rob Landley, linux-kernel
In-Reply-To: <p7365vptz49.fsf@oldwotan.suse.de>

On Oct 26, 2002  09:53 +0200, Andi Kleen wrote:
> Patches available on request or older versions from 
> ftp://ftp.firstfloor.org/pub/ak/v2.5/nsec*
> They don't actually add ns resolution, but jiffies resolution, which
> is 1ms on 2.5 and should be good enough for now. It reuses reserved fields
> in struct stat and doesn't need any user interface changes.
> 
> It requires editing of a lot of file systems in a straight forward way,
> so should be better done before the stable series starts.
> 
> There are some minor compatbility issues with fs that only support 
> second timestamps like ext2/ext3, see nsec.notes in the ftp directory
> or past threads on that on the list.

Just as an FYI - this is "in the pipes" for ext2/ext3 also, which the
(very basic) support for variable-sized inodes that Ted has already
submitted is the groundwork for (among other things).  We will then have
space to add usec timestamps to ext2/ext3 inodes for people who choose to
have larger inodes (new filesystems only, to start with), and when we get
more efficient EA storage we will also be able to store the "large inode
fields" into EAs for existing filesystems.

Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/


^ permalink raw reply

* Re: running 2.4.2 kernel under 4MB Ram
From: Rogier Wolff @ 2002-10-26  8:13 UTC (permalink / raw)
  To: Alan Cox; +Cc: Amol Kumar Lad, Linux Kernel Mailing List, linux-mm
In-Reply-To: <1035301164.31917.78.camel@irongate.swansea.linux.org.uk>

On Tue, Oct 22, 2002 at 04:39:24PM +0100, Alan Cox wrote:
> On Wed, 2002-10-23 at 01:31, Amol Kumar Lad wrote:
> > It means that I _cannot_ run 2.4.2 on a 4MB box. 
> > Actually my embedded system already has 2.4.2 running on a 16Mb. I was
> > looking for a way to run it in 4Mb. 
> > So Is upgrade to 2.4.19 the only option ??
> 
> You should move to a later kernel anyway 2.4.2 has a lot of bugs
> including some security ones.

If the "embedded system" just brews his coffee, then there are not
many security issues he cares about. It gets the job done. 

Amol, Just add a "mem=4M" to the kernel commandline and see what 
happens. It depends a lot on what and how many applications you run
on that system. 

But still, Alan is right. You might run into odd problems that are
simply fixed if you upgrade. (My workstation was "pretty good" at 
staying up under 2.4.2 (about a month at a time), and I didn't want 
to upgrade, for fear of it getting worse. I upgraded and now get
much better uptimes (until my colleague types "reboot -n -f" into 
the wrong window)). 

		Roger.	

-- 
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* The Worlds Ecosystem is a stable system. Stable systems may experience *
* excursions from the stable situation. We are currently in such an      * 
* excursion: The stable situation does not include humans. ***************

^ permalink raw reply

* [PATCH] PCI should use bios if direct is not detected
From: Jim Radford @ 2002-10-26  8:04 UTC (permalink / raw)
  To: Linux Kernel

In 2.4.10 the pci subsystem stopped using the bios to access the PCI
config space when no direct method is detected even though it does
detect that it *can* use the bios leaving my machine PCI-less :-(.
This patch restores the older saner behavior and shouldn't affect any
working system.

-Jim

diff -Nru linux-2.5.44/arch/i386/pci/direct.c linux-2.5.44-bios/arch/i386/pci/direct.c
--- linux-2.5.44/arch/i386/pci/direct.c    Sat Oct 26 00:39:23 2002
+++ linux-2.5.44-bios/arch/i386/pci/direct.c    Sat Oct 26 00:39:23 2002
@@ -261,7 +261,6 @@
        }

        local_irq_restore(flags);
-       pci_root_ops = NULL;
        return 0;
 }


^ permalink raw reply

* Is there a way to just start a program...
From: Soeren Sonnenburg @ 2002-10-26  7:52 UTC (permalink / raw)
  To: linux-hotplug

Hi!

I have an MMC/CF reader here... I set it up such that whenever the
usb-storage module gets loaded it copies all the stuff on the MMC/CF
card to certain directory and then unmounts the device.

However this happens only once. When the driver is *NOT* already loaded.
So I wonder whether there is some of ACTION (like there is ADD/REMOVE
atm), with which I can just startup programs whenever a device is added.

Thanks,
Soeren.

PS: Infact I want my camera, whenever connected to save all the pictures
in a directory of the current date.




-------------------------------------------------------
This SF.net email is sponsored by: ApacheCon, November 18-21 in
Las Vegas (supported by COMDEX), the only Apache event to be
fully supported by the ASF. http://www.apachecon.com
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

^ permalink raw reply

* Re: The return of the return of crunch time (2.5 merge candidate list 1.6)
From: Andi Kleen @ 2002-10-26  7:53 UTC (permalink / raw)
  To: Rob Landley; +Cc: linux-kernel
In-Reply-To: <200210251557.55202.landley@trommello.org.suse.lists.linux.kernel>

Rob Landley <landley@trommello.org> writes:

I have some patches to offer better than second resolution for stat.
That is needed for parallel make on MP systems, because otherwise it
cannot detect changes that need less than a second to execute. With CPUs
being as fast as they are and getting even faster currently it is becomming 
a bigger problem. You don't hit it that easily with gcc because it's 
getting faster slower than cpus are getting faster so it's usually slower
than a second, but some people use make rules with other compilers or other 
commands.

I see it in the same category as "necessary changes" similar to 32bit dev_t. 

Linux already has several filesystems in tree that support ns or better than s 
resolution in their underlying formats (XFS,JFS,NFSv3,VFAT)

Patches available on request or older versions from 
ftp://ftp.firstfloor.org/pub/ak/v2.5/nsec*
They don't actually add ns resolution, but jiffies resolution, which
is 1ms on 2.5 and should be good enough for now. It reuses reserved fields
in struct stat and doesn't need any user interface changes.

It requires editing of a lot of file systems in a straight forward way,
so should be better done before the stable series starts.

There are some minor compatbility issues with fs that only support 
second timestamps like ext2/ext3, see nsec.notes in the ftp directory
or past threads on that on the list.

-Andi

^ permalink raw reply

* How to run multiple instances of dos for netware access (with SPX) ?
From: G.S.Mohan @ 2002-10-26  7:44 UTC (permalink / raw)
  To: linux-msdos

Dear All,

I would like to know how to run multiple instances of dosemu for netware
access with SPX support enabled.

Is there a workaround for this in dosemu ?

Thanks for any help.

with regards,
:-) G S Mohan


^ permalink raw reply

* RE: respawning too fast
From: fred @ 2002-10-26  7:44 UTC (permalink / raw)
  To: 'Ing.Gianfranco Morandi', LinuxPPC
In-Reply-To: <007c01c27c08$d9bb2b60$0700a8c0@pc005>


Is there a proper define of /dev/console?

-----Original Message-----
From: Ing.Gianfranco Morandi [mailto:gianfranco.morandi@euro-studio.it]
Sent: Friday, October 25, 2002 5:28 PM
To: LinuxPPC
Subject: respawning too fast


Finally I have solved the starting problem on my EST8260 board. I have
burned the flash with the PPCboot 1.20 and I've been able to load any
kernel: M.V. 2.4.2 and ELDK 2.4.4.
Now I was trying to go ahead with a newer version of kernel (i.e. 2.4.18)
and now this is what happens:


BOOTP broadcast 1
ARP broadcast 1
TFTP from server 10.0.0.10; our IP address is 10.0.0.20
Filename '/tftpboot/image'.
Load address: 0x500000
Loading: #################################################################
         ###############################
done
Bytes transferred = 491392 (77f80 hex)
## Booting image at 00500000 ...
   Image Name:   FEC-Linux 2.4.18
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:    491328 Bytes = 479.8 kB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
Memory BAT mapping: BAT2=64Mb, BAT3=0Mb, residual: 0Mb
..................
..................
Sending BOOTP requests . OK
IP-Config: Got BOOTP answer from 10.0.0.10, my address is 10.0.0.20
IP-Config: Complete:
      device=eth0, addr=10.0.0.20, mask=255.0.0.0, gw=255.255.255.255,
     host=10.0.0.20, domain=, nis-domain=(none),
     bootserver=10.0.0.10, rootserver=10.0.0.10, rootpath=/opt/eldk/ppc_82xx
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Looking up port of RPC 100003/2 on 10.0.0.10
Looking up port of RPC 100005/1 on 10.0.0.10
VFS: Mounted root (nfs filesystem).
Freeing unused kernel memory: 52k init
tty_io.c: process 1 (swapper) used obsolete /dev/cua - update software to
use /d
ev/ttyS0
tty_io.c: process 1 (init) used obsolete /dev/cua - update software to use
/dev/
ttyS0
tty_io.c: process 1 (init) used obsolete /dev/cua - update software to use
/dev/
ttyS0
INIT: tty_io.c: process 1 (init) used obsolete /dev/cua - update software to
use
 /dev/ttyS0
version 2.78 bootingtty_io.c: process 1 (init) used obsolete /dev/cua -
update s
oftware to use /dev/ttyS0
                Welcome to DENX Embedded Linux Environment
                Press 'I' to enter interactive startup.
Mounting proc filesystem:  [  OK  ]
Configuring kernel parameters:  [  OK  ]
Cannot access the Hardware Clock via any known method.
Use the --debug option to see the details of our search for an access
method.
Setting clock : Wed Dec 31 19:00:07 EST 1969 [  OK  ]
Activating swap partitions:  [  OK  ]
Setting hostname 10.0.0.20:  [  OK  ]
Checking filesystems
Checking all file systems.
[  OK  ]
Mounting local filesystems:  [  OK  ]
Enabling swap space:  [  OK  ]
INIT: Entering runlevel: 3
Entering non-interactive startup
Starting system logger: [  OK  ]
Starting kernel logger: [  OK  ]
Starting xinetd: [  OK  ]
INIT: Id "3" respawning too fast: disabled for 5 minutes
INIT: no more processes left in this runlevel

I don't understand the messages related to the /dev/cua (these messages were
not present with the ELDK) and why the INIT process doesn't let me get the
console prompt.

Any suggestions?

Thanks
Gianfranco


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

^ permalink raw reply

* Re: Debugging a Process ...
From: Steven Smith @ 2002-10-26  7:44 UTC (permalink / raw)
  To: Ivan Deras; +Cc: linux-c-programming
In-Reply-To: <3DB86A25.5000109@uv.unitec.edu>

[-- Attachment #1: Type: text/plain, Size: 613 bytes --]

> I want to know how to debug a process in Linux, i know that in Windows i 
> can use Windows-API to attach a debugger process to the debugged 
> process, but in Linux i don't know ...
If you want to attach an existing debugger, look at the documentation
for that debugger (in gdb, it's ``gdb <program_name> <pid of program>'').
If you're thinking of writing your own, have a look at man ptrace.
This isn't the clearest of documents, so you may want to have a look
at the source to a few programs which use it, like gdb, strace, or
ltrace, before starting on your own.

Steven Smith,
sos22@cam.ac.uk.

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

^ permalink raw reply


This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.