All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: [LARTC] Shaping traffic to local users ?
From: Patrick McHardy @ 2002-12-19 16:03 UTC (permalink / raw)
  To: lartc
In-Reply-To: <marc-lartc-104030478706921@msgid-missing>

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

Hi Dimitris,

You could try this patch to the owner match. Its working fine for me, 
but i've seen it crash for unknown reasons
on other boxes. anyway its not very important to me so i won't try to 
fix it, but if you're brave you could give
it a shot ;)

Bye,
Patrick

Dimitris Kotsonis wrote:

>     
>     Hello
>     
>     Is it possible to shape incoming traffic for local linux users ?
>
>     Iptables can mark packets created from certain pid/uid/gid. Is 
> there a way to do the same for packets _destined_ for some pid/uid/gid 
> so that I can later shape them with IMQ ?
>
>     
>     Thanks in advance
>
>     Dimitris Kotsonis
>
>
>
>     
>
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/



[-- Attachment #2: owner-v4-pom.diff --]
[-- Type: text/plain, Size: 7380 bytes --]

diff -urN patch-o-matic-clean/extra/owner-socketlookup.patch patch-o-matic/extra/owner-socketlookup.patch
--- patch-o-matic-clean/extra/owner-socketlookup.patch	1970-01-01 01:00:00.000000000 +0100
+++ patch-o-matic/extra/owner-socketlookup.patch	2002-08-30 01:38:02.000000000 +0200
@@ -0,0 +1,182 @@
+diff -urN ../kernel/linux-2.4.20-pre4/include/net/tcp.h linux-2.4.20-pre4/include/net/tcp.h
+--- ../kernel/linux-2.4.20-pre4/include/net/tcp.h	2002-08-29 01:56:12.000000000 +0200
++++ linux-2.4.20-pre4/include/net/tcp.h	2002-08-30 00:16:56.000000000 +0200
+@@ -140,6 +140,7 @@
+ extern void tcp_bucket_unlock(struct sock *sk);
+ extern int tcp_port_rover;
+ extern struct sock *tcp_v4_lookup_listener(u32 addr, unsigned short hnum, int dif);
++extern struct sock *tcp_v4_lookup(u32 saddr, u16 sport, u32 daddr, u16 hnum, int dif);
+ 
+ /* These are AF independent. */
+ static __inline__ int tcp_bhashfn(__u16 lport)
+diff -urN ../kernel/linux-2.4.20-pre4/include/net/udp.h linux-2.4.20-pre4/include/net/udp.h
+--- ../kernel/linux-2.4.20-pre4/include/net/udp.h	2001-11-22 20:47:15.000000000 +0100
++++ linux-2.4.20-pre4/include/net/udp.h	2002-08-30 00:22:24.000000000 +0200
+@@ -69,6 +69,8 @@
+ extern int	udp_ioctl(struct sock *sk, int cmd, unsigned long arg);
+ extern int	udp_disconnect(struct sock *sk, int flags);
+ 
++extern struct sock *udp_v4_lookup(u32 saddr, u16 sport, u32 daddr, u16 dport, int dif);
++
+ extern struct udp_mib udp_statistics[NR_CPUS*2];
+ #define UDP_INC_STATS(field)		SNMP_INC_STATS(udp_statistics, field)
+ #define UDP_INC_STATS_BH(field)		SNMP_INC_STATS_BH(udp_statistics, field)
+diff -urN ../kernel/linux-2.4.20-pre4/net/ipv4/netfilter/ipt_owner.c linux-2.4.20-pre4/net/ipv4/netfilter/ipt_owner.c
+--- ../kernel/linux-2.4.20-pre4/net/ipv4/netfilter/ipt_owner.c	2002-08-29 01:56:13.000000000 +0200
++++ linux-2.4.20-pre4/net/ipv4/netfilter/ipt_owner.c	2002-08-28 22:19:39.000000000 +0200
+@@ -2,17 +2,26 @@
+    locally generated outgoing packets.
+ 
+    Copyright (C) 2000 Marc Boucher
++
++   08/28/2002 Patrick McHardy <kaber@trash.net> 
++   		- Modified to also match properties of receiving sockets
+  */
+ #include <linux/module.h>
+ #include <linux/skbuff.h>
+ #include <linux/file.h>
++#include <linux/ip.h>
++#include <linux/tcp.h>
++#include <linux/udp.h>
+ #include <net/sock.h>
++#include <net/tcp.h>
++#include <net/udp.h>
++#include <net/route.h>
+ 
+ #include <linux/netfilter_ipv4/ipt_owner.h>
+ #include <linux/netfilter_ipv4/ip_tables.h>
+ 
+ static int
+-match_comm(const struct sk_buff *skb, const char *comm)
++match_comm(const struct sock *sk, const char *comm)
+ {
+ 	struct task_struct *p;
+ 	struct files_struct *files;
+@@ -28,7 +38,7 @@
+ 		if(files) {
+ 			read_lock(&files->file_lock);
+ 			for (i=0; i < files->max_fds; i++) {
+-				if (fcheck_files(files, i) == skb->sk->socket->file) {
++				if (fcheck_files(files, i) == sk->socket->file) {
+ 					read_unlock(&files->file_lock);
+ 					task_unlock(p);
+ 					read_unlock(&tasklist_lock);
+@@ -44,7 +54,7 @@
+ }
+ 
+ static int
+-match_pid(const struct sk_buff *skb, pid_t pid)
++match_pid(const struct sock *sk, pid_t pid)
+ {
+ 	struct task_struct *p;
+ 	struct files_struct *files;
+@@ -59,7 +69,7 @@
+ 	if(files) {
+ 		read_lock(&files->file_lock);
+ 		for (i=0; i < files->max_fds; i++) {
+-			if (fcheck_files(files, i) == skb->sk->socket->file) {
++			if (fcheck_files(files, i) == sk->socket->file) {
+ 				read_unlock(&files->file_lock);
+ 				task_unlock(p);
+ 				read_unlock(&tasklist_lock);
+@@ -75,10 +85,10 @@
+ }
+ 
+ static int
+-match_sid(const struct sk_buff *skb, pid_t sid)
++match_sid(const struct sock *sk, pid_t sid)
+ {
+ 	struct task_struct *p;
+-	struct file *file = skb->sk->socket->file;
++	struct file *file = sk->socket->file;
+ 	int i, found=0;
+ 
+ 	read_lock(&tasklist_lock);
+@@ -119,36 +129,55 @@
+       int *hotdrop)
+ {
+ 	const struct ipt_owner_info *info = matchinfo;
++	struct sock *sk = NULL;
+ 
+-	if (!skb->sk || !skb->sk->socket || !skb->sk->socket->file)
++	if (out) {
++		sk = skb->sk;
++	} else {
++		struct iphdr *iph = skb->nh.iph;
++		if (iph->protocol == IPPROTO_TCP) {
++			struct tcphdr *tcph =
++				(struct tcphdr*)((u_int32_t*)iph + iph->ihl);
++			sk = tcp_v4_lookup(iph->saddr, tcph->source,
++					   iph->daddr, tcph->dest,
++					   ((struct rtable*)skb->dst)->rt_iif);
++		} else if (iph->protocol == IPPROTO_UDP) {
++			struct udphdr *udph =
++				(struct udphdr*)((u_int32_t*)iph + iph->ihl);
++			sk = udp_v4_lookup(iph->daddr, udph->dest, iph->saddr,
++					   udph->source, skb->dev->ifindex);
++		}
++	} 
++					
++	if (!sk || !sk->socket || !sk->socket->file)
+ 		return 0;
+ 
+ 	if(info->match & IPT_OWNER_UID) {
+-		if((skb->sk->socket->file->f_uid != info->uid) ^
++		if((sk->socket->file->f_uid != info->uid) ^
+ 		    !!(info->invert & IPT_OWNER_UID))
+ 			return 0;
+ 	}
+ 
+ 	if(info->match & IPT_OWNER_GID) {
+-		if((skb->sk->socket->file->f_gid != info->gid) ^
++		if((sk->socket->file->f_gid != info->gid) ^
+ 		    !!(info->invert & IPT_OWNER_GID))
+ 			return 0;
+ 	}
+ 
+ 	if(info->match & IPT_OWNER_PID) {
+-		if (!match_pid(skb, info->pid) ^
++		if (!match_pid(sk, info->pid) ^
+ 		    !!(info->invert & IPT_OWNER_PID))
+ 			return 0;
+ 	}
+ 
+ 	if(info->match & IPT_OWNER_SID) {
+-		if (!match_sid(skb, info->sid) ^
++		if (!match_sid(sk, info->sid) ^
+ 		    !!(info->invert & IPT_OWNER_SID))
+ 			return 0;
+ 	}
+ 
+ 	if(info->match & IPT_OWNER_COMM) {
+-		if (!match_comm(skb, info->comm) ^
++		if (!match_comm(sk, info->comm) ^
+ 		    !!(info->invert & IPT_OWNER_COMM))
+ 			return 0;
+ 	}
+@@ -164,8 +193,10 @@
+            unsigned int hook_mask)
+ {
+         if (hook_mask
+-            & ~((1 << NF_IP_LOCAL_OUT) | (1 << NF_IP_POST_ROUTING))) {
+-                printk("ipt_owner: only valid for LOCAL_OUT or POST_ROUTING.\n");
++            & ~((1 << NF_IP_LOCAL_OUT) | (1 << NF_IP_POST_ROUTING) |
++		(1 << NF_IP_LOCAL_IN)  | (1 << NF_IP_PRE_ROUTING))) {
++                printk("ipt_owner: only valid for LOCAL_OUT, LOCAL_IN, "
++		       "POST_ROUTING or PRE_ROUTING.\n");
+                 return 0;
+         }
+ 
+diff -urN ../kernel/linux-2.4.20-pre4/net/netsyms.c linux-2.4.20-pre4/net/netsyms.c
+--- ../kernel/linux-2.4.20-pre4/net/netsyms.c	2002-08-29 01:56:13.000000000 +0200
++++ linux-2.4.20-pre4/net/netsyms.c	2002-08-28 22:19:39.000000000 +0200
+@@ -597,4 +597,9 @@
+ EXPORT_SYMBOL(wireless_send_event);
+ #endif /* CONFIG_NET_RADIO || CONFIG_NET_PCMCIA_RADIO */
+ 
++#if defined(CONFIG_IP_NF_MATCH_OWNER)||defined(CONFIG_IP_NF_MATCH_OWNER_MODULE)
++EXPORT_SYMBOL(tcp_v4_lookup);
++EXPORT_SYMBOL(udp_v4_lookup);
++#endif /* CONFIG_IP_NF_MATCH_OWNER */
++
+ #endif  /* CONFIG_NET */
diff -urN patch-o-matic-clean/extra/owner-socketlookup.patch.help patch-o-matic/extra/owner-socketlookup.patch.help
--- patch-o-matic-clean/extra/owner-socketlookup.patch.help	1970-01-01 01:00:00.000000000 +0100
+++ patch-o-matic/extra/owner-socketlookup.patch.help	2002-08-30 01:37:47.000000000 +0200
@@ -0,0 +1,13 @@
+Author: Patrick McHardy <kaber@trash.net>
+Status: working
+
+The patch allows you to use the owner match in the INPUT/PREROUTING chains to
+match properties of the receiving socket.
+
+Example:
+
+	# Allow packets coming in on eth0 to sockets owned be local user
+	# kaber
+	
+	iptables -A INPUT -i eth0 -m owner --uid-owner kaber -j ACCEPT
+

^ permalink raw reply

* ADMIN: A note to all subscribers ...
From: Matti Aarnio @ 2002-12-19 16:11 UTC (permalink / raw)
  To: linux-kernel

.. and especially those, who use free email services with
lowish quotas.

  The  linux-kernel  list has VERY HIGH TRAFFIC VOLUME.
( ok, you know that by now ;-) )

When we sysadmins see some subscriber bouncing with "mailbox full",
or something of that theme, we just bluntly cancel such subscriptions.
For obvious reasons we can't inform the user of this fact either.

This list has several archives, see links at:

  http://vger.kernel.org/vger-lists.html#linux-kernel


^ permalink raw reply

* reiserfs messages on root partition at system boot time
From: Sewell, Cassandra D (Cassandra) @ 2002-12-19 16:04 UTC (permalink / raw)
  To: reiserfs-list

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

I am seeing the following messages on a system I have at boot time.  This system 
is running the 2.2.17 kernel w/ RFS 3.5.32.  I am awaiting delivery of the harddrive & 
will be executing the fsck on this drive (along with some hw diagnostics) but was hoping to get an indication as to what these messages may be indicating.  I do not see any hardware errors in the 
system log file.  

************************/var/log/messages*************************************

Dec 31 19:35:32 **** kernel: Checking ReiserFS transaction log (device 03:06) ... 
Dec 31 19:35:32 **** kernel: Warning, log recovery starting on readonly filesystem 
Dec 31 19:35:32 **** kernel: Replayed 6 transactions in 6 seconds 
Dec 31 19:35:32 **** kernel: Using r5 hash to sort names 
Dec 31 19:35:32 **** kernel: Primary Sponsor thresholdnetworks.com 
Dec 31 19:35:32 **** kernel: Raid Tuning sponsored by emusic.com 
Dec 31 19:35:32 **** kernel: HSM sponsored by bigstorage.com 
Dec 31 19:35:32 **** kernel: Alpha port and SMP sponsored by www.api-networks.com, alpha port by www.innovative-software.com and www.quant-x.com. 
Dec 31 19:35:32 **** kernel: ReiserFS version 3.5.32 
Dec 31 19:35:32 **** kernel: VFS: Mounted root (reiserfs filesystem) readonly. 
Dec 31 19:35:32 **** kernel: Freeing unused kernel memory: 72k freed 
Dec 31 19:35:32 **** kernel: Adding Swap: 530136k swap-space (priority -1) 
.....
Dec 31 19:35:32 **** kernel: i2c-core.o: i2c core module 
Dec 31 19:35:32 **** kernel: sensors.o version 2.5.5 (20010115) 
Dec 31 19:35:32 **** kernel: piix4.o version 2.5.5 (20010115) 
Dec 31 19:35:32 **** kernel: i2c-core.o: adapter SMBus PIIX4 adapter at 1040 registered as adapter 0. 
Dec 31 19:35:32 **** kernel: i2c-piix4.o: PIIX4 bus detected and initialized 
Dec 31 19:35:32 **** kernel: adm1021.o version 2.5.5 (20010115) 
Dec 31 19:35:32 **** kernel: i2c-core.o: driver ADM1021, MAX1617 sensor driver registered. 
Dec 31 19:35:32 **** kernel: i2c-core.o: client [LM84 chip] registered to adapter [SMBus PIIX4 adapter at 1040](pos. 0). 
Dec 31 19:35:32 **** kernel: usb.c: registered new driver acm 

Dec 31 19:35:32 **** kernel: Checking ReiserFS transaction log (device 03:01) ... 
Dec 31 19:35:32 **** kernel: Using r5 hash to sort names 
Dec 31 19:35:32 **** kernel: ReiserFS version 3.5.32 
Dec 31 19:35:32 **** kernel: attempt to access beyond end of device 
Dec 31 19:35:32 **** kernel: 03:0c: rw=0, want=65, limit=0 
Dec 31 19:35:32 **** kernel: dev 03:0c blksize=1024 blocknr=64 sector=128 size=1024 count=1 
Dec 31 19:35:32 **** kernel: reiserfs_read_super: unable to read superblock on dev 03:0c 
Dec 31 19:35:32 **** kernel: reiserfs_read_super: try to find super block in old location 
Dec 31 19:35:32 **** kernel: attempt to access beyond end of device 
Dec 31 19:35:32 **** kernel: 03:0c: rw=0, want=12, limit=0 
Dec 31 19:35:32 **** kernel: dev 03:0c blksize=4096 blocknr=2 sector=16 size=4096 count=1 
Dec 31 19:35:32 **** kernel: reiserfs_read_super: unable to read superblock on dev 03:0c 
Dec 31 19:35:32 **** kernel: attempt to access beyond end of device 
Dec 31 19:35:32 **** kernel: 03:0d: rw=0, want=65, limit=0 
Dec 31 19:35:32 **** kernel: dev 03:0d blksize=1024 blocknr=64 sector=128 size=1024 count=1 
Dec 31 19:35:32 **** kernel: reiserfs_read_super: unable to read superblock on dev 03:0d 
Dec 31 19:35:32 **** kernel: reiserfs_read_super: try to find super block in old location 
Dec 31 19:35:32 **** kernel: attempt to access beyond end of device 
Dec 31 19:35:32 **** kernel: 03:0d: rw=0, want=12, limit=0 
Dec 31 19:35:32 **** kernel: dev 03:0d blksize=4096 blocknr=2 sector=16 size=4096 count=1 
Dec 31 19:35:32 **** kernel: reiserfs_read_super: unable to read superblock on dev 03:0d 
Dec 31 19:35:32 **** kernel: attempt to access beyond end of device 
Dec 31 19:35:32 **** kernel: 03:0e: rw=0, want=65, limit=0 
Dec 31 19:35:32 **** kernel: dev 03:0e blksize=1024 blocknr=64 sector=128 size=1024 count=1 
Dec 31 19:35:32 **** kernel: reiserfs_read_super: unable to read superblock on dev 03:0e 
Dec 31 19:35:32 **** kernel: reiserfs_read_super: try to find super block in old location 
Dec 31 19:35:32 **** kernel: attempt to access beyond end of device 
Dec 31 19:35:32 **** kernel: 03:0e: rw=0, want=12, limit=0 
Dec 31 19:35:32 **** kernel: dev 03:0e blksize=4096 blocknr=2 sector=16 size=4096 count=1 
Dec 31 19:35:32 **** kernel: reiserfs_read_super: unable to read superblock on dev 03:0e 
Dec 31 19:35:32 **** kernel: Checking ReiserFS transaction log (device 03:08) ... 
Dec 31 19:35:32 **** kernel: Using r5 hash to sort names 
Dec 31 19:35:32 **** kernel: ReiserFS version 3.5.32 
Dec 31 19:35:32 **** kernel: Checking ReiserFS transaction log (device 03:09) ... 
Dec 31 19:35:32 **** kernel: Using r5 hash to sort names 
Dec 31 19:35:32 **** kernel: ReiserFS version 3.5.32 
Dec 31 19:35:32 **** kernel: Checking ReiserFS transaction log (device 03:0a) ... 
Dec 31 19:35:32 **** kernel: Using r5 hash to sort names 
Dec 31 19:35:32 **** kernel: ReiserFS version 3.5.32 
Dec 31 19:35:32 **** kernel: reiserfs_read_super: can't find a reiserfs filesystem on dev 03:0b. 
Dec 31 19:35:32 **** kernel: reiserfs_read_super: try to find super block in old location 
Dec 31 19:35:32 **** kernel: reiserfs_read_super: can't find a reiserfs filesystem on dev 03:0b. 
Dec 31 19:35:32 **** kernel: Checking ReiserFS transaction log (device 03:05) ... 
Dec 31 19:35:32 **** kernel: Replayed 127 transactions in 3 seconds 
Dec 31 19:35:32 **** kernel: Using r5 hash to sort names 
Dec 31 19:35:32 **** kernel: ReiserFS version 3.5.32 
Dec 31 19:35:32 **** kernel: Intel(R) PRO/100 Fast Ethernet Adapter - Loadable driver, ver 1.5.5 
.......

Thanks, 

C. Sewell


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

^ permalink raw reply

* Re: [patch] fix drivers/scsi/sd.c warnings
From: James Bottomley @ 2002-12-19 16:07 UTC (permalink / raw)
  To: Andrew Morton; +Cc: James Bottomley, linux-scsi
In-Reply-To: <3E016158.CC3D9909@digeo.com>

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

akpm@digeo.com said:
> Somebody forgot to test with CONFIG_LBD=n: 

Well, OK, that would be me (but then you guessed that).

I enhanced your patch slightly, since we would get a wraparound on x86 without 
CONFIG_LBD for large devices, so now it will assume the maximum (2Tb) and 
print a warning.

Hopefully, it should also be obvious to the compiler at compile time that 
longrc can only be set if sizeof(block) > 4 and therefore allow it to optimise 
correctly (or am I just being optimistic).

That's also why I was reluctant to make block a u64, since then we'd always 
run the > 0xffffffff test, which we know will never be true if LBD is not set.

How does the attached work?

James


[-- Attachment #2: tmp.diff --]
[-- Type: text/plain , Size: 2789 bytes --]

===== drivers/scsi/sd.c 1.98 vs edited =====
--- 1.98/drivers/scsi/sd.c	Tue Dec 17 12:21:56 2002
+++ edited/drivers/scsi/sd.c	Thu Dec 19 09:59:10 2002
@@ -301,10 +301,10 @@
 	
 	if (block > 0xffffffff) {
 		SCpnt->cmnd[0] += READ_16 - READ_6;
-		SCpnt->cmnd[2] = (unsigned char) (block >> 56) & 0xff;
-		SCpnt->cmnd[3] = (unsigned char) (block >> 48) & 0xff;
-		SCpnt->cmnd[4] = (unsigned char) (block >> 40) & 0xff;
-		SCpnt->cmnd[5] = (unsigned char) (block >> 32) & 0xff;
+		SCpnt->cmnd[2] = sizeof(block) > 4 ? (unsigned char) (block >> 56) & 0xff : 0;
+		SCpnt->cmnd[3] = sizeof(block) > 4 ? (unsigned char) (block >> 48) & 0xff : 0;
+		SCpnt->cmnd[4] = sizeof(block) > 4 ? (unsigned char) (block >> 40) & 0xff : 0;
+		SCpnt->cmnd[5] = sizeof(block) > 4 ? (unsigned char) (block >> 32) & 0xff : 0;
 		SCpnt->cmnd[6] = (unsigned char) (block >> 24) & 0xff;
 		SCpnt->cmnd[7] = (unsigned char) (block >> 16) & 0xff;
 		SCpnt->cmnd[8] = (unsigned char) (block >> 8) & 0xff;
@@ -931,7 +931,7 @@
 		if (longrc) {
 			memset((void *) cmd, 0, 16);
 			cmd[0] = SERVICE_ACTION_IN;
-			cmd[1] = 0x10; /* READ CAPACITY (16) */
+			cmd[1] = SAI_READ_CAPACITY_16;
 			cmd[13] = 12;
 			memset((void *) buffer, 0, 12);
 		} else {
@@ -1002,21 +1002,25 @@
 		sector_size = (buffer[4] << 24) |
 			(buffer[5] << 16) | (buffer[6] << 8) | buffer[7];
 		if (buffer[0] == 0xff && buffer[1] == 0xff &&
-			buffer[2] == 0xff && buffer[3] == 0xff) {
-			printk(KERN_NOTICE "%s : very big device. try to use"
-				" READ CAPACITY(16).\n", diskname);
-			longrc = 1;
-			goto repeat;
+		    buffer[2] == 0xff && buffer[3] == 0xff) {
+			if(sizeof(sdkp->capacity) > 4) {
+				printk(KERN_NOTICE "%s : very big device. try to use"
+				       " READ CAPACITY(16).\n", diskname);
+				longrc = 1;
+				goto repeat;
+			} else {
+				printk(KERN_ERR "%s: too big for kernel.  Assuming maximum 2Tb\n", diskname);
+			}
 		}
 		sdkp->capacity = 1 + (((sector_t)buffer[0] << 24) |
 			(buffer[1] << 16) |
 			(buffer[2] << 8) |
 			buffer[3]);			
 	} else {
-		sdkp->capacity = 1 + (((sector_t)buffer[0] << 56) |
-			((sector_t)buffer[1] << 48) |
-			((sector_t)buffer[2] << 40) |
-			((sector_t)buffer[3] << 32) |
+		sdkp->capacity = 1 + (((u64)buffer[0] << 56) |
+			((u64)buffer[1] << 48) |
+			((u64)buffer[2] << 40) |
+			((u64)buffer[3] << 32) |
 			((sector_t)buffer[4] << 24) |
 			((sector_t)buffer[5] << 16) |
 			((sector_t)buffer[6] << 8)  |
===== include/scsi/scsi.h 1.7 vs edited =====
--- 1.7/include/scsi/scsi.h	Tue Dec 17 12:21:56 2002
+++ edited/include/scsi/scsi.h	Thu Dec 19 09:59:56 2002
@@ -99,6 +99,8 @@
 #define READ_16               0x88
 #define WRITE_16              0x8a
 #define SERVICE_ACTION_IN     0x9e
+/* values for service action in */
+#define	SAI_READ_CAPACITY_16  0x10
 
 
 /*

^ permalink raw reply

* RE: After Uncompresseing Linux..., what's next
From: James Don @ 2002-12-19 16:10 UTC (permalink / raw)
  To: 'Prakash kanthi', LinuxPPC


I just went thru this myself ... ;-)

1.) Get a BDM/JTAG tool look halt the processor after you see " Now booting
the kernel" and look for valid asm at 0x0 ... make sure it mathes your
start.s file ...

2.) Veryfy you have your mem map from ppcboot matching requirements for the
kernel i.e ram (physical=0x0, virtual=0xc0000000) and immr (phys 0xff000000
virtual 0xff000000) ... I had my immr in ppc boot at 0x02200000 this screwed
me for quite a while ... otherwise you have no printk ... the memory map is
very important not to screw with some things depend on it (unless your
careful) ...

3.) verify you SMC1 (uart) is getting proper clocking config ... i.e
bus->brg1 and brg1 is 16 times baud rate ... otherwise you have no printk

4.) and always always keep in mind your RAM refesh could be wrong ...
everyone will tell you this even when it has nothing to do with your problem
... try not to ignore them if you are still stuck ;-) But verifying step 1
should prove your ok ...

Best of luck,
Jim


-----Original Message-----
From: Prakash kanthi [mailto:pkanthi@yahoo.com]
Sent: Wednesday, December 18, 2002 7:14 PM
To: LinuxPPC
Subject: After Uncompresseing Linux..., what's next


Hi there,

I was trying to load linuxppc_2_4_devel onto my board.
It goes through the board info read, UART init and
Uncompressing the linux kernel. But after that, i do
not see any messages and board hangs.

Here is the UART output:
------------------------------------
OS Booting...

loaded at:     00400000 0060D1CC
board data at: 00000030 00000044
relocated to:  00405C24 00405C38
zimage at:     00406290 004A08FF
initrd at:     004A1000 006097CA
avail ram:     0060E000 007F8000

Linux/PPC load: console=ttyS0,9600 console=tty1 ip=on
root=/dev/xsysace/disc0/pa
rt3 rw
Uncompressing Linux...done.
Now booting the kernel
-------------------------------------------

After the last line, it hangs. I get a feeling that,
the uncompressing process is not writing in the memory
starting from 0x00000000 and, after uncompressing, it
is jumping into 0x00000000 and is not able to find
anything.

My questions are,
1. How can i make sure that, the uncompressing process
is going to start writing the data from 0x00000000.

2. How big a space this uncompressing process needs?
And also how much overall memory is required for
running linux. I just have 8MB SDRAM.

3. What is the next step in the booting process? Which
Device (eth, pci, ide, ???) Initialization?

Your help is appreciated.

thanks,
Prakash


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

^ permalink raw reply

* Re: 2.5.52: PDC20268 failure - ACPI to blame !!!
From: Frank van de Pol @ 2002-12-19 16:24 UTC (permalink / raw)
  To: Alan Cox; +Cc: Frank van de Pol, Linux Kernel Mailing List
In-Reply-To: <1040259796.26906.2.camel@irongate.swansea.linux.org.uk>

On Thu, Dec 19, 2002 at 01:03:16AM +0000, Alan Cox wrote:
> On Wed, 2002-12-18 at 23:28, Frank van de Pol wrote:
> > 
> > the 2.5 series of kernels (since early ide changes) fails on my machine when
> > configuring the harddisks.
> 
> Can you tell me if 2.4.21-pre does - that has the IDE changes without
> the other stuff so is a good test of which bit is involved
> 
> Also try 2.5.52 with ACPI disabled

Good thinking Alan! it seems ACPI is causing the trouble.

2.4.18 - OK
2.4.19 - OK
2.4.20 - OK
2.4.21-pre2 OK  (using pdc202xx_new driver)

2.5.52 with ACPI - Failure, IRQ troubles wrong IRQ assigned for promise
                   boards, lockup of box during boot
2.5.52 no ACPI   - OK !!!

What information do I need to provide to fix this problem?

Frank.

-- 
+---- --- -- -  -   -    - 
| Frank van de Pol                  -o)    A-L-S-A
| FvdPol@home.nl                    /\\  Sounds good!
| http://www.alsa-project.org      _\_v
| Linux - Why use Windows if we have doors available?

^ permalink raw reply

* Re: reiserfs messages on root partition at system boot time
From: Oleg Drokin @ 2002-12-19 16:15 UTC (permalink / raw)
  To: Sewell, Cassandra D (Cassandra); +Cc: reiserfs-list
In-Reply-To: <0E18D85A21D2874080456C3B8A12E83E01009F9C@cof110avexu4.global.avaya.com>

Hello!

On Thu, Dec 19, 2002 at 09:04:34AM -0700, Sewell, Cassandra D (Cassandra) wrote:
> I am seeing the following messages on a system I have at boot time.  This system 
> is running the 2.2.17 kernel w/ RFS 3.5.32.  I am awaiting delivery of the harddrive & 

version 3.5.32 is way too old, there are never versions available.

> Dec 31 19:35:32 **** kernel: Using r5 hash to sort names 
> Dec 31 19:35:32 **** kernel: ReiserFS version 3.5.32 
> Dec 31 19:35:32 **** kernel: attempt to access beyond end of device 
> Dec 31 19:35:32 **** kernel: 03:0c: rw=0, want=65, limit=0 
> Dec 31 19:35:32 **** kernel: dev 03:0c blksize=1024 blocknr=64 sector=128 size=1024 count=1 

Hm, this device is of zero size. Very strange.

> Dec 31 19:35:32 **** kernel: attempt to access beyond end of device 
> Dec 31 19:35:32 **** kernel: 03:0d: rw=0, want=65, limit=0 
> Dec 31 19:35:32 **** kernel: dev 03:0d blksize=1024 blocknr=64 sector=128 size=1024 count=1 

One more zero-sized partition.

> Dec 31 19:35:32 **** kernel: attempt to access beyond end of device 
> Dec 31 19:35:32 **** kernel: 03:0e: rw=0, want=65, limit=0 
> Dec 31 19:35:32 **** kernel: dev 03:0e blksize=1024 blocknr=64 sector=128 size=1024 count=1 

And third zero sized partition.

> Dec 31 19:35:32 **** kernel: Using r5 hash to sort names 
> Dec 31 19:35:32 **** kernel: ReiserFS version 3.5.32 
> Dec 31 19:35:32 **** kernel: reiserfs_read_super: can't find a reiserfs filesystem on dev 03:0b. 
> Dec 31 19:35:32 **** kernel: reiserfs_read_super: try to find super block in old location 
> Dec 31 19:35:32 **** kernel: reiserfs_read_super: can't find a reiserfs filesystem on dev 03:0b. 

Hm, hard to tell about this one.
What does reiserfsck (pick latest one!) says about /dev/hda11?

> Dec 31 19:35:32 **** kernel: Checking ReiserFS transaction log (device 03:05) ... 
> Dec 31 19:35:32 **** kernel: Replayed 127 transactions in 3 seconds 
> Dec 31 19:35:32 **** kernel: Using r5 hash to sort names 
> Dec 31 19:35:32 **** kernel: ReiserFS version 3.5.32 

This one mounted ok.

So it seems that several extended partitions are corrupted
(or just missed - you have not posted relevant part of the log).
These are /dev/hda12 /dev/hda13 /dev/hda14.

Bye,
    Oleg

^ permalink raw reply

* mmap problem with personnal code driver
From: Xavier Grave @ 2002-12-19 16:18 UTC (permalink / raw)
  To: linuxppc-dev


Hi all,

I have written a driver for a pci to vme bridge and I have the following
problem : when I try to mmap some pci space to the user memory read is ok but
write seems broken on ppc arch. (it run without problem on x86 arch).

I think the problem is in the pgprot_val(vma->vm_page_prot) value.

I wonder if I haven't see something about that in the list before but I
couldn't find it for the moment.
Does anyone have an idea to help me ? :-)

xavier
PS: for people interested in the vme driver the new version support both
rtlinux, rtai and standard linux.

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

^ permalink raw reply

* Re: raidtools-20010914
From: Claudio Fleiner @ 2002-12-19 16:22 UTC (permalink / raw)
  To: Jarmo Järvenpää; +Cc: linux-raid
In-Reply-To: <3E01CBD8.6A18B88F@softers.net>

I had the same problem and a quick look at the kernel shows
that although the ioctl for generating the fault exists
in the kernel, the main part is commented out and therefore
the operation is a noop.

This is true for the 2.4.19 and at least the beginning of
the 2.5.* kernels. If you want to use raidhotgenerateerror
you need to edit a few kernel files.

Claudio


on Thu, 19 Dec 2002 15:38:32 +0200 Jarmo =?iso-8859-1?Q?J=E4rvenp=E4=E4?= 
        <Jarmo.Jarvenpaa@softers.net> wrote:
> - 3 RAID 1 devices with each having 2 partitions mirrored together.
> - Kernel 2.4.20
> 
> I tried to remove /dev/hda1 from /dev/md0 by using raidhotgenerateerror
> and got this:
> 

----------------------------------------------------------------------------
Claudio Fleiner                                          claudio@fleiner.com



^ permalink raw reply

* RE: kazaa
From: Rowan Reid @ 2002-12-19 16:26 UTC (permalink / raw)
  To: 'Paulo Andre', 'netfilter'
In-Reply-To: <1040285287.11114.143.camel@bigblue>



I run a plain 1.2.6a version of netfilter. Wherein all internal hosts
are masquaraded I've never had a problem with Kaaza inbound or outbound.
To be honest most complaints I've heard is how to stop the damn thing
from connecting.

 
Rowan Reid
Job Captain, 
Systems Administrator
STUDIO 3 ARCHITECTS
909  982  1717


> -----Original Message-----
> From: netfilter-admin@lists.netfilter.org 
> [mailto:netfilter-admin@lists.netfilter.org] On Behalf Of Paulo Andre
> Sent: Thursday, December 19, 2002 12:08 AM
> To: netfilter
> Subject: kazaa
> 
> 
> I know that this is an old topic but I have done some reading 
> and am still stuck. I have opened tcp and udp for port 1214 
> outgoing, but Kazaa is still not connecting am I missing 
> something..???
> 
> Paulo
> 
> 
> 
> 



^ permalink raw reply

* 2.5 sbpcd config error
From: John Bradford @ 2002-12-19 16:47 UTC (permalink / raw)
  To: linux-kernel; +Cc: emoenke

I've just noticed, the help text for this driver says:

> This driver can support up to four CD-ROM controller cards, and each
> card can support up to four CD-ROM drives; if you say Y here, you
> will be asked how many controller cards you have.

but it doesn't seem to prompt for the second and subsequent interfaces
like 2.4 does.

I know, there are probably not many people using five or more of the
corresponding CD-ROM drives on a 2.5 machine, (I don't even own one of
the drives), but I thought I'd point it out.

John.

^ permalink raw reply

* Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)
From: Eli Carter @ 2002-12-19 16:39 UTC (permalink / raw)
  To: Russell King; +Cc: Adam J. Richter, linux-kernel
In-Reply-To: <20021219091336.A20477@flint.arm.linux.org.uk>

Russell King wrote:
> On Wed, Dec 18, 2002 at 05:08:45PM -0800, Adam J. Richter wrote:
> 
>>	I don't currently use bugzilla (just due to inertia), but the
>>whole world doesn't have to switch to something overnight in order for
>>that facility to end up saving more time and resources than it has
>>cost.  Adoption can grow gradually, and it's probably easier to work
>>out bugs (in bugzilla) and improvements that way anyhow.
> 
> 
> I'm not asking the world to switch to it overnight.  Just one person
> would be nice. 8)
> 

Ok, Russell, maybe I can lend a small hand there....

You have a bug tracking mechanism of your own on www.arm.linux.org.uk, 
along with a separate patch tracker.
Do you want ARM bug reports in bugzilla instead of your site?  If so, 
can you link to it from that bug tracker page?  (I suppose you'd want to 
  direct people to bugzilla for just 2.5.* and 2.5.*-rmk*)

I submitted a 2.4 bug to your bug tracker, got an answer to the question 
when I posted to the arm mailing lists (thanks!), and submitted a patch 
to the mailing list.  But nothing has happened on the bug status.  I 
asked if you wanted patches for bugs put in the patch tracker or the bug 
tracker, but got no reply.
I understand that you're fighting the Acorn battle of 2.5.50 -> 2.5.52, 
so I'm trying not to sound like I'm complaining.  (Failing, yes, I know, 
sorry. :/ )  Some assurance that you will acknowledge bugs in bugzilla 
would be greatly encouraging to me.  (Such as a reply to this message?)

I'll try to get 2.5 bug reports for ARM into bugzilla based on your 
comments here, but a couple of suggestions:
- post an announcement to the arm lists of where you want which bugs to go,
- link to the same in a prominent place from your bug and patch trackers
- if you can, perhaps give priority in terms of replies and such to 
those who use bugzilla... I value your replies, and if I can do 
something to increase my chances of even getting an "Ack, I'll look at 
it next week", I'll try to do that.

Comments?

Eli
--------------------. "If it ain't broke now,
Eli Carter           \                  it will be soon." -- crypto-gram
eli.carter(a)inet.com `-------------------------------------------------


^ permalink raw reply

* (no subject)
From: Hans Jorgensen @ 2002-12-19 16:32 UTC (permalink / raw)
  To: netfilter-devel

Dear list

Can anyone tell me how to add a new connection tracking entry? I am 
developing my own netfilter kernel module.

A code example would be nice.

Thanks in advance.

/Hans





_________________________________________________________________
The new MSN 8: advanced junk mail protection and 2 months FREE* 
http://join.msn.com/?page=features/junkmail

^ permalink raw reply

* Re: problem using jffs2 on DiskOnChip
From: Brian Austin @ 2002-12-19 12:21 UTC (permalink / raw)
  To: wolff; +Cc: linux-mtd
In-Reply-To: <000301c2a773$6f5d5360$446410ac@lt-gw8l30j.turnkiek.nl>

On Thursday 19 December 2002 09:29, Carl Wolff wrote:

use ext3 instead.  Depending onhow big your chip is.
or reiserfs


> Hello David,
>
> OK. Two questions:
> 1) Does JFFS2 actually work on a DiskOnChip?
> 2) Other alternatives? We need a powersafe filesystem on DiskOnChip.
>
>
> Thanks, and happy newyear, I'm going on holiday now.
>
> Carl.
>
> > -----Original Message-----
> > From: David Woodhouse [mailto:dwmw2@redhat.com]On Behalf Of David
> > Woodhouse
> > Sent: donderdag 19 december 2002 11:14
> > To: wolff@turnkiek.nl
> > Cc: linux-mtd@lists.infradead.org
> > Subject: Re: problem using jffs2 on DiskOnChip
> >
> > wolff@turnkiek.nl said:
> > > Short read: 0x10 bytes at 0x000001f0 instead of requested 44
> >
> > The DiskOnChip hardware driver hasn't been used much with
> > anything other
> > than NFTL. It appears not to do a full read if you ask it to
> > read a range
> > of data which crosses a page boundary. Fix it accordingly by
> > putting an
> > appropriate loop in instead of...
> >
> >         /* Don't allow a single read to cross a 512-byte
> > block boundary */
> >         if (from + len > ((from | 0x1ff) + 1))
> >                 len = ((from | 0x1ff) + 1) - from;
> >
> > --
> > dwmw2
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply

* Re: After Uncompresseing Linux..., what's next
From: Tom Rini @ 2002-12-19 16:39 UTC (permalink / raw)
  To: James Don; +Cc: 'Prakash kanthi', LinuxPPC
In-Reply-To: <DB0585C9F6F9D411BE8F00D0B7896A4CC05F66@SNCMAIL>


On Thu, Dec 19, 2002 at 11:10:41AM -0500, James Don wrote:

> 2.) Veryfy you have your mem map from ppcboot matching requirements for the
> kernel i.e ram (physical=0x0, virtual=0xc0000000) and immr (phys 0xff000000
> virtual 0xff000000) ... I had my immr in ppc boot at 0x02200000 this screwed
> me for quite a while ... otherwise you have no printk ... the memory map is
> very important not to screw with some things depend on it (unless your
> careful) ...
>
> 3.) verify you SMC1 (uart) is getting proper clocking config ... i.e
> bus->brg1 and brg1 is 16 times baud rate ... otherwise you have no printk

That's all 8xx-specific isn't it 'tho?  It looks like this is a Xilinx
ML300 board, and thus a '40x'.

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

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

^ permalink raw reply

* Re: How can I expand the window size of a telnet session?
From: Ray Olszewski @ 2002-12-19 16:40 UTC (permalink / raw)
  To: linux-newbie
In-Reply-To: <atsoff$m76$1@main.gmane.org>

At 10:27 AM 12/19/02 -0500, Jamie Risk wrote:
>I've given up getting an XTerm session from my windows X
>client working, and really all I want is large text window session.

"X client"? X is a server; client applications use it. And I'm assuming 
below that "windows" refers to some version of Microsoft Windows.

>So, how can I expand the window size of telnet session beyond
>the anaemic dimensions of 80x25?

Window size (in the form of characters per line and lines on the screen) is 
information that the terminal-emulator client (or the actual terminal, but 
that's pretty much ancient history) passes on to the server. Since your 
client is running on Windows, this is really a Windows question, save for 
the Linux advice that you use a client that supports larger window sizes.

As to Windows client selection ... I no longer do telnet sessions, but 
Putty communicates window resizing smoothly for ssh sessions (all I need to 
do is drag the window to a larger size), so it probably does the same for 
telnets. TerraTerm was clunkier in this respect (and many others), which is 
why I no longer use it. Beefore I switched to ssh, I did use a terminal app 
that also resized nicely for telnets, but I forget its name. No doubt a 
search of a Windows freeware/shareware archive like TUCOWS will turn up 
some other choices.


--
-------------------------------------------"Never tell me the odds!"--------
Ray Olszewski					-- Han Solo
Palo Alto, California, USA			  ray@comarre.com
-------------------------------------------------------------------------------

-
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: Intel P6 vs P7 system call performance
From: Dave Jones @ 2002-12-19 16:56 UTC (permalink / raw)
  To: Jamie Lokier
  Cc: bart, torvalds, hpa, terje.eggestad, drepper, matti.aarnio, hugh,
	mingo, linux-kernel
In-Reply-To: <20021219142212.GA17324@bjl1.asuk.net>

On Thu, Dec 19, 2002 at 02:22:12PM +0000, Jamie Lokier wrote:

 > <evil-grin>
 > No, because the static binary installs a SIGSEGV handler to emulate
 > the magic page on older kernels :)
 > </evil-grin>

You're a sick man. Really. 8)

		Dave

-- 
| Dave Jones.        http://www.codemonkey.org.uk

^ permalink raw reply

* Re: reiserfsck --rebuild-tree on a big filesystem
From: Zygo Blaxell @ 2002-12-19 16:51 UTC (permalink / raw)
  To: reiserfs-list
In-Reply-To: <20021125174846.A31778@namesys.com>

This thread is rather old, but I have basically the same problem...

In article <20021125174846.A31778@namesys.com>,
Oleg Drokin  <green@namesys.com> wrote:
>On Mon, Nov 25, 2002 at 03:36:34PM +0100, Mira Temp?r wrote:
>> my setup:
>> linux 2.4.18 SMP, HW RAID5, nearly full 240GB reiserfs of mostly small files,
>> reiserprogs 3.6.4.
>> With advice to run --rebuild-tree.

Mine:

Linux 2.4.18 UP (SMP kernel), SW RAID0 and linear, nearly full 160GB
reiserfs of mostly small files, reiserfsprogs 1:3.6.3-1 (Debian).  I had
two machines go through a power failure while doing lots of concurrent
hard links and deletes.  The linear system survived apparently intact,
while the RAID0 system had the usual "stat Permission denied"
problem.

This has happened a number of times before on a variety of systems
(it seems to be reiserfs's most common failure mode).  The events are
very similar each time.  AFAICT you just have to set up a reiserfs on
some kind of RAID system and let it run through a few power failures to
reproduce the problem.

>> But after 16 hours of running it, it is still on 0% and whole process 
>> would take about 1 month to complete (started at 2000 blocks/sec, 
>> but now running at 26b/s).

My reiserfsck --rebuild-tree has been running for a little over an hour
and has degraded to 49 blocks/sec (about 10 days).  r-fsck absorbs all
the CPU it can get.  The reiserfsck process's memory usage increases by
about 8 bytes per block read, and as far as I can tell all of the RAM
allocated after the first 24 megs or so is active (I determine this by
creating a large process to swap out all the inactive pages, then
counting what remains).  Nothing is physically wrong with the disks,
it was just another power failure.  

Based on past events, the read speed will probably degrade to zero in a
week or two, if the reiserfsck process doesn't run out of RAM+swap first.
It only takes 20 days to repopulate the disk, so in the past when this
happens I usually just mkreiserfs (or mke2fs -j!) and move on.  I've never
seen a reiserfsck --rebuild-tree run to completion.

If you feel that 'debugreiserfs -p ... | bzip2' output would be helpful,
I could generate it, but that's about 40GB of data.

-- 
Opinions expressed are my own, I don't speak for my employer, and all that.
Encrypted email preferred.  Go ahead, you know you want to.  ;-)
OpenPGP at work: 3528 A66A A62D 7ACE 7258 E561 E665 AA6F 263D 2C3D

^ permalink raw reply

* mremap use-after-free [was Re: 2.5.52-mm2]
From: Hugh Dickins @ 2002-12-19 17:02 UTC (permalink / raw)
  To: Andrew Morton; +Cc: lkml, linux-mm
In-Reply-To: <3E01943B.4170B911@digeo.com>

On Thu, 19 Dec 2002, Andrew Morton wrote:
> Andrew Morton wrote:
> > ...
> > slab-poisoning.patch
> >   more informative slab poisoning
> 
> This patch has exposed a quite long-standing use-after-free bug in
> mremap().  It make the machine go BUG when starting the X server if
> memory debugging is turned on.

Good catch, shame about the patch!
Please don't apply this, or its 2.4 sister, as is.

> The bug might be present in 2.4 as well..

I doubt that (but may be wrong, I haven't time right now to think as
twistedly as mremap demands).  The code (patently!) expects new_vma
to be good at the end, it certainly wasn't intending to unmap it;
but 2.5 split_vma has been through a couple of convulsions, either
of which might have resulted in the potential for new_vma to be
freed where before it was guaranteed to remain.

Do you know the vmas before and after, and the mremap which did this?
I couldn't reproduce it starting X here, and an example would help to
uncloud my mind.  But you can reasonably answer that one example won't
prove anything, and where there's doubt, the code must be defensive.
(Besides, I'll be offline shortly.)

On to the patch...

> --- 25/mm/mremap.c~move_vma-use-after-free	Thu Dec 19 00:51:49 2002
> +++ 25-akpm/mm/mremap.c	Thu Dec 19 01:08:45 2002
> @@ -183,14 +183,16 @@ static unsigned long move_vma(struct vm_
>  	next = find_vma_prev(mm, new_addr, &prev);
>  	if (next) {
>  		if (prev && prev->vm_end == new_addr &&
> -		    can_vma_merge(prev, vma->vm_flags) && !vma->vm_file && !(vma->vm_flags & VM_SHARED)) {
> +				can_vma_merge(prev, vma->vm_flags) &&
> +				!(vma->vm_flags & VM_SHARED)) {
>  			spin_lock(&mm->page_table_lock);
>  			prev->vm_end = new_addr + new_len;
>  			spin_unlock(&mm->page_table_lock);
>  			new_vma = prev;
>  			if (next != prev->vm_next)
>  				BUG();
> -			if (prev->vm_end == next->vm_start && can_vma_merge(next, prev->vm_flags)) {
> +			if (prev->vm_end == next->vm_start &&
> +					can_vma_merge(next, prev->vm_flags)) {
>  				spin_lock(&mm->page_table_lock);
>  				prev->vm_end = next->vm_end;
>  				__vma_unlink(mm, next, prev);
> @@ -201,7 +203,8 @@ static unsigned long move_vma(struct vm_
>  				kmem_cache_free(vm_area_cachep, next);
>  			}
>  		} else if (next->vm_start == new_addr + new_len &&
> -			   can_vma_merge(next, vma->vm_flags) && !vma->vm_file && !(vma->vm_flags & VM_SHARED)) {
> +					can_vma_merge(next, vma->vm_flags) &&
> +					!(vma->vm_flags & VM_SHARED)) {
>  			spin_lock(&mm->page_table_lock);
>  			next->vm_start = new_addr;
>  			spin_unlock(&mm->page_table_lock);
> @@ -210,7 +213,8 @@ static unsigned long move_vma(struct vm_
>  	} else {
>  		prev = find_vma(mm, new_addr-1);
>  		if (prev && prev->vm_end == new_addr &&
> -		    can_vma_merge(prev, vma->vm_flags) && !vma->vm_file && !(vma->vm_flags & VM_SHARED)) {
> +				can_vma_merge(prev, vma->vm_flags) &&
> +				!(vma->vm_flags & VM_SHARED)) {
>  			spin_lock(&mm->page_table_lock);
>  			prev->vm_end = new_addr + new_len;
>  			spin_unlock(&mm->page_table_lock);

Hmmm.  Am I right to suppose that all the changes above are "cleanup"
which you couldn't resist making while you looked through this code,
but entirely irrelevant to the bug in question?  If those mods above
were right, they should be the subject of a separate patch.

There's certainly room for cleanup there, but my preference would be
to remove "can_vma_merge" completely, or at least its use in mremap.c,
using its explicit tests instead.  It looks like it was originally
quite appropriate for a use or two in mmap.c, but obscurely unhelpful
here - because in itself it is testing a bizarre asymmetric subset of
what's needed (that subset which remained to be tested in its original
use in mmap.c).

The problem with your changes above is, you've removed the !vma->vm_file
tests, presumably because you noticed that can_vma_merge already tests
!vma->vm_file.  But "vma" within can_vma_merge is "prev" or "next" here:
they are distinct tests, and you're now liable to merge an anonymous
mapping with a private file mapping - nice if it's from /dev/zero,
but otherwise not.  Please just cut those hunks out.

(Of course, I wouldn't have spotted this if I hadn't embarked on,
then retreated from, a similar cleanup myself a few months back.)

> @@ -227,12 +231,16 @@ static unsigned long move_vma(struct vm_
>  	}
>  
>  	if (!move_page_tables(vma, new_addr, addr, old_len)) {
> +		unsigned long must_fault_in;
> +		unsigned long fault_in_start;
> +		unsigned long fault_in_end;
> +
>  		if (allocated_vma) {
>  			*new_vma = *vma;
>  			INIT_LIST_HEAD(&new_vma->shared);
>  			new_vma->vm_start = new_addr;
>  			new_vma->vm_end = new_addr+new_len;
> -			new_vma->vm_pgoff += (addr - vma->vm_start) >> PAGE_SHIFT;
> +			new_vma->vm_pgoff += (addr-vma->vm_start) >> PAGE_SHIFT;

Hrrmph.

>  			if (new_vma->vm_file)
>  				get_file(new_vma->vm_file);
>  			if (new_vma->vm_ops && new_vma->vm_ops->open)
> @@ -251,19 +259,25 @@ static unsigned long move_vma(struct vm_
>  		} else
>  			vma = NULL;		/* nothing more to do */
>  
> -		do_munmap(current->mm, addr, old_len);
> -

Anguished cry!  There was careful manipulation of VM_ACCOUNT before and
after do_munmap, now you've for no reason moved do_munmap down outside.

>  		/* Restore VM_ACCOUNT if one or two pieces of vma left */
>  		if (vma) {
>  			vma->vm_flags |= VM_ACCOUNT;
>  			if (split)
>  				vma->vm_next->vm_flags |= VM_ACCOUNT;
>  		}
> +
> +		must_fault_in = new_vma->vm_flags & VM_LOCKED;
> +		fault_in_start = new_vma->vm_start;
> +		fault_in_end = new_vma->vm_end;
> +
> +		do_munmap(current->mm, addr, old_len);
> +
> +		/* new_vma could have been invalidated by do_munmap */
> +
>  		current->mm->total_vm += new_len >> PAGE_SHIFT;
> -		if (new_vma->vm_flags & VM_LOCKED) {
> +		if (must_fault_in) {
>  			current->mm->locked_vm += new_len >> PAGE_SHIFT;
> -			make_pages_present(new_vma->vm_start,
> -					   new_vma->vm_end);
> +			make_pages_present(fault_in_start, fault_in_end);
>  		}
>  		return new_addr;
>  	}

But the bugfix part of it looks good.

Hugh


^ permalink raw reply

* Re: 'D' processes on a healthy system?
From: Alan Cox @ 2002-12-19 17:43 UTC (permalink / raw)
  To: martin f krafft; +Cc: Linux Kernel Mailing List
In-Reply-To: <20021219124043.GA28617@fishbowl.madduck.net>

On Thu, 2002-12-19 at 12:40, martin f krafft wrote:
> [please CC me on replies]
> 19268 madduck   18   0  2208 2208  1076 D     1.3  0.4   0:00 sanitizer
>     6 root       9   0     0    0     0 DW    0.3  0.0   1:10 kupdated
>  8457 root      10   0  1156 1156   820 R     0.3  0.2   0:02 top
> 10843 postfix    9   0  1364 1364  1016 D     0.3  0.2   0:00 cleanup
>  3156 madduck    0   0   636  636   540 D     0.1  0.1   0:00 procmail
> 28356 root       9   0   292  288   240 R     0.0  0.0   0:01 supervise
> 28706 root       9   0  2060 2036  1724 D     0.0  0.4   0:00 sshd
> 21395 root      15   0  1944 1944  1876 D     0.0  0.3   0:00 zsh
> 
> notice the number of processes in       ^
> uninterruptible sleep mode in this column.

Your disk is too slow for the work being asked of it, thats all.
Eventually it'll get there

> My laptop, which is running Debian testing/unstable is not showing
> this behaviour, and its load goes far higher at times. I also run
> various other servers, partially on P5-120 systems, vanilla 2.4.xx
> kernels and Debian testing, and there are no such problems there.

sendmail tuning ?


^ permalink raw reply

* Hammerfall configuration
From: patrick reardon @ 2002-12-19 16:55 UTC (permalink / raw)
  To: alsa-devel

i have an AI-3 connected to the hammerfall's optical in/outs.  the converter will slave to
any clock, but when it's the master clock it only operates at 48K.  when i use "arecord -f
cd <file>" this seems to cause arecord to write 44.1k headers even though the data is at
48K.  "aplay" has no  problem with this (files play back at normal speed), but it seems to
cause problems with other software such as "cdrecord" which burns the files to disk about
2-3 half steps too low.  i tried resampling down to 44.1k with "sox" but it didn't seem to
help (i'm guessing it's also fooled by the 44.1k headers).

i'd like to use the hammerfall's internal clock as the master and let the AI-3 slave to
it, but am having trouble changing the configuration of the card.  i've looked for
documentation about this but so far haven't found any.  i tried editing asound.state 

-----------snip------------
        control.7 {
                comment.access 'read write'
                comment.type ENUMERATED
                comment.item.0 AutoSync
                comment.item.1 Master
                comment.item.2 'Word Clock'
                iface PCM
                name 'Sync Mode'
                value AutoSync
        }
        control.8 {
                comment.access 'read write'
                comment.type ENUMERATED
                comment.item.0 'IEC958 In'
                comment.item.1 'ADAT1 In'
                comment.item.2 'ADAT2 In'
                iface PCM
                name 'Preferred Sync Source'
                value 'ADAT1 In'
------------snip------------

by hand, changing the 'Sync Mode'  value from AutoSync to Master (should these values be
in quotes?), ran "alsactl store hammerfall", unloaded then reloaded the alsa modules, then
ran "alsactl restore hammerfall.  ("hammerfall" is the card's id.)  but asound.state 
still indicates Sync Mode is set to AutoSync.  "vi /proc/asound/hammerfall/rme9652" reads

--------------snip----------------
Latency: 8192 samples (2 periods of 32768 bytes)
Hardware pointer (frames): 0
Passthru: no
Clock mode: autosync
Pref. sync source: ADAT1

IEC958 input: Coaxial
IEC958 output: Coaxial only
IEC958 quality: Consumer
IEC958 emphasis: off
IEC958 Dolby: off
IEC958 sample rate: error flag set

ADAT Sample rate: 48000Hz
ADAT1: No Lock
ADAT2: No Lock
ADAT3: No Lock
--------------snip-----------------



i'm also curious if the "IEC958 sample rate: error flag set" is normal and if not, what to
look at to fix it.  asound.state says

----------snip-----------
        control.10 {
                comment.access read
                comment.type INTEGER
                comment.range '0 - 96000'
                iface PCM
                name 'IEC958 Sample Rate'
                value -1
----------snip-----------


changing the configuration must be a simple affair (i think) but i'm out of ideas.  any
suggestions or a pointer to relevant documentation would be appreciated.  also, if there's
no  documentation on this issue, i'd be glad to write some once i figure it out.  

tia, 
patrick


-------------------------------------------------------
This SF.NET email is sponsored by: Geek Gift Procrastinating?
Get the perfect geek gift now!  Before the Holidays pass you by.
T H I N K G E E K . C O M      http://www.thinkgeek.com/sf/

^ permalink raw reply

* Re: [LARTC] Shaping traffic to local users ?
From: Patrick McHardy @ 2002-12-19 16:56 UTC (permalink / raw)
  To: lartc
In-Reply-To: <marc-lartc-104030478706921@msgid-missing>

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

Hi again,
after looking at it i noticed a possible reason for the crashes i 
menitioned. This version has at least that problem fixed
(and some mix-ups i changed manually in my running version). Still no 
promises but at least it should be better than the
first version.

Bye,
Patrick

Patrick McHardy wrote:

> Hi Dimitris,
>
> You could try this patch to the owner match. Its working fine for me, 
> but i've seen it crash for unknown reasons
> on other boxes. anyway its not very important to me so i won't try to 
> fix it, but if you're brave you could give
> it a shot ;)
>
> Bye,
> Patrick
>
> Dimitris Kotsonis wrote:
>
>>         Hello
>>         Is it possible to shape incoming traffic for local linux users ?
>>
>>     Iptables can mark packets created from certain pid/uid/gid. Is 
>> there a way to do the same for packets _destined_ for some 
>> pid/uid/gid so that I can later shape them with IMQ ?
>>
>>         Thanks in advance
>>
>>     Dimitris Kotsonis
>>
>>
>>
>>    
>> _______________________________________________
>> LARTC mailing list / LARTC@mailman.ds9a.nl
>> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
>
>
>


[-- Attachment #2: owner-v4-pom.diff-2 --]
[-- Type: text/plain, Size: 7523 bytes --]

diff -urN patch-o-matic-20020825-orig/extra/owner-socketlookup.patch patch-o-matic-20020825/extra/owner-socketlookup.patch
--- patch-o-matic-20020825-orig/extra/owner-socketlookup.patch	1970-01-01 01:00:00.000000000 +0100
+++ patch-o-matic-20020825/extra/owner-socketlookup.patch	2002-12-19 17:51:24.000000000 +0100
@@ -0,0 +1,201 @@
+diff -urN linux-2.4.19-clean/include/net/tcp.h linux-2.4.19/include/net/tcp.h
+--- linux-2.4.19-clean/include/net/tcp.h	2002-08-03 02:39:46.000000000 +0200
++++ linux-2.4.19/include/net/tcp.h	2002-12-19 17:42:45.000000000 +0100
+@@ -140,6 +140,7 @@
+ extern void tcp_bucket_unlock(struct sock *sk);
+ extern int tcp_port_rover;
+ extern struct sock *tcp_v4_lookup_listener(u32 addr, unsigned short hnum, int dif);
++extern struct sock *tcp_v4_lookup(u32 saddr, u16 sport, u32 daddr, u16 hnum, int dif);
+ 
+ /* These are AF independent. */
+ static __inline__ int tcp_bhashfn(__u16 lport)
+diff -urN linux-2.4.19-clean/include/net/udp.h linux-2.4.19/include/net/udp.h
+--- linux-2.4.19-clean/include/net/udp.h	2001-11-22 20:47:15.000000000 +0100
++++ linux-2.4.19/include/net/udp.h	2002-12-19 17:42:45.000000000 +0100
+@@ -69,6 +69,8 @@
+ extern int	udp_ioctl(struct sock *sk, int cmd, unsigned long arg);
+ extern int	udp_disconnect(struct sock *sk, int flags);
+ 
++extern struct sock *udp_v4_lookup(u32 saddr, u16 sport, u32 daddr, u16 dport, int dif);
++
+ extern struct udp_mib udp_statistics[NR_CPUS*2];
+ #define UDP_INC_STATS(field)		SNMP_INC_STATS(udp_statistics, field)
+ #define UDP_INC_STATS_BH(field)		SNMP_INC_STATS_BH(udp_statistics, field)
+diff -urN linux-2.4.19-clean/net/ipv4/netfilter/ipt_owner.c linux-2.4.19/net/ipv4/netfilter/ipt_owner.c
+--- linux-2.4.19-clean/net/ipv4/netfilter/ipt_owner.c	2002-12-19 17:43:07.000000000 +0100
++++ linux-2.4.19/net/ipv4/netfilter/ipt_owner.c	2002-12-19 17:47:38.000000000 +0100
+@@ -2,17 +2,26 @@
+    locally generated outgoing packets.
+ 
+    Copyright (C) 2000 Marc Boucher
++
++   08/28/2002 Patrick McHardy <kaber@trash.net> 
++   		- Modified to also match properties of receiving sockets
+  */
+ #include <linux/module.h>
+ #include <linux/skbuff.h>
+ #include <linux/file.h>
++#include <linux/ip.h>
++#include <linux/tcp.h>
++#include <linux/udp.h>
+ #include <net/sock.h>
++#include <net/tcp.h>
++#include <net/udp.h>
++#include <net/route.h>
+ 
+ #include <linux/netfilter_ipv4/ipt_owner.h>
+ #include <linux/netfilter_ipv4/ip_tables.h>
+ 
+ static int
+-match_comm(const struct sk_buff *skb, const char *comm)
++match_comm(const struct sock *sk, const char *comm)
+ {
+ 	struct task_struct *p;
+ 	struct files_struct *files;
+@@ -28,7 +37,7 @@
+ 		if(files) {
+ 			read_lock(&files->file_lock);
+ 			for (i=0; i < files->max_fds; i++) {
+-				if (fcheck_files(files, i) == skb->sk->socket->file) {
++				if (fcheck_files(files, i) == sk->socket->file) {
+ 					read_unlock(&files->file_lock);
+ 					task_unlock(p);
+ 					read_unlock(&tasklist_lock);
+@@ -44,7 +53,7 @@
+ }
+ 
+ static int
+-match_pid(const struct sk_buff *skb, pid_t pid)
++match_pid(const struct sock *sk, pid_t pid)
+ {
+ 	struct task_struct *p;
+ 	struct files_struct *files;
+@@ -59,7 +68,7 @@
+ 	if(files) {
+ 		read_lock(&files->file_lock);
+ 		for (i=0; i < files->max_fds; i++) {
+-			if (fcheck_files(files, i) == skb->sk->socket->file) {
++			if (fcheck_files(files, i) == sk->socket->file) {
+ 				read_unlock(&files->file_lock);
+ 				task_unlock(p);
+ 				read_unlock(&tasklist_lock);
+@@ -75,10 +84,10 @@
+ }
+ 
+ static int
+-match_sid(const struct sk_buff *skb, pid_t sid)
++match_sid(const struct sock *sk, pid_t sid)
+ {
+ 	struct task_struct *p;
+-	struct file *file = skb->sk->socket->file;
++	struct file *file = sk->socket->file;
+ 	int i, found=0;
+ 
+ 	read_lock(&tasklist_lock);
+@@ -119,41 +128,67 @@
+       int *hotdrop)
+ {
+ 	const struct ipt_owner_info *info = matchinfo;
++	struct sock *sk = NULL;
++	int ret = 0;
+ 
+-	if (!skb->sk || !skb->sk->socket || !skb->sk->socket->file)
+-		return 0;
++	if (out) {
++		sk = skb->sk;
++	} else {
++		struct iphdr *iph = skb->nh.iph;
++		if (iph->protocol == IPPROTO_TCP) {
++			struct tcphdr *tcph =
++				(struct tcphdr*)((u_int32_t*)iph + iph->ihl);
++			sk = tcp_v4_lookup(iph->saddr, tcph->source,
++					   iph->daddr, tcph->dest,
++					   ((struct rtable*)skb->dst)->rt_iif);
++		} else if (iph->protocol == IPPROTO_UDP) {
++			struct udphdr *udph =
++				(struct udphdr*)((u_int32_t*)iph + iph->ihl);
++			sk = udp_v4_lookup(iph->saddr, udph->source, iph->daddr,
++					   udph->dest, skb->dev->ifindex);
++		}
++	} 
++					
++	if (!sk || !sk->socket || !sk->socket->file)
++		goto out;
+ 
+ 	if(info->match & IPT_OWNER_UID) {
+-		if((skb->sk->socket->file->f_uid != info->uid) ^
++		if((sk->socket->file->f_uid != info->uid) ^
+ 		    !!(info->invert & IPT_OWNER_UID))
+-			return 0;
++			goto out;
+ 	}
+ 
+ 	if(info->match & IPT_OWNER_GID) {
+-		if((skb->sk->socket->file->f_gid != info->gid) ^
++		if((sk->socket->file->f_gid != info->gid) ^
+ 		    !!(info->invert & IPT_OWNER_GID))
+-			return 0;
++			goto out;
+ 	}
+ 
+ 	if(info->match & IPT_OWNER_PID) {
+-		if (!match_pid(skb, info->pid) ^
++		if (!match_pid(sk, info->pid) ^
+ 		    !!(info->invert & IPT_OWNER_PID))
+-			return 0;
++			goto out;
+ 	}
+ 
+ 	if(info->match & IPT_OWNER_SID) {
+-		if (!match_sid(skb, info->sid) ^
++		if (!match_sid(sk, info->sid) ^
+ 		    !!(info->invert & IPT_OWNER_SID))
+-			return 0;
++			goto out;
+ 	}
+ 
+ 	if(info->match & IPT_OWNER_COMM) {
+-		if (!match_comm(skb, info->comm) ^
++		if (!match_comm(sk, info->comm) ^
+ 		    !!(info->invert & IPT_OWNER_COMM))
+-			return 0;
++			goto out;
+ 	}
+ 
+-	return 1;
++	ret = 1;
++
++out:
++	if (in && sk)
++		sock_put(sk);
++
++	return ret;
+ }
+ 
+ static int
+@@ -164,8 +199,10 @@
+            unsigned int hook_mask)
+ {
+         if (hook_mask
+-            & ~((1 << NF_IP_LOCAL_OUT) | (1 << NF_IP_POST_ROUTING))) {
+-                printk("ipt_owner: only valid for LOCAL_OUT or POST_ROUTING.\n");
++            & ~((1 << NF_IP_LOCAL_OUT) | (1 << NF_IP_POST_ROUTING) |
++		(1 << NF_IP_LOCAL_IN)  | (1 << NF_IP_PRE_ROUTING))) {
++                printk("ipt_owner: only valid for LOCAL_OUT, LOCAL_IN, "
++		       "POST_ROUTING or PRE_ROUTING.\n");
+                 return 0;
+         }
+ 
+diff -urN linux-2.4.19-clean/net/netsyms.c linux-2.4.19/net/netsyms.c
+--- linux-2.4.19-clean/net/netsyms.c	2002-08-03 02:39:46.000000000 +0200
++++ linux-2.4.19/net/netsyms.c	2002-12-19 17:42:45.000000000 +0100
+@@ -588,4 +588,9 @@
+ EXPORT_SYMBOL(net_call_rx_atomic);
+ EXPORT_SYMBOL(softnet_data);
+ 
++#if defined(CONFIG_IP_NF_MATCH_OWNER)||defined(CONFIG_IP_NF_MATCH_OWNER_MODULE)
++EXPORT_SYMBOL(tcp_v4_lookup);
++EXPORT_SYMBOL(udp_v4_lookup);
++#endif /* CONFIG_IP_NF_MATCH_OWNER */
++
+ #endif  /* CONFIG_NET */
diff -urN patch-o-matic-20020825-orig/extra/owner-socketlookup.patch.help patch-o-matic-20020825/extra/owner-socketlookup.patch.help
--- patch-o-matic-20020825-orig/extra/owner-socketlookup.patch.help	1970-01-01 01:00:00.000000000 +0100
+++ patch-o-matic-20020825/extra/owner-socketlookup.patch.help	2002-12-19 17:31:05.000000000 +0100
@@ -0,0 +1,13 @@
+Author: Patrick McHardy <kaber@trash.net>
+Status: working
+
+The patch allows you to use the owner match in the INPUT/PREROUTING chains to
+match properties of the receiving socket.
+
+Example:
+
+	# Allow packets coming in on eth0 to sockets owned be local user
+	# kaber
+	
+	iptables -A INPUT -i eth0 -m owner --uid-owner kaber -j ACCEPT
+

^ permalink raw reply

* Re: reiserfsck --rebuild-tree on a big filesystem
From: Oleg Drokin @ 2002-12-19 17:00 UTC (permalink / raw)
  To: Zygo Blaxell; +Cc: reiserfs-list
In-Reply-To: <atsteb$44s$1@genki.hungrycats.org>

Hello!

On Thu, Dec 19, 2002 at 04:51:23PM +0000, Zygo Blaxell wrote:

> >> would take about 1 month to complete (started at 2000 blocks/sec, 
> >> but now running at 26b/s).
> My reiserfsck --rebuild-tree has been running for a little over an hour
> and has degraded to 49 blocks/sec (about 10 days).  r-fsck absorbs all

Part of this problem is solved - get latest 3.6.5-pre version of reiserfsprogs
and give it a try.

> Based on past events, the read speed will probably degrade to zero in a
> week or two, if the reiserfsck process doesn't run out of RAM+swap first.

No it won't.

> If you feel that 'debugreiserfs -p ... | bzip2' output would be helpful,
> I could generate it, but that's about 40GB of data.

No, we know what the problem with read speed degradation at pass0 is and
Vitaly have fixed it already.
Also there is similar problem expected at semantic pass that was not dealt with
because we are not yet sure how to solve that. But overall
3.6.5-pre1 should be noticeable faster.

Bye,
    Oleg

^ permalink raw reply

* Re: 8260 - Spurious interrupts again
From: Tom Rini @ 2002-12-19 17:02 UTC (permalink / raw)
  To: Hans Feldt; +Cc: Shen Rong, linuxppc-embedded
In-Reply-To: <3DD4D6EE.5000902@uab.ericsson.se>


On Fri, Nov 15, 2002 at 12:13:50PM +0100, Hans Feldt wrote:

> On 11/15/02 09:58 AM, Shen Rong wrote:
>
> >    I have the same problem like you, and I added a "sync" at the last
> >    line in
> >m8260_mask_and_ack like you, and it solves the ploblem. But it is
> >interesting
> >that if I add a "sync" above the last line, it's also ok, that's
>
> Well its the write to SIMR that needs a sync before enabling external
> interrupts, not the sipnr variable.
>
> >So I think there should be a time delay when we do mask&ack(&following
> >operation maybe).
>
> Don't agree, I believe the missing sync is a bug. I talked a Motorola
> FAE yesterday and he says the same thing. It doesn't really matter if
> you have the 8260 as a slave or not.
>
> What does the maintainers of this code (Tom Rini?) think about it?

Sorry it took so long to get back to this thread, I'm not sure.  I don't
think I know enough about this code to say either way.  But I'm inclined
to think the sync is needed regardless as well.

If someone would post a patch vs current linuxppc_2_4 and linuxppc-2.5,
I'll apply it as there definatly seems to be a problem here.

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

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

^ permalink raw reply

* Promise SX6000 question.
From: Seth Hall @ 2002-12-19 17:02 UTC (permalink / raw)
  To: linux-raid@vger.kernel.org; +Cc: linuxcomments, Jordan Rhody, support, support

Hi,

I am using a Promise SX6000 RAID controller and five Seagate 120GB drives to
create a 480GB RAID-5 array, to be used under Slackware v8.1. I was able to
compile and load the Promise pti_st.o module, and subsequently was able to
create a single new large partition on the /dev/sda1 drive, as follows:

Disk /dev/sda1: 64 heads, 32 sectors, 457758 cylinders
Units = cylinders of 2048 * 512 bytes

     Device Boot    Start       End    Blocks   Id  System
/dev/sda1p1             1    457758 468744176   83  Linux


The problem is I cannot seem to create a file system on this new partition. I
was assuming that ext3 would be a good initial  choice, at least while we were
fooling around using this new array.

Any thoughts about what I might be doing wrong, or what I might be missing?

	Thanks,
		Seth Hall
		Speech Comm. Group
		MIT, Cambridge

^ 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.