linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
* PREEMPT on PPC
@ 2004-03-25  6:47 Benjamin Herrenschmidt
  2004-03-25  8:01 ` Benjamin Herrenschmidt
  0 siblings, 1 reply; 16+ messages in thread
From: Benjamin Herrenschmidt @ 2004-03-25  6:47 UTC (permalink / raw)
  To: linuxppc-dev list; +Cc: debian-powerpc@lists.debian.org


Hi !

I've start looking into the various issues of running
CONFIG_PREEMPT on ppc32. I found some problems, there
may be more, but here's a first patch that should apply on a
recent 2.6.x.

I suggest if you want to try this out that you run with the
various kernel debugging options enabled. Report me remaining
problems.

Ben.

===== arch/ppc/kernel/entry.S 1.44 vs edited =====
--- 1.44/arch/ppc/kernel/entry.S	Mon Feb 16 18:06:27 2004
+++ edited/arch/ppc/kernel/entry.S	Thu Mar 25 14:10:41 2004
@@ -171,9 +171,10 @@
 	bl	do_show_syscall
 #endif /* SHOW_SYSCALLS */
 	rlwinm	r10,r1,0,0,18	/* current_thread_info() */
+	lwz	r11,TI_LOCAL_FLAGS(r10)
+	rlwinm	r11,r11,0,~_TIFL_FORCE_NOERROR
+	stw	r11,TI_LOCAL_FLAGS(r10)
 	lwz	r11,TI_FLAGS(r10)
-	rlwinm	r11,r11,0,~_TIF_FORCE_NOERROR
-	stw	r11,TI_FLAGS(r10)
 	andi.	r11,r11,_TIF_SYSCALL_TRACE
 	bne-	syscall_dotrace
 syscall_dotrace_cont:
@@ -196,8 +197,8 @@
 	cmpl	0,r3,r11
 	rlwinm	r12,r1,0,0,18	/* current_thread_info() */
 	blt+	30f
-	lwz	r11,TI_FLAGS(r12)
-	andi.	r11,r11,_TIF_FORCE_NOERROR
+	lwz	r11,TI_LOCAL_FLAGS(r12)
+	andi.	r11,r11,_TIFL_FORCE_NOERROR
 	bne	30f
 	neg	r3,r3
 	lwz	r10,_CCR(r1)	/* Set SO bit in CR */
===== arch/ppc/kernel/pci.c 1.57 vs edited =====
--- 1.57/arch/ppc/kernel/pci.c	Tue Mar 23 16:42:53 2004
+++ edited/arch/ppc/kernel/pci.c	Thu Mar 25 15:09:51 2004
@@ -1557,6 +1557,7 @@
 	}

 	vma->vm_pgoff = offset >> PAGE_SHIFT;
+
 	return ret;
 }

===== arch/ppc/kernel/process.c 1.57 vs edited =====
--- 1.57/arch/ppc/kernel/process.c	Mon Nov 17 12:29:47 2003
+++ edited/arch/ppc/kernel/process.c	Thu Mar 25 14:35:07 2004
@@ -164,6 +164,7 @@
 void
 enable_kernel_altivec(void)
 {
+	preempt_disable();
 #ifdef CONFIG_SMP
 	if (current->thread.regs && (current->thread.regs->msr & MSR_VEC))
 		giveup_altivec(current);
@@ -172,12 +173,14 @@
 #else
 	giveup_altivec(last_task_used_altivec);
 #endif /* __SMP __ */
+	preempt_enable();
 }
 #endif /* CONFIG_ALTIVEC */

 void
 enable_kernel_fp(void)
 {
+	preempt_disable();
 #ifdef CONFIG_SMP
 	if (current->thread.regs && (current->thread.regs->msr & MSR_FP))
 		giveup_fpu(current);
@@ -186,13 +189,16 @@
 #else
 	giveup_fpu(last_task_used_math);
 #endif /* CONFIG_SMP */
+	preempt_enable();
 }

 int
 dump_fpu(struct pt_regs *regs, elf_fpregset_t *fpregs)
 {
+	preempt_disable();
 	if (regs->msr & MSR_FP)
 		giveup_fpu(current);
+	preempt_enable();
 	memcpy(fpregs, &current->thread.fpr[0], sizeof(*fpregs));
 	return 1;
 }
@@ -330,12 +336,14 @@

 	if (regs == NULL)
 		return;
+	preempt_disable();
 	if (regs->msr & MSR_FP)
 		giveup_fpu(current);
 #ifdef CONFIG_ALTIVEC
 	if (regs->msr & MSR_VEC)
 		giveup_altivec(current);
 #endif /* CONFIG_ALTIVEC */
+	preempt_enable();
 }

 /*
@@ -480,12 +488,14 @@
 	error = PTR_ERR(filename);
 	if (IS_ERR(filename))
 		goto out;
+	preempt_disable();
 	if (regs->msr & MSR_FP)
 		giveup_fpu(current);
 #ifdef CONFIG_ALTIVEC
 	if (regs->msr & MSR_VEC)
 		giveup_altivec(current);
 #endif /* CONFIG_ALTIVEC */
+	preempt_enable();
 	error = do_execve(filename, (char __user *__user *) a1,
 			  (char __user *__user *) a2, regs);
 	if (error == 0)
===== arch/ppc/kernel/traps.c 1.44 vs edited =====
--- 1.44/arch/ppc/kernel/traps.c	Tue Mar 23 12:46:58 2004
+++ edited/arch/ppc/kernel/traps.c	Thu Mar 25 13:21:47 2004
@@ -438,8 +438,14 @@
 		int code = 0;
 		u32 fpscr;

+		/* We must make sure the FP state is consistent with
+		 * our MSR_FP in regs
+		 */
+		preempt_disable();
 		if (regs->msr & MSR_FP)
 			giveup_fpu(current);
+		preempt_enable();
+
 		fpscr = current->thread.fpscr;
 		fpscr &= fpscr << 22;	/* mask summary bits with enables */
 		if (fpscr & FPSCR_VX)
@@ -603,8 +609,11 @@
 void
 AltivecAssistException(struct pt_regs *regs)
 {
+	preempt_disable();
 	if (regs->msr & MSR_VEC)
 		giveup_altivec(current);
+	preempt_enable();
+
 	/* XXX quick hack for now: set the non-Java bit in the VSCR */
 	current->thread.vscr.u[3] |= 0x10000;
 }
===== arch/ppc/syslib/prom_init.c 1.26 vs edited =====
--- 1.26/arch/ppc/syslib/prom_init.c	Sat Feb 14 19:29:14 2004
+++ edited/arch/ppc/syslib/prom_init.c	Wed Mar 24 12:35:20 2004
@@ -44,8 +44,12 @@
  * things like "driver,AAPL,MacOS,PowerPC" properties.  But this value
  * does need to be big enough to ensure that we don't lose things
  * like the interrupt-map property on a PCI-PCI bridge.
+ *
+ * 24/03/2004 - BenH: Bump that limitation to 512k and remove the
+ *                    filter for the MacOS drivers as we may now run
+ *                    those in a shell
  */
-#define MAX_PROPERTY_LENGTH	4096
+#define MAX_PROPERTY_LENGTH	(512 * 1024)

 #ifndef FB_MAX			/* avoid pulling in all of the fb stuff */
 #define FB_MAX	8
===== drivers/macintosh/adbhid.c 1.33 vs edited =====
--- 1.33/drivers/macintosh/adbhid.c	Sat Feb 14 19:29:16 2004
+++ edited/drivers/macintosh/adbhid.c	Thu Mar 25 16:16:56 2004
@@ -107,7 +107,6 @@
 static void adbhid_probe(void);

 static void adbhid_input_keycode(int, int, int, struct pt_regs *);
-static void leds_done(struct adb_request *);

 static void init_trackpad(int id);
 static void init_trackball(int id);
@@ -446,24 +445,54 @@

 static struct adb_request led_request;
 static int leds_pending[16];
+static int leds_req_pending;
 static int pending_devs[16];
 static int pending_led_start=0;
 static int pending_led_end=0;
+static spinlock_t leds_lock  = SPIN_LOCK_UNLOCKED;
+
+static void leds_done(struct adb_request *req)
+{
+	int leds, device;
+	unsigned long flags;
+
+	spin_lock_irqsave(&leds_lock, flags);
+
+	if (pending_led_start != pending_led_end) {
+		device = pending_devs[pending_led_start];
+		leds = leds_pending[device] & 0xff;
+		leds_pending[device] = 0;
+		pending_led_start++;
+		pending_led_start = (pending_led_start < 16) ? pending_led_start : 0;
+	} else
+		leds_req_pending = 0;
+
+	spin_unlock_irqrestore(&leds_lock, flags);
+	if (leds_req_pending)
+		adb_request(&led_request, leds_done, 0, 3,
+			    ADB_WRITEREG(device, KEYB_LEDREG), 0xff, ~leds);
+}

 static void real_leds(unsigned char leds, int device)
 {
-    if (led_request.complete) {
-	adb_request(&led_request, leds_done, 0, 3,
-		    ADB_WRITEREG(device, KEYB_LEDREG), 0xff,
-		    ~leds);
-    } else {
-	if (!(leds_pending[device] & 0x100)) {
-	    pending_devs[pending_led_end] = device;
-	    pending_led_end++;
-	    pending_led_end = (pending_led_end < 16) ? pending_led_end : 0;
+	unsigned long flags;
+
+	spin_lock_irqsave(&leds_lock, flags);
+	if (!leds_req_pending) {
+		leds_req_pending = 1;
+		spin_unlock_irqrestore(&leds_lock, flags);
+		adb_request(&led_request, leds_done, 0, 3,
+			    ADB_WRITEREG(device, KEYB_LEDREG), 0xff, ~leds);
+		return;
+	} else {
+		if (!(leds_pending[device] & 0x100)) {
+			pending_devs[pending_led_end] = device;
+			pending_led_end++;
+			pending_led_end = (pending_led_end < 16) ? pending_led_end : 0;
+		}
+		leds_pending[device] = leds | 0x100;
 	}
-	leds_pending[device] = leds | 0x100;
-    }
+	spin_unlock_irqrestore(&leds_lock, flags);
 }

 /*
@@ -487,21 +516,6 @@
 	return -1;
 }

-static void leds_done(struct adb_request *req)
-{
-    int leds,device;
-
-    if (pending_led_start != pending_led_end) {
-	device = pending_devs[pending_led_start];
-	leds = leds_pending[device] & 0xff;
-	leds_pending[device] = 0;
-	pending_led_start++;
-	pending_led_start = (pending_led_start < 16) ? pending_led_start : 0;
-	real_leds(leds,device);
-    }
-
-}
-
 static int
 adb_message_handler(struct notifier_block *this, unsigned long code, void *x)
 {
@@ -518,7 +532,7 @@
 		}

 		/* Stop pending led requests */
-		while(!led_request.complete)
+		while(leds_req_pending)
 			adb_poll();
 		break;

===== drivers/macintosh/via-pmu.c 1.61 vs edited =====
--- 1.61/drivers/macintosh/via-pmu.c	Thu Mar  4 13:04:36 2004
+++ edited/drivers/macintosh/via-pmu.c	Thu Mar 25 16:04:35 2004
@@ -137,7 +137,8 @@
 static int data_len;
 static volatile int adb_int_pending;
 static volatile int disable_poll;
-static struct adb_request bright_req_1, bright_req_2, bright_req_3;
+static struct adb_request bright_req_1, bright_req_2;
+static unsigned long async_req_locks;
 static struct device_node *vias;
 static int pmu_kind = PMU_UNKNOWN;
 static int pmu_fully_inited = 0;
@@ -404,7 +405,6 @@

 	bright_req_1.complete = 1;
 	bright_req_2.complete = 1;
-	bright_req_3.complete = 1;
 #ifdef CONFIG_PMAC_PBOOK
 	batt_req.complete = 1;
 	if (pmac_call_feature(PMAC_FTR_SLEEP_STATE,NULL,0,-1) >= 0)
@@ -710,6 +710,8 @@
 	pmu_batteries[pmu_cur_battery].amperage = amperage;
 	pmu_batteries[pmu_cur_battery].voltage = voltage;
 	pmu_batteries[pmu_cur_battery].time_remaining = time;
+
+	clear_bit(0, &async_req_locks);
 }

 static void __pmac
@@ -785,12 +787,14 @@
 		pmu_batteries[pmu_cur_battery].time_remaining = 0;

 	pmu_cur_battery = (pmu_cur_battery + 1) % pmu_battery_count;
+
+	clear_bit(0, &async_req_locks);
 }

 static void __pmac
 query_battery_state(void)
 {
-	if (!batt_req.complete)
+	if (test_and_set_bit(0, &async_req_locks))
 		return;
 	if (pmu_kind == PMU_OHARE_BASED)
 		pmu_request(&batt_req, done_battery_state_ohare,
@@ -1690,20 +1694,30 @@
 	return 0;
 }

+static void __openfirmware
+pmu_bright_complete(struct adb_request *req)
+{
+	if (req == &bright_req_1)
+		clear_bit(1, &async_req_locks);
+	if (req == &bright_req_2)
+		clear_bit(2, &async_req_locks);
+}
+
 static int __openfirmware
 pmu_set_backlight_level(int level, void* data)
 {
 	if (vias == NULL)
 		return -ENODEV;

-	if (!bright_req_1.complete)
+	if (test_and_set_bit(1, &async_req_locks))
 		return -EAGAIN;
-	pmu_request(&bright_req_1, NULL, 2, PMU_BACKLIGHT_BRIGHT,
+	pmu_request(&bright_req_1, pmu_bright_complete, 2, PMU_BACKLIGHT_BRIGHT,
 		backlight_to_bright[level]);
-	if (!bright_req_2.complete)
+	if (test_and_set_bit(2, &async_req_locks))
 		return -EAGAIN;
-	pmu_request(&bright_req_2, NULL, 2, PMU_POWER_CTRL, PMU_POW_BACKLIGHT
-		| (level > BACKLIGHT_OFF ? PMU_POW_ON : PMU_POW_OFF));
+	pmu_request(&bright_req_2, pmu_bright_complete, 2, PMU_POWER_CTRL,
+		    PMU_POW_BACKLIGHT | (level > BACKLIGHT_OFF ?
+					 PMU_POW_ON : PMU_POW_OFF));

 	return 0;
 }
@@ -2360,7 +2374,7 @@

 	/* Wait for completion of async backlight requests */
 	while (!bright_req_1.complete || !bright_req_2.complete ||
-		!bright_req_3.complete || !batt_req.complete)
+	       !batt_req.complete)
 		pmu_poll();

 	/* Giveup the lazy FPU & vec so we don't have to back them
@@ -2427,9 +2441,12 @@
 	if (!grackle)
 		return -ENODEV;

+	preempt_disable();
+
 	ret = pmac_suspend_devices();
 	if (ret) {
 		printk(KERN_ERR "Sleep rejected by devices\n");
+		preempt_enable();
 		return ret;
 	}

@@ -2497,6 +2514,8 @@

 	pmac_wakeup_devices();

+	preempt_enable();
+
 	return 0;
 }

@@ -2513,9 +2532,12 @@
 		return -ENOSYS;
 	}

+	preempt_disable();
+
 	ret = pmac_suspend_devices();
 	if (ret) {
 		printk(KERN_ERR "Sleep rejected by devices\n");
+		preempt_enable();
 		return ret;
 	}

@@ -2595,6 +2617,8 @@

 	pmac_wakeup_devices();

+	preempt_enable();
+
 	return 0;
 }

@@ -2619,12 +2643,15 @@
 	}
 	mem_ctrl_sleep = (unsigned int *) (mem_ctrl + PB3400_MEM_CTRL_SLEEP);

+	preempt_disable();
+
 	/* Allocate room for PCI save */
 	pbook_alloc_pci_save();

 	ret = pmac_suspend_devices();
 	if (ret) {
 		pbook_free_pci_save();
+		preempt_enable();
 		printk(KERN_ERR "Sleep rejected by devices\n");
 		return ret;
 	}
@@ -2673,9 +2700,10 @@
 		mb();

 	pmac_wakeup_devices();
-
 	pbook_free_pci_save();
+	preempt_enable();
 	iounmap(mem_ctrl);
+
 	return 0;
 }

===== include/asm-ppc/ptrace.h 1.11 vs edited =====
--- 1.11/include/asm-ppc/ptrace.h	Tue Jun 24 14:45:56 2003
+++ edited/include/asm-ppc/ptrace.h	Thu Mar 25 14:02:44 2004
@@ -49,7 +49,10 @@
 #define instruction_pointer(regs) ((regs)->nip)
 #define user_mode(regs) (((regs)->msr & MSR_PR) != 0)

-#define force_successful_syscall_return()   set_thread_flag(TIF_FORCE_NOERROR)
+#define force_successful_syscall_return()   \
+	do { \
+		current_thread_info()->local_flags |= _TIFL_FORCE_NOERROR; \
+	} while(0)

 /*
  * We use the least-significant bit of the trap field to indicate
===== include/asm-ppc/thread_info.h 1.17 vs edited =====
--- 1.17/include/asm-ppc/thread_info.h	Tue Oct 14 17:28:08 2003
+++ edited/include/asm-ppc/thread_info.h	Thu Mar 25 14:03:56 2004
@@ -18,6 +18,7 @@
 	struct task_struct	*task;		/* main task structure */
 	struct exec_domain	*exec_domain;	/* execution domain */
 	unsigned long		flags;		/* low level flags */
+	unsigned long		local_flags;	/* non-racy flags */
 	int			cpu;		/* cpu we're on */
 	int			preempt_count;
 	struct restart_block	restart_block;
@@ -28,6 +29,7 @@
 	.task =		&tsk,			\
 	.exec_domain =	&default_exec_domain,	\
 	.flags =	0,			\
+	.local_flags =  0,			\
 	.cpu =		0,			\
 	.preempt_count = 1,			\
 	.restart_block = {			\
@@ -69,8 +71,9 @@
 #define TI_TASK		0
 #define TI_EXECDOMAIN	4
 #define TI_FLAGS	8
-#define TI_CPU		12
-#define TI_PREEMPT	16
+#define TI_LOCAL_FLAGS	12
+#define TI_CPU		16
+#define TI_PREEMPT	20

 #define PREEMPT_ACTIVE		0x4000000

@@ -83,16 +86,22 @@
 #define TIF_NEED_RESCHED	3	/* rescheduling necessary */
 #define TIF_POLLING_NRFLAG	4	/* true if poll_idle() is polling
 					   TIF_NEED_RESCHED */
-#define TIF_FORCE_NOERROR	5	/* don't return error from current
-					   syscall even if result < 0 */
-
 /* as above, but as bit values */
 #define _TIF_SYSCALL_TRACE	(1<<TIF_SYSCALL_TRACE)
 #define _TIF_NOTIFY_RESUME	(1<<TIF_NOTIFY_RESUME)
 #define _TIF_SIGPENDING		(1<<TIF_SIGPENDING)
 #define _TIF_NEED_RESCHED	(1<<TIF_NEED_RESCHED)
 #define _TIF_POLLING_NRFLAG	(1<<TIF_POLLING_NRFLAG)
-#define _TIF_FORCE_NOERROR	(1<<TIF_FORCE_NOERROR)
+
+/*
+ * Non racy (local) flags bit numbers
+ */
+#define TIFL_FORCE_NOERROR	0	/* don't return error from current
+					   syscall even if result < 0 */
+
+/* as above, but as bit values */
+#define _TIFL_FORCE_NOERROR	(1<<TIFL_FORCE_NOERROR)
+

 #endif /* __KERNEL__ */

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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: PREEMPT on PPC
  2004-03-25  6:47 PREEMPT on PPC Benjamin Herrenschmidt
@ 2004-03-25  8:01 ` Benjamin Herrenschmidt
  2004-03-25 16:09   ` Colin Leroy
                     ` (2 more replies)
  0 siblings, 3 replies; 16+ messages in thread
From: Benjamin Herrenschmidt @ 2004-03-25  8:01 UTC (permalink / raw)
  To: linuxppc-dev list; +Cc: debian-powerpc@lists.debian.org


On Thu, 2004-03-25 at 17:47, Benjamin Herrenschmidt wrote:
>
> I've start looking into the various issues of running CONFIG_PREEMPT
> on ppc32. I found some problems, there may be more, but here's a first
> patch that should apply on a recent 2.6.x.
>
> I suggest if you want to try this out that you run with the various
> kernel debugging options enabled. Report me remaining problems.

And here's an updated version of that patch that doesn't break
sleep on laptops.

Ben.

===== arch/ppc/kernel/entry.S 1.44 vs edited =====
--- 1.44/arch/ppc/kernel/entry.S	Mon Feb 16 18:06:27 2004
+++ edited/arch/ppc/kernel/entry.S	Thu Mar 25 14:10:41 2004
@@ -171,9 +171,10 @@
 	bl	do_show_syscall
 #endif /* SHOW_SYSCALLS */
 	rlwinm	r10,r1,0,0,18	/* current_thread_info() */
+	lwz	r11,TI_LOCAL_FLAGS(r10)
+	rlwinm	r11,r11,0,~_TIFL_FORCE_NOERROR
+	stw	r11,TI_LOCAL_FLAGS(r10)
 	lwz	r11,TI_FLAGS(r10)
-	rlwinm	r11,r11,0,~_TIF_FORCE_NOERROR
-	stw	r11,TI_FLAGS(r10)
 	andi.	r11,r11,_TIF_SYSCALL_TRACE
 	bne-	syscall_dotrace
 syscall_dotrace_cont:
@@ -196,8 +197,8 @@
 	cmpl	0,r3,r11
 	rlwinm	r12,r1,0,0,18	/* current_thread_info() */
 	blt+	30f
-	lwz	r11,TI_FLAGS(r12)
-	andi.	r11,r11,_TIF_FORCE_NOERROR
+	lwz	r11,TI_LOCAL_FLAGS(r12)
+	andi.	r11,r11,_TIFL_FORCE_NOERROR
 	bne	30f
 	neg	r3,r3
 	lwz	r10,_CCR(r1)	/* Set SO bit in CR */
===== arch/ppc/kernel/pci.c 1.57 vs edited =====
--- 1.57/arch/ppc/kernel/pci.c	Tue Mar 23 16:42:53 2004
+++ edited/arch/ppc/kernel/pci.c	Thu Mar 25 15:09:51 2004
@@ -1557,6 +1557,7 @@
 	}

 	vma->vm_pgoff = offset >> PAGE_SHIFT;
+
 	return ret;
 }

===== arch/ppc/kernel/process.c 1.57 vs edited =====
--- 1.57/arch/ppc/kernel/process.c	Mon Nov 17 12:29:47 2003
+++ edited/arch/ppc/kernel/process.c	Thu Mar 25 14:35:07 2004
@@ -164,6 +164,7 @@
 void
 enable_kernel_altivec(void)
 {
+	preempt_disable();
 #ifdef CONFIG_SMP
 	if (current->thread.regs && (current->thread.regs->msr & MSR_VEC))
 		giveup_altivec(current);
@@ -172,12 +173,14 @@
 #else
 	giveup_altivec(last_task_used_altivec);
 #endif /* __SMP __ */
+	preempt_enable();
 }
 #endif /* CONFIG_ALTIVEC */

 void
 enable_kernel_fp(void)
 {
+	preempt_disable();
 #ifdef CONFIG_SMP
 	if (current->thread.regs && (current->thread.regs->msr & MSR_FP))
 		giveup_fpu(current);
@@ -186,13 +189,16 @@
 #else
 	giveup_fpu(last_task_used_math);
 #endif /* CONFIG_SMP */
+	preempt_enable();
 }

 int
 dump_fpu(struct pt_regs *regs, elf_fpregset_t *fpregs)
 {
+	preempt_disable();
 	if (regs->msr & MSR_FP)
 		giveup_fpu(current);
+	preempt_enable();
 	memcpy(fpregs, &current->thread.fpr[0], sizeof(*fpregs));
 	return 1;
 }
@@ -330,12 +336,14 @@

 	if (regs == NULL)
 		return;
+	preempt_disable();
 	if (regs->msr & MSR_FP)
 		giveup_fpu(current);
 #ifdef CONFIG_ALTIVEC
 	if (regs->msr & MSR_VEC)
 		giveup_altivec(current);
 #endif /* CONFIG_ALTIVEC */
+	preempt_enable();
 }

 /*
@@ -480,12 +488,14 @@
 	error = PTR_ERR(filename);
 	if (IS_ERR(filename))
 		goto out;
+	preempt_disable();
 	if (regs->msr & MSR_FP)
 		giveup_fpu(current);
 #ifdef CONFIG_ALTIVEC
 	if (regs->msr & MSR_VEC)
 		giveup_altivec(current);
 #endif /* CONFIG_ALTIVEC */
+	preempt_enable();
 	error = do_execve(filename, (char __user *__user *) a1,
 			  (char __user *__user *) a2, regs);
 	if (error == 0)
===== arch/ppc/kernel/traps.c 1.44 vs edited =====
--- 1.44/arch/ppc/kernel/traps.c	Tue Mar 23 12:46:58 2004
+++ edited/arch/ppc/kernel/traps.c	Thu Mar 25 13:21:47 2004
@@ -438,8 +438,14 @@
 		int code = 0;
 		u32 fpscr;

+		/* We must make sure the FP state is consistent with
+		 * our MSR_FP in regs
+		 */
+		preempt_disable();
 		if (regs->msr & MSR_FP)
 			giveup_fpu(current);
+		preempt_enable();
+
 		fpscr = current->thread.fpscr;
 		fpscr &= fpscr << 22;	/* mask summary bits with enables */
 		if (fpscr & FPSCR_VX)
@@ -603,8 +609,11 @@
 void
 AltivecAssistException(struct pt_regs *regs)
 {
+	preempt_disable();
 	if (regs->msr & MSR_VEC)
 		giveup_altivec(current);
+	preempt_enable();
+
 	/* XXX quick hack for now: set the non-Java bit in the VSCR */
 	current->thread.vscr.u[3] |= 0x10000;
 }
===== arch/ppc/syslib/prom_init.c 1.26 vs edited =====
--- 1.26/arch/ppc/syslib/prom_init.c	Sat Feb 14 19:29:14 2004
+++ edited/arch/ppc/syslib/prom_init.c	Wed Mar 24 12:35:20 2004
@@ -44,8 +44,12 @@
  * things like "driver,AAPL,MacOS,PowerPC" properties.  But this value
  * does need to be big enough to ensure that we don't lose things
  * like the interrupt-map property on a PCI-PCI bridge.
+ *
+ * 24/03/2004 - BenH: Bump that limitation to 512k and remove the
+ *                    filter for the MacOS drivers as we may now run
+ *                    those in a shell
  */
-#define MAX_PROPERTY_LENGTH	4096
+#define MAX_PROPERTY_LENGTH	(512 * 1024)

 #ifndef FB_MAX			/* avoid pulling in all of the fb stuff */
 #define FB_MAX	8
===== drivers/macintosh/adbhid.c 1.33 vs edited =====
--- 1.33/drivers/macintosh/adbhid.c	Sat Feb 14 19:29:16 2004
+++ edited/drivers/macintosh/adbhid.c	Thu Mar 25 16:16:56 2004
@@ -107,7 +107,6 @@
 static void adbhid_probe(void);

 static void adbhid_input_keycode(int, int, int, struct pt_regs *);
-static void leds_done(struct adb_request *);

 static void init_trackpad(int id);
 static void init_trackball(int id);
@@ -446,24 +445,54 @@

 static struct adb_request led_request;
 static int leds_pending[16];
+static int leds_req_pending;
 static int pending_devs[16];
 static int pending_led_start=0;
 static int pending_led_end=0;
+static spinlock_t leds_lock  = SPIN_LOCK_UNLOCKED;
+
+static void leds_done(struct adb_request *req)
+{
+	int leds, device;
+	unsigned long flags;
+
+	spin_lock_irqsave(&leds_lock, flags);
+
+	if (pending_led_start != pending_led_end) {
+		device = pending_devs[pending_led_start];
+		leds = leds_pending[device] & 0xff;
+		leds_pending[device] = 0;
+		pending_led_start++;
+		pending_led_start = (pending_led_start < 16) ? pending_led_start : 0;
+	} else
+		leds_req_pending = 0;
+
+	spin_unlock_irqrestore(&leds_lock, flags);
+	if (leds_req_pending)
+		adb_request(&led_request, leds_done, 0, 3,
+			    ADB_WRITEREG(device, KEYB_LEDREG), 0xff, ~leds);
+}

 static void real_leds(unsigned char leds, int device)
 {
-    if (led_request.complete) {
-	adb_request(&led_request, leds_done, 0, 3,
-		    ADB_WRITEREG(device, KEYB_LEDREG), 0xff,
-		    ~leds);
-    } else {
-	if (!(leds_pending[device] & 0x100)) {
-	    pending_devs[pending_led_end] = device;
-	    pending_led_end++;
-	    pending_led_end = (pending_led_end < 16) ? pending_led_end : 0;
+	unsigned long flags;
+
+	spin_lock_irqsave(&leds_lock, flags);
+	if (!leds_req_pending) {
+		leds_req_pending = 1;
+		spin_unlock_irqrestore(&leds_lock, flags);
+		adb_request(&led_request, leds_done, 0, 3,
+			    ADB_WRITEREG(device, KEYB_LEDREG), 0xff, ~leds);
+		return;
+	} else {
+		if (!(leds_pending[device] & 0x100)) {
+			pending_devs[pending_led_end] = device;
+			pending_led_end++;
+			pending_led_end = (pending_led_end < 16) ? pending_led_end : 0;
+		}
+		leds_pending[device] = leds | 0x100;
 	}
-	leds_pending[device] = leds | 0x100;
-    }
+	spin_unlock_irqrestore(&leds_lock, flags);
 }

 /*
@@ -487,21 +516,6 @@
 	return -1;
 }

-static void leds_done(struct adb_request *req)
-{
-    int leds,device;
-
-    if (pending_led_start != pending_led_end) {
-	device = pending_devs[pending_led_start];
-	leds = leds_pending[device] & 0xff;
-	leds_pending[device] = 0;
-	pending_led_start++;
-	pending_led_start = (pending_led_start < 16) ? pending_led_start : 0;
-	real_leds(leds,device);
-    }
-
-}
-
 static int
 adb_message_handler(struct notifier_block *this, unsigned long code, void *x)
 {
@@ -518,7 +532,7 @@
 		}

 		/* Stop pending led requests */
-		while(!led_request.complete)
+		while(leds_req_pending)
 			adb_poll();
 		break;

===== drivers/macintosh/via-pmu.c 1.61 vs edited =====
--- 1.61/drivers/macintosh/via-pmu.c	Thu Mar  4 13:04:36 2004
+++ edited/drivers/macintosh/via-pmu.c	Thu Mar 25 18:52:00 2004
@@ -137,7 +137,8 @@
 static int data_len;
 static volatile int adb_int_pending;
 static volatile int disable_poll;
-static struct adb_request bright_req_1, bright_req_2, bright_req_3;
+static struct adb_request bright_req_1, bright_req_2;
+static unsigned long async_req_locks;
 static struct device_node *vias;
 static int pmu_kind = PMU_UNKNOWN;
 static int pmu_fully_inited = 0;
@@ -404,7 +405,6 @@

 	bright_req_1.complete = 1;
 	bright_req_2.complete = 1;
-	bright_req_3.complete = 1;
 #ifdef CONFIG_PMAC_PBOOK
 	batt_req.complete = 1;
 	if (pmac_call_feature(PMAC_FTR_SLEEP_STATE,NULL,0,-1) >= 0)
@@ -710,6 +710,8 @@
 	pmu_batteries[pmu_cur_battery].amperage = amperage;
 	pmu_batteries[pmu_cur_battery].voltage = voltage;
 	pmu_batteries[pmu_cur_battery].time_remaining = time;
+
+	clear_bit(0, &async_req_locks);
 }

 static void __pmac
@@ -785,12 +787,14 @@
 		pmu_batteries[pmu_cur_battery].time_remaining = 0;

 	pmu_cur_battery = (pmu_cur_battery + 1) % pmu_battery_count;
+
+	clear_bit(0, &async_req_locks);
 }

 static void __pmac
 query_battery_state(void)
 {
-	if (!batt_req.complete)
+	if (test_and_set_bit(0, &async_req_locks))
 		return;
 	if (pmu_kind == PMU_OHARE_BASED)
 		pmu_request(&batt_req, done_battery_state_ohare,
@@ -1690,20 +1694,30 @@
 	return 0;
 }

+static void __openfirmware
+pmu_bright_complete(struct adb_request *req)
+{
+	if (req == &bright_req_1)
+		clear_bit(1, &async_req_locks);
+	if (req == &bright_req_2)
+		clear_bit(2, &async_req_locks);
+}
+
 static int __openfirmware
 pmu_set_backlight_level(int level, void* data)
 {
 	if (vias == NULL)
 		return -ENODEV;

-	if (!bright_req_1.complete)
+	if (test_and_set_bit(1, &async_req_locks))
 		return -EAGAIN;
-	pmu_request(&bright_req_1, NULL, 2, PMU_BACKLIGHT_BRIGHT,
+	pmu_request(&bright_req_1, pmu_bright_complete, 2, PMU_BACKLIGHT_BRIGHT,
 		backlight_to_bright[level]);
-	if (!bright_req_2.complete)
+	if (test_and_set_bit(2, &async_req_locks))
 		return -EAGAIN;
-	pmu_request(&bright_req_2, NULL, 2, PMU_POWER_CTRL, PMU_POW_BACKLIGHT
-		| (level > BACKLIGHT_OFF ? PMU_POW_ON : PMU_POW_OFF));
+	pmu_request(&bright_req_2, pmu_bright_complete, 2, PMU_POWER_CTRL,
+		    PMU_POW_BACKLIGHT | (level > BACKLIGHT_OFF ?
+					 PMU_POW_ON : PMU_POW_OFF));

 	return 0;
 }
@@ -2330,6 +2344,8 @@
 		return -EBUSY;
 	}

+	preempt_disable();
+
 	/* Make sure the decrementer won't interrupt us */
 	asm volatile("mtdec %0" : : "r" (0x7fffffff));
 	/* Make sure any pending DEC interrupt occurring while we did
@@ -2352,6 +2368,7 @@
 	if (ret) {
 		wakeup_decrementer();
 		local_irq_enable();
+		preempt_enable();
 		device_resume();
 		broadcast_wake();
 		printk(KERN_ERR "Driver powerdown failed\n");
@@ -2360,7 +2377,8 @@

 	/* Wait for completion of async backlight requests */
 	while (!bright_req_1.complete || !bright_req_2.complete ||
-		!bright_req_3.complete || !batt_req.complete)
+
+			!batt_req.complete)
 		pmu_poll();

 	/* Giveup the lazy FPU & vec so we don't have to back them
@@ -2398,6 +2416,8 @@

 	pmu_blink(1);

+	preempt_enable();
+
 	/* Resume devices */
 	device_resume();

@@ -2673,9 +2693,9 @@
 		mb();

 	pmac_wakeup_devices();
-
 	pbook_free_pci_save();
 	iounmap(mem_ctrl);
+
 	return 0;
 }

===== include/asm-ppc/ptrace.h 1.11 vs edited =====
--- 1.11/include/asm-ppc/ptrace.h	Tue Jun 24 14:45:56 2003
+++ edited/include/asm-ppc/ptrace.h	Thu Mar 25 14:02:44 2004
@@ -49,7 +49,10 @@
 #define instruction_pointer(regs) ((regs)->nip)
 #define user_mode(regs) (((regs)->msr & MSR_PR) != 0)

-#define force_successful_syscall_return()   set_thread_flag(TIF_FORCE_NOERROR)
+#define force_successful_syscall_return()   \
+	do { \
+		current_thread_info()->local_flags |= _TIFL_FORCE_NOERROR; \
+	} while(0)

 /*
  * We use the least-significant bit of the trap field to indicate
===== include/asm-ppc/thread_info.h 1.17 vs edited =====
--- 1.17/include/asm-ppc/thread_info.h	Tue Oct 14 17:28:08 2003
+++ edited/include/asm-ppc/thread_info.h	Thu Mar 25 14:03:56 2004
@@ -18,6 +18,7 @@
 	struct task_struct	*task;		/* main task structure */
 	struct exec_domain	*exec_domain;	/* execution domain */
 	unsigned long		flags;		/* low level flags */
+	unsigned long		local_flags;	/* non-racy flags */
 	int			cpu;		/* cpu we're on */
 	int			preempt_count;
 	struct restart_block	restart_block;
@@ -28,6 +29,7 @@
 	.task =		&tsk,			\
 	.exec_domain =	&default_exec_domain,	\
 	.flags =	0,			\
+	.local_flags =  0,			\
 	.cpu =		0,			\
 	.preempt_count = 1,			\
 	.restart_block = {			\
@@ -69,8 +71,9 @@
 #define TI_TASK		0
 #define TI_EXECDOMAIN	4
 #define TI_FLAGS	8
-#define TI_CPU		12
-#define TI_PREEMPT	16
+#define TI_LOCAL_FLAGS	12
+#define TI_CPU		16
+#define TI_PREEMPT	20

 #define PREEMPT_ACTIVE		0x4000000

@@ -83,16 +86,22 @@
 #define TIF_NEED_RESCHED	3	/* rescheduling necessary */
 #define TIF_POLLING_NRFLAG	4	/* true if poll_idle() is polling
 					   TIF_NEED_RESCHED */
-#define TIF_FORCE_NOERROR	5	/* don't return error from current
-					   syscall even if result < 0 */
-
 /* as above, but as bit values */
 #define _TIF_SYSCALL_TRACE	(1<<TIF_SYSCALL_TRACE)
 #define _TIF_NOTIFY_RESUME	(1<<TIF_NOTIFY_RESUME)
 #define _TIF_SIGPENDING		(1<<TIF_SIGPENDING)
 #define _TIF_NEED_RESCHED	(1<<TIF_NEED_RESCHED)
 #define _TIF_POLLING_NRFLAG	(1<<TIF_POLLING_NRFLAG)
-#define _TIF_FORCE_NOERROR	(1<<TIF_FORCE_NOERROR)
+
+/*
+ * Non racy (local) flags bit numbers
+ */
+#define TIFL_FORCE_NOERROR	0	/* don't return error from current
+					   syscall even if result < 0 */
+
+/* as above, but as bit values */
+#define _TIFL_FORCE_NOERROR	(1<<TIFL_FORCE_NOERROR)
+

 #endif /* __KERNEL__ */

===== sound/oss/dmasound/dmasound_core.c 1.22 vs edited =====
--- 1.22/sound/oss/dmasound/dmasound_core.c	Mon Feb  9 13:18:52 2004
+++ edited/sound/oss/dmasound/dmasound_core.c	Thu Mar 25 18:41:02 2004
@@ -1004,6 +1004,7 @@
 static int sq_fsync(struct file *filp, struct dentry *dentry)
 {
 	int rc = 0;
+	int timeout = 5;

 	write_sq.syncing |= 1;
 	sq_play();	/* there may be an incomplete frame waiting */
@@ -1016,6 +1017,12 @@
 			 * and clear the queue. */
 			sq_reset_output();
 			rc = -EINTR;
+			break;
+		}
+		if (!--timeout) {
+			printk(KERN_WARNING "dmasound: Timeout draining output\n");
+			sq_reset_output();
+			rc = -EIO;
 			break;
 		}
 	}

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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: PREEMPT on PPC
  2004-03-25  8:01 ` Benjamin Herrenschmidt
@ 2004-03-25 16:09   ` Colin Leroy
  2004-03-25 22:42     ` Benjamin Herrenschmidt
  2004-03-26 17:48   ` Michael Schmitz
  2004-03-27 15:05   ` Michel Dänzer
  2 siblings, 1 reply; 16+ messages in thread
From: Colin Leroy @ 2004-03-25 16:09 UTC (permalink / raw)
  To: Benjamin Herrenschmidt, linuxppc-dev list; +Cc: debian-powerpc


Hi Ben!

> + *
> + * 24/03/2004 - BenH: Bump that limitation to 512k and remove the
> + *                    filter for the MacOS drivers as we may now run
> + *                    those in a shell
>   */
> -#define MAX_PROPERTY_LENGTH 4096
> +#define MAX_PROPERTY_LENGTH (512 * 1024)

It doesn't look like related to preempt, but it actually interests me :)
Is it a work in progress ? And most importantly ;), does it enable us to
reboot a radeon 9200 after sleep ?

--
Colin


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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: PREEMPT on PPC
  2004-03-25 16:09   ` Colin Leroy
@ 2004-03-25 22:42     ` Benjamin Herrenschmidt
  0 siblings, 0 replies; 16+ messages in thread
From: Benjamin Herrenschmidt @ 2004-03-25 22:42 UTC (permalink / raw)
  To: Colin Leroy; +Cc: linuxppc-dev list, debian-powerpc@lists.debian.org


On Fri, 2004-03-26 at 03:09, Colin Leroy wrote:
> Hi Ben!
>
> > + *
> > + * 24/03/2004 - BenH: Bump that limitation to 512k and remove the
> > + *                    filter for the MacOS drivers as we may now run
> > + *                    those in a shell
> >   */
> > -#define MAX_PROPERTY_LENGTH 4096
> > +#define MAX_PROPERTY_LENGTH (512 * 1024)
>
> It doesn't look like related to preempt, but it actually interests me :)
> Is it a work in progress ? And most importantly ;), does it enable us to
> reboot a radeon 9200 after sleep ?

It's a work in progress, and it will not work for nVidia's unless you
can find the "old" PEF driver for them somewhere. For ATIs the "PEF"
driver has to be extracted from MacOS X. It's not complete yet, I'll
post some announce when that's done.

Ben.


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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: PREEMPT on PPC
  2004-03-25  8:01 ` Benjamin Herrenschmidt
  2004-03-25 16:09   ` Colin Leroy
@ 2004-03-26 17:48   ` Michael Schmitz
  2004-03-26 19:27     ` Michel Dänzer
  2004-03-27 15:05   ` Michel Dänzer
  2 siblings, 1 reply; 16+ messages in thread
From: Michael Schmitz @ 2004-03-26 17:48 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, debian-powerpc@lists.debian.org


> > I've start looking into the various issues of running CONFIG_PREEMPT
> > on ppc32. I found some problems, there may be more, but here's a
> > first patch that should apply on a recent 2.6.x.
> >
> > I suggest if you want to try this out that you run with the various
> > kernel debugging options enabled. Report me remaining problems.
>
> And here's an updated version of that patch that doesn't break sleep
> on laptops.

Works fine here on 2.6.5-rc2-ben0 . Including disk suspend.

	Michael

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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: PREEMPT on PPC
  2004-03-26 17:48   ` Michael Schmitz
@ 2004-03-26 19:27     ` Michel Dänzer
  2004-03-27  9:14       ` Mathieu Segaud
  0 siblings, 1 reply; 16+ messages in thread
From: Michel Dänzer @ 2004-03-26 19:27 UTC (permalink / raw)
  To: Michael Schmitz
  Cc: Benjamin Herrenschmidt, linuxppc-dev list,
	debian-powerpc@lists.debian.org


On Fri, 2004-03-26 at 18:48, Michael Schmitz wrote:
>
> Works fine here on 2.6.5-rc2-ben0 . Including disk suspend.

Have you hit swap with it? The problems with preempt usually only
started at that point here.

--
Earthling Michel Dänzer      |     Debian (powerpc), X and DRI developer
Libre software enthusiast    |   http://svcs.affero.net/rm.php?r=daenzer

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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: PREEMPT on PPC
  2004-03-26 19:27     ` Michel Dänzer
@ 2004-03-27  9:14       ` Mathieu Segaud
  0 siblings, 0 replies; 16+ messages in thread
From: Mathieu Segaud @ 2004-03-27  9:14 UTC (permalink / raw)
  To: Michel Dänzer
  Cc: Michael Schmitz, Benjamin Herrenschmidt, linuxppc-dev list,
	debian-powerpc@lists.debian.org


Michel Dänzer <daenzer@debian.org> writes:

> On Fri, 2004-03-26 at 18:48, Michael Schmitz wrote:
>>
>> Works fine here on 2.6.5-rc2-ben0 . Including disk suspend.
>
> Have you hit swap with it? The problems with preempt usually only
> started at that point here.

here I hit swap on my iBook2.2, and GCC gives ICE segfault every 5 minutes in a
kernel compilation. And X does not last longer than one hour.
Seems to be some other races.

--
Mathieu Segaud

"This, btw, is not something I would suggest you do in your living room.
 Getting a penguin to pee on demand is _messy_. We're talking yellow spots
 on the walls, on the ceiling, yea verily even behind the fridge. However.
 I would also advice against doing this outside - it may be a lot easier to
 clean up, but you're likely to get reported and arrested for public
 lewdness Never mind that you had a perfectly good explanation for it all."

 	- Linus Torvalds on sprinkling holy penguin pee

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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: PREEMPT on PPC
  2004-03-25  8:01 ` Benjamin Herrenschmidt
  2004-03-25 16:09   ` Colin Leroy
  2004-03-26 17:48   ` Michael Schmitz
@ 2004-03-27 15:05   ` Michel Dänzer
  2004-03-29  1:26     ` Benjamin Herrenschmidt
  2 siblings, 1 reply; 16+ messages in thread
From: Michel Dänzer @ 2004-03-27 15:05 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, debian-powerpc@lists.debian.org


On Thu, 2004-03-25 at 09:01, Benjamin Herrenschmidt wrote:
> On Thu, 2004-03-25 at 17:47, Benjamin Herrenschmidt wrote:
> >
> > I've start looking into the various issues of running CONFIG_PREEMPT
> > on ppc32. I found some problems, there may be more, but here's a first
> > patch that should apply on a recent 2.6.x.
> >
> > I suggest if you want to try this out that you run with the various
> > kernel debugging options enabled. Report me remaining problems.
>
> And here's an updated version of that patch that doesn't break
> sleep on laptops.

I appreciate a lot that you're working on this, but unfortunately, this
patch doesn't seem to make any difference here. I still get random
segfaults, weird behaviour in galeon, ... as soon as I hit swap. How can
I provide useful debugging information?


--
Earthling Michel Dänzer      |     Debian (powerpc), X and DRI developer
Libre software enthusiast    |   http://svcs.affero.net/rm.php?r=daenzer


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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: PREEMPT on PPC
  2004-03-27 15:05   ` Michel Dänzer
@ 2004-03-29  1:26     ` Benjamin Herrenschmidt
  2004-03-29  1:38       ` Michel Dänzer
  0 siblings, 1 reply; 16+ messages in thread
From: Benjamin Herrenschmidt @ 2004-03-29  1:26 UTC (permalink / raw)
  To: Michel Dänzer; +Cc: linuxppc-dev list, debian-powerpc@lists.debian.org


> I appreciate a lot that you're working on this, but unfortunately, this
> patch doesn't seem to make any difference here. I still get random
> segfaults, weird behaviour in galeon, ... as soon as I hit swap. How can
> I provide useful debugging information?

In general, is there a relationship with highmem ? that is do you
have highmem enabled and if yes, does it get better without it ?

I hit swap on the test wallstreet here and things just worked...

Ben.


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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: PREEMPT on PPC
  2004-03-29  1:26     ` Benjamin Herrenschmidt
@ 2004-03-29  1:38       ` Michel Dänzer
  2004-03-29  1:55         ` Benjamin Herrenschmidt
  0 siblings, 1 reply; 16+ messages in thread
From: Michel Dänzer @ 2004-03-29  1:38 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, debian-powerpc@lists.debian.org


On Mon, 2004-03-29 at 03:26, Benjamin Herrenschmidt wrote:
> > I appreciate a lot that you're working on this, but unfortunately, this
> > patch doesn't seem to make any difference here. I still get random
> > segfaults, weird behaviour in galeon, ... as soon as I hit swap. How can
> > I provide useful debugging information?
>
> In general, is there a relationship with highmem ? that is do you
> have highmem enabled and if yes, does it get better without it ?

It's enabled, but diasbling it didn't seem to make a difference either.

FWIW, http://penguinppc.org/~daenzer/config-2.6.5-rc2-ben0-ck1 is my
current, preempt-less config.

Note that I'm not sure how tightly the problems are tied to swap; after
they start, they seem to persist even when swap is no longer used. It's
just the best criterion I've been able to identify so far.


--
Earthling Michel Dänzer      |     Debian (powerpc), X and DRI developer
Libre software enthusiast    |   http://svcs.affero.net/rm.php?r=daenzer


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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: PREEMPT on PPC
  2004-03-29  1:38       ` Michel Dänzer
@ 2004-03-29  1:55         ` Benjamin Herrenschmidt
  2004-03-29  9:31           ` Michael Schmitz
  2004-03-29 10:43           ` Michel Dänzer
  0 siblings, 2 replies; 16+ messages in thread
From: Benjamin Herrenschmidt @ 2004-03-29  1:55 UTC (permalink / raw)
  To: Michel Dänzer; +Cc: linuxppc-dev list, debian-powerpc@lists.debian.org


> Note that I'm not sure how tightly the problems are tied to swap; after
> they start, they seem to persist even when swap is no longer used. It's
> just the best criterion I've been able to identify so far.

Weird. I just can't reproduce any of your problems, neither on the
tipb with highmem & lots of RAM, or on the wallstreet with no highmem
and little RAM (thus swap)...

I've been running with preempt for a few days now without trouble.

What else are you using ? I suspect something like MOL may have troubles
with preempt for example...

Ben.


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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: PREEMPT on PPC
  2004-03-29  1:55         ` Benjamin Herrenschmidt
@ 2004-03-29  9:31           ` Michael Schmitz
  2004-03-29 10:43           ` Michel Dänzer
  1 sibling, 0 replies; 16+ messages in thread
From: Michael Schmitz @ 2004-03-29  9:31 UTC (permalink / raw)
  To: Benjamin Herrenschmidt
  Cc: Michel Dänzer, linuxppc-dev list,
	debian-powerpc@lists.debian.org


> > Note that I'm not sure how tightly the problems are tied to swap; after
> > they start, they seem to persist even when swap is no longer used. It's
> > just the best criterion I've been able to identify so far.
>
> Weird. I just can't reproduce any of your problems, neither on the
> tipb with highmem & lots of RAM, or on the wallstreet with no highmem
> and little RAM (thus swap)...

Same here - 128 MB RAM, 256 MB swap with half of that currently in use
(mostly by mol). Doesn't miss a beat.

> I've been running with preempt for a few days now without trouble.
>
> What else are you using ? I suspect something like MOL may have troubles
> with preempt for example...

Apparently not (0.9.69-20031019-5 here, haven't got 0.9.70 to behave yet).

	Michael


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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: PREEMPT on PPC
  2004-03-29  1:55         ` Benjamin Herrenschmidt
  2004-03-29  9:31           ` Michael Schmitz
@ 2004-03-29 10:43           ` Michel Dänzer
  2004-03-29 11:29             ` Michael Schmitz
  2004-03-29 12:00             ` Benjamin Herrenschmidt
  1 sibling, 2 replies; 16+ messages in thread
From: Michel Dänzer @ 2004-03-29 10:43 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, debian-powerpc@lists.debian.org


On Mon, 2004-03-29 at 03:55, Benjamin Herrenschmidt wrote:
> > Note that I'm not sure how tightly the problems are tied to swap; after
> > they start, they seem to persist even when swap is no longer used. It's
> > just the best criterion I've been able to identify so far.
>
> Weird. I just can't reproduce any of your problems, neither on the
> tipb with highmem & lots of RAM, or on the wallstreet with no highmem
> and little RAM (thus swap)...
>
> I've been running with preempt for a few days now without trouble.
>
> What else are you using ? I suspect something like MOL may have troubles
> with preempt for example...

Not using that regularly. Not sure what's special about my setup, XFS
maybe?

What about this:

-CONFIG_TASK_SIZE=0xc0000000
+CONFIG_TASK_SIZE=0x80000000

I can't seem to find any other significant differences between
pmac_defconfig and mine. I'll keep trying...


--
Earthling Michel Dänzer      |     Debian (powerpc), X and DRI developer
Libre software enthusiast    |   http://svcs.affero.net/rm.php?r=daenzer


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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: PREEMPT on PPC
  2004-03-29 10:43           ` Michel Dänzer
@ 2004-03-29 11:29             ` Michael Schmitz
  2004-03-29 12:01               ` Benjamin Herrenschmidt
  2004-03-29 12:00             ` Benjamin Herrenschmidt
  1 sibling, 1 reply; 16+ messages in thread
From: Michael Schmitz @ 2004-03-29 11:29 UTC (permalink / raw)
  To: Michel Dänzer
  Cc: Benjamin Herrenschmidt, linuxppc-dev list,
	debian-powerpc@lists.debian.org


> > What else are you using ? I suspect something like MOL may have troubles
> > with preempt for example...
>
> Not using that regularly. Not sure what's special about my setup, XFS
> maybe?
>
> What about this:
>
> -CONFIG_TASK_SIZE=0xc0000000
> +CONFIG_TASK_SIZE=0x80000000

Nope, that's what my kernel is built with as well.

	Michael


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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: PREEMPT on PPC
  2004-03-29 10:43           ` Michel Dänzer
  2004-03-29 11:29             ` Michael Schmitz
@ 2004-03-29 12:00             ` Benjamin Herrenschmidt
  1 sibling, 0 replies; 16+ messages in thread
From: Benjamin Herrenschmidt @ 2004-03-29 12:00 UTC (permalink / raw)
  To: Michel Dänzer; +Cc: linuxppc-dev list, debian-powerpc@lists.debian.org


On Mon, 2004-03-29 at 20:43, Michel Dänzer wrote:
> On Mon, 2004-03-29 at 03:55, Benjamin Herrenschmidt wrote:
> > > Note that I'm not sure how tightly the problems are tied to swap; after
> > > they start, they seem to persist even when swap is no longer used. It's
> > > just the best criterion I've been able to identify so far.
> >
> > Weird. I just can't reproduce any of your problems, neither on the
> > tipb with highmem & lots of RAM, or on the wallstreet with no highmem
> > and little RAM (thus swap)...
> >
> > I've been running with preempt for a few days now without trouble.
> >
> > What else are you using ? I suspect something like MOL may have troubles
> > with preempt for example...
>
> Not using that regularly. Not sure what's special about my setup, XFS
> maybe?
>
> What about this:
>
> -CONFIG_TASK_SIZE=0xc0000000
> +CONFIG_TASK_SIZE=0x80000000
>
> I can't seem to find any other significant differences between
> pmac_defconfig and mine. I'll keep trying...

Shouldn't affect it, on ppc32, I hope nothing tries to map between 2G
and 3G... (except on G5 though)

Ben.


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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: PREEMPT on PPC
  2004-03-29 11:29             ` Michael Schmitz
@ 2004-03-29 12:01               ` Benjamin Herrenschmidt
  0 siblings, 0 replies; 16+ messages in thread
From: Benjamin Herrenschmidt @ 2004-03-29 12:01 UTC (permalink / raw)
  To: Michael Schmitz
  Cc: Michel Dänzer, linuxppc-dev list,
	debian-powerpc@lists.debian.org


On Mon, 2004-03-29 at 21:29, Michael Schmitz wrote:
> > > What else are you using ? I suspect something like MOL may have troubles
> > > with preempt for example...
> >
> > Not using that regularly. Not sure what's special about my setup, XFS
> > maybe?
> >
> > What about this:
> >
> > -CONFIG_TASK_SIZE=0xc0000000
> > +CONFIG_TASK_SIZE=0x80000000
>
> Nope, that's what my kernel is built with as well.

BTW. I pushed more preempt fixes upsteam (see lkml if not in
mainstream yet).

Ben.


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

^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2004-03-29 12:01 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-03-25  6:47 PREEMPT on PPC Benjamin Herrenschmidt
2004-03-25  8:01 ` Benjamin Herrenschmidt
2004-03-25 16:09   ` Colin Leroy
2004-03-25 22:42     ` Benjamin Herrenschmidt
2004-03-26 17:48   ` Michael Schmitz
2004-03-26 19:27     ` Michel Dänzer
2004-03-27  9:14       ` Mathieu Segaud
2004-03-27 15:05   ` Michel Dänzer
2004-03-29  1:26     ` Benjamin Herrenschmidt
2004-03-29  1:38       ` Michel Dänzer
2004-03-29  1:55         ` Benjamin Herrenschmidt
2004-03-29  9:31           ` Michael Schmitz
2004-03-29 10:43           ` Michel Dänzer
2004-03-29 11:29             ` Michael Schmitz
2004-03-29 12:01               ` Benjamin Herrenschmidt
2004-03-29 12:00             ` Benjamin Herrenschmidt

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).