All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] IRQ distribution in the 2.5.52  kernel
From: Kamble, Nitin A @ 2002-12-20  9:08 UTC (permalink / raw)
  To: linux-kernel; +Cc: Kamble, Nitin A

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

Hello All,

  We were looking at the performance impact of the IRQ routing from the 2.5.52 Linux kernel. This email includes some of our findings about the way the interrupts are getting moved in the 2.5.52 kernel. Also there is discussion and a patch for a new implementation. Let me know what you think at nitin.a.kamble@intel.com
 
Current implementation:
======================
We have found that the existing implementation works well on IA32 SMP systems with light load of interrupts. Also we noticed that it is not working that well under heavy interrupt load conditions on these SMP systems. The observations are:
 
* Interrupt load of each IRQ is getting balanced on CPUs independent of load of other IRQs. Also the current implementation moves the IRQs randomly. This works well when the interrupt load is light. But we start seeing imbalance of interrupt load with existence of multiple heavy interrupt sources. Frequently multiple heavily loaded IRQs gets moved to a single CPU while other CPUs stay very lightly loaded. To achieve a good interrupts load balance, it is important to consider the load of all the interrupts together.
    This further can be explained with an example of 4 CPUs and 4 heavy interrupt sources. With the existing random movement approach, the chance of each of these heavy interrupt sources moving to separate CPUs is: (4/4)*(3/4)*(2/4)*(1/4) = 3/16. It means 13/16 = 81.25% of the time the situation is, some CPUs are very lightly loaded and some are loaded with multiple heavy interrupts. This causes the interrupt load imbalance and results in less performance. In a case of 2 CPUs and 2 heavily loaded interrupt sources, this imbalance happens 1/2 = 50% of the times. This issue becomes more and more severe with increasing number of heavy interrupt sources.
 
* Another interesting observation is: We cannot see the imbalance of the interrupt load from /proc/interrupts. (/proc/interrupts shows the cumulative load of interrupts on all CPUs.) If the interrupt load is imbalanced and this imbalance is getting rotated among CPUs continuously, then /proc/interrupts will still show that the interrupt load is going to processors very evenly. Currently at the frequency (HZ/50) at which IRQs are moved across CPUs, it is not possible to see any interrupt load imbalance happening.
 
* We have also found that, in certain cases the static IRQ binding performs better than the existing kernel distribution of interrupt load. The reason is, in a well-balanced interrupt load situations, these interrupts are unnecessarily getting frequently moved across CPUs. This adds an extra overhead; also it takes off the CPU cache warmth benefits.
  This came out from the performance measurements done on a 4-way HT (8 logical processors) Pentium 4 Xeon system running 8 copies of netperf. The 4 NICs in the system taking different IRQs generated sizable interrupt load with the help of connected clients.
 
Here the netperf transactions/sec throughput numbers observed are:
 
IRQs nicely manually bound to CPUs: 56.20K 
The current kernel implementation of IRQ movement: 50.05K
 -----------------------
 The static binding of IRQs has performed 12.28% better than the current IRQ movement implemented in the kernel.
 
* The current implementation does not distinguish siblings from the HT (Hyper-Threading(tm)) enabled CPUs. It will be beneficial to balance the interrupt load with respect to processor packages first, and then among logical CPUs inside processor packages. 
  For example if we have 2 heavy interrupt sources and 2 processor packages (4 logical CPUs); Assigning both the heavy interrupt sources in different processor packages is better, it will use different execution resources from the different processor packages.
 
 

New revised implementation:
==========================
We also have been working on a new implementation. The following points are in main focus.
 
* At any moment heavily loaded IRQs are distributed to different CPUs to achieve as much balance as possible. 
 
* Lightly loaded interrupt sources are ignored from the load balancing, as they do not cause considerable imbalance.
 
* When the heavy interrupt sources are balanced, they are not moved around. This also helps in keeping the CPU caches warm.
 
* It has been made HT aware. While distributing the load, the load on a processor package to which the logical CPUs belong to is also considered.
 
* In the situations of few (lesser than num_cpus) heavy interrupt sources, it is not possible to balance them evenly. In such case the existing code has been reused to move the interrupts. The randomness from the original code has been removed.
 
* The time interval for redistribution has been made flexible. It varies as the system interrupt load changes.
 
* A new kernel_thread is introduced to do the load balancing calculations for all the interrupt sources. It keeps the balanace_maps ready for interrupt handlers, keeping the overhead in the interrupt handling to minimum.
 
* It allows the disabling of the IRQ distribution from the boot loader command line, if anybody wants to do it for any reason. 
 
* The algorithm also takes into account the static binding of interrupts to CPUs that user imposes from the /proc/irq/{n}/smp_affinity interface.
 
 
Throughput numbers with the netperf setup for the new implementation:
 
Current kernel IRQ balance implementation: 50.02K transactions/sec
The new IRQ balance implementation: 56.01K transactions/sec
 ---------------------
  The performance improvement on P4 Xeon of 11.9% is observed.
 
The new IRQ balance implementation also shows little performance improvement on P6 (Pentium II, III) systems.
 
On a P6 system the netperf throughput numbers are:
Current kernel IRQ balance implementation: 36.96K transactions/sec
The new IRQ balance implementation: 37.65K transactions/sec
 ---------------------
  Here the performance improvement on P6 system of about 2% is observed.
 
 
Thanks,
Nitin

diff -Naru 2.5.52/Documentation/kernel-parameters.txt kirqb/Documentation/kernel-parameters.txt
--- 2.5.52/Documentation/kernel-parameters.txt	Tue Dec 17 15:35:57 2002
+++ kirqb/Documentation/kernel-parameters.txt	Tue Dec 17 15:37:29 2002
@@ -352,6 +352,8 @@
 
 	hugepages=	[HW,IA-32] Maximal number of HugeTLB pages
 
+	noirqbalance	[IA-32,SMP,KNL] Disable kernel irq balancing
+
 	i8042_direct	[HW] Non-translated mode
 	i8042_dumbkbd
 	i8042_noaux
diff -Naru 2.5.52/arch/i386/kernel/io_apic.c kirqb/arch/i386/kernel/io_apic.c
--- 2.5.52/arch/i386/kernel/io_apic.c	Tue Dec 17 15:35:26 2002
+++ kirqb/arch/i386/kernel/io_apic.c	Fri Dec 20 01:23:15 2002
@@ -206,19 +206,37 @@
 	spin_unlock_irqrestore(&ioapic_lock, flags);
 }
 
-#if CONFIG_SMP
+#if defined(CONFIG_SMP)
+# include <asm/processor.h>	/* kernel_thread() */
+# include <linux/kernel_stat.h>	/* kstat */
+# include <linux/slab.h>		/* kmalloc() */
+# include <linux/timer.h>	/* time_after() */
+ 
+# if CONFIG_BALANCED_IRQ_DEBUG
+#  define TDprintk(x...) do { printk("<%ld:%s:%d>: ", jiffies, __FILE__, __LINE__); printk(x); } while (0)
+#  define Dprintk(x...) do { TDprintk(x); } while (0)
+# else
+#  define TDprintk(x...) 
+#  define Dprintk(x...) 
+# endif
 
-typedef struct {
-	unsigned int cpu;
-	unsigned long timestamp;
-} ____cacheline_aligned irq_balance_t;
-
-static irq_balance_t irq_balance[NR_IRQS] __cacheline_aligned
-			= { [ 0 ... NR_IRQS-1 ] = { 0, 0 } };
+# define MIN(a,b) (((a) < (b)) ? (a) : (b))
+# define MAX(a,b) (((a) > (b)) ? (a) : (b))
 
 extern unsigned long irq_affinity [NR_IRQS];
-
-#endif
+unsigned long __cacheline_aligned irq_balance_mask [NR_IRQS];
+static int irqbalance_disabled __initdata = 0;
+static int physical_balance = 0;
+
+struct irq_cpu_info {
+	unsigned long * last_irq;
+	unsigned long * irq_delta;
+	unsigned long irq;
+} irq_cpu_data[NR_CPUS];
+
+#define CPU_IRQ(cpu)		(irq_cpu_data[cpu].irq)
+#define LAST_CPU_IRQ(cpu,irq)   (irq_cpu_data[cpu].last_irq[irq])
+#define IRQ_DELTA(cpu,irq) 	(irq_cpu_data[cpu].irq_delta[irq])
 
 #define IDLE_ENOUGH(cpu,now) \
 		(idle_cpu(cpu) && ((now) - irq_stat[(cpu)].idle_timestamp > 1))
@@ -226,10 +244,224 @@
 #define IRQ_ALLOWED(cpu,allowed_mask) \
 		((1 << cpu) & (allowed_mask))
 
-#if CONFIG_SMP
+#define CPU_TO_PACKAGEINDEX(i) \
+		((physical_balance && i > cpu_sibling_map[i]) ? cpu_sibling_map[i] : i)
+
+#define MAX_BALANCED_IRQ_INTERVAL	(5*HZ)
+#define MIN_BALANCED_IRQ_INTERVAL	(HZ/2)
+#define BALANCED_IRQ_MORE_DELTA		(HZ/10)
+#define BALANCED_IRQ_LESS_DELTA		(HZ)
+
+unsigned long balanced_irq_interval = MAX_BALANCED_IRQ_INTERVAL;
+					 
+static inline void balance_irq(int cpu, int irq);
+
+static inline void rotate_irqs_among_cpus(unsigned long useful_load_threshold)
+{
+	int i, j;
+	Dprintk("Rotating IRQs among CPUs.\n");
+	for (i = 0; i < NR_CPUS; i++) {
+		for (j = 0; cpu_online(i) && (j < NR_IRQS); j++) {
+			if (!irq_desc[j].action)
+				continue;
+			/* Is it a significant load ?  */
+			if (IRQ_DELTA(CPU_TO_PACKAGEINDEX(i),j) < useful_load_threshold)
+				continue;
+			balance_irq(i, j);
+		}
+	}
+	balanced_irq_interval = MAX(MIN_BALANCED_IRQ_INTERVAL,
+		balanced_irq_interval - BALANCED_IRQ_LESS_DELTA);	
+	return;
+}
+
+static void do_irq_balance(void)
+{
+	int i, j;
+	unsigned long max_cpu_irq = 0, min_cpu_irq = (~0);
+	unsigned long move_this_load = 0;
+	int max_loaded = 0, min_loaded = 0;
+	unsigned long useful_load_threshold = balanced_irq_interval + 10;
+	int selected_irq;
+	int tmp_loaded, first_attempt = 1;
+	unsigned long tmp_cpu_irq;
+	unsigned long imbalance = 0;
+	unsigned long allowed_mask;
+	unsigned long target_cpu_mask;
+
+	for (i = 0; i < NR_CPUS; i++) {
+		int package_index;
+		CPU_IRQ(i) = 0;
+		if (!cpu_online(i))
+			continue;
+		package_index = CPU_TO_PACKAGEINDEX(i);
+		for (j = 0; j < NR_IRQS; j++) {
+			unsigned long value_now, delta;
+			/* Is this an active IRQ? */
+			if (!irq_desc[j].action)
+				continue;
+			if (package_index == i)
+				IRQ_DELTA(package_index,j) = 0;
+			/* Determine the total count per processor per IRQ */
+			value_now = (unsigned long) kstat_cpu(i).irqs[j];
+
+			/* Determine the activity per processor per IRQ */
+			delta = value_now - LAST_CPU_IRQ(i,j);
+
+			/* Update last_cpu_irq[][] for the next time */
+			LAST_CPU_IRQ(i,j) = value_now;
+
+			/* Ignore IRQs whose rate is less than the clock */
+			if (delta < useful_load_threshold)
+				continue;
+			/* update the load for the processor or package total */
+			IRQ_DELTA(package_index,j) += delta;
+
+			/* Keep track of the higher numbered sibling as well */
+			if (i != package_index)
+				CPU_IRQ(i) += delta;
+			/*
+			 * We have sibling A and sibling B in the package
+			 *
+			 * cpu_irq[A] = load for cpu A + load for cpu B
+			 * cpu_irq[B] = load for cpu B
+			 */
+			CPU_IRQ(package_index) += delta;
+		}
+	}
+	/* Find the least loaded processor package */
+	for (i = 0; i < NR_CPUS; i++) {
+		if (!cpu_online(i))
+			continue;
+		if (physical_balance && i > cpu_sibling_map[i])
+			continue;
+		if (min_cpu_irq > CPU_IRQ(i)) {
+			min_cpu_irq = CPU_IRQ(i);
+			min_loaded = i;
+		}
+	}
+	max_cpu_irq = ULONG_MAX;
+
+tryanothercpu:
+	/* Look for heaviest loaded processor.
+	 * We may come back to get the next heaviest loaded processor.
+	 * Skip processors with trivial loads.
+	 */
+	tmp_cpu_irq = 0;
+	tmp_loaded = -1;
+	for (i = 0; i < NR_CPUS; i++) {
+		if (!cpu_online(i))
+			continue;
+		if (physical_balance && i > cpu_sibling_map[i])
+			continue;
+		if (max_cpu_irq <= CPU_IRQ(i)) 
+			continue;
+		if (tmp_cpu_irq < CPU_IRQ(i)) {
+			tmp_cpu_irq = CPU_IRQ(i);
+			tmp_loaded = i;
+		}
+	}
+
+	if (tmp_loaded == -1) {
+ 	 /* In the case of small number of heavy interrupt sources, 
+	  * loading some of the cpus too much. We use Ingo's original 
+	  * approach to rotate them around.
+	  */
+		if (!first_attempt && imbalance >= useful_load_threshold) {
+			rotate_irqs_among_cpus(useful_load_threshold);
+			return;
+		}
+		goto not_worth_the_effort;
+	}
+	
+	first_attempt = 0;		/* heaviest search */
+	max_cpu_irq = tmp_cpu_irq;	/* load */
+	max_loaded = tmp_loaded;	/* processor */
+	imbalance = (max_cpu_irq - min_cpu_irq) / 2;
+	
+	Dprintk("max_loaded cpu = %d\n", max_loaded);
+	Dprintk("min_loaded cpu = %d\n", min_loaded);
+	Dprintk("max_cpu_irq load = %ld\n", max_cpu_irq);
+	Dprintk("min_cpu_irq load = %ld\n", min_cpu_irq);
+	Dprintk("load imbalance = %lu\n", imbalance);
+
+	/* if imbalance is less than approx 10% of max load, then
+	 * observe diminishing returns action. - quit
+	 */
+	if (imbalance < (max_cpu_irq >> 3)) {
+		Dprintk("Imbalance too trivial\n");
+		goto not_worth_the_effort;
+	}
+
+tryanotherirq:
+	/* if we select an IRQ to move that can't go where we want, then
+	 * see if there is another one to try.
+	 */
+	move_this_load = 0;
+	selected_irq = -1;
+	for (j = 0; j < NR_IRQS; j++) {
+		/* Is this an active IRQ? */
+		if (!irq_desc[j].action)
+			continue;
+		if (imbalance <= IRQ_DELTA(max_loaded,j))
+			continue;
+		/* Try to find the IRQ that is closest to the imbalance
+		 * without going over.
+		 */
+		if (move_this_load < IRQ_DELTA(max_loaded,j)) {
+			move_this_load = IRQ_DELTA(max_loaded,j);
+			selected_irq = j;
+		}
+	}
+	if (selected_irq == -1) {
+		goto tryanothercpu;
+	}
 
-#define IRQ_BALANCE_INTERVAL (HZ/50)
+	imbalance = move_this_load;
 	
+	/* For physical_balance case, we accumlated both load
+	 * values in the one of the siblings cpu_irq[],
+	 * to use the same code for physical and logical processors
+	 * as much as possible. 
+	 *
+	 * NOTE: the cpu_irq[] array holds the sum of the load for
+	 * sibling A and sibling B in the slot for the lowest numbered
+	 * sibling (A), _AND_ the load for sibling B in the slot for
+	 * the higher numbered sibling.
+	 *
+	 * We seek the least loaded sibling by making the comparison
+	 * (A+B)/2 vs B
+	 */
+	if (physical_balance && (CPU_IRQ(min_loaded) >> 1) > CPU_IRQ(cpu_sibling_map[min_loaded]))
+		min_loaded = cpu_sibling_map[min_loaded];
+
+	allowed_mask = cpu_online_map & irq_affinity[selected_irq];
+	target_cpu_mask = 1 << min_loaded;
+
+	if (target_cpu_mask & allowed_mask) {
+		irq_desc_t *desc = irq_desc + selected_irq;
+		Dprintk("irq = %d moved to cpu = %d\n", selected_irq, min_loaded);
+		/* mark for change destination */
+		spin_lock(&desc->lock);
+		irq_balance_mask[selected_irq] = target_cpu_mask;
+		spin_unlock(&desc->lock);
+		/* Since we made a change, come back sooner to 
+		 * check for more variation.
+		 */
+		balanced_irq_interval = MAX(MIN_BALANCED_IRQ_INTERVAL,
+			balanced_irq_interval - BALANCED_IRQ_LESS_DELTA);	
+		return;
+	}
+	goto tryanotherirq;
+
+not_worth_the_effort:
+	/* if we did not find an IRQ to move, then adjust the time interval upward */
+	balanced_irq_interval = MIN(MAX_BALANCED_IRQ_INTERVAL,
+		balanced_irq_interval + BALANCED_IRQ_MORE_DELTA);	
+	Dprintk("IRQ worth rotating not found\n");
+	return;
+}
+
 static unsigned long move(int curr_cpu, unsigned long allowed_mask, unsigned long now, int direction)
 {
 	int search_idle = 1;
@@ -256,34 +488,112 @@
 	return cpu;
 }
 
-static inline void balance_irq(int irq)
+static inline void balance_irq (int cpu, int irq)
 {
-	irq_balance_t *entry = irq_balance + irq;
 	unsigned long now = jiffies;
-
+	unsigned long allowed_mask;
+	unsigned int new_cpu;
+		
 	if (clustered_apic_mode)
 		return;
 
-	if (unlikely(time_after(now, entry->timestamp + IRQ_BALANCE_INTERVAL))) {
-		unsigned long allowed_mask;
-		unsigned int new_cpu;
-		int random_number;
-
-		rdtscl(random_number);
-		random_number &= 1;
-
-		allowed_mask = cpu_online_map & irq_affinity[irq];
-		entry->timestamp = now;
-		new_cpu = move(entry->cpu, allowed_mask, now, random_number);
-		if (entry->cpu != new_cpu) {
-			entry->cpu = new_cpu;
-			set_ioapic_affinity(irq, 1 << new_cpu);
+	allowed_mask = cpu_online_map & irq_affinity[irq];
+	new_cpu = move(cpu, allowed_mask, now, 1);
+	if (cpu != new_cpu) {
+		irq_desc_t *desc = irq_desc + irq;
+		spin_lock(&desc->lock);
+		irq_balance_mask[irq] = 1 << new_cpu;
+		spin_unlock(&desc->lock);
+	}
+}
+
+int balanced_irq(void *unused)
+{
+	int i;
+	unsigned long prev_balance_time = jiffies;
+	long time_remaining = balanced_irq_interval;
+	daemonize();
+	sigfillset(&current->blocked);
+	sprintf(current->comm, "balanced_irq");
+	
+	/* push everything to CPU 0 to give us a starting point.  */
+	for (i = 0 ; i < NR_IRQS ; i++)
+		irq_balance_mask[i] = 1 << 0;
+	for (;;) {
+		set_current_state(TASK_INTERRUPTIBLE);
+		time_remaining = schedule_timeout(time_remaining);
+		if (time_after(jiffies, prev_balance_time+balanced_irq_interval)) {
+			Dprintk("balanced_irq: calling do_irq_balance() %lu\n", jiffies);
+			do_irq_balance();
+			prev_balance_time = jiffies;
+			time_remaining = balanced_irq_interval;
 		}
+        }
+}
+
+static int __init balanced_irq_init(void)
+{
+	int i;
+	struct cpuinfo_x86 *c;
+        c = &boot_cpu_data;
+	if (irqbalance_disabled)
+		return 0;
+	/* Enable physical balance only if more than 
+	 * one physical processor package is present */
+	if (smp_num_siblings > 1 && cpu_online_map >> 2)
+		physical_balance = 1;
+
+	for (i = 0; i < NR_CPUS; i++) {
+		if (!cpu_online(i))
+			continue;
+		irq_cpu_data[i].irq_delta = kmalloc(sizeof(unsigned long) * NR_IRQS, GFP_KERNEL);
+		irq_cpu_data[i].last_irq = kmalloc(sizeof(unsigned long) * NR_IRQS, GFP_KERNEL);
+		if (irq_cpu_data[i].irq_delta == NULL || irq_cpu_data[i].last_irq == NULL) {
+			printk(KERN_ERR "balanced_irq_init: out of memory");
+			goto failed;
+		}
+		memset(irq_cpu_data[i].irq_delta,0,sizeof(unsigned long) * NR_IRQS);
+		memset(irq_cpu_data[i].last_irq,0,sizeof(unsigned long) * NR_IRQS);
+	}
+	
+	printk(KERN_INFO "Starting balanced_irq\n");
+	if (kernel_thread(balanced_irq, NULL, CLONE_KERNEL) >= 0) 
+		return 0;
+	else 
+		printk(KERN_ERR "balanced_irq_init: failed to spawn balanced_irq");
+failed:
+	for (i = 0; i < NR_CPUS; i++) {
+		if (irq_cpu_data[i].irq_delta)
+			kfree(irq_cpu_data[i].irq_delta);
+		if (irq_cpu_data[i].last_irq)
+			kfree(irq_cpu_data[i].last_irq);
 	}
+	return 0;
 }
-#else /* !SMP */
-static inline void balance_irq(int irq) { }
-#endif
+
+static int __init irqbalance_disable(char *str)
+{
+	irqbalance_disabled = 1;
+	return 0;
+}
+
+__setup("noirqbalance", irqbalance_disable);
+
+static void set_ioapic_affinity (unsigned int irq, unsigned long mask);
+
+static inline void move_irq(int irq)
+{
+	/* note - we hold the desc->lock */
+	if (unlikely(irq_balance_mask[irq])) {
+		set_ioapic_affinity(irq, irq_balance_mask[irq]);
+		irq_balance_mask[irq] = 0;
+	}
+}
+
+__initcall(balanced_irq_init);
+
+#endif /* defined(CONFIG_SMP) */
+
 
 /*
  * support for broken MP BIOSs, enables hand-redirection of PIRQ0-7 to
@@ -1308,7 +1618,7 @@
  */
 static void ack_edge_ioapic_irq(unsigned int irq)
 {
-	balance_irq(irq);
+	move_irq(irq);
 	if ((irq_desc[irq].status & (IRQ_PENDING | IRQ_DISABLED))
 					== (IRQ_PENDING | IRQ_DISABLED))
 		mask_IO_APIC_irq(irq);
@@ -1348,7 +1658,7 @@
 	unsigned long v;
 	int i;
 
-	balance_irq(irq);
+	move_irq(irq);
 /*
  * It appears there is an erratum which affects at least version 0x11
  * of I/O APIC (that's the 82093AA and cores integrated into various



[-- Attachment #2: kirqb_2.5.52.ZIP --]
[-- Type: application/x-zip-compressed, Size: 4484 bytes --]

^ permalink raw reply

* trouble building iptables-1.2.7a in 2.4.17
From: Don Cohen @ 2002-12-20  8:59 UTC (permalink / raw)
  To: netfilter-devel


transcript follows
I do see, e.g., IP_CT_DIR_MAX declared in 
/home/user/linux-2.4.17/include/linux/netfilter_ipv4/ip_conntrack_tuple.h
but that seems to be only #ifdef __KERNEL__

It looks like this is corrected in
patch-o-matic-20020825/submitted/2.4.18.patch but I'm in .17 and
iptables-1.2.7a claims to require 2.4.4 + so should build here, right?

====

[root@router2 /root]# cd iptables-1.2.7a/
[root@router2 iptables-1.2.7a]# make KERNEL_DIR=/home/user/linux-2.4.17
Making dependencies: please wait...
Extensions found:
cc -O2 -Wall -Wunused -I/home/user/linux-2.4.17/include -Iinclude/ -DIPTABLES_VERSION=\"1.2.7a\"  -fPIC -o extensions/libipt_ah_sh.o -c extensions/libipt_ah.c
ld -shared -o extensions/libipt_ah.so extensions/libipt_ah_sh.o
cc -O2 -Wall -Wunused -I/home/user/linux-2.4.17/include -Iinclude/ -DIPTABLES_VERSION=\"1.2.7a\"  -fPIC -o extensions/libipt_conntrack_sh.o -c extensions/libipt_conntrack.c
In file included from extensions/libipt_conntrack.c:15:
include/linux/netfilter_ipv4/ipt_conntrack.h:28: `IP_CT_DIR_MAX' undeclared here (not in a function)
include/linux/netfilter_ipv4/ipt_conntrack.h:29: `IP_CT_DIR_MAX' undeclared here (not in a function)
include/linux/netfilter_ipv4/ipt_conntrack.h:29: `IP_CT_DIR_MAX' undeclared here (not in a function)
extensions/libipt_conntrack.c: In function `parse_status':
extensions/libipt_conntrack.c:103: `IPS_EXPECTED' undeclared (first use in this function)
extensions/libipt_conntrack.c:103: (Each undeclared identifier is reported only once
extensions/libipt_conntrack.c:103: for each function it appears in.)
extensions/libipt_conntrack.c:105: `IPS_SEEN_REPLY' undeclared (first use in this function)
extensions/libipt_conntrack.c:107: `IPS_ASSURED' undeclared (first use in this function)
extensions/libipt_conntrack.c: In function `parse':
extensions/libipt_conntrack.c:202: `IP_CT_DIR_ORIGINAL' undeclared (first use in this function)
extensions/libipt_conntrack.c:259: `IP_CT_DIR_REPLY' undeclared (first use in this function)
extensions/libipt_conntrack.c: In function `print_status':
extensions/libipt_conntrack.c:364: `IPS_EXPECTED' undeclared (first use in this function)
extensions/libipt_conntrack.c:368: `IPS_SEEN_REPLY' undeclared (first use in this function)
extensions/libipt_conntrack.c:372: `IPS_ASSURED' undeclared (first use in this function)
extensions/libipt_conntrack.c: In function `matchinfo_print':
extensions/libipt_conntrack.c:420: `IP_CT_DIR_ORIGINAL' undeclared (first use in this function)
extensions/libipt_conntrack.c:440: `IP_CT_DIR_REPLY' undeclared (first use in this function)
make: *** [extensions/libipt_conntrack_sh.o] Error 1

^ permalink raw reply

* RE: 3ware driver in 2.4.x and 2.5.x not compatible with 6x00 seri es cards
From: Michael Knigge @ 2002-12-20  9:05 UTC (permalink / raw)
  To: Adam Radford
  Cc: 'Dave Jones', Nathan Neulinger, linux-kernel, uetrecht
In-Reply-To: <A1964EDB64C8094DA12D2271C04B812672C927@tabby>

Hi all,

> 3ware supports 6, 7, and 8000 series cards with a single driver in
> 2.2, 2.4, and 2.5 trees.

<snip>
scsi0 : 3ware Storage Controller 1.02.00.006
scsi : 1 host.
  Vendor: 3ware     Model: 3w-xxxx           Rev: 1.0
  Type:   Direct-Access                      ANSI SCSI revision: 00
</snip>

would it be hard to add the 3ware model? "3w-xxxx"... hmmmm... 
currently I want to buy some more controllers and want to get the same 
as I currenty have - but I really can't remember which ones I own 
;-)))) 

And I don't want to reboot (hey, I would loose my uptime) ;)))


I now run these controllers on 6 of my 6 servers and all run without 
problems. Isn't it time to change the driver's status? Iirc it is 
still marked "experimental"....


Bye
  Michael






^ permalink raw reply

* Re: Adaptec 79xx support in 2.4.x
From: Martin Knoblauch @ 2002-12-20  9:03 UTC (permalink / raw)
  To: waltabbyh, linux-kernel

> Adaptec 79xx support in 2.4.x
> 
> From: Walt H (waltabbyh@mindspring.com)
> Date: Thu Dec 19 2002 - 23:21:42 EST
> 
>    * Next message: Stephen Satchell: "Re: Saving logs when system is started"
>    * Previous message: Alex Goddard: "Re: depmod errors in 2.5.52-bk"
>    * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> 
>   ------------------------------------------------------------------------
> 
> Hello,
> 
> I have a Tyan Thunder K7XPro based server with the onboard AIC7902
> controllers. At the present time, its is running 2.4.19 patched with
> Adaptec's source release for the SCSI support. Adaptec's drivers did not
>   seamlessly integrate into the 2.4.19 kernel. I found an old mail
> stating that support for this chipset would be added eventually. It
> doesn't appear to be added to the 2.4 series yet. Is there something I
> should be concerned about with regards to my server? The overall
> performance and stability seem fine so far, but it is a relatively new
> box with only about 1 month in production - so far so good :)
> 
> According to Justin at Adaptec, the source has been given to both Linus
> and Marcelo. I'd sure like to see it in mainline to avoid having to hack
> it in there as it stands. Thanks.
> 
> -Walt
> 

 I would like to second that request. Those 7902 pop up in a lot of new
motherboards recently and not having them in mailine is a PITA.

 The driver itself seems to be OK, but there seems to be a higher
sensitivity to cabling and drive quality that with U160. I am just now
fighting with some FUJITSU MAP3735NC on a SuperMicro P4DP8-G2
motherboard that only work OK when running at 160 MB/s.


My two Eurocent
Martin

^ permalink raw reply

* 2.4.21-pre2 hdparm Kernel Oops
From: Bob @ 2002-12-20  8:58 UTC (permalink / raw)
  To: linux-kernel

Hi. I haven't seen any discussions about the 2.4.21-pre1 and pre2
kernels kernel panicing when you execute  
/sbin/hdparm -d1 -c3 -m16 -k1 /dev/hdb
/sbin/hdparm -d1 -c3 -m16 -k1 /dev/hda

(where /dev/hda contains both my boot and root partitions).

I ran this command in a startup script to improve disk performance.  It
would cause the kernel to panic on startup.  I commented it out of the
script, and the newly built kernels would startup and run OK, but when I
went back and re-ran the script (with the now running system), it would
crash the box.  I installed a new version of hdparm (5.3) to make sure
it wasn't an old version problem.

Thanks in advance, apologies if it's already been looked at, or if it's
just me.

Bob   




^ permalink raw reply

* [PATCH]Timer list init is done AFTER use
From: george anzinger @ 2002-12-20  8:43 UTC (permalink / raw)
  To: linux-kernel@vger.kernel.org, Linus Torvalds

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

On SMP systems the timer list init is done by way of a
cpu_notifier call.  This has two problems:

1.) Timers are started WAY before the cpu_notifier call
chain is executed.  In particular the console blanking timer
is deleted and inserted every time printk() is called.  That
this does not fail is only because the kernel has yet to
protect location zero.

2.) This notifier is called when a cpu comes up.  I suspect
that initializing the timer list when a hot swap of a cpu is
done is NOT the right thing to do.  In any case, if this is
a desired action, the list still needs to be initialized
prior to its use.

The attached patch initializes all the timer lists at
init_timers time and does not put code in the notify list.
--
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

[-- Attachment #2: timer-init-fix.patch --]
[-- Type: text/plain, Size: 1027 bytes --]

--- linux-2.5.52-bk4-org/kernel/timer.c~	Thu Dec 19 12:13:18 2002
+++ linux/kernel/timer.c	Fri Dec 20 00:38:15 2002
@@ -1150,7 +1150,7 @@
 	return 0;
 }
 
-static void __devinit init_timers_cpu(int cpu)
+static void __init init_timers_cpu(int cpu)
 {
 	int j;
 	tvec_base_t *base;
@@ -1167,29 +1167,12 @@
 		INIT_LIST_HEAD(base->tv1.vec + j);
 }
 	
-static int __devinit timer_cpu_notify(struct notifier_block *self, 
-				unsigned long action, void *hcpu)
-{
-	long cpu = (long)hcpu;
-	switch(action) {
-	case CPU_UP_PREPARE:
-		init_timers_cpu(cpu);
-		break;
-	default:
-		break;
-	}
-	return NOTIFY_OK;
-}
-
-static struct notifier_block __devinitdata timers_nb = {
-	.notifier_call	= timer_cpu_notify,
-};
-
 
 void __init init_timers(void)
 {
-	timer_cpu_notify(&timers_nb, (unsigned long)CPU_UP_PREPARE,
-				(void *)(long)smp_processor_id());
-	register_cpu_notifier(&timers_nb);
+	int cpu;
+	for (cpu = 0; cpu < NR_CPUS; cpu++){
+		init_timers_cpu(cpu);
+	}
 	open_softirq(TIMER_SOFTIRQ, run_timer_softirq, NULL);
 }


^ permalink raw reply

* kgdb compile error
From: 于婧 @ 2002-12-20  8:35 UTC (permalink / raw)
  To: linuxppc-embedded@lists.linuxppc.org


hi!
  I want to debug the kernel with kgdb,so I build the kernel with CONFIG_KGDB.While there are something wrong with it.The error is listed below:
/////////
ppc_74xx-ld -T arch/ppc/vmlinux.lds -Ttext 0xc0000000 -Bstatic arch/ppc/kernel/head.o init/main.o init/version.o \
 --start-group \
 arch/ppc/kernel/kernel.o arch/ppc/platforms/platform.o arch/ppc/mm/mm.o arch/ppc/lib/lib.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o \
  drivers/char/char.o drivers/block/block.o drivers/misc/misc.o drivers/net/net.o drivers/media/media.o drivers/ide/idedriver.o drivers/scsi/scsidrv.o drivers/cdrom/driver.o drivers/pci/driver.o drivers/macintosh/macintosh.o \
 net/network.o \
 /home/yujing/mykernel/kernel/lib/lib.a \
 --end-group \
 -o vmlinux
ppc_74xx-ld: Dwarf Error: Could not find abbrev number 106.
ppc_74xx-ld: Dwarf Error: Could not find abbrev number 97.
ppc_74xx-ld: Dwarf Error: Line offset (33554432) bigger than line size (223020).
ppc_74xx-ld: Dwarf Error: Could not find abbrev number 95.
ppc_74xx-ld: Dwarf Error: Could not find abbrev number 95.
ppc_74xx-ld: Dwarf Error: Could not find abbrev number 95.
ppc_74xx-ld: Dwarf Error: Could not find abbrev number 95.
ppc_74xx-ld: Dwarf Error: Could not find abbrev number 95.
ppc_74xx-ld: Dwarf Error: Could not find abbrev number 99.
arch/ppc/kernel/kernel.o: In function `_get_L2CR':
arch/ppc/kernel/entry.S(.text+0x89fc): undefined reference to
'getDebugChar'
arch/ppc/kernel/entry.S(.text+0x89fc): relocation truncated to fit: R_PPC_REL24 getDebugChar
arch/ppc/kernel/entry.S(.text+0x8a30): undefined reference to `getDebugChar'
arch/ppc/kernel/entry.S(.text+0x8a30): relocation truncated to fit: R_PPC_REL24 getDebugChar
arch/ppc/kernel/entry.S(.text+0x8a4c): undefined reference to `getDebugChar'
arch/ppc/kernel/entry.S(.text+0x8a4c): relocation truncated to fit: R_PPC_REL24 getDebugChar
arch/ppc/kernel/entry.S(.text+0x8a5c): undefined reference to `getDebugChar'
arch/ppc/kernel/entry.S(.text+0x8a5c): relocation truncated to fit: R_PPC_REL24 getDebugChar
arch/ppc/kernel/entry.S(.text+0x8a7c): undefined reference to `putDebugChar'
arch/ppc/kernel/entry.S(.text+0x8a7c): relocation truncated to fit: R_PPC_REL24 putDebugChar
arch/ppc/kernel/entry.S(.text+0x8a88): undefined reference to `putDebugChar'
arch/ppc/kernel/entry.S(.text+0x8a88): relocation truncated to fit: R_PPC_REL24 putDebugChar
arch/ppc/kernel/entry.S(.text+0x8aa0): undefined reference to `putDebugChar'
arch/ppc/kernel/entry.S(.text+0x8aa0): relocation truncated to fit: R_PPC_REL24 putDebugChar
arch/ppc/kernel/entry.S(.text+0x8aac): undefined reference to `putDebugChar'
arch/ppc/kernel/entry.S(.text+0x8aac): relocation truncated to fit: R_PPC_REL24 putDebugChar
arch/ppc/kernel/entry.S(.text+0x8b20): undefined reference to `putDebugChar'
arch/ppc/kernel/entry.S(.text+0x8b20): relocation truncated to fit: R_PPC_REL24 putDebugChar
arch/ppc/kernel/kernel.o(.text+0x8b3c):arch/ppc/kernel/entry.S: more undefined references to `putDebugChar' follow
arch/ppc/kernel/kernel.o: In function `_get_L2CR':
arch/ppc/kernel/entry.S(.text+0x8b3c): relocation truncated to fit: R_PPC_REL24 putDebugChar
arch/ppc/kernel/entry.S(.text+0x8b58): relocation truncated to fit: R_PPC_REL24 putDebugChar
arch/ppc/kernel/entry.S(.text+0x8b68): relocation truncated to fit: R_PPC_REL24 putDebugChar
arch/ppc/kernel/entry.S(.text+0x8b78): relocation truncated to fit: R_PPC_REL24 putDebugChar
arch/ppc/kernel/entry.S(.text+0x8b7c): undefined reference to `getDebugChar'
arch/ppc/kernel/entry.S(.text+0x8b7c): relocation truncated to fit: R_PPC_REL24 getDebugChar
arch/ppc/kernel/entry.S(.text+0x8df4): undefined reference to `kgdb_interruptible'
arch/ppc/kernel/entry.S(.text+0x8df4): relocation truncated to fit: R_PPC_REL24 kgdb_interruptible
arch/ppc/kernel/entry.S(.text+0x9388): undefined reference to `kgdb_interruptible'
arch/ppc/kernel/entry.S(.text+0x9388): relocation truncated to fit: R_PPC_REL24 kgdb_interruptible
make: *** [vmlinux] Error 1
 ///////
What's the problem?Wait for your help!
Thanks in advance!
                                                                         yujing
                                                                           yuj@mail.ndsc.com.cn

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

^ permalink raw reply

* use bdi on board with ppcbug
From: 于婧 @ 2002-12-20  8:34 UTC (permalink / raw)
  To: linuxppc-embedded@lists.linuxppc.org


hi!
  I want to debug the kernel on the motorola lopec p011 board with bdi tools.
And the first thing I must solve is to let the ppcbug "go" under the bdi control.But  I don't know where the entry of ppcbug is,so I can't "go" the ppcbug.Has anybody know that?Or,the ppcbug can not be run under this circumstances?

  Wait for your reply?
  Thanks in advance!


                                                               yujing
                                                        yuj@mail.ndsc.com.cn

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

^ permalink raw reply

* Fw: Re: What is the difference between modprobe and insmod?
From: Torsten Puls @ 2002-12-20  8:27 UTC (permalink / raw)
  To: IP

Hello

>   
> 
>          While writing IPtables scripts,there are two command:  modprobe and insmod.
> 
>          In some example,some use : modprobe ip_tables,but others use: insmod  ip_tables.
> 
>          Why?  Is there difference between them?
> 
>           
>          Thanks
> 
> 
modprobe make "insmod with dependencies"
insmod make "insmod without dependencies"


Greetz Torsten


^ permalink raw reply

* Re: [lvm-devel] [PATCH] add kobject to struct mapped_device
From: Greg KH @ 2002-12-20  8:31 UTC (permalink / raw)
  To: lvm-devel; +Cc: linux-kernel
In-Reply-To: <20021219105530.GA2003@reti>

On Thu, Dec 19, 2002 at 10:55:30AM +0000, Joe Thornber wrote:
> Greg,
> 
> This looks like patch 1 of many, since it doesn't actually export any
> attributes through sysfs yet.

Correct.

> Can you please give me more of an idea
> of what the attributes are that you want to export ?  Are you trying
> to move the dmfs functionality into sysfs ?

Only the parts of dmfs that make sense to :)

Right now every struct gendisk shows up in sysfs under the block/
directory, including every struct mapped_device that is created through
the dm code.  Now every mapped_device that already exists in sysfs,
exports the major/minor number (in the dev file), and other gendisk
specific attributes.  Why not just add the mapped_device specific
attributes of this gendisk object into the same directory (or one lower
to try to partition things a bit.)  That would mean taking the files
that were going to be in dmfs, and placing them into this directory
(like status, suspend, and others).  Some of them might have to be split
up into multiple files to keep the "one value per file" rule, but that
shouldn't be very difficult.

Here's an ascii picture which probably makes more sense:
/sys/block/
|-- fd0
|   |-- dev
|   |-- range
|   |-- size
|   `-- stat
|-- dm-1
|   |-- dev
|   |-- dm
|   |   |-- device0 -> ../../devices/pci0/00:02.5/ide0/0.0
|   |   |-- device1 -> ../../devices/pci0/00:02.5/ide1/1.0
|   |   |-- status
|   |   |-- suspend
|   |   `-- table
|   |-- range
|   |-- size
|   `-- stat

Look reasonable?

And yes, the deviceX files are symlinks to the struct block_device that
are controlled by this mapped_device, which I think is a easy visual
clue as to what is going on.

I know, this doesn't address the issue of creating these mapped_device
structures in the first place with either an ioctl, or a "special file",
but let's try to export the values and relationships that we already
have.  One step at a time...

> I won't accept this patch on it's own, but am sure what you are trying
> to do is the right thing, so will probably have no objections when the
> rest of the patches arrive.

That's fair enough, I'll work on getting the rest of the patches out in
a fairly timely manner, considering the holiday season...

> On Wed, Dec 18, 2002 at 10:43:07AM -0800, Greg KH wrote:
> > Oh, and why isn't struct mapped_device declared in dm.h?  If it was,
> > dm_get and dm_put could be inlined, along with a few other potential
> > cleanups.
> 
> I'm try to keep implementation details out of header files.  dm_get()
> and dm_put() are not performance critical so I see no need to inline them.

Ok.  I can place all of the sysfs specific functions in dm.c, just like
drivers/block/genhd.c has, or if we place struct mapped_device into
dm.h, they can live in their own file.  Doesn't bother me either way.

thanks,

greg k-h

^ permalink raw reply

* Patch for e100 on my z505je
From: Pete Zaitcev @ 2002-12-20  8:32 UTC (permalink / raw)
  To: jgarzik; +Cc: linux-kernel

Jeff,

I tried Marcelo's 2.4.21-pre2 and the driver fails the self-test,
then dies in an unserviced interrupt storm. An obvious patch
seems to fix the problem here.

Amazingly enough, the driver works in RH 2.4.18-14 (e100 2.1.6-k1),
but if I take the same 2.1.6-k1 and implant it into Marcelo tree,
everything dies as before. Something is fishy here.

-- Pete

diff -urN -X dontdiff linux-2.4.21-pre2/drivers/net/e100/e100_main.c linux-2.4.21-pre2-usb/drivers/net/e100/e100_main.c
--- linux-2.4.21-pre2/drivers/net/e100/e100_main.c	2002-12-19 19:50:58.000000000 -0800
+++ linux-2.4.21-pre2-usb/drivers/net/e100/e100_main.c	2002-12-20 00:07:36.000000000 -0800
@@ -2288,6 +2288,8 @@
 
 	/* initialize the nic state before running test */
 	e100_sw_reset(bdp, PORT_SOFTWARE_RESET);
+	e100_dis_intr(bdp);
+
 	/* Setup the address of the self_test area */
 	selftest_cmd = bdp->selftest_phys;
 
@@ -2302,9 +2304,9 @@
 	writel(selftest_cmd, &bdp->scb->scb_port);
 	readw(&(bdp->scb->scb_status));	/* flushes last write, read-safe */
 
-	/* Wait at least 10 milliseconds for the self-test to complete */
+	/* Wait at least 20 milliseconds for the self-test to complete */
 	set_current_state(TASK_UNINTERRUPTIBLE);
-	schedule_timeout(HZ / 100 + 1);
+	schedule_timeout(HZ / 50 + 1);
 
 	/* disable interrupts since the're now enabled */
 	e100_dis_intr(bdp);

^ permalink raw reply

* PTRACE_GET_THREAD_AREA
From: Roland McGrath @ 2002-12-20  8:32 UTC (permalink / raw)
  To: linux-kernel; +Cc: Ingo Molnar

This patch vs 2.5.51 (should apply fine to 2.5.52) adds two new ptrace
requests for i386, PTRACE_GET_THREAD_AREA and PTRACE_SET_THREAD_AREA.
These let another process using ptrace do the equivalent of performing
get_thread_area and set_thread_area system calls for another thread.

We are working on gdb support for the new threading code in the kernel
using the new NPTL library, and use PTRACE_GET_THREAD_AREA for that.
This patch has been working fine for that.

I added PTRACE_SET_THREAD_AREA just for completeness, so that you can
change all the state via ptrace that you can read via ptrace as has
previously been the case.  It doesn't have an equivalent of set_thread_area
with .entry_number = -1, but is otherwise the same.

Both requests use the ptrace `addr' argument for the entry number rather
than the entry_number field in the struct.  The `data' parameter gives the
address of a struct user_desc as used by the set/get_thread_area syscalls.

The code is quite simple, and doesn't need any special synchronization
because in the ptrace context the thread must be stopped already.

I chose the new request numbers arbitrarily from ones not used on i386.
I have no opinion on what values should be used.

People I talked to preferred adding this interface over putting an array of
struct user_desc in struct user as accessed by PTRACE_PEEKUSR/POKEUSR
(which would be a bit unnatural since those calls access one word at a time).


Thanks,
Roland



--- linux-2.5.51/include/asm-i386/ptrace.h.orig	Mon Dec  9 18:45:43 2002
+++ linux-2.5.51/include/asm-i386/ptrace.h	Thu Dec 12 04:42:06 2002
@@ -51,6 +51,10 @@ struct pt_regs {
 
 #define PTRACE_OLDSETOPTIONS         21
 
+#define PTRACE_GET_THREAD_AREA    25
+#define PTRACE_SET_THREAD_AREA    26
+
+
 #ifdef __KERNEL__
 #define user_mode(regs) ((VM_MASK & (regs)->eflags) || (3 & (regs)->xcs))
 #define instruction_pointer(regs) ((regs)->eip)
--- linux-2.5.51/arch/i386/kernel/ptrace.c.orig	Mon Dec  9 18:45:52 2002
+++ linux-2.5.51/arch/i386/kernel/ptrace.c	Thu Dec 12 04:42:12 2002
@@ -21,6 +21,8 @@
 #include <asm/processor.h>
 #include <asm/i387.h>
 #include <asm/debugreg.h>
+#include <asm/ldt.h>
+#include <asm/desc.h>
 
 /*
  * does not yet catch signals sent when the child dies.
@@ -416,6 +418,80 @@ asmlinkage int sys_ptrace(long request, 
 		break;
 	}
 
+	case PTRACE_GET_THREAD_AREA: {
+		int idx = addr;
+		struct user_desc info;
+		struct desc_struct *desc;
+
+/*
+ * Get the current Thread-Local Storage area:
+ */
+
+#define GET_BASE(desc) ( \
+	(((desc)->a >> 16) & 0x0000ffff) | \
+	(((desc)->b << 16) & 0x00ff0000) | \
+	( (desc)->b        & 0xff000000)   )
+
+#define GET_LIMIT(desc) ( \
+	((desc)->a & 0x0ffff) | \
+	 ((desc)->b & 0xf0000) )
+
+#define GET_32BIT(desc)		(((desc)->b >> 23) & 1)
+#define GET_CONTENTS(desc)	(((desc)->b >> 10) & 3)
+#define GET_WRITABLE(desc)	(((desc)->b >>  9) & 1)
+#define GET_LIMIT_PAGES(desc)	(((desc)->b >> 23) & 1)
+#define GET_PRESENT(desc)	(((desc)->b >> 15) & 1)
+#define GET_USEABLE(desc)	(((desc)->b >> 20) & 1)
+
+		if (idx < GDT_ENTRY_TLS_MIN || idx > GDT_ENTRY_TLS_MAX) {
+			ret = -EINVAL;
+			break;
+		}
+
+		desc = child->thread.tls_array + idx - GDT_ENTRY_TLS_MIN;
+
+		info.entry_number = idx;
+		info.base_addr = GET_BASE(desc);
+		info.limit = GET_LIMIT(desc);
+		info.seg_32bit = GET_32BIT(desc);
+		info.contents = GET_CONTENTS(desc);
+		info.read_exec_only = !GET_WRITABLE(desc);
+		info.limit_in_pages = GET_LIMIT_PAGES(desc);
+		info.seg_not_present = !GET_PRESENT(desc);
+		info.useable = GET_USEABLE(desc);
+
+		if (copy_to_user((struct user_desc *) data,
+				 &info, sizeof(info)))
+			ret = -EFAULT;
+		break;
+	}
+
+	case PTRACE_SET_THREAD_AREA: {
+		int idx = addr;
+		struct user_desc info;
+		struct desc_struct *desc;
+
+		if (copy_from_user(&info,
+				   (struct user_desc *) data, sizeof(info))) {
+			ret = -EFAULT;
+			break;
+		}
+		if (idx < GDT_ENTRY_TLS_MIN || idx > GDT_ENTRY_TLS_MAX) {
+			ret = -EINVAL;
+			break;
+		}
+		desc = current->thread.tls_array + idx - GDT_ENTRY_TLS_MIN;
+		if (LDT_empty(&info)) {
+			desc->a = 0;
+			desc->b = 0;
+		} else {
+			desc->a = LDT_entry_a(&info);
+			desc->b = LDT_entry_b(&info);
+		}
+		ret = 0;
+		break;
+	}
+
 	default:
 		ret = ptrace_request(child, request, addr, data);
 		break;

^ permalink raw reply

* Re: [Linux-ia64] Can't boot in SMP with kernel 2.5.50 ia64
From: Xavier Bru @ 2002-12-20  8:23 UTC (permalink / raw)
  To: linux-ia64
In-Reply-To: <marc-linux-ia64-105590709805616@msgid-missing>

David Mosberger writes:
 > >>>>> On Thu, 19 Dec 2002 08:53:06 +0100 (NFT), Xavier Bru  <Xavier.Bru@bull.net> said:
 > 
 >   Xavier> Hello,
 > 
 >   Xavier> Booting 2.5.50 with David's patch, it seems we can't boot in
 >   Xavier> SMP on an ia64 machine. We get the message: SMP mode
 >   Xavier> deactivated.  Problem is due to smp_prepare_cpus() declaring
 >   Xavier> max_cpus as "unsigned int" and testing against the -1 value.
 >   Xavier> Problem was not seen in 2.5.45 because max_cpus was
 >   Xavier> initialized to UINT_MAX.
 > 
 > I think the test in smp_prepare_cpus() is bogus.  I changed it to test
 > just against 0 (as is done in the x86 version of smpboot.c).
 > 
 > 	--david

Hi David,
Thanks for answering my mail.
I just changed to "int" because I saw that max_cpus can be modified at 
boot time (maxcpus=...), and get_option() provides an int.
I think this is why test was done against a negative or null value.

"Joyeux Noel et Bonne Annee a tous".

-- 

 Sincères salutations.
_____________________________________________________________________
 
Xavier BRU                 BULL ISD/R&D/INTEL office:     FREC B1-422
tel : +33 (0)4 76 29 77 45                    http://www-frec.bull.fr
fax : +33 (0)4 76 29 77 70                 mailto:Xavier.Bru@bull.net
addr: BULL, 1 rue de Provence, BP 208, 38432 Echirolles Cedex, FRANCE
_____________________________________________________________________



^ permalink raw reply

* Re: What is the difference between modprobe and insmod?
From: Joel Newkirk @ 2002-12-20  8:20 UTC (permalink / raw)
  To: bobo, netfilter@lists.netfilter.org; +Cc: bobowd@sohu.com
In-Reply-To: <20021220070647.BA0B01C959464@sm181.163.com>

On Friday 20 December 2002 02:11 am, bobo wrote:
>          While writing IPtables scripts,there are two command: 
> modprobe and insmod.
>
>          In some example,some use : modprobe ip_tables,but others use:
> insmod  ip_tables.
>
>          Why?  Is there difference between them?

For the purpose of loading specified modules you can consider them the 
same.  Modprobe is a higher-level interface that will call insmod.  I 
personally use modprobe since it succeeds silently.  IE, if it 
successfully loads the module, or if the module is already loaded, 
insmod will report this, while modprobe will not output anything in 
these situations.  They will both, by default, report failure to 
find/load a module, and the -q option tells them both to be quiet about 
errors, but insmod will /still/ report success even with -q.

For full details see "man insmod" and "man modprobe"... :^)
(under KDE, the default IIRC with RedHat 7.2,  using alt-F2 then #insmod 
in the dialog, or #insmod as a URL in konquerer works nicely)

j



^ permalink raw reply

* EDE 0.0.5
From: Neil Holmes @ 2002-12-20  8:16 UTC (permalink / raw)
  To: Linux 8086

Harry has set up the ELKS Distribution Edition as a package on the ELKS
project. Thanks for this Harry.

I have uploaded EDE-0.0.5. Please have a look and see how you get on.

The download is EDE-0.0.5.zip. It contains an floppy disk image "Image", the
source to my install versions of getty and isreboot as well as some snazzy
floppy disk labels to preserve your release !! <g>

I am still having serious unreliability problems using fdisk and mkfs. You
may have to play around with dos fdisk before you get a smooth install. Alas
the science seems very inprecise to me at the moment so I cannot offer
step-by-step instructions. Sorry.

One very important last note. 0.0.5 is for INSTALL ONLY. I have not released
the "upgrade to a new release" code yet as I have had a couple of problems
with it. I was very keen to get some feedback on the "graphical" (?!!)
install so released as an INSTALL disk only. I'll put a separate "dev"
upload with upgrade code when it is ready but I expect to use this as a
feature on 0.0.6.

If you only want a tentative experiment, it all seems to work fine in
DOSEMU.

Please let me know how you get on.

Have Fun !

Neil




^ permalink raw reply

* cramfs over ramdisk broken ?
From: Steffen Rumler @ 2002-12-20  8:19 UTC (permalink / raw)
  To: linux-kernel; +Cc: Steffen.Rumler

Hi,

I have tried to use cramfs over a ramdisk.
It seems not working stable.
I have tested this for the 2.4.2 and 2.4.20 kernel,
with the same result:

#  create a file tree
#
$ mkdir x
$ touch x/a
$ touch x/b
$ touch x/c

#  make a cramfs image
#
$ mkcramfs x x.img
Super block: 76 bytes
   a
   b
   c
Directory data: 124 bytes
Everything: 4 kilobytes
warning: gids truncated to 8 bits.  (This may be a security concern.)

#  dump the cramfs image; seems OK
#
$ od -x x.img
0000000 3d45 28cd 0000 0001 0000 0000 0000 0000
0000020 6f43 706d 6572 7373 6465 5220 4d4f 5346
0000040 e779 c669 363f 24cf 0b02 65c2 aef3 7fdb
0000060 6f43 706d 6572 7373 6465 0000 0000 0000
0000100 41ed 0000 0030 4200 04c0 0000 81a4 0000
0000120 0000 4200 0001 0000 0061 0000 81a4 0000
0000140 0000 4200 0001 0000 0062 0000 81a4 0000
0000160 0000 4200 0001 0000 0063 0000 0000 0000
0000200 0000 0000 0000 0000 0000 0000 0000 0000
*
0010000

#  write cramfs image to ramdisc
#
$ dd if=x.img of=/dev/ram15
8+0 records in
8+0 records out

#  check the ramdisc; seems OK
#
$ od -x /dev/ram15 | head
0000000 3d45 28cd 0000 0001 0000 0000 0000 0000
0000020 6f43 706d 6572 7373 6465 5220 4d4f 5346
0000040 e779 c669 363f 24cf 0b02 65c2 aef3 7fdb
0000060 6f43 706d 6572 7373 6465 0000 0000 0000
0000100 41ed 0000 0030 4200 04c0 0000 81a4 0000
0000120 0000 4200 0001 0000 0061 0000 81a4 0000
0000140 0000 4200 0001 0000 0062 0000 81a4 0000
0000160 0000 4200 0001 0000 0063 0000 0000 0000
0000200 0000 0000 0000 0000 0000 0000 0000 0000
*

#  mount it (first try)
#
$ mkdir mnt
$ mount -t cramfs /dev/ram15 mnt
mount: wrong fs type, bad option, bad superblock on /dev/ram15,
        or too many mounted file systems

#  check the ramdisc again; it seems to be demaged :-(
#
$ od -x /dev/ram15 | head
0000000 01fd 0809 0000 0000 8d28 080a 0000 0000
0000020 01fd 0809 0000 0000 8dc8 080a 0000 0000
0000040 01fd 0809 0000 0000 0000 0000 0000 0000
0000060 01fd 0809 0000 0000 e028 0809 0000 0000
0000100 01fd 0809 0000 0000 0000 0000 0000 0000
0000120 01fd 0809 0000 0000 e048 0809 0000 0000
0000140 01fd 0809 0000 0000 8b48 080a 0000 0000
0000160 01fd 0809 0000 0000 0000 0000 0000 0000
0000200 01fd 0809 0000 0000 0063 0064 0000 0000
*

#  write cramfs image to ram disc (second try)
#
$ dd if=x.img of=/dev/ram15
8+0 records in
8+0 records out

#  mount it (second try); it seems now working now !!!
#
$ mount -t cramfs /dev/ram15 mnt
$ ls mnt/
a  b  c


Any idea ?


Steffen

-- 


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

Steffen Rumler
ICN CP D NT SW 7
Siemens AG
Hofmannstr. 51                 Email: Steffen.Rumler@siemens.com
D-81359 Munich                 Phone: +49 89 722-44061
Germany                        Fax  : +49 89 722-36703

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




^ permalink raw reply

* Re: New style dpalloc/hostalloc routines (diff).
From: Pantelis Antoniou @ 2002-12-20  8:09 UTC (permalink / raw)
  To: Paul Mackerras; +Cc: linuxppc-embedded
In-Reply-To: <15874.23846.177956.192840@argo.ozlabs.ibm.com>


Paul Mackerras wrote:

>Pantelis Antoniou writes:
>
>
>>+# Support new type of routines, usable from modules
>>+bool 'Use new type dpalloc routines()' CONFIG_NEW_DPALLOC
>>+bool 'Use new type hostalloc routines()' CONFIG_NEW_HOSTALLOC
>>+if [ "$CONFIG_NEW_DPALLOC" = "y" -o "$CONFIG_NEW_HOSTALLOC" = "y" ]; then
>>+  define_bool CONFIG_CPM_RHEAP y
>>+fi
>>
>
>I don't want to see config options that select between different
>internal implementations of the same thing.  Either your new routines
>are better, and we'll use them, or they are worse, and we'll use the
>old ones.  Having a config option just leads to tons of ifdefs
>throughout the code, which makes it harder to read and understand.
>Having two implementations of the same thing is just bloat.
>
>Similarly, I don't like the way all your new routines have a "new_"
>prefix on the name.  You should be thinking of replacing the existing
>routines rather than providing an alternative implementation with a
>different name.  Where you have changed the API, either fix the
>drivers or provide a compatibility routine.
>
>The way it looks at the moment, it seems that you don't really have
>the conviction that your code is better than what is there already.
>Please redo your patch so that it just replaces the old routines.  And
>please don't send it as a bkpatch since they are impossible to read, a
>plain diff -u is much better.
>
>Paul.
>
>
>
>
>
Well that's easy to do since that's the way it is in my tree.

The only reason for the new_ prefixes and the config options was to
make it easy for people to test them.

I didn't sent it only as a bkpatch, a following mail had the patch in
diff format.

Anyway I'll repost them as per you suggestions...

Pantelis


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

^ permalink raw reply

* Re: Sony Vaio Battery Info
From: Malte Thoma @ 2002-12-20  8:03 UTC (permalink / raw)
  To: Markus Gaugusch; +Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <Pine.LNX.4.50.0212192106570.950-100000-KjnUIgV0B0bsKMwAuzqOxrNldLUNz+W/@public.gmane.org>



Markus Gaugusch wrote:
> As previously written, reading the battery info on sony vaio laptops
> (FX/FXA series) takes very long time (~0.6 sec). Battery state takes only
> ~0.1 sec, but this is still too long for constantly using a battery
> monitor.


Hallo Marcus,
(perhaps you remember me:-)

I have a SONY-VAIO FX505, is the 'keybord-look-bug' fixed? (I still run 
an half-year-old ACPI)

In my opinion the info-file need only to be read ONCE, because it 
contains only 'static' infos about the battery.
My skills are not high enough to help you withe the bug, but I would 
like to invite you to test (use, help me to improve) heatload, which is 
a small applet, showing information about the battery (and something more).

Greetings,

Malte


https://lists.berlios.de/mailman/listinfo/heatload-general



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

* Problems while starting 1.1.4 with other user than root
From: Peter Forst @ 2002-12-20  7:53 UTC (permalink / raw)
  To: DosEmu Mailinglist

Hi there,

After upgrading from 1.1.3-7 to 1.1.4, any other user, than root
can not start anymore the dosemu. Error-message:

-- Running unpriviledged in low feature mode
Linux kernel 2.4.16; CPU speed is 1460485000 Hz
Dosemu-1.1.4.0 Running on CPU=586, FPU=1
ERROR: can't open /dev/mem: errno=13, Keine Berechtigung 

An ls -l shows following:
crw-r-----    1 root     kmem       1,   1 May 12  2001 /dev/mem

Also an chmod to 777
crwxrwxrwx    1 root     kmem       1,   1 May 12  2001 /dev/mem

Takes no effect.

Hope someone can help me to fix the problem. Thanxxx :-)







Peter Forst
<mail: pforst@firemail.de>

^ permalink raw reply

* Re: [PATCH][2.4]  generic cluster APIC support for systems with more than 8 CPUs
From: Christoph Hellwig @ 2002-12-20  8:00 UTC (permalink / raw)
  To: James Cleverdon
  Cc: Pallipadi, Venkatesh, Linux Kernel, Martin Bligh, John Stultz,
	Nakajima, Jun, Mallick, Asit K, Saxena, Sunil
In-Reply-To: <200212191804.55194.jamesclv@us.ibm.com>

On Thu, Dec 19, 2002 at 06:04:55PM -0800, James Cleverdon wrote:
> A generic patch should also support Unisys' new box, the ES7000 or some such.

That box needs more changes than just the apic setup.  Unfortunately
unisys thinks they shouldn't send their patches to lkml, but when you see
them e.g. in the suse tree it's a bit understandable that they don't want
anyone to really see their mess :)

And btw, the box isn't that new, but three years ago or so when they first
showed it on cebit they even refused to talk about linux due to their
restrictive agreements with Microsoft..

^ permalink raw reply

* heatload
From: Malte Thoma @ 2002-12-20  7:51 UTC (permalink / raw)
  To: jluehr-UIqTAjE4tzc5WgrkcBd8vg,
	abs-SA7OhAOe25xnNxvc45mVi0K323yFvGpRdefyYXQ/eNw,
	ducrot-kk6yZipjEM5g9hUCZPvPmw, faye-6JSjyQ0Qj1ReoWH0uzbU5w,
	ACPI-Devel
In-Reply-To: <200212171503.03753-UlMRvbVDEoV7PMRmdqgSDxn2srH7JjnQ@public.gmane.org>

Hallo,

if you would like to support me, developing 'heatload' than please 
subscirbe to the mailing-list.

Greetings,

Malte


BTW: 'scandir' is on the TODO list, until then the user can adjust the 
files via an config-file.

* What about the internel structure of the files in /proc/acpi? Is it 
always the same or does it depend on the manufactor, too? That would be 
horrible!
* Because my laptop doesn't support FAN and PERFORMANCE, it would be 
nice, if someone can send me a 'cat' of those files. Than I can 
implement it into heatload.
* If you have a wishlist for me, we can improve heatload to the limits ;-)

https://lists.berlios.de/mailman/listinfo/heatload-general
______________________________________________________________________________


Hallo Ihr,

Ich weiß nicht, ob ich Euch schon angeschrieben hatte:

Bitte trage Euch doch in die meilingliste ein, wenn Ihr mir bei der 
Entwicklung von heatload helfen mögt.
Dort erfährt DIhr auch immer wenn es eine neue Version gibt.


Gruß,

Malte





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

* how can 'iptables -D ...' get EAGAIN?
From: Alain Fauconnet @ 2002-12-20  7:48 UTC (permalink / raw)
  To: netfilter

Hello,

On a server that has a very dynamic set of iptables  rules  (used  for
traffic accounting), I occasionally see a  'iptables  -D ...'  command
in the session start or session end scripts return:

iptables: Resource temporarily unavailable

I've checked the source  code  for  any  occurance  of  EAGAIN  (which
matches this message) but there isn't any.

Can someone explain in which case iptables would get a EAGAIN error?

This  is  a -D (delete rule) command, not -L, so I don't think that it
can be DNS-related, can it?

Thanks in advance for any hint,
Greets,
_Alain_


^ permalink raw reply

* Re: reiserfs and TUX2 - 2.4.18 or 2.4.19?
From: Oleg Drokin @ 2002-12-20  7:47 UTC (permalink / raw)
  To: Dirk Mueller; +Cc: reiserfs-list
In-Reply-To: <20021220071131.GA8162@matrix.wg>

Hello!

On Fri, Dec 20, 2002 at 08:11:31AM +0100, Dirk Mueller wrote:

> >    If you'd have canilla 2.4.18, you'd need
> >    2.4.18.pending and 2.4.19.pending
> >    With RedHat some of these patches might be already included, so
> >    you probably need to try and see it for yourself which ones are missing. 
> Wouldn't it be better to push the changes into the vanilla kernel to save 
> everyone from this patch nightmare?

Well, all of the changes are in latest kernel already (2.4.20 as of now).
But the question was about using old kernel (well, may be not that old.
And patched by RedHat. And this was 56 megabytes of patches last time I checked)

Bye,
    Oleg

^ permalink raw reply

* Re: [PATCH] 2.5.52: compilation fixes for alpha
From: Jochen Friedrich @ 2002-12-20  7:44 UTC (permalink / raw)
  To: Hannes Reinecke; +Cc: Linux Kernel
In-Reply-To: <3E0241C3.4060206@hannes-reinecke.de>

Hi Hannes,

> attached are some compilation fixes needed to get the alpha port up and
> running. Note: These fixes are on top of patch-2.5.52-bk3 in the
> 2.5/testing directory, which contain some neccessary fixes regarding
> exception handling.

Is there an additional patch missing?

arch/alpha/mm/extable.c: In function `search_exception_table':
arch/alpha/mm/extable.c:48: `module_list' undeclared (first use in this
function)

This is -bk3 from v2.5/snapshots +your patch (-bk4 +your patch fails to
compile with the same message).

It looks like i386 replaced the loop through module_list by a walk through
extables which is not yet in alpha code.

Thanks,
--jochen


^ permalink raw reply

* Re: need for benchmarking system?
From: Russell Coker @ 2002-12-20  7:37 UTC (permalink / raw)
  To: grobe, reiserfs-list
In-Reply-To: <9135.1040347243@www36.gmx.net>

On Fri, 20 Dec 2002 02:20, grobe@gmx.net wrote:
> As we are going to get a quite big new server in january, and as I have
> taken a lot of advantage from the reiserfs development, I wonder if I could
> contribute a bit by making a "reiserfs-large-server-test-day"?

I'm not sure that 2TB is really a large server any more.  I know people with 
home machines of 1TB, and on the IDE-arrays list about half the regulars are 
pushing up against the 2TB block device limit in kernel 2.4 (and a 2TB limit 
in 3Ware hardware).

That said, my latest servers are at ~220G.  But that's due to not wanting any 
external storage and wanting a hot-spare, combined with the limit of 76G for 
a SCSI disk.

> The system will be a redundant fibrechannel storage with two dual processor
> systems, about 2 Terabytes raid5. I am going to install SuSE ES8 (I usually
> install on LVM).

I'll be interested to see the results of that.  Every time I've checked out 
the performance of FC devices in the past I've been very unimpressed by the 
results.  The best I've seen from FC is 60MB/s sustained for a single process 
(which isn't THAT much better than a single new IDE hard drive).

> If the reiserfs-team thinks this could be useful, please tell me the
> configuration you need (e.g. kernel 2.4.xx, 2.5.xx, reiserfs 3.xx or 4?)
> and how we should do this (benchmark scripts etc), I will try to get the
> specs of the system and see how to put this into the schedule.

I suggest benchmarking 2.4.x vs 2.5.x.  2.5.x has many changes that should 
improve performance.  Also see if you can show the benefits of the 
pre-emptable kernel support in recent 2.5.x.

-- 
http://www.coker.com.au/bonnie++/     Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/       Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/     My home page


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