[PATCH]: ioremap function balancing in init/cleanup sound/oss/dmasound/dmacound_awacs.c

2007-07-29 Thread postfail
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Two cases where ioremap can be called in init function but will
never be cleaned up. patch is against 2.6.23-rc1.

Signed-off-by: Post Fail  hushmail.com>
- ---

- --- ./linux-2.6.22.clean/sound/oss/dmasound/dmasound_awacs.c  2007-
07-08 19:32:17.0 -0400
+++ ./linux-2.6.22/sound/oss/dmasound/dmasound_awacs.c  2007-07-29
23:05:30.0 -0400
@@ -3204,6 +3204,12 @@ static void __exit dmasound_awacs_cleanu
}
dmasound_deinit();

+if (latch_base)
+iounmap(latch_base);
+
+if (macio_base)
+iounmap(macio_base);
+
of_node_put(awacs_node);
of_node_put(i2s_node);
 }

-BEGIN PGP SIGNATURE-
Note: This signature can be verified at https://www.hushtools.com/verify
Version: Hush 2.5

wpwEAQECAAYFAkateM4ACgkQ5iui/yAtoVllnAP/b/B6G+rmMgu0DXi6UOmpkPhw2aWZ
o8E7PiKXmqIjuxVcGERch+dQ5Fv2HytDWE0Wx7/T2P/4Q8rIbPLSemgIQmk0ZHUfPydG
mQ+kKMmtFI5MwJ63QeHwuz4O+E+3CzIS3j+ZDb+nYrOXOZexWHMWRSm8zG+3WjBj8wCH
G1z+Wvg=
=WXVV
-END PGP SIGNATURE-

--
Click here for a free directory of employee development and training solutions
http://tagline.hushmail.com/fc/Ioyw6h4dDApAP0vm8MwFLWUmr7tHObB8rYAXa7zXQmEHPyHNeojRUQ/


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: 2.6.23-rc1-mm1 -- INFO: possible recursive locking detected -- (>hb_spinlock){....}, at: [] irias_seq_show+0xba/0x1a8

2007-07-29 Thread Paul Menage
On 7/28/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> >  [] proc_cpuset_show+0x5e/0xb9
> >  [] seq_read+0xef/0x266
> >  [] vfs_read+0x8e/0x117
> >  [] sys_read+0x3d/0x61
> >  [] sysenter_past_esp+0x5f/0x99
> >  ===
> > INFO: lockdep is turned off.
> > Code: 00 89 d8 83 c4 0c 5b 5e 5f 5d c3 55 89 e5 57 56 53 83 ec 08 89
> > 45 f0 89 55 ec 89 d3 01 cb 8d 43 ff c6 43 ff 00 8b 55 f0 8b 72 1c <8b>
> > 56 3c 29 d0 3b 45 ec 72 45 89 d1 c1 e9 02 8b 76 40 89 c7 f3
> > EIP: [] container_path+0x20/0x7b SS:ESP 0068:c5ccff00
>

Oops, this is a case of trying to read /proc/self/cpuset when cpusets
are completely unmounted. It works fine when cpusets is mounted as
part of any hierarchy, or part of an active but unmounted hierarchy.
Attached patch fixes it, and should be rolled in to the first patch of
the series. (basic framework patch).

Paul
---
 kernel/container.c |9 +
 1 file changed, 9 insertions(+)

Index: container-2.6.22-rc6-mm1/kernel/container.c
===
--- container-2.6.22-rc6-mm1.orig/kernel/container.c
+++ container-2.6.22-rc6-mm1/kernel/container.c
@@ -684,6 +684,15 @@ int container_path(const struct containe
 {
 	char *start;
 
+	if (cont == dummytop) {
+		/*
+		 * Inactive subsystems have no dentry for their root
+		 * container
+		 */
+		strcpy(buf, "/");
+		return 0;
+	}
+
 	start = buf + buflen;
 
 	*--start = '\0';


Re: [PATCH 1/5] Use mutex instead of semaphore in the Host AP driver

2007-07-29 Thread Matthias Kaehlcke
El Mon, Jul 30, 2007 at 09:17:25AM +0530 Satyam Sharma ha dit:

> Whoops ...
> 
> 
> On Mon, 30 Jul 2007, Satyam Sharma wrote:
> 
> > On Mon, 30 Jul 2007, Michael Buesch wrote:
> > 
> > > On Sunday 29 July 2007 23:34, Matthias Kaehlcke wrote:
> > > > The Host AP driver uses a semaphore as mutex. Use the mutex API
> > > > instead of the (binary) semaphore.
> > > > 
> > > > Signed-off-by: Matthias Kaehlcke <[EMAIL PROTECTED]>
> > 
> > [ Something seems to have gone wrong with your diff / patch / script.
> >   There was no diff header here, which should have been. ]
> > 
> > > > -   res = down_interruptible(>rid_bap_sem);
> > > > +   res = mutex_lock_interruptible(>rid_bap_mtx);
> > > > if (res)
> > > > return res;
> > > >  
> > > > @@ -902,7 +902,7 @@ static int hfa384x_set_rid(struct net_device *dev, 
> > > > u16 rid, void *buf, int len)
> > > > /* RID len in words and +1 for rec.rid */
> > > > rec.len = cpu_to_le16(len / 2 + len % 2 + 1);
> > > >  
> > > > -   res = down_interruptible(>rid_bap_sem);
> > > > +   res = mutex_lock_interruptible(>rid_bap_mtx);
> > > > if (res)
> > > > return res;
> > > >  
> > > 
> > > Is res returned to userspace? If yes, that's not right.
> > 
> > Yup, that's not right.
> > 
> > > On a interrupted mutex allocation you should return
> > > -ERESTARTSYS to userspace.
> > 
> > Nope, userspace must not see ERESTARTSYS (I /think/ this is the third
> > time I'm participating in this exact same discussion :-)
> > 
> > If the return would be caught by a previous in-kernel caller in the
> > call chain, ERESTARTSYS is okay and it could try to restart the
> > operation. However, if the return goes unfiltered directly to
> > userspace, EINTR is the correct choice.
> 
> Eek, and because mutex_lock_interruptible() *does* return -EINTR when
> interrupted by a signal, and I noticed that hfa384x_set_rid() could be
> called from an ioctl(2) codepath with no intermediate caller trying to
> restart it, so the code is perfectly alright, actually.
> 
> But the patch doesn't have the diff header anyway, so Matthias would
> probably have to resend in any case :-)

thanks for reviewing the patch and for your comments, here is the
patch with the diff header (no idea what when wrong with the other
one)

regards

matthias

--

The Host AP driver uses a semaphore as mutex. Use the mutex API
instead of the (binary) semaphore.

Signed-off-by: Matthias Kaehlcke <[EMAIL PROTECTED]>

--

diff --git a/drivers/net/wireless/hostap/hostap_hw.c 
b/drivers/net/wireless/hostap/hostap_hw.c
index 959887b..d3dacbc 100644
--- a/drivers/net/wireless/hostap/hostap_hw.c
+++ b/drivers/net/wireless/hostap/hostap_hw.c
@@ -825,7 +825,7 @@ static int hfa384x_get_rid(struct net_device *dev, u16 rid, 
void *buf, int len,
local->hw_downloading)
return -ENODEV;
 
-   res = down_interruptible(>rid_bap_sem);
+   res = mutex_lock_interruptible(>rid_bap_mtx);
if (res)
return res;
 
@@ -834,7 +834,7 @@ static int hfa384x_get_rid(struct net_device *dev, u16 rid, 
void *buf, int len,
printk(KERN_DEBUG "%s: hfa384x_get_rid: CMDCODE_ACCESS failed "
   "(res=%d, rid=%04x, len=%d)\n",
   dev->name, res, rid, len);
-   up(>rid_bap_sem);
+   mutex_unlock(>rid_bap_mtx);
return res;
}
 
@@ -861,7 +861,7 @@ static int hfa384x_get_rid(struct net_device *dev, u16 rid, 
void *buf, int len,
res = hfa384x_from_bap(dev, BAP0, buf, len);
 
spin_unlock_bh(>baplock);
-   up(>rid_bap_sem);
+   mutex_unlock(>rid_bap_mtx);
 
if (res) {
if (res != -ENODATA)
@@ -902,7 +902,7 @@ static int hfa384x_set_rid(struct net_device *dev, u16 rid, 
void *buf, int len)
/* RID len in words and +1 for rec.rid */
rec.len = cpu_to_le16(len / 2 + len % 2 + 1);
 
-   res = down_interruptible(>rid_bap_sem);
+   res = mutex_lock_interruptible(>rid_bap_mtx);
if (res)
return res;
 
@@ -917,12 +917,12 @@ static int hfa384x_set_rid(struct net_device *dev, u16 
rid, void *buf, int len)
if (res) {
printk(KERN_DEBUG "%s: hfa384x_set_rid (rid=%04x, len=%d) - "
   "failed - res=%d\n", dev->name, rid, len, res);
-   up(>rid_bap_sem);
+   mutex_unlock(>rid_bap_mtx);
return res;
}
 
res = hfa384x_cmd(dev, HFA384X_CMDCODE_ACCESS_WRITE, rid, NULL, NULL);
-   up(>rid_bap_sem);
+   mutex_unlock(>rid_bap_mtx);
 
if (res) {
printk(KERN_DEBUG "%s: hfa384x_set_rid: CMDCODE_ACCESS_WRITE "
@@ -3171,7 +3171,7 @@ prism2_init_local_data(struct prism2_helper_functions 
*funcs, int card_idx,
spin_lock_init(>cmdlock);
spin_lock_init(>baplock);
spin_lock_init(>lock);
-   init_MUTEX(>rid_bap_sem);
+   

Re: [PATCH -rt 1/9] preempt rcu: check for underflow

2007-07-29 Thread Paul E. McKenney
On Sun, Jul 29, 2007 at 07:45:35PM -0700, Daniel Walker wrote:
> Simple WARN_ON to catch any underflow in rcu_read_lock_nesting.
> 
> Signed-off-by: Daniel Walker <[EMAIL PROTECTED]>

Acked-by: Paul E. McKenney <[EMAIL PROTECTED]>

> ---
>  kernel/rcupreempt.c |6 ++
>  1 file changed, 6 insertions(+)
> 
> Index: linux-2.6.22/kernel/rcupreempt.c
> ===
> --- linux-2.6.22.orig/kernel/rcupreempt.c
> +++ linux-2.6.22/kernel/rcupreempt.c
> @@ -157,6 +157,12 @@ void __rcu_read_unlock(void)
>   }
> 
>   local_irq_restore(oldirq);
> +
> + /*
> +  * If our rcu_read_lock_nesting went negative, likely
> +  * something is wrong..
> +  */
> + WARN_ON(current->rcu_read_lock_nesting < 0);
>  }
> 
>  static void __rcu_advance_callbacks(void)
> 
> -- 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: v2.6.23-rc1-rt6-dw1

2007-07-29 Thread Arjan van de Ven
>  
> +/*
> + * trigger a reschedule on all other CPUs:
> + */
> +extern void smp_send_reschedule_allbutself(void);
> +
> +/*
> + * trigger a reschedule on all other CPUs:
> + */
> +extern void smp_send_reschedule_allbutself(void);
> +

just to make sure the C compiler doesn't forget it ?
or maybe the parser is suffering from memory lapse ? ;)

>  
> -#ifdef CONFIG_DEBUG_SPINLOCK_SLEEP
> +#if defined(CONFIG_DEBUG_SPINLOCK_SLEEP) || defined(CONFIG_DEBUG_PREEMPT)

why this change? the change is for spinlock debugging.. why add preempt
to this?


>void __might_sleep(char *file, int line);
>  # define might_sleep() \
>   do { __might_sleep(__FILE__, __LINE__); might_resched(); } while (0)
> @@ -198,6 +198,7 @@ extern void add_taint(unsigned);
>  /* Values used for system_state */
>  extern enum system_states {
>   SYSTEM_BOOTING,
> + SYSTEM_BOOTING_SCHEDULER_OK,

what is this used for? your patch doesn't add users of this...

>   SYSTEM_RUNNING,
>   SYSTEM_HALT,
>   SYSTEM_POWER_OFF,
> --- linux-2.6.22.orig/init/main.c
> +++ linux-2.6.22/init/main.c
> @@ -438,6 +438,8 @@ static void noinline __init_refok rest_i
>  {
>   int pid;
>  
> + system_state = SYSTEM_BOOTING_SCHEDULER_OK;
> +
>   kernel_thread(kernel_init, NULL, CLONE_FS | CLONE_SIGHAND);
>   numa_default_policy();
>   pid = kernel_thread(kthreadd, NULL, CLONE_FS | CLONE_FILES);
> --- linux-2.6.22.orig/lib/kernel_lock.c
> +++ linux-2.6.22/lib/kernel_lock.c
> @@ -35,22 +35,25 @@ DECLARE_MUTEX(kernel_sem);
>   * about recursion, both due to the down() and due to the enabling of
>   * preemption. schedule() will re-check the preemption flag after
>   * reacquiring the semaphore.
> + *
> + * Called with interrupts disabled.
>   */
>  int __lockfunc __reacquire_kernel_lock(void)
>  {
>   struct task_struct *task = current;
>   int saved_lock_depth = task->lock_depth;
>  
> + local_irq_enable();

eh... if interrupts are off here that's a bad bug. Why work around it?

>   BUG_ON(saved_lock_depth < 0);
>  
>   task->lock_depth = -1;
> - __preempt_enable_no_resched();
>  
>   down(_sem);
>  
> - preempt_disable();
>   task->lock_depth = saved_lock_depth;
>  
> + local_irq_disable();
> +

same here..

>  int __lockfunc __reacquire_kernel_lock(void)
>  {
> - while (!_raw_spin_trylock(_flag)) {
> - if (test_thread_flag(TIF_NEED_RESCHED))
> - return -EAGAIN;
> - cpu_relax();
> - }
> + local_irq_enable();
> + _raw_spin_lock(_flag);
> + local_irq_disable();

are you sure you want this semantics change?



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: v2.6.23-rc1-rt6-dw1

2007-07-29 Thread Arjan van de Ven
>  
> +/*
> + * trigger a reschedule on all other CPUs:
> + */
> +extern void smp_send_reschedule_allbutself(void);
> +
> +/*
> + * trigger a reschedule on all other CPUs:
> + */
> +extern void smp_send_reschedule_allbutself(void);
> +
>  
>  /*
>   * Prepare machine for booting other CPUs.
> @@ -97,6 +107,7 @@ static inline int up_smp_call_function(v
>   0;  \
>   })
>  static inline void smp_send_reschedule(int cpu) { }
> +static inline void smp_send_reschedule_allbutself(void) { }
>  #define num_booting_cpus()   1
>  #define smp_prepare_boot_cpu()   do {} while (0)
>  #define smp_call_function_single(cpuid, func, info, retry, wait) \
> :: end preempt-realtime-i386.patch ::
> :: start preempt-realtime-sched.patch ::
> --- linux-2.6.22.orig/include/linux/kernel.h
> +++ linux-2.6.22/include/linux/kernel.h
> @@ -88,7 +88,7 @@ extern int cond_resched(void);
>  # define might_resched() do { } while (0)
>  #endif
>  
> -#ifdef CONFIG_DEBUG_SPINLOCK_SLEEP
> +#if defined(CONFIG_DEBUG_SPINLOCK_SLEEP) || defined(CONFIG_DEBUG_PREEMPT)
>void __might_sleep(char *file, int line);
>  # define might_sleep() \
>   do { __might_sleep(__FILE__, __LINE__); might_resched(); } while (0)
> @@ -198,6 +198,7 @@ extern void add_taint(unsigned);
>  /* Values used for system_state */
>  extern enum system_states {
>   SYSTEM_BOOTING,
> + SYSTEM_BOOTING_SCHEDULER_OK,
>   SYSTEM_RUNNING,
>   SYSTEM_HALT,
>   SYSTEM_POWER_OFF,
> --- linux-2.6.22.orig/init/main.c
> +++ linux-2.6.22/init/main.c
> @@ -438,6 +438,8 @@ static void noinline __init_refok rest_i
>  {
>   int pid;
>  
> + system_state = SYSTEM_BOOTING_SCHEDULER_OK;
> +
>   kernel_thread(kernel_init, NULL, CLONE_FS | CLONE_SIGHAND);
>   numa_default_policy();
>   pid = kernel_thread(kthreadd, NULL, CLONE_FS | CLONE_FILES);
> --- linux-2.6.22.orig/lib/kernel_lock.c
> +++ linux-2.6.22/lib/kernel_lock.c
> @@ -35,22 +35,25 @@ DECLARE_MUTEX(kernel_sem);
>   * about recursion, both due to the down() and due to the enabling of
>   * preemption. schedule() will re-check the preemption flag after
>   * reacquiring the semaphore.
> + *
> + * Called with interrupts disabled.
>   */
>  int __lockfunc __reacquire_kernel_lock(void)
>  {
>   struct task_struct *task = current;
>   int saved_lock_depth = task->lock_depth;
>  
> + local_irq_enable();
>   BUG_ON(saved_lock_depth < 0);
>  
>   task->lock_depth = -1;
> - __preempt_enable_no_resched();
>  
>   down(_sem);
>  
> - preempt_disable();
>   task->lock_depth = saved_lock_depth;
>  
> + local_irq_disable();
> +
>   return 0;
>  }
>  
> @@ -67,11 +70,15 @@ void __lockfunc lock_kernel(void)
>   struct task_struct *task = current;
>   int depth = task->lock_depth + 1;
>  
> - if (likely(!depth))
> + if (likely(!depth)) {
>   /*
>* No recursion worries - we set up lock_depth _after_
>*/
>   down(_sem);
> +#ifdef CONFIG_DEBUG_RT_MUTEXES
> + current->last_kernel_lock = __builtin_return_address(0);
> +#endif
> + }
>  
>   task->lock_depth = depth;
>  }
> @@ -82,8 +89,12 @@ void __lockfunc unlock_kernel(void)
>  
>   BUG_ON(task->lock_depth < 0);
>  
> - if (likely(--task->lock_depth < 0))
> + if (likely(--task->lock_depth == -1)) {
> +#ifdef CONFIG_DEBUG_RT_MUTEXES
> + current->last_kernel_lock = NULL;
> +#endif
>   up(_sem);
> + }
>  }
>  
>  #else
> @@ -116,11 +127,9 @@ static  __cacheline_aligned_in_smp DEFIN
>   */
>  int __lockfunc __reacquire_kernel_lock(void)
>  {
> - while (!_raw_spin_trylock(_flag)) {
> - if (test_thread_flag(TIF_NEED_RESCHED))
> - return -EAGAIN;
> - cpu_relax();
> - }
> + local_irq_enable();
> + _raw_spin_lock(_flag);
> + local_irq_disable();
>   preempt_disable();
>   return 0;
>  }
> :: end preempt-realtime-sched.patch ::
> :: start preempt-realtime-core.patch ::
> diff -u linux-rt-rebase.q/include/linux/kernel.h 
> linux-2.6.22/include/linux/kernel.h
> --- linux-rt-rebase.q/include/linux/kernel.h
> +++ linux-2.6.22/include/linux/kernel.h   2007-07-27 01:32:15.0 
> +
> @@ -88,7 +88,7 @@
>  # define might_resched() do { } while (0)
>  #endif
>  
> -#if defined(CONFIG_DEBUG_SPINLOCK_SLEEP) || defined(CONFIG_DEBUG_PREEMPT)
> +#ifdef CONFIG_DEBUG_SPINLOCK_SLEEP
>void __might_sleep(char *file, int line);
>  # define might_sleep() \
>   do { __might_sleep(__FILE__, __LINE__); might_resched(); } while (0)
> @@ -210,7 +210,6 @@
>  /* Values used for system_state */
>  extern enum system_states {
>   SYSTEM_BOOTING,
> - SYSTEM_BOOTING_SCHEDULER_OK,
>   SYSTEM_RUNNING,
>   SYSTEM_HALT,
>   SYSTEM_POWER_OFF,
> reverted:
> --- linux-rt-rebase.q/include/linux/smp.h
> +++ linux-rt-rebase.q.orig/include/linux/smp.h
> 

changing include/asm-generic/pgtable.h for non-mmu

2007-07-29 Thread Greg Ungerer

Hi All,

There are some parts of include/asm-generic/pgtable.h that are
relevant to the non-mmu architectures. To make it easier to include
this from them I would like to ifdef the relevant parts.
Does anyone object to something like the patch below?

Without this there is a handful of functions that are referenced
in here that are not defined on many non-mmu architectures. They
could be defined out ofcourse, as an alternative approach.

Regards
Greg




diff -Naur linux-2.6.23-rc1-git2/include/asm-generic/pgtable.h 
linux/include/asm-generic/pgtable.h
--- linux-2.6.23-rc1-git2/include/asm-generic/pgtable.h 2007-07-26 
10:38:56.0 +1000
+++ linux/include/asm-generic/pgtable.h 2007-07-30 15:02:40.0 +1000
@@ -2,6 +2,7 @@
 #define _ASM_GENERIC_PGTABLE_H
 
 #ifndef __ASSEMBLY__
+#ifdef CONFIG_MMU
 
 #ifndef __HAVE_ARCH_PTEP_SET_ACCESS_FLAGS
 /*
@@ -133,41 +134,6 @@
 #endif
 
 /*
- * A facility to provide lazy MMU batching.  This allows PTE updates and
- * page invalidations to be delayed until a call to leave lazy MMU mode
- * is issued.  Some architectures may benefit from doing this, and it is
- * beneficial for both shadow and direct mode hypervisors, which may batch
- * the PTE updates which happen during this window.  Note that using this
- * interface requires that read hazards be removed from the code.  A read
- * hazard could result in the direct mode hypervisor case, since the actual
- * write to the page tables may not yet have taken place, so reads though
- * a raw PTE pointer after it has been modified are not guaranteed to be
- * up to date.  This mode can only be entered and left under the protection of
- * the page table locks for all page tables which may be modified.  In the UP
- * case, this is required so that preemption is disabled, and in the SMP case,
- * it must synchronize the delayed page table writes properly on other CPUs.
- */
-#ifndef __HAVE_ARCH_ENTER_LAZY_MMU_MODE
-#define arch_enter_lazy_mmu_mode() do {} while (0)
-#define arch_leave_lazy_mmu_mode() do {} while (0)
-#define arch_flush_lazy_mmu_mode() do {} while (0)
-#endif
-
-/*
- * A facility to provide batching of the reload of page tables with the
- * actual context switch code for paravirtualized guests.  By convention,
- * only one of the lazy modes (CPU, MMU) should be active at any given
- * time, entry should never be nested, and entry and exits should always
- * be paired.  This is for sanity of maintaining and reasoning about the
- * kernel code.
- */
-#ifndef __HAVE_ARCH_ENTER_LAZY_CPU_MODE
-#define arch_enter_lazy_cpu_mode() do {} while (0)
-#define arch_leave_lazy_cpu_mode() do {} while (0)
-#define arch_flush_lazy_cpu_mode() do {} while (0)
-#endif
-
-/*
  * When walking page tables, get the address of the next boundary,
  * or the end address of the range if that comes earlier.  Although no
  * vma end wraps to 0, rounded up __boundary may wrap to 0 throughout.
@@ -233,6 +199,43 @@
}
return 0;
 }
+#endif /* CONFIG_MMU */
+
+/*
+ * A facility to provide lazy MMU batching.  This allows PTE updates and
+ * page invalidations to be delayed until a call to leave lazy MMU mode
+ * is issued.  Some architectures may benefit from doing this, and it is
+ * beneficial for both shadow and direct mode hypervisors, which may batch
+ * the PTE updates which happen during this window.  Note that using this
+ * interface requires that read hazards be removed from the code.  A read
+ * hazard could result in the direct mode hypervisor case, since the actual
+ * write to the page tables may not yet have taken place, so reads though
+ * a raw PTE pointer after it has been modified are not guaranteed to be
+ * up to date.  This mode can only be entered and left under the protection of
+ * the page table locks for all page tables which may be modified.  In the UP
+ * case, this is required so that preemption is disabled, and in the SMP case,
+ * it must synchronize the delayed page table writes properly on other CPUs.
+ */
+#ifndef __HAVE_ARCH_ENTER_LAZY_MMU_MODE
+#define arch_enter_lazy_mmu_mode() do {} while (0)
+#define arch_leave_lazy_mmu_mode() do {} while (0)
+#define arch_flush_lazy_mmu_mode() do {} while (0)
+#endif
+
+/*
+ * A facility to provide batching of the reload of page tables with the
+ * actual context switch code for paravirtualized guests.  By convention,
+ * only one of the lazy modes (CPU, MMU) should be active at any given
+ * time, entry should never be nested, and entry and exits should always
+ * be paired.  This is for sanity of maintaining and reasoning about the
+ * kernel code.
+ */
+#ifndef __HAVE_ARCH_ENTER_LAZY_CPU_MODE
+#define arch_enter_lazy_cpu_mode() do {} while (0)
+#define arch_leave_lazy_cpu_mode() do {} while (0)
+#define arch_flush_lazy_cpu_mode() do {} while (0)
+#endif
+
 #endif /* !__ASSEMBLY__ */
 
 #endif /* _ASM_GENERIC_PGTABLE_H */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" 

Re: [ck] Re: Linus 2.6.23-rc1

2007-07-29 Thread Matthew Hawkins
On 7/30/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> For example, how hard is it for people to just admit that CFS actually
> does better than SD on a number of things? Including very much on the
> desktop.

Actually in benchmarks Ingo has quoted, SD was better on the desktop
(by a small margin).
CFS is still a bit bursty, though it has significantly improved with
age.  I know, I did those benchmarks.  That being said, I'm really
glad to see CFS in your git tree because the new framework around it
really improves the readability of the code, and actually makes it
easier to start experimenting with scheduler improvements from an
entire scheduler like SD to minor bits like priorities.

I have one concern - my benchmarking took load average as the common
denominator and CFS alters the way the load average is calculated, so
perhaps it wasn't a fair comparison.  That being said, they still
showed CFS could scale very well and SD did not, so considering we're
dealing with everything from wristwatches to BlueGene/L I believe the
right choice was made.  Those arguing for the 2% improvement that SD
would give them in their environment would be better off

a) helping port SD to the new scheduler framework
b) assisting Ingo in improving CFS to meet/exceed their requirements
c) giving practical assistance to anyone doing either of the above

I'm re-learning git and using my Copious Spare Time (tm) to do what I
can - but I have to admit I'm really in over my head.  But hey, if
Jeff Garzik can do it, so can I.  I remember when he couldn't grok C &
now he's got control over all our data :-)

-- 
Matt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [ck] Re: Linus 2.6.23-rc1

2007-07-29 Thread Mike Galbraith
On Sun, 2007-07-29 at 14:48 -0700, Bill Huey wrote:
> On Sun, Jul 29, 2007 at 10:25:42PM +0200, Mike Galbraith wrote:
> > Absolutely.
> > 
> > Con quit for his own reasons.  Given that Con himself has said that CFS
> > was _not_ why he quite, please discard this... bait.  Anyone who's name
> > isn't Con Kolivas, who pretends to speak for him is at the very least
> > overstepping his bounds, and that is being _very_ generous.
> 
> I know Con personally and I completely identify with his circumstance. This

You're still not Con, and I still think it's inappropriate for any
person to speak for another unless that person is the designated proxy.

> is precisely why he quit the project because of a generally perceived
> ignorance and disconnect from end users. Since you side with Ingo on many
> issues politically, this response from you is no surprise.

Hm.  I don't recall entering the world of politics.  Where's my cool
lapel button?

-Mike

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] Doc: DMA-API update

2007-07-29 Thread Muli Ben-Yehuda
On Sun, Jul 29, 2007 at 06:27:22PM -0700, Randy Dunlap wrote:
> From: Randy Dunlap <[EMAIL PROTECTED]>
> 
> Fix typos and update function parameters.
> 
> Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>

Acked-by: Muli Ben-Yehuda <[EMAIL PROTECTED]>

Cheers,
Muli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH -rt 6/9] spinlock/rt_lock random cleanups

2007-07-29 Thread Ankita Garg
On Sun, Jul 29, 2007 at 07:45:40PM -0700, Daniel Walker wrote:
> Signed-off-by: Daniel Walker <[EMAIL PROTECTED]>
> 
> ---
>  include/linux/rt_lock.h  |6 --
>  include/linux/spinlock.h |5 +++--
>  2 files changed, 7 insertions(+), 4 deletions(-)
> 
> Index: linux-2.6.22/include/linux/rt_lock.h
> ===
> --- linux-2.6.22.orig/include/linux/rt_lock.h
> +++ linux-2.6.22/include/linux/rt_lock.h
> @@ -128,12 +128,14 @@ struct semaphore name = \
>   */
>  #define DECLARE_MUTEX_LOCKED COMPAT_DECLARE_MUTEX_LOCKED
> 
> -extern void fastcall __sema_init(struct semaphore *sem, int val, char *name, 
> char *file, int line);
> +extern void fastcall
> +__sema_init(struct semaphore *sem, int val, char *name, char *file, int 
> line);
> 
>  #define rt_sema_init(sem, val) \
>   __sema_init(sem, val, #sem, __FILE__, __LINE__)
> 
> -extern void fastcall __init_MUTEX(struct semaphore *sem, char *name, char 
> *file, int line);
> +extern void fastcall
> +__init_MUTEX(struct semaphore *sem, char *name, char *file, int line);
>  #define rt_init_MUTEX(sem) \
>   __init_MUTEX(sem, #sem, __FILE__, __LINE__)
> 
> Index: linux-2.6.22/include/linux/spinlock.h
> ===
> --- linux-2.6.22.orig/include/linux/spinlock.h
> +++ linux-2.6.22/include/linux/spinlock.h
> @@ -126,7 +126,7 @@ extern int __lockfunc generic__raw_read_
> 
>  #ifdef CONFIG_DEBUG_SPINLOCK
>   extern __lockfunc void _raw_spin_lock(raw_spinlock_t *lock);
> -#define _raw_spin_lock_flags(lock, flags) _raw_spin_lock(lock)
> +# define _raw_spin_lock_flags(lock, flags) _raw_spin_lock(lock)

Any reason behind including a space here?

>   extern __lockfunc int _raw_spin_trylock(raw_spinlock_t *lock);
>   extern __lockfunc void _raw_spin_unlock(raw_spinlock_t *lock);
>   extern __lockfunc void _raw_read_lock(raw_rwlock_t *lock);
> @@ -325,7 +325,8 @@ do {  
> \
> 
>  # define _read_trylock(rwl)  rt_read_trylock(rwl)
>  # define _write_trylock(rwl) rt_write_trylock(rwl)
> -#define _write_trylock_irqsave(rwl, flags)  rt_write_trylock_irqsave(rwl, 
> flags)
> +# define _write_trylock_irqsave(rwl, flags) \
> + rt_write_trylock_irqsave(rwl, flags)
> 
>  # define _read_lock(rwl) rt_read_lock(rwl)
>  # define _write_lock(rwl)rt_write_lock(rwl)
> 

-- 
Regards,
Ankita Garg ([EMAIL PROTECTED])
Linux Technology Center
IBM India Systems & Technology Labs, 
Bangalore, India   
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: LinuxPPS & spinlocks

2007-07-29 Thread Satyam Sharma
Hi Rodolfo,


On Sun, 29 Jul 2007, Rodolfo Giometti wrote:

> On Sat, Jul 28, 2007 at 05:11:17AM +0530, Satyam Sharma wrote:
> 
> > Take the race between the time_pps_setparams() syscall and a concurrent
> > pps_event() from an interrupt for instance. From sys_time_pps_setparams,
> > the parameters for an existing source are not modified / set atomically,
> > which means a pps_event() called on the same source in between will see
> > invalid parameters ... and bad things will happen.
> 
> I think this should be a good solution... :)
> 
> diff --git a/drivers/pps/kapi.c b/drivers/pps/kapi.c
> index 08de71d..f0c42ec 100644
> --- a/drivers/pps/kapi.c
> +++ b/drivers/pps/kapi.c
> @@ -29,12 +29,6 @@
>  #include 
>  
>  /*
> - * Local variables
> - */
> -
> -static spinlock_t pps_lock = SPIN_LOCK_UNLOCKED;
> -
> -/*
>   * Local functions
>   */
>  
> diff --git a/drivers/pps/pps.c b/drivers/pps/pps.c
> index 9176c01..91b7e4d 100644
> --- a/drivers/pps/pps.c
> +++ b/drivers/pps/pps.c
> @@ -35,6 +35,7 @@
>  
>  struct pps_s pps_source[PPS_MAX_SOURCES];
>  DEFINE_MUTEX(pps_mutex);
> +spinlock_t pps_lock = SPIN_LOCK_UNLOCKED;
>  
>  /*
>   * Misc functions
> @@ -227,6 +228,8 @@ asmlinkage long sys_time_pps_setparams(int source,
> goto sys_time_pps_setparams_exit;
> }
>  
> +   spin_lock(_lock);
> +
> /* Save the new parameters */
> ret = copy_from_user(_source[source].params, params,
> sizeof(struct pps_kparams));
> @@ -245,6 +248,8 @@ asmlinkage long sys_time_pps_setparams(int source,
> pps_source[source].params.mode |= PPS_CANWAIT;
> pps_source[source].params.api_version = PPS_API_VERS;
>  
> +   spin_unlock(_lock);
> +
>  sys_time_pps_setparams_exit:
> mutex_unlock(_mutex);


Nopes, this isn't quite correct/safe. I suggest you should read:

http://www.kernel.org/pub/linux/kernel/people/rusty/kernel-locking/


Satyam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: LinuxPPS & spinlocks

2007-07-29 Thread Satyam Sharma
Hi,


On Sun, 29 Jul 2007, Rodolfo Giometti wrote:

> On Sat, Jul 28, 2007 at 05:11:17AM +0530, Satyam Sharma wrote:
> 
> > > [ Also, have you considered making pps_source a list and not an array?
> > > It'll help you lose a whole lot of MAX_SOURCES, pps_is_allocated, etc
> > > kind of gymnastics in there, and you _can_ return a pointer to the
> > > corresponding pps source struct from the register() function to the 
> > > in-kernel
> > > users, so that way you get to retain the O(1) access to the corresponding
> > > source when a client calls into pps_event(), similar to how you're using 
> > > the
> > > array index presently. ]
> > 
> > I think the above would be sane and safe -- your driver has pretty simple
> > lifetime rules, and "sources" are only created / destroyed from within 
> > kernel,
> > as and when clients call pps_register_source() and pps_unregister_source().
> > So pps_event() can be called on a given source only between the
> > corresponding register() and unregister() -- which means register() can
> > return us a reference/pointer on the source after allocating / adding it to
> > the list (instead of the fixed array index as it presently is), which 
> > remains
> > valid for the entire duration of the source, till unregister() is called, 
> > after
> > which we can't be calling pps_event() on the same source anyway.
> 
> Ok. I see. I'll study the problem but I think this is can be done
> later, now I think is better having a working code. :)

Fair enough, but I think the code could become a trifle simpler/easier
after the conversion, so probably greater chances of getting merged :-)


> > Ok, I've looked through (most of) the RFC and code now, and am only
> > commenting on a design-level for now. Anyway, I didn't like the way
> > you've significantly drifted from the RFC in several ways:
> > 
> > 1. The RFC mandates no such userspace interface / syscall as the
> > time_pps_cmd() that you've implemented -- it looks, smells, and feels
> > like an ioctl, in fact that's what it is for practical purposes. I'm 
> > confused
> > as to why didn't you just go ahead and implement the special-file-and-
> > file-descriptor based approach as advocated / mandated there.
> 
> This is because is not always true that a PPS source is connected with
> a char (or other) device.

But that's alright -- see, as I said, you're confusing between the
"special device" that represents the *PPS source* itself, with the port
or device that it uses to *physically* connect to the PC.

In the RFC, when they say that the userspace app must open(2) the PPS
source (as they have illustrated in the example too), they mean that
it open(2)'s the special device/file associated with the PPS source,
and *not* the /dev/lpXXX or /dev/ttySXXX that it might be connected
through physically.

So they mean something like /dev/pps0, /dev/pps1 etc instead. Of course,
no such special device exists on a Linux box already, but that's fine
and obvious! *You* are supposed to create / instantiate that when a
pps_register_source() is done from some in-kernel subsystem.


> People whose designed RFC didn't think about
> systems where the PPS signal is connected with a CPU's GPIO and the
> O.S. doesn't provide any char device to refere with!

As I said, it's not the char device for the physical interface itself
being discussed there. That could be parport, uart, some arbit GPIO pin
whatever. But whenever the corresponding kernel subsystem does a
register_source(), you could create the /dev/ppsXXX device ...

> In the common desktop PCs the GPS antenna is connected with the serial
> line and the PPS source is attached to the serial CD, but in the
> embedded systems this is _not_ true. GPS antennae may still be
> connected with serial line but the PPS signal is usually connected
> with a GPIO pin.
> 
> In this scenario you cannot use the serial file descriptor to manage
> the PPS signal since it cannot goes to the serial port.

See above.

> > [ You've implemented the (optional, as per RFC) time_pps_findsource
> > operation in the kernel using the above "pseudo-ioctl", but that wasn't
> > necessary -- as the RFC itself illustrates, it's something that can easily
> > be done (in fact should be done) completely in userspace itself. ]
> 
> I used pseudo-ioctl interface since it allows me to easily extend PPS
> support with special, and uncommon, commands.

Hmm, but that's a non-standard, not-mandated-by-RFC syscall. I don't see
how you can get this merged, really :-)

> > * At the time of pps_register_source()  -- called by an in-kernel client
> > subsystem that creates a PPS source -- allocate a pps source, generate
> > an identifier for it, instantiate a special file -- the RFC does not mention
> > whether a char or block device, but char device (I noticed an example
> > in the RFC where they've used /dev/ppsXX as a possible path) would be
> > proper for this. Finally add it to the list of sources. This returns a
> > reference/pointer on that 

[PATCH] Eliminate warnings in ide-tape.c

2007-07-29 Thread Stephen Rothwell
drivers/ide/ide-tape.c: In function '__idetape_kmalloc_stage':
drivers/ide/ide-tape.c:2588: warning: large integer implicitly truncated to 
unsigned type
drivers/ide/ide-tape.c:2616: warning: large integer implicitly truncated to 
unsigned type

b_size in struct idetape_bh is an unsigned short.  We sometimes assigne
PAGE_SIZE to it and PAGE_SIZE can be 64K or larger, so make it a u32.

Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
---
 drivers/ide/ide-tape.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

-- 
Cheers,
Stephen Rothwell[EMAIL PROTECTED]

diff --git a/drivers/ide/ide-tape.c b/drivers/ide/ide-tape.c
index e82bfa5..1fa5794 100644
--- a/drivers/ide/ide-tape.c
+++ b/drivers/ide/ide-tape.c
@@ -640,7 +640,7 @@ typedef enum {
 } idetape_chrdev_direction_t;
 
 struct idetape_bh {
-   unsigned short b_size;
+   u32 b_size;
atomic_t b_count;
struct idetape_bh *b_reqnext;
char *b_data;
-- 
1.5.2.4

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] Remove fs.h from mm.h

2007-07-29 Thread Bryan Wu
On Mon, 2007-07-30 at 08:08 +0800, Linus Torvalds wrote:
> 
> 
> On Mon, 30 Jul 2007, Alexey Dobriyan wrote: 
> >  
> > Cross-compile tested without regressions on my two usual configs and
> (sigh): 
> >  
> > alpha  arm-mx1adsmips-bigsur
> powerpc-ebony 
> ..
> 
> Heh. 
> 
> Kudos for going above and beyond.
> 
> "But where is blackfin and frv?"
> 
> Thanks,
> 
> Linus 

Hi Alexey,

Can I do something to help this regression testing?

Please feel free to ask me.

Thanks a lot
Best Regards,
- Bryan Wu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [SPARC32] NULL pointer derefference

2007-07-29 Thread David Miller
From: Mark Fortescue <[EMAIL PROTECTED]>
Date: Mon, 30 Jul 2007 03:18:42 +0100 (BST)

> Unfortunatly Sparc32 sun4c low level memory management apears to be 
> incompatible with commit b6a2fea39318e43fee84fa7b0b90d68bed92d2ba
> mm: variable length argument support.
> 
> For some reason, this commit corrupts the memory used by the low level 
> context/pte handling ring buffers in arch/sparc/mm/sun4c (in 
> add_ring_ordered, head->next becomes set to a NULL pointer).
> 
> I had a quick look at http://www.linux-mm.org to see if there were any 
> diagrams that show what is going on in the memory management systems, to 
> see if there was something that I could use to help me work out what is 
> going on, but I could not see any.

One possible issue is sequencing, perhaps the stack argument copy
is occuring before the new context is setup properly on sun4c.

Another issue might be the new flush_cache_page() call in this
new code in fs/exec.c, there are now cases where flush_cache_page()
will be called on kernel addresses, and sun4c's implementation might
not like that at all.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: LinuxPPS & spinlocks

2007-07-29 Thread Satyam Sharma
Hi Rodolfo,


On Sun, 29 Jul 2007, Rodolfo Giometti wrote:

> On Sat, Jul 28, 2007 at 02:17:24AM +0530, Satyam Sharma wrote:
> > 
> > I only glanced through the code, so could be wrong, but I noticed that
> > the only global / shared data you have in there is a global "pps_source"
> > array of pps_s structs. That's accessed / modified from the various
> > syscalls introduced in the API exported to userspace, as well as the
> > register/unregister/pps_event API exported to in-kernel client subsystems,
> > yes? So it looks like you need to introduce proper locking for it, simply
> > type-qualifying it as "volatile" is not enough.
> > 
> > However, I think you've introduced two locks for it. The syscalls (that
> > run in process context, obviously) seem to use a pps_mutex and
> > pps_event() seems to be using the pps_lock spinlock (because that
> > gets executed from interrupt context) -- and from the looks of it, the
> > register/unregister functions are using /both/ the mutex and spinlock (!)
> 
> This is right.
> 
> > This isn't quite right, (in fact there's nothing to protect pps_event from
> > racing against a syscall), so you should use *only* the spinlock for
> > synchronization -- the spin_lock_irqsave/restore() variants, in fact.
> 
> We can't use the spin_lock_irqsave/restore() variants since PPS
> sources cannot manage IRQ enable/disable. For instance, the serial
> source doesn't manage IRQs directly but just uses it to record PPS
> events. The serial driver manages the IRQ enable/disable, not the PPS
> source which only uses the IRQ handler to records events.

Hmm? I still don't see why you can't introduce spin_lock_irqsave/restore()
in pps_event() around the access to pps_source.


> About using both mutex and spinlock I did it since (I think) I should
> protect syscalls from each others and from pps_register/unregister(),
> and pps_event() against pps_register/unregister().

Nopes, it's not about protecting code from each other, you're needlessly
complicating things. Locking is pretty simple, really -- any shared data,
that can be concurrently accessed by multiple threads (or from interrupts)
must be protected with a lock. Note that *data* is protected by a lock,
and not "code" that handles it (well, this is the kind of behaviour most
cases need, at least, including yours).

So here we're introducing the lock to protect *pps_source*, and not keep
*threads* of execution from stepping over each other. So, simply, just
ensure you grab the lock whenever you want to start accessing the shared
data, and release it when you're done.

The _irqsave/restore() variants are required because (say) one of the
syscalls executing in process context grabs the spinlock. Then, before it
has released it, it gets interrupted and pps_event() begins executing.
Now pps_event() also wants to grab the lock, but the syscall already
has it, so will continue spinning and deadlock!


> > [ Also, have you considered making pps_source a list and not an array?
> > It'll help you lose a whole lot of MAX_SOURCES, pps_is_allocated, etc
> > kind of gymnastics in there, and you _can_ return a pointer to the
> > corresponding pps source struct from the register() function to the 
> > in-kernel
> > users, so that way you get to retain the O(1) access to the corresponding
> > source when a client calls into pps_event(), similar to how you're using the
> > array index presently. ]
> > 
> > I also noticed code like (from pps_event):
> > 
> > +   /* Try to grab the lock, if not we prefere loose the event... */
> > +   if (!spin_trylock(_lock))
> > +   return;
> > 
> > which looks worrisome and unnecessary. That spinlock looks to be of
> > fine enough granularity to me, do you think there'd be any contention
> > on it? I /think/ you can simply make that a spin_lock().
> 
> This is due the fact I cannot manage IRQ enable/disable.

What I meant is that you could make it a proper spin_lock() --
or spin_lock_irqsave(), actually -- instead of the _trylock_ variant
that it currently is.

I think you're unnecessarily worrying about contention here -- you can
have multiple locks (one for the list, and separate ones for your sources)
if you're really worrying about contention -- or probably rwlocks. But
really, rwlocks would end up being *slower* than spinlocks, unless the
contention is really heavy and it helps to keep multiple readers in the
critical section. But frankly, with at max a few (I'd expect generally
one) PPS sources ever to be connected / registered with teh system, and
just one-pulse-per-second, I don't see why any contention is ever gonna
happen.


Satyam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 01/10] Task Containers(V11): Basic task container framework

2007-07-29 Thread YAMAMOTO Takashi
> +extern void container_init_smp(void);

> +static inline void container_init_smp(void) {}

stale prototypes?

YAMAMOTO Takashi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 5/5] Use mutex instead of semaphore in the DVB frontend tuning interface

2007-07-29 Thread Satyam Sharma


On Sun, 29 Jul 2007, Matthias Kaehlcke wrote:

> The DVB frontend tuning interface uses a semaphore as mutex. Use the
> mutex API instead of the (binary) semaphore.
> 
> Signed-off-by: Matthias Kaehlcke <[EMAIL PROTECTED]>

Reviewed-by: Satyam Sharma <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 4/5] Use mutex instead of semaphore in ISDN subsystem common functions

2007-07-29 Thread Satyam Sharma


On Sun, 29 Jul 2007, Matthias Kaehlcke wrote:

> The ISDN subsystem common functions use a semaphore as mutex. Use the
> mutex API instead of the (binary) semaphore.
> 
> Signed-off-by: Matthias Kaehlcke <[EMAIL PROTECTED]>

Reviewed-by: Satyam Sharma <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 1/5] Use mutex instead of semaphore in the Host AP driver

2007-07-29 Thread Satyam Sharma
Whoops ...


On Mon, 30 Jul 2007, Satyam Sharma wrote:

> On Mon, 30 Jul 2007, Michael Buesch wrote:
> 
> > On Sunday 29 July 2007 23:34, Matthias Kaehlcke wrote:
> > > The Host AP driver uses a semaphore as mutex. Use the mutex API
> > > instead of the (binary) semaphore.
> > > 
> > > Signed-off-by: Matthias Kaehlcke <[EMAIL PROTECTED]>
> 
> [ Something seems to have gone wrong with your diff / patch / script.
>   There was no diff header here, which should have been. ]
> 
> > > - res = down_interruptible(>rid_bap_sem);
> > > + res = mutex_lock_interruptible(>rid_bap_mtx);
> > >   if (res)
> > >   return res;
> > >  
> > > @@ -902,7 +902,7 @@ static int hfa384x_set_rid(struct net_device *dev, 
> > > u16 rid, void *buf, int len)
> > >   /* RID len in words and +1 for rec.rid */
> > >   rec.len = cpu_to_le16(len / 2 + len % 2 + 1);
> > >  
> > > - res = down_interruptible(>rid_bap_sem);
> > > + res = mutex_lock_interruptible(>rid_bap_mtx);
> > >   if (res)
> > >   return res;
> > >  
> > 
> > Is res returned to userspace? If yes, that's not right.
> 
> Yup, that's not right.
> 
> > On a interrupted mutex allocation you should return
> > -ERESTARTSYS to userspace.
> 
> Nope, userspace must not see ERESTARTSYS (I /think/ this is the third
> time I'm participating in this exact same discussion :-)
> 
> If the return would be caught by a previous in-kernel caller in the
> call chain, ERESTARTSYS is okay and it could try to restart the
> operation. However, if the return goes unfiltered directly to
> userspace, EINTR is the correct choice.

Eek, and because mutex_lock_interruptible() *does* return -EINTR when
interrupted by a signal, and I noticed that hfa384x_set_rid() could be
called from an ioctl(2) codepath with no intermediate caller trying to
restart it, so the code is perfectly alright, actually.

But the patch doesn't have the diff header anyway, so Matthias would
probably have to resend in any case :-)


Satyam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


v2.6.23-rc1-rt6-dw1

2007-07-29 Thread Daniel Walker

I've released another version of the real-time tree. It's just a
slightly more bisectable tree, and it includes the fixes I've just
released.

You can download a combined patch from, 

ftp://source.mvista.com/pub/dwalker/rt/patch-2.6.23-rc1-rt6-dw1

Or a broken out set from,

ftp://source.mvista.com/pub/dwalker/rt/patch-2.6.23-rc1-rt6-dw1.tar.gz

Below I've included a per patch delta (as good as interdiff can make).
In the hopes that it will help integration. The changes are additions to
preempt-realtime-sched.patch which are extracted from patches later in
the series. This allow preempt-realtime-sched.patch to compile
standalone .. There was also a stray hunk in the version.patch which I
moved to another location. 

:: start series ::
--- tmp/patches/series  2007-07-26 14:47:21.0 -0700
+++ patches/series  2007-07-29 19:48:07.0 -0700
@@ -670,3 +670,12 @@
 schedule_on_each_cpu-enhance.patch
 schedule_on_each_cpu-enhance-rt.patch
 version.patch
+add-warn-on-rcu-read-unlock-imbalance.patch
+preempt-hardirqs-selects-preempt-softirqs.patch
+initialize-last_tick-in-calc_load.patch
+softirq-raise-wakeup-fix.patch
+preempt-realtime-net-mismerge.patch
+locking-cleanup.patch
+pickop-rt_lock_h.patch
+pickop-spinlock-rwlocks.patch
+pickop-seqlocks.patch
:: end series ::
:: start preempt-realtime-i386.patch ::
--- linux-2.6.22.orig/include/linux/smp.h   2007-07-27 00:20:49.0 
+
+++ linux-2.6.22/include/linux/smp.h2007-07-27 00:20:50.0 +
@@ -33,6 +33,16 @@ extern void smp_send_stop(void);
  */
 extern void smp_send_reschedule(int cpu);
 
+/*
+ * trigger a reschedule on all other CPUs:
+ */
+extern void smp_send_reschedule_allbutself(void);
+
+/*
+ * trigger a reschedule on all other CPUs:
+ */
+extern void smp_send_reschedule_allbutself(void);
+
 
 /*
  * Prepare machine for booting other CPUs.
@@ -97,6 +107,7 @@ static inline int up_smp_call_function(v
0;  \
})
 static inline void smp_send_reschedule(int cpu) { }
+static inline void smp_send_reschedule_allbutself(void) { }
 #define num_booting_cpus() 1
 #define smp_prepare_boot_cpu() do {} while (0)
 #define smp_call_function_single(cpuid, func, info, retry, wait) \
:: end preempt-realtime-i386.patch ::
:: start preempt-realtime-sched.patch ::
--- linux-2.6.22.orig/include/linux/kernel.h
+++ linux-2.6.22/include/linux/kernel.h
@@ -88,7 +88,7 @@ extern int cond_resched(void);
 # define might_resched() do { } while (0)
 #endif
 
-#ifdef CONFIG_DEBUG_SPINLOCK_SLEEP
+#if defined(CONFIG_DEBUG_SPINLOCK_SLEEP) || defined(CONFIG_DEBUG_PREEMPT)
   void __might_sleep(char *file, int line);
 # define might_sleep() \
do { __might_sleep(__FILE__, __LINE__); might_resched(); } while (0)
@@ -198,6 +198,7 @@ extern void add_taint(unsigned);
 /* Values used for system_state */
 extern enum system_states {
SYSTEM_BOOTING,
+   SYSTEM_BOOTING_SCHEDULER_OK,
SYSTEM_RUNNING,
SYSTEM_HALT,
SYSTEM_POWER_OFF,
--- linux-2.6.22.orig/init/main.c
+++ linux-2.6.22/init/main.c
@@ -438,6 +438,8 @@ static void noinline __init_refok rest_i
 {
int pid;
 
+   system_state = SYSTEM_BOOTING_SCHEDULER_OK;
+
kernel_thread(kernel_init, NULL, CLONE_FS | CLONE_SIGHAND);
numa_default_policy();
pid = kernel_thread(kthreadd, NULL, CLONE_FS | CLONE_FILES);
--- linux-2.6.22.orig/lib/kernel_lock.c
+++ linux-2.6.22/lib/kernel_lock.c
@@ -35,22 +35,25 @@ DECLARE_MUTEX(kernel_sem);
  * about recursion, both due to the down() and due to the enabling of
  * preemption. schedule() will re-check the preemption flag after
  * reacquiring the semaphore.
+ *
+ * Called with interrupts disabled.
  */
 int __lockfunc __reacquire_kernel_lock(void)
 {
struct task_struct *task = current;
int saved_lock_depth = task->lock_depth;
 
+   local_irq_enable();
BUG_ON(saved_lock_depth < 0);
 
task->lock_depth = -1;
-   __preempt_enable_no_resched();
 
down(_sem);
 
-   preempt_disable();
task->lock_depth = saved_lock_depth;
 
+   local_irq_disable();
+
return 0;
 }
 
@@ -67,11 +70,15 @@ void __lockfunc lock_kernel(void)
struct task_struct *task = current;
int depth = task->lock_depth + 1;
 
-   if (likely(!depth))
+   if (likely(!depth)) {
/*
 * No recursion worries - we set up lock_depth _after_
 */
down(_sem);
+#ifdef CONFIG_DEBUG_RT_MUTEXES
+   current->last_kernel_lock = __builtin_return_address(0);
+#endif
+   }
 
task->lock_depth = depth;
 }
@@ -82,8 +89,12 @@ void __lockfunc unlock_kernel(void)
 
BUG_ON(task->lock_depth < 0);
 
-   if (likely(--task->lock_depth < 0))
+   if (likely(--task->lock_depth == -1)) {
+#ifdef CONFIG_DEBUG_RT_MUTEXES
+   current->last_kernel_lock = NULL;
+#endif

Re: sk98lin for 2.6.23-rc1

2007-07-29 Thread Rob Sims
On Thu, Jul 26, 2007 at 06:57:01PM +0200, Adrian Bunk wrote:
> On Thu, Jul 26, 2007 at 11:16:36AM -0400, Kyle Rose wrote:
> > >From http://www.krose.org/~krose/computing.html:
> > 
> > Since the sky2 driver continues to suck ass (which is a technical
> > description for "it hangs all the time under load, at least on my
> > hardware" :-) ), I've fixed the sk98lin driver to compile for
> > linux-2.6.23-rc1. Those who continue to have problems with sky2 can
> > still use 2.6.23-rc1, simply by doing the following:
> >...
> > Personally, I'd like to see sk98lin remain in the kernel proper until
> > sky2 goes at least 6 months without reported problems.  The fact that I
> > am not the only one still seeing issues is a clear indication that sky2
> > (even with the recent patches in 2.6.23-rc1) is not yet ready to replace
> > sk98lin.
> >...
> 
> This sounds good in theory.
> 
> The practical problem with this approach is that there are always many 
> people who use the old driver when the new driver doesn't work for them 
> instead of reporting their problems with the new driver.
> 
> For these people a new driver will often suck when the old driver gets 
> removed, but after the removal of the old driver they are finally forced 
> to report their bugs resulting in a better new driver for everyone.
> 
> The sky2 driver is since nearly 2 years in the kernel and Stephen is 
> usually quite good at handling bugs.

The driver still (2.6.20/sky2 1.13) hangs for me (more rarely than in
the past), and cycling the module generally fixes the issues.  I have
supplied all the information that Stephen has asked for, but still no
resolution.  I am not complaining about the lack of a fix, but don't
assume that all it takes to get sky2 working is adequate bug reports.  I
have been and remain willing to test and assist debug, but after several
dropped threads, I feel like the desire or ability to fix this issue
isn't there (and remote debug of an intermittent hardware issue IS
hard), and I didn't want to be a nuisance to someone that has no
obligation to me to address the issue in the first place.

Stability has improved, it's just not there yet.

I'll switch to 1.16 soon, and respond to Stephen's request on netdev for
current issues.
-- 
Rob


signature.asc
Description: Digital signature


Re: [PATCH 3/5] Use mutex instead of semaphore in the SCSI Tape driver

2007-07-29 Thread Satyam Sharma


On Sun, 29 Jul 2007, Matthias Kaehlcke wrote:

> The SCSI Tape driver uses a semaphore as mutex. Use the mutex API
> instead of the (binary) semaphore.
> 
> Signed-off-by: Matthias Kaehlcke <[EMAIL PROTECTED]>

Reviewed-by: Satyam Sharma <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [patch][rfc] 2.6.23-rc1 mm: NUMA replicated pagecache

2007-07-29 Thread Nick Piggin
On Fri, Jul 27, 2007 at 10:30:47AM -0400, Lee Schermerhorn wrote:
> On Fri, 2007-07-27 at 10:42 +0200, Nick Piggin wrote:
> > Hi,
> > 
> > Just got a bit of time to take another look at the replicated pagecache
> > patch. The nopage vs invalidate race and clear_page_dirty_for_io fixes
> > gives me more confidence in the locking now; the new ->fault API makes
> > MAP_SHARED write faults much more efficient; and a few bugs were found
> > and fixed.
> > 
> > More stats were added: *repl* in /proc/vmstat. Survives some kbuilding
> > tests...
> > 
> > --
> > 
> > Page-based NUMA pagecache replication.
> 
> 
> Hi, Nick.
> 
> Glad to see you're back on this.  It's been on my list, but delayed by
> other patch streams...

Yeah, thought I should keep it alive :) Patch is against 2.6.23-rc1.

 
> As I mentioned to you in prior mail, I want to try to integrate this
> atop my "auto/lazy migration" patches, such that when a task moves to a
> new node, we remove just that task's pte ref's to page cache pages
> [along with all refs to anon pages, as I do now] so that the task will
> take a fault on next touch and either use an existing local copy or
> replicate the page at that time.  Unfortunately, that's in the queue
> behind the memoryless node patches and my stalled shared policy patches,
> among other things :-(.

That's OK. It will likely be a long process to get any of this in...
As you know, replicated currently needs some of your automigration
infrastructure in order to get ptes pointing to the right places
after a task migration. I'd like to try some experiments with them on
a larger system, once you get time to update your patchset...

Thanks,
Nick
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[2.6.22] negative time jump

2007-07-29 Thread Vasily Averin
I've investigated why my testnode freezes. When I found that node is freezed
again I've started to press Sysrq keys and noticed the following negative time 
jump.

Could anybody please help me to understand the reasons of this issue?

--- VvS comment: some pre-history: node boot
Jul 27 13:58:10 ts28 Linux version 2.6.22 ([EMAIL PROTECTED]) (gcc version 3.4.6
20060404 (Red Hat 3.4.6-3)) #11 SMP Fri Jul 27 12:47:45 MSD 2007
Jul 27 13:58:10 ts28 Command line: ro root=LABEL=/1 console=ttyS0,115200
console=tty debug silencelevel=8 [EMAIL PROTECTED] acpc=noirq clocksource=tsc

[EMAIL PROTECTED] ~]# echo q > /proc/sysrq-trigger
Jul 27 14:09:34 ts28 now at 685327961777 nsecs

--- VvS comment: AIM7 test hangs at friday ~Jul 27 20:27:06 2007
48  135.33   98 2.8193   2149.48167.67   Fri Jul 27 17:42:10 2007
54  127.76   99 2.3660   2561.30190.97   Fri Jul 27 18:24:51 2007
67  117.00   99 1.7463   3470.13237.20   Fri Jul 27 19:22:41 2007
72  112.89   99 1.5679   3864.93248.71   Fri Jul 27 20:27:06 2007
82


---VvS comment: what I do monday morning:
[EMAIL PROTECTED] ~]# echo q > /proc/sysrq-trigger
Jul 30 06:15:37 ts28 SysRq : Show Pending Timers
Jul 30 06:15:37 ts28 Timer List Version: v0.3
Jul 30 06:15:37 ts28 HRTIMER_MAX_CLOCK_BASES: 2
Jul 30 06:15:37 ts28 now at 29111288132045 nsecs
--- VvS comment: I would note: 29111 sec is very strange value for node with 3
day uptime...

[EMAIL PROTECTED] ~]# echo q > /proc/sysrq-trigger
Jul 30 06:16:21 ts28 now at 29155644785562 nsecs

[EMAIL PROTECTED] ~]# echo 1 > /proc/timer_stats
[EMAIL PROTECTED] ~]# cat /proc/timer_stats
Timer Stats Version: v0.1
Sample period: 17.992 s
0 total events
[EMAIL PROTECTED] ~]# cat /proc/timer_stats
Timer Stats Version: v0.1
Sample period: -4366.278 s
0 total events
[EMAIL PROTECTED] ~]# cat /proc/timer_stats
Timer Stats Version: v0.1
Sample period: -4359.840 s
0 total events
[EMAIL PROTECTED] ~]# cat /proc/timer_stats
Timer Stats Version: v0.1
Sample period: -4347.397 s
0 total events
[EMAIL PROTECTED] ~]# cat /proc/timer_stats
Timer Stats Version: v0.1
Sample period: -4331.652 s
0 total events
[EMAIL PROTECTED] ~]# cat /proc/timer_stats
Timer Stats Version: v0.1
Sample period: -4297.293 s
0 total events
[EMAIL PROTECTED] ~]# echo q > /proc/sysrq-trigger
Jul 30 06:19:07 ts28 now at 24922828615221 nsecs

[EMAIL PROTECTED] ~]# echo q > /proc/sysrq-trigger
Jul 30 06:22:07 ts28 now at 25103332336122 nsecs

[EMAIL PROTECTED] ~]# cat /proc/timer_stats
Timer Stats Version: v0.1
Sample period: -4065.515 s
0 total events
[EMAIL PROTECTED] ~]# cat /proc/timer_stats
Timer Stats Version: v0.1
Sample period: -3913.800 s
0 total events
[EMAIL PROTECTED] ~]# echo q > /proc/sysrq-trigger
Jul 30 06:25:47 ts28 now at 25322820465391 nsecs

Full serial console logs are attached, The other hardware details can be found
in http://bugzilla.kernel.org/show_bug.cgi?id=8650

Thank you,
Vasily Averin
Jul 27 13:58:10 ts28 Linux version 2.6.22 ([EMAIL PROTECTED]) (gcc version 3.4.6 20060404 (Red Hat 3.4.6-3)) #11 SMP Fri Jul 27 12:47:45 MSD 2007
Jul 27 13:58:10 ts28 Command line: ro root=LABEL=/1 console=ttyS0,115200 console=tty debug silencelevel=8 [EMAIL PROTECTED] acpc=noirq clocksource=tsc
Jul 27 13:58:10 ts28 BIOS-provided physical RAM map:
Jul 27 13:58:10 ts28  BIOS-e820:  - 0009d800 (usable)
Jul 27 13:58:10 ts28  BIOS-e820: 0009d800 - 000a (reserved)
Jul 27 13:58:10 ts28  BIOS-e820: 000f - 0010 (reserved)
Jul 27 13:58:10 ts28  BIOS-e820: 0010 - dfee (usable)
Jul 27 13:58:10 ts28  BIOS-e820: dfee - dfee3000 (ACPI NVS)
Jul 27 13:58:10 ts28  BIOS-e820: dfee3000 - dfef (ACPI data)
Jul 27 13:58:10 ts28 
Jul 27 13:58:10 ts28  BIOS-e820: dfef - dff0 (reserved)
Jul 27 13:58:10 ts28  BIOS-e820: fec0 - 0001 (reserved)
Jul 27 13:58:10 ts28 Entering add_active_range(0, 0, 157) 0 entries of 3200 used
Jul 27 13:58:10 ts28 Entering add_active_range(0, 256, 917216) 1 entries of 3200 used
Jul 27 13:58:10 ts28 end_pfn_map = 1048576
Jul 27 13:58:10 ts28 DMI 2.3 present.
Jul 27 13:58:10 ts28 ACPI: RSDP 000F6980, 0014 (r0 VIAK8 )
Jul 27 13:58:10 ts28 
Jul 27 13:58:10 ts28 ACPI: RSDT DFEE3000, 002C (r1 VIAK8  AWRDACPI 42302E31 AWRD0)
Jul 27 13:58:10 ts28 ACPI: FACP DFEE3040, 0074 (r1 VIAK8  AWRDACPI 42302E31 AWRD0)
Jul 27 13:58:10 ts28 ACPI: DSDT DFEE30C0, 4A4C (r1 VIAK8  AWRDACPI 1000 MSFT  10E)
Jul 27 13:58:10 ts28 ACPI: FACS DFEE, 0040
Jul 27 13:58:10 ts28 ACPI: APIC DFEE7B40, 0068 (r1 VIAK8  AWRDACPI 42302E31 AWRD0)
Jul 27 13:58:10 ts28 Scanning NUMA topology in Northbridge 24
Jul 27 13:58:10 ts28 Number of nodes 2
Jul 27 13:58:10 ts28 Node 0 MemBase  Limit dfee
Jul 27 13:58:10 ts28 Entering add_active_range(0, 0, 157) 0 entries of 3200 used
Jul 27 13:58:10 ts28 Entering 

Re: [PATCH 2/5] Use mutex instead of semaphore in the OnStream SCSI Tape driver

2007-07-29 Thread Satyam Sharma
Hi,


On Sun, 29 Jul 2007, Matthias Kaehlcke wrote:

> The OnStream SCSI Tape driver uses a semaphore as mutex. Use the mutex
> API instead of the (binary) semaphore.
> 
> Signed-off-by: Matthias Kaehlcke <[EMAIL PROTECTED]>
> [...]
> @@ -3298,7 +3298,7 @@ static ssize_t osst_write(struct file * filp, const 
> char __user * buf, size_t co
>   char* name = tape_name(STp);
>  
>  
> - if (down_interruptible(>lock))
> + if (mutex_lock_interruptible(>lock))
>   return (-ERESTARTSYS);

The () after return existed in the code already, but you could've felt
free to remove them :-)

> @@ -3619,7 +3619,7 @@ static ssize_t osst_read(struct file * filp, char 
> __user * buf, size_t count, lo
>   char* name  = tape_name(STp);
>  
>  
> - if (down_interruptible(>lock))
> + if (mutex_lock_interruptible(>lock))
>   return (-ERESTARTSYS);

Same here.

Reviewed-by: Satyam Sharma <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 1/5] Use mutex instead of semaphore in the Host AP driver

2007-07-29 Thread Satyam Sharma


On Mon, 30 Jul 2007, Michael Buesch wrote:

> On Sunday 29 July 2007 23:34, Matthias Kaehlcke wrote:
> > The Host AP driver uses a semaphore as mutex. Use the mutex API
> > instead of the (binary) semaphore.
> > 
> > Signed-off-by: Matthias Kaehlcke <[EMAIL PROTECTED]>

[ Something seems to have gone wrong with your diff / patch / script.
  There was no diff header here, which should have been. ]

> > -   res = down_interruptible(>rid_bap_sem);
> > +   res = mutex_lock_interruptible(>rid_bap_mtx);
> > if (res)
> > return res;
> >  
> > @@ -902,7 +902,7 @@ static int hfa384x_set_rid(struct net_device *dev, u16 
> > rid, void *buf, int len)
> > /* RID len in words and +1 for rec.rid */
> > rec.len = cpu_to_le16(len / 2 + len % 2 + 1);
> >  
> > -   res = down_interruptible(>rid_bap_sem);
> > +   res = mutex_lock_interruptible(>rid_bap_mtx);
> > if (res)
> > return res;
> >  
> 
> Is res returned to userspace? If yes, that's not right.

Yup, that's not right.

> On a interrupted mutex allocation you should return
> -ERESTARTSYS to userspace.

Nope, userspace must not see ERESTARTSYS (I /think/ this is the third
time I'm participating in this exact same discussion :-)

If the return would be caught by a previous in-kernel caller in the
call chain, ERESTARTSYS is okay and it could try to restart the
operation. However, if the return goes unfiltered directly to
userspace, EINTR is the correct choice.


Satyam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [linux-usb-devel] usb-storage autosuspend bug?

2007-07-29 Thread Linus Torvalds


On Fri, 27 Jul 2007, Alan Stern wrote:
> 
> I don't think it's a refcounting problem.  My guess is that the 
> underlying cause is the bug in your urb->status removal patch for 
> usb_start_wait_urb() -- the one I fixed here:
> 
> http://marc.info/?l=linux-usb-devel=118531582013355=2
> 
> Of course, my guess could be wrong.  I haven't tried to recreate 
> Linus's bug with that patch reverted.  But with the patch present I was 
> not able to duplicate the bug.

I finally got around to testing this, and while I still have problems with 
that reader, I can't reproduce the oops with that patch in place either.

Of course, I only ever saw the oops once, so I really don't know how 
reproducible it was. Maybe you have to remove the USB reader at _just_ the 
right moment. But I did get

...
usb 2-6: reset high speed USB device using ehci_hcd and address 4
usb 2-6: USB disconnect, address 4
sd 6:0:0:1: [sdc] Result: hostbyte=0x07 driverbyte=0x00
end_request: I/O error, dev sdc, sector 1999855
...
scsi 6:0:0:1: rejecting I/O to dead device

so the testing was done with the kind of behaviour that resulted in an 
oops and a dead khubd last time around.

So I guess I'll ack the patch for whatever that is worth.

Over to you, Greg..

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH][resend] Fix a typo in Documentation/keys.txt

2007-07-29 Thread Satyam Sharma
[PATCH] Fix a typo in Documentation/keys.txt

Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
Acked-by: David Howells <[EMAIL PROTECTED]>

---

[ Previously sent on: June 9, 2007 ]

 Documentation/keys.txt |5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff -ruNp a/Documentation/keys.txt b/Documentation/keys.txt
--- a/Documentation/keys.txt2007-06-03 02:33:02.0 +0530
+++ b/Documentation/keys.txt2007-06-03 02:38:52.0 +0530
@@ -859,9 +859,8 @@ payload contents" for more information.
void unregister_key_type(struct key_type *type);
 
 
-Under some circumstances, it may be desirable to desirable to deal with a
-bundle of keys.  The facility provides access to the keyring type for managing
-such a bundle:
+Under some circumstances, it may be desirable to deal with a bundle of keys.
+The facility provides access to the keyring type for managing such a bundle:
 
struct key_type key_type_keyring;
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 2/2] Introduce CONFIG_SUSPEND

2007-07-29 Thread Kyle Moffett

On Jul 29, 2007, at 17:30:40, Richard Hughes wrote:

So are you guys using:

"standby" = idle state, ~0.5 seconds
"suspend" = sleep to ram, ~10 seconds
"hibernate" = sleep to disk, ~30 seconds

If so - you rock. This is the common nomenclature I've been pushing  
for
a few months now in GNOME, KDE and general userspace. I've written  
up a

spec here:
http://cvs.gnome.org/viewcvs/*checkout*/gnome-power-manager/docs/ 
sleep-names.html


Well, those times don't quite work for my PowerBook.  If we fixed  
suspend-to-RAM to reinitialize devices in parallel then it would  
easily hit 0.5 second transition times, but even now it's only at  
most 2 seconds.  Also once in a while I'll be too hasty plugging my  
USB devices and manage to hardlock one of the USB busses, but that's  
an isolated USB driver suspend issue.


And it's certainly not called "standby", because the box can  
literally remain asleep for 7 days on a full charge, versus about 5  
hours when just idle with wireless, backlight, and HDD off.


Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Update: ide problems: 2.6.22-git17 working, 2.6.23-rc1* is not:

2007-07-29 Thread Danny ter Haar
Quoting Gabriel C ([EMAIL PROTECTED]):
> Now while we think is ACPI this should be easy for you to bisect.
> This commit 
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=39804b20f62532fa05c2a8c3e2d1ae551fd0327b
> merged ACPI so this one should be your first bad one.
> Maybe Len has some idea and you don't need to bisect :)

Thanks to personal coaching of Gabriel i bisected the last few days.

It looked like this was the cullprit:

22aadf8a07067644e101267ed5003043f2ad05bf is first bad commit

2.6.23-rc1-git[1-6] all lockup solid after either direct or
within a couple of minutes (less than 2) after reboot.

They all run fine with "acpi=off" as boot argument.


However, i'm currently running 2.6.23-rc1-git6 with this reverted:

diff --git a/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c 
b/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
index 18c8b67..6f846be 100644 (file)
--- a/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
+++ b/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
@@ -665,8 +665,8 @@ static int acpi_cpufreq_cpu_init(struct cpufreq_policy 
*policy)
data->max_freq = perf->states[0].core_frequency * 1000;
/* table init */
for (i=0; istate_count; i++) {
-   if (i>0 && perf->states[i].core_frequency ==
-   perf->states[i-1].core_frequency)
+   if (i>0 && perf->states[i].core_frequency >=
+   data->freq_table[valid_states-1].frequency / 1000)
continue;

---

I could hardly believe this could be the cause.
And indeed after about 16 minutes the kernel froze again, though longer
uptime than other kernels :-(

This hardware is a via epia 5000 with latest bios available (2.07)

It's remarkable that with acpi=off the machine is rocksolid.
As is with 2.6.22* kernels _with_ acpi enabled!
weeks of uptime before i wanted to upgrade to a new kernel ;-)

I'm thinking of redoing the git disect but this time really powercycle
the unit between kernels since it "seems/feels" like a timer which 
really counts to 0 and then locks the machine. 
After a lockup/freeze i cant boot the kernel another time with acpi 
enabled: it will simply hang after booting init.
And again nobody home: no keyboard activity whatsoever.

I've put the dmesg of 2.6.23-rc1-git6 with and without acpi=off online:
http://www.dth.net/kernel/via_output_2.6.23-rc1-git6-acpi_off
http://www.dth.net/kernel/via_output_2.6.23-rc1-git6-acpi_on

I would like to hear if someone has an idea how to tackle this problem.

Danny
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH -rt 8/9] spinlocks/rwlocks: use PICK_FUNCTION()

2007-07-29 Thread Daniel Walker
Reaplace old PICK_OP style macros with the new PICK_FUNCTION macro.

Signed-off-by: Daniel Walker <[EMAIL PROTECTED]>

---
 include/linux/sched.h|   13 -
 include/linux/spinlock.h |  345 ++-
 kernel/rtmutex.c |2 
 lib/dec_and_lock.c   |2 
 4 files changed, 111 insertions(+), 251 deletions(-)

Index: linux-2.6.22/include/linux/sched.h
===
--- linux-2.6.22.orig/include/linux/sched.h
+++ linux-2.6.22/include/linux/sched.h
@@ -1997,17 +1997,8 @@ extern int __cond_resched_raw_spinlock(r
 extern int __cond_resched_spinlock(spinlock_t *spinlock);
 
 #define cond_resched_lock(lock) \
-({ \
-   int __ret;  \
-   \
-   if (TYPE_EQUAL((lock), raw_spinlock_t)) \
-   __ret = __cond_resched_raw_spinlock((raw_spinlock_t *)lock);\
-   else if (TYPE_EQUAL(lock, spinlock_t))  \
-   __ret = __cond_resched_spinlock((spinlock_t *)lock); \
-   else __ret = __bad_spinlock_type(); \
-   \
-   __ret;  \
-})
+   PICK_SPIN_OP_RET(__cond_resched_raw_spinlock, __cond_resched_spinlock,\
+lock)
 
 extern int cond_resched_softirq(void);
 extern int cond_resched_softirq_context(void);
Index: linux-2.6.22/include/linux/spinlock.h
===
--- linux-2.6.22.orig/include/linux/spinlock.h
+++ linux-2.6.22/include/linux/spinlock.h
@@ -91,6 +91,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -162,7 +163,7 @@ extern void __lockfunc rt_spin_unlock_wa
 extern int __lockfunc
 rt_spin_trylock_irqsave(spinlock_t *lock, unsigned long *flags);
 extern int __lockfunc rt_spin_trylock(spinlock_t *lock);
-extern int _atomic_dec_and_spin_lock(atomic_t *atomic, spinlock_t *lock);
+extern int _atomic_dec_and_spin_lock(spinlock_t *lock, atomic_t *atomic);
 
 /*
  * lockdep-less calls, for derived types like rwlock:
@@ -243,54 +244,6 @@ do {   
\
 #  define _spin_trylock_irqsave(l,f)   TSNBCONRT(l)
 #endif
 
-#undef TYPE_EQUAL
-#define TYPE_EQUAL(lock, type) \
-   __builtin_types_compatible_p(typeof(lock), type *)
-
-#define PICK_OP(op, lock)  \
-do {   \
-   if (TYPE_EQUAL((lock), raw_spinlock_t)) \
-   __spin##op((raw_spinlock_t *)(lock));   \
-   else if (TYPE_EQUAL(lock, spinlock_t))  \
-   _spin##op((spinlock_t *)(lock));\
-   else __bad_spinlock_type(); \
-} while (0)
-
-#define PICK_OP_RET(op, lock...)   \
-({ \
-   unsigned long __ret;\
-   \
-   if (TYPE_EQUAL((lock), raw_spinlock_t)) \
-   __ret = __spin##op((raw_spinlock_t *)(lock));   \
-   else if (TYPE_EQUAL(lock, spinlock_t))  \
-   __ret = _spin##op((spinlock_t *)(lock));\
-   else __ret = __bad_spinlock_type(); \
-   \
-   __ret;  \
-})
-
-#define PICK_OP2(op, lock, flags)  \
-do {   \
-   if (TYPE_EQUAL((lock), raw_spinlock_t)) \
-   __spin##op((raw_spinlock_t *)(lock), flags);\
-   else if (TYPE_EQUAL(lock, spinlock_t))  \
-   _spin##op((spinlock_t *)(lock), flags); \
-   else __bad_spinlock_type(); \
-} while (0)
-
-#define PICK_OP2_RET(op, lock, flags)  \
-({ \
-   unsigned long __ret;\
-   \
-   if (TYPE_EQUAL((lock), raw_spinlock_t)) \
-   __ret = __spin##op((raw_spinlock_t *)(lock), flags);\
-   else if (TYPE_EQUAL(lock, spinlock_t))  \
-   __ret = 

[PATCH -rt 9/9] seqlocks: use PICK_FUNCTION

2007-07-29 Thread Daniel Walker
Replace the old PICK_OP style macros with PICK_FUNCTION. Although,
seqlocks has some alien code, which I also replaced as can be seen
from the line count below.

Signed-off-by: Daniel Walker <[EMAIL PROTECTED]>

---
 include/linux/seqlock.h |  234 +++-
 1 file changed, 134 insertions(+), 100 deletions(-)

Index: linux-2.6.22/include/linux/seqlock.h
===
--- linux-2.6.22.orig/include/linux/seqlock.h
+++ linux-2.6.22/include/linux/seqlock.h
@@ -90,6 +90,12 @@ static inline void __write_seqlock(seqlo
smp_wmb();
 }
 
+static __always_inline unsigned long __write_seqlock_irqsave(seqlock_t *sl)
+{
+   __write_seqlock(sl);
+   return 0;
+}
+
 static inline void __write_sequnlock(seqlock_t *sl)
 {
smp_wmb();
@@ -97,6 +103,8 @@ static inline void __write_sequnlock(seq
spin_unlock(>lock);
 }
 
+#define __write_sequnlock_irqrestore(sl, flags)__write_sequnlock(sl)
+
 static inline int __write_tryseqlock(seqlock_t *sl)
 {
int ret = spin_trylock(>lock);
@@ -149,6 +157,28 @@ static __always_inline void __write_seql
smp_wmb();
 }
 
+static __always_inline unsigned long
+__write_seqlock_irqsave_raw(raw_seqlock_t *sl)
+{
+   unsigned long flags;
+
+   local_irq_save(flags);
+   __write_seqlock_raw(sl);
+   return flags;
+}
+
+static __always_inline void __write_seqlock_irq_raw(raw_seqlock_t *sl)
+{
+   local_irq_disable();
+   __write_seqlock_raw(sl);
+}
+
+static __always_inline void __write_seqlock_bh_raw(raw_seqlock_t *sl)
+{
+   local_bh_disable();
+   __write_seqlock_raw(sl);
+}
+
 static __always_inline void __write_sequnlock_raw(raw_seqlock_t *sl)
 {
smp_wmb();
@@ -156,6 +186,27 @@ static __always_inline void __write_sequ
spin_unlock(>lock);
 }
 
+static __always_inline void
+__write_sequnlock_irqrestore_raw(raw_seqlock_t *sl, unsigned long flags)
+{
+   __write_sequnlock_raw(sl);
+   local_irq_restore(flags);
+   preempt_check_resched();
+}
+
+static __always_inline void __write_sequnlock_irq_raw(raw_seqlock_t *sl)
+{
+   __write_sequnlock_raw(sl);
+   local_irq_enable();
+   preempt_check_resched();
+}
+
+static __always_inline void __write_sequnlock_bh_raw(raw_seqlock_t *sl)
+{
+   __write_sequnlock_raw(sl);
+   local_bh_enable();
+}
+
 static __always_inline int __write_tryseqlock_raw(raw_seqlock_t *sl)
 {
int ret = spin_trylock(>lock);
@@ -182,60 +233,92 @@ static __always_inline int __read_seqret
 
 extern int __bad_seqlock_type(void);
 
-#define PICK_SEQOP(op, lock)   \
+/*
+ * PICK_SEQ_OP() is a small redirector to allow less typing of the lock
+ * types raw_seqlock_t, seqlock_t, at the front of the PICK_FUNCTION
+ * macro.
+ */
+#define PICK_SEQ_OP(...) PICK_FUNCTION(raw_seqlock_t, seqlock_t, ##__VA_ARGS__)
+#define PICK_SEQ_OP_RET(...) \
+   PICK_FUNCTION_RET(raw_seqlock_t, seqlock_t, ##__VA_ARGS__)
+
+#define write_seqlock(sl) PICK_SEQ_OP(__write_seqlock_raw, __write_seqlock, sl)
+
+#define write_sequnlock(sl)\
+   PICK_SEQ_OP(__write_sequnlock_raw, __write_sequnlock, sl)
+
+#define write_tryseqlock(sl)   \
+   PICK_SEQ_OP_RET(__write_tryseqlock_raw, __write_tryseqlock, sl)
+
+#define read_seqbegin(sl)  \
+   PICK_SEQ_OP_RET(__read_seqbegin_raw, __read_seqbegin, sl)
+
+#define read_seqretry(sl, iv)  \
+   PICK_SEQ_OP_RET(__read_seqretry_raw, __read_seqretry, sl, iv)
+
+#define write_seqlock_irqsave(lock, flags) \
 do {   \
-   if (TYPE_EQUAL((lock), raw_seqlock_t))  \
-   op##_raw((raw_seqlock_t *)(lock));  \
-   else if (TYPE_EQUAL((lock), seqlock_t)) \
-   op((seqlock_t *)(lock));\
-   else __bad_seqlock_type();  \
+   flags = PICK_SEQ_OP_RET(__write_seqlock_irqsave_raw,\
+   __write_seqlock_irqsave, lock); \
 } while (0)
 
-#define PICK_SEQOP_RET(op, lock)   \
-({ \
-   unsigned long __ret;\
-   \
-   if (TYPE_EQUAL((lock), raw_seqlock_t))  \
-   __ret = op##_raw((raw_seqlock_t *)(lock));  \
-   else if (TYPE_EQUAL((lock), seqlock_t)) \
-   __ret = op((seqlock_t *)(lock));\
-   else __ret = __bad_seqlock_type();  \
-   \
-   __ret;  \
-})
-
-#define PICK_SEQOP_CONST_RET(op, lock) \
-({   

[PATCH -rt 2/9] Dont allow non-threaded softirqs and threaded hardirqs

2007-07-29 Thread Daniel Walker
From: Steven Rostedt <[EMAIL PROTECTED]>

Ingo,

I think this was sent before, and it did cause problems before. Would
there be *any* reason to have non-threaded softirqs but threaded hardirqs.
I can see lots of issues with that.

This patch has selecting hardirqs also select softirqs as threads.

Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>

---
 kernel/Kconfig.preempt |1 +
 1 file changed, 1 insertion(+)

Index: linux-2.6.22/kernel/Kconfig.preempt
===
--- linux-2.6.22.orig/kernel/Kconfig.preempt2007-07-26 14:59:11.0 
+
+++ linux-2.6.22/kernel/Kconfig.preempt 2007-07-26 14:59:48.0 +
@@ -106,6 +106,7 @@ config PREEMPT_HARDIRQS
bool "Thread Hardirqs"
default n
depends on !GENERIC_HARDIRQS_NO__DO_IRQ
+   select PREEMPT_SOFTIRQS
help
  This option reduces the latency of the kernel by 'threading'
   hardirqs. This means that all (or selected) hardirqs will run

-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH -rt 4/9] ifdef raise_softirq_irqoff wakeup

2007-07-29 Thread Daniel Walker
raise_softirq is called every timer interrupt in run_local_timers(),
which causes a thread wakeup to happen every timer interrupt. This
happens in !CONFIG_PREEMPT_SOFTIRQS, which means the wakeup is most
likely not needed. In addition it also fouls calc_load() since it's,
agian, observing at least one thread running on every invocation.

Signed-off-by: Daniel Walker <[EMAIL PROTECTED]>
 
---
 kernel/softirq.c |2 ++
 1 file changed, 2 insertions(+)

Index: linux-2.6.22/kernel/softirq.c
===
--- linux-2.6.22.orig/kernel/softirq.c
+++ linux-2.6.22/kernel/softirq.c
@@ -508,7 +508,9 @@ inline fastcall void raise_softirq_irqof
 {
__do_raise_softirq_irqoff(nr);
 
+#ifdef CONFIG_PREEMPT_SOFTIRQS
wakeup_softirqd(nr);
+#endif
 }
 
 EXPORT_SYMBOL(raise_softirq_irqoff);

-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH -rt 7/9] introduce PICK_FUNCTION

2007-07-29 Thread Daniel Walker
PICK_FUNCTION() is similar to the other PICK_OP style macros, and was
created to replace them all. I used variable argument macros to handle
PICK_FUNC_2ARG/PICK_FUNC_1ARG. Otherwise the marcos are similar to the
original macros used for semaphores. The entire system is used to do a
compile time switch between two different locking APIs. For example,
real spinlocks (raw_spinlock_t) and mutexes (or sleeping spinlocks).

This new macro replaces all the duplication from lock type to lock type.
The result of this patch, and the next two, is a fairly nice simplification,
and consolidation. Although the seqlock changes are larger than the originals
I think over all the patchset is worth while.

Signed-off-by: Daniel Walker <[EMAIL PROTECTED]>

---
 include/linux/pickop.h  |   32 +++
 include/linux/rt_lock.h |  129 +++-
 2 files changed, 73 insertions(+), 88 deletions(-)

Index: linux-2.6.22/include/linux/pickop.h
===
--- /dev/null
+++ linux-2.6.22/include/linux/pickop.h
@@ -0,0 +1,32 @@
+#ifndef _LINUX_PICKOP_H
+#define _LINUX_PICKOP_H
+
+#undef TYPE_EQUAL
+#define TYPE_EQUAL(var, type) \
+   __builtin_types_compatible_p(typeof(var), type *)
+
+extern int __bad_func_type(void);
+
+#define PICK_FUNCTION(type1, type2, func1, func2, arg0, ...)   \
+do {   \
+   if (TYPE_EQUAL((arg0), type1))  \
+   func1((type1 *)(arg0), ##__VA_ARGS__);  \
+   else if (TYPE_EQUAL((arg0), type2)) \
+   func2((type2 *)(arg0), ##__VA_ARGS__);  \
+   else __bad_func_type(); \
+} while (0)
+
+#define PICK_FUNCTION_RET(type1, type2, func1, func2, arg0, ...)   \
+({ \
+   unsigned long __ret;\
+   \
+   if (TYPE_EQUAL((arg0), type1))  \
+   __ret = func1((type1 *)(arg0), ##__VA_ARGS__);  \
+   else if (TYPE_EQUAL((arg0), type2)) \
+   __ret = func2((type2 *)(arg0), ##__VA_ARGS__);  \
+   else __ret = __bad_func_type(); \
+   \
+   __ret;  \
+})
+
+#endif /* _LINUX_PICKOP_H */
Index: linux-2.6.22/include/linux/rt_lock.h
===
--- linux-2.6.22.orig/include/linux/rt_lock.h
+++ linux-2.6.22/include/linux/rt_lock.h
@@ -156,76 +156,40 @@ extern void fastcall rt_up(struct semaph
 
 extern int __bad_func_type(void);
 
-#undef TYPE_EQUAL
-#define TYPE_EQUAL(var, type) \
-   __builtin_types_compatible_p(typeof(var), type *)
-
-#define PICK_FUNC_1ARG(type1, type2, func1, func2, arg)
\
-do {   \
-   if (TYPE_EQUAL((arg), type1))   \
-   func1((type1 *)(arg));  \
-   else if (TYPE_EQUAL((arg), type2))  \
-   func2((type2 *)(arg));  \
-   else __bad_func_type(); \
-} while (0)
+#include 
 
-#define PICK_FUNC_1ARG_RET(type1, type2, func1, func2, arg)\
-({ \
-   unsigned long __ret;\
-   \
-   if (TYPE_EQUAL((arg), type1))   \
-   __ret = func1((type1 *)(arg));  \
-   else if (TYPE_EQUAL((arg), type2))  \
-   __ret = func2((type2 *)(arg));  \
-   else __ret = __bad_func_type(); \
-   \
-   __ret;  \
-})
-
-#define PICK_FUNC_2ARG(type1, type2, func1, func2, arg0, arg1) \
-do {   \
-   if (TYPE_EQUAL((arg0), type1))  \
-   func1((type1 *)(arg0), arg1);   \
-   else if (TYPE_EQUAL((arg0), type2)) \
-   func2((type2 *)(arg0), arg1);   \
-   else __bad_func_type();   

[PATCH -rt 3/9] Fix jiffies wrap issue in update_times

2007-07-29 Thread Daniel Walker
In prior -rt verisons the last_tick value was called wall_jiffies 
and was initialized in this same way as below. If this value isn't
initialized the calc_load function gets skewed for several minutes
right after boot up. Skewed meaning always zero.

Signed-off-by: Daniel Walker <[EMAIL PROTECTED]>

---
 kernel/timer.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6.22/kernel/timer.c
===
--- linux-2.6.22.orig/kernel/timer.c
+++ linux-2.6.22/kernel/timer.c
@@ -987,7 +987,7 @@ void run_local_timers(void)
  */
 static inline void update_times(void)
 {
-   static unsigned long last_tick;
+   static unsigned long last_tick = INITIAL_JIFFIES;
unsigned long ticks, flags;
 
/*

-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH -rt 6/9] spinlock/rt_lock random cleanups

2007-07-29 Thread Daniel Walker
Signed-off-by: Daniel Walker <[EMAIL PROTECTED]>

---
 include/linux/rt_lock.h  |6 --
 include/linux/spinlock.h |5 +++--
 2 files changed, 7 insertions(+), 4 deletions(-)

Index: linux-2.6.22/include/linux/rt_lock.h
===
--- linux-2.6.22.orig/include/linux/rt_lock.h
+++ linux-2.6.22/include/linux/rt_lock.h
@@ -128,12 +128,14 @@ struct semaphore name = \
  */
 #define DECLARE_MUTEX_LOCKED COMPAT_DECLARE_MUTEX_LOCKED
 
-extern void fastcall __sema_init(struct semaphore *sem, int val, char *name, 
char *file, int line);
+extern void fastcall
+__sema_init(struct semaphore *sem, int val, char *name, char *file, int line);
 
 #define rt_sema_init(sem, val) \
__sema_init(sem, val, #sem, __FILE__, __LINE__)
 
-extern void fastcall __init_MUTEX(struct semaphore *sem, char *name, char 
*file, int line);
+extern void fastcall
+__init_MUTEX(struct semaphore *sem, char *name, char *file, int line);
 #define rt_init_MUTEX(sem) \
__init_MUTEX(sem, #sem, __FILE__, __LINE__)
 
Index: linux-2.6.22/include/linux/spinlock.h
===
--- linux-2.6.22.orig/include/linux/spinlock.h
+++ linux-2.6.22/include/linux/spinlock.h
@@ -126,7 +126,7 @@ extern int __lockfunc generic__raw_read_
 
 #ifdef CONFIG_DEBUG_SPINLOCK
  extern __lockfunc void _raw_spin_lock(raw_spinlock_t *lock);
-#define _raw_spin_lock_flags(lock, flags) _raw_spin_lock(lock)
+# define _raw_spin_lock_flags(lock, flags) _raw_spin_lock(lock)
  extern __lockfunc int _raw_spin_trylock(raw_spinlock_t *lock);
  extern __lockfunc void _raw_spin_unlock(raw_spinlock_t *lock);
  extern __lockfunc void _raw_read_lock(raw_rwlock_t *lock);
@@ -325,7 +325,8 @@ do {
\
 
 # define _read_trylock(rwl)rt_read_trylock(rwl)
 # define _write_trylock(rwl)   rt_write_trylock(rwl)
-#define _write_trylock_irqsave(rwl, flags)  rt_write_trylock_irqsave(rwl, 
flags)
+# define _write_trylock_irqsave(rwl, flags) \
+   rt_write_trylock_irqsave(rwl, flags)
 
 # define _read_lock(rwl)   rt_read_lock(rwl)
 # define _write_lock(rwl)  rt_write_lock(rwl)

-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH -rt 5/9] net: fix mis-merge in qdisc_restart

2007-07-29 Thread Daniel Walker
This mismerge caused my networking to malfunction. The interface would
come up, but no traffic would make it in/out ..

Signed-off-by: Daniel Walker <[EMAIL PROTECTED]>

---
 net/sched/sch_generic.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6.22/net/sched/sch_generic.c
===
--- linux-2.6.22.orig/net/sched/sch_generic.c
+++ linux-2.6.22/net/sched/sch_generic.c
@@ -156,7 +156,7 @@ static inline int qdisc_restart(struct n
 #ifdef CONFIG_PREEMPT_RT
netif_tx_lock(dev);
 #else
-   if (netif_tx_trylock(dev))
+   if (!netif_tx_trylock(dev))
/* Another CPU grabbed the driver tx lock */
return handle_dev_cpu_collision(skb, dev, q);
 #endif

-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH -rt 1/9] preempt rcu: check for underflow

2007-07-29 Thread Daniel Walker
Simple WARN_ON to catch any underflow in rcu_read_lock_nesting.

Signed-off-by: Daniel Walker <[EMAIL PROTECTED]>

---
 kernel/rcupreempt.c |6 ++
 1 file changed, 6 insertions(+)

Index: linux-2.6.22/kernel/rcupreempt.c
===
--- linux-2.6.22.orig/kernel/rcupreempt.c
+++ linux-2.6.22/kernel/rcupreempt.c
@@ -157,6 +157,12 @@ void __rcu_read_unlock(void)
}
 
local_irq_restore(oldirq);
+
+   /*
+* If our rcu_read_lock_nesting went negative, likely
+* something is wrong..
+*/
+   WARN_ON(current->rcu_read_lock_nesting < 0);
 }
 
 static void __rcu_advance_callbacks(void)

-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v3 -mm 9/9] netconsole: Support dynamic reconfiguration using configfs

2007-07-29 Thread Satyam Sharma
From: Satyam Sharma <[EMAIL PROTECTED]>

[9/9] netconsole: Support dynamic reconfiguration using configfs

This patch introduces support for dynamic reconfiguration (adding, removing
and/or modifying parameters of netconsole targets at runtime) using a
userspace interface exported via configfs. Documentation is also updated
accordingly.

Issues and brief design overview:

(1) Kernel-initiated creation / destruction of kernel objects is not
possible with configfs -- the lifetimes of the "config items" is managed
exclusively from userspace. But netconsole must support boot/module params
too, and these are parsed in kernel and hence netpolls must be setup from
the kernel. Joel Becker suggested to separately manage the lifetimes of
the two kinds of netconsole_target objects -- those created via configfs
mkdir(2) from userspace and those specified from the boot/module option
string. This adds complexity and some redundancy here and also means that
boot/module param-created targets are not exposed through the configfs
namespace (and hence cannot be updated / destroyed dynamically). However,
this saves us from locking / refcounting complexities that would need to
be introduced in configfs to support kernel-initiated item creation /
destroy there.

(2) In configfs, item creation takes place in the call chain of the mkdir(2)
syscall in the driver subsystem. If we used an ioctl(2) to create / destroy
objects from userspace, the special userspace program is able to fill out
the structure to be passed into the ioctl and hence specify attributes such
as local interface that are required at the time we set up the netpoll.
For configfs, this information is not available at the time of mkdir(2).
So, we keep all newly-created targets (via configfs) disabled by default.
The user is expected to set various attributes appropriately (including the
local network interface if required) and then write(2) "1" to the "enabled"
attribute. Thus, netpoll_setup() is then called on the set parameters in the
context of _this_ write(2) on the "enabled" attribute itself. This design
enables the user to reconfigure existing netconsole targets at runtime to
be attached to newly-come-up interfaces that may not have existed when
netconsole was loaded or when the targets were actually created. All this
effectively enables us to get rid of custom ioctls.

(3) Ultra-paranoid configfs attribute show() and store() operations, with
sanity and input range checking, using only safe string primitives, and
compliant with the recommendations in Documentation/filesystems/sysfs.txt.

(4) A new function netpoll_print_options() is created in the netpoll API,
that just prints out the configured parameters for a netpoll structure.
netpoll_parse_options() is modified to use that and it is also exported to
be used from netconsole.

Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
Acked-by: Keiichi Kii <[EMAIL PROTECTED]>

---

 Documentation/networking/netconsole.txt |   68 
 drivers/net/Kconfig |   10 +
 drivers/net/netconsole.c|  605 +--
 include/linux/netpoll.h |1 +
 net/core/netpoll.c  |   44 ++-
 5 files changed, 683 insertions(+), 45 deletions(-)

diff --git a/Documentation/networking/netconsole.txt 
b/Documentation/networking/netconsole.txt
index 1aaa738..3c2f2b3 100644
--- a/Documentation/networking/netconsole.txt
+++ b/Documentation/networking/netconsole.txt
@@ -3,6 +3,10 @@ started by Ingo Molnar <[EMAIL PROTECTED]>, 2001.09.17
 2.6 port and netpoll api by Matt Mackall <[EMAIL PROTECTED]>, Sep 9 2003
 
 Please send bug reports to Matt Mackall <[EMAIL PROTECTED]>
+and Satyam Sharma <[EMAIL PROTECTED]>
+
+Introduction:
+=
 
 This module logs kernel printk messages over UDP allowing debugging of
 problem where disk logging fails and serial consoles are impractical.
@@ -13,6 +17,9 @@ the specified interface as soon as possible. While this 
doesn't allow
 capture of early kernel panics, it does capture most of the boot
 process.
 
+Sender and receiver configuration:
+==
+
 It takes a string configuration parameter "netconsole" in the
 following format:
 
@@ -46,6 +53,67 @@ address.
 
 The remote host can run either 'netcat -u -l -p ' or syslogd.
 
+Dynamic reconfiguration:
+
+
+Dynamic reconfigurability is a useful addition to netconsole that enables
+remote logging targets to be dynamically added, removed, or have their
+parameters reconfigured at runtime from a configfs-based userspace interface.
+[ Note that the parameters of netconsole targets that were specified/created
+from the boot/module option are not exposed via this interface, and hence
+cannot be modified dynamically. ]
+
+To include this feature, select CONFIG_NETCONSOLE_DYNAMIC when building the
+netconsole module (or kernel, if netconsole is built-in).
+
+Some examples follow (where configfs is mounted at the 

[PATCH v3 -mm 6/9] netconsole: Introduce netconsole_target

2007-07-29 Thread Satyam Sharma
From: Satyam Sharma <[EMAIL PROTECTED]>

[6/9] netconsole: Introduce netconsole_target

Introduce a wrapper structure over netpoll to represent logging targets
configured in netconsole. This will get extended with other members in
further patches.

This is done independent of the (to-be-introduced) NETCONSOLE_DYNAMIC
config option so that we're able to drastically cut down on the #ifdef
complexity of final netconsole.c. Also, struct netconsole_target would be
required for multiple targets support also, and not just dynamic
reconfigurability.

Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
Signed-off-by: Keiichi Kii <[EMAIL PROTECTED]>

---

 drivers/net/netconsole.c |   36 +---
 1 files changed, 25 insertions(+), 11 deletions(-)

diff --git a/drivers/net/netconsole.c b/drivers/net/netconsole.c
index 75cb761..be15ca6 100644
--- a/drivers/net/netconsole.c
+++ b/drivers/net/netconsole.c
@@ -62,24 +62,35 @@ static int __init option_setup(char *opt)
 __setup("netconsole=", option_setup);
 #endif /* MODULE */
 
-static struct netpoll np = {
-   .name   = "netconsole",
-   .dev_name   = "eth0",
-   .local_port = 6665,
-   .remote_port= ,
-   .remote_mac = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff},
+/**
+ * struct netconsole_target - Represents a configured netconsole target.
+ * @np:The netpoll structure for this target.
+ */
+struct netconsole_target {
+   struct netpoll  np;
+};
+
+static struct netconsole_target default_target = {
+   .np = {
+   .name   = "netconsole",
+   .dev_name   = "eth0",
+   .local_port = 6665,
+   .remote_port= ,
+   .remote_mac = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff},
+   },
 };
 
 static void write_msg(struct console *con, const char *msg, unsigned int len)
 {
int frag, left;
unsigned long flags;
+   struct netconsole_target *nt = _target;
 
-   if (netif_running(np.dev)) {
+   if (netif_running(nt->np.dev)) {
local_irq_save(flags);
for (left = len; left;) {
frag = min(left, MAX_PRINT_CHUNK);
-   netpoll_send_udp(, msg, frag);
+   netpoll_send_udp(>np, msg, frag);
msg += frag;
left -= frag;
}
@@ -96,17 +107,18 @@ static struct console netconsole = {
 static int __init init_netconsole(void)
 {
int err = 0;
+   struct netconsole_target *nt = _target;
 
if (!strnlen(config, MAX_PARAM_LENGTH)) {
printk(KERN_INFO "netconsole: not configured, aborting\n");
goto out;
}
 
-   err = netpoll_parse_options(, config);
+   err = netpoll_parse_options(>np, config);
if (err)
goto out;
 
-   err = netpoll_setup();
+   err = netpoll_setup(>np);
if (err)
goto out;
 
@@ -119,8 +131,10 @@ out:
 
 static void __exit cleanup_netconsole(void)
 {
+   struct netconsole_target *nt = _target;
+
unregister_console();
-   netpoll_cleanup();
+   netpoll_cleanup(>np);
 }
 
 module_init(init_netconsole);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v3 -mm 7/9] netconsole: Introduce netconsole_netdev_notifier

2007-07-29 Thread Satyam Sharma
From: Satyam Sharma <[EMAIL PROTECTED]>

[7/9] netconsole: Introduce netconsole_netdev_notifier

To update fields of underlying netpoll structure at runtime on
corresponding NETDEV_CHANGEADDR or NETDEV_CHANGENAME notifications.

ioctl(SIOCSIFHWADDR or SIOCSIFNAME) could be used to change the
hardware/MAC address or name of the local interface that our netpoll
is attached to. Whenever this happens, netdev notifier chain is called
out with the NETDEV_CHANGEADDR or NETDEV_CHANGENAME event message. We
respond to that and update the local_mac or dev_name field of the struct
netpoll. This makes sense anyway, but is especially required for dynamic
netconsole because the netpoll structure's internal members become user
visible files when either sysfs or configfs are used. So this helps us
to keep up with the MAC address/name changes and keep values in struct
netpoll uptodate.

[ Note that ioctl(SIOCSIFADDR) to change IP address of interface at
  runtime is not handled (to update local_ip of netpoll) on purpose --
  some setups may set the local_ip to a private address, not necessary
  the actual IP address of the sender host, as presently allowed. ]

Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
Signed-off-by: Keiichi Kii <[EMAIL PROTECTED]>

---

 drivers/net/netconsole.c |   32 
 1 files changed, 32 insertions(+), 0 deletions(-)

diff --git a/drivers/net/netconsole.c b/drivers/net/netconsole.c
index be15ca6..5557098 100644
--- a/drivers/net/netconsole.c
+++ b/drivers/net/netconsole.c
@@ -80,6 +80,33 @@ static struct netconsole_target default_target = {
},
 };
 
+/* Handle network interface device notifications */
+static int netconsole_netdev_event(struct notifier_block *this,
+  unsigned long event,
+  void *ptr)
+{
+   struct net_device *dev = ptr;
+   struct netconsole_target *nt = _target;
+
+   if (nt->np.dev == dev) {
+   switch (event) {
+   case NETDEV_CHANGEADDR:
+   memcpy(nt->np.local_mac, dev->dev_addr, ETH_ALEN);
+   break;
+
+   case NETDEV_CHANGENAME:
+   strlcpy(nt->np.dev_name, dev->name, IFNAMSIZ);
+   break;
+   }
+   }
+
+   return NOTIFY_DONE;
+}
+
+static struct notifier_block netconsole_netdev_notifier = {
+   .notifier_call  = netconsole_netdev_event,
+};
+
 static void write_msg(struct console *con, const char *msg, unsigned int len)
 {
int frag, left;
@@ -122,6 +149,10 @@ static int __init init_netconsole(void)
if (err)
goto out;
 
+   err = register_netdevice_notifier(_netdev_notifier);
+   if (err)
+   goto out;
+
register_console();
printk(KERN_INFO "netconsole: network logging started\n");
 
@@ -134,6 +165,7 @@ static void __exit cleanup_netconsole(void)
struct netconsole_target *nt = _target;
 
unregister_console();
+   unregister_netdevice_notifier(_netdev_notifier);
netpoll_cleanup(>np);
 }
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v3 -mm 8/9] netconsole: Support multiple logging targets

2007-07-29 Thread Satyam Sharma
From: Satyam Sharma <[EMAIL PROTECTED]>

[8/9] netconsole: Support multiple logging targets

This patch introduces support for multiple targets, independent of
CONFIG_NETCONSOLE_DYNAMIC -- this is useful even in the default case and
(including the infrastructure introduced in previous patches) doesn't
really add too many bytes to module text. All the complexity (and size)
comes with the dynamic reconfigurability / userspace interface patch,
and so it's plausible users may want to keep this enabled but that
disabled (say to avoid a dependency on CONFIG_CONFIGFS_FS too).

Also update documentation to mention the use of ";" separator to specify
multiple logging targets in the boot/module option string.

Brief overview:

We maintain a target_list (and corresponding lock). Get rid of the static
"default_target" and introduce allocation and release functions for our
netconsole_target objects (but keeping sure to preserve previous behaviour
such as default values). During init_netconsole(), ";" is used as the
separator to identify multiple target specifications in the boot/module
option string. The target specifications are parsed and netpolls setup.
During exit, the target_list is torn down and all items released.

Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
Signed-off-by: Keiichi Kii <[EMAIL PROTECTED]>

---

 Documentation/networking/netconsole.txt |6 +
 drivers/net/netconsole.c|  171 +++---
 2 files changed, 137 insertions(+), 40 deletions(-)

diff --git a/Documentation/networking/netconsole.txt 
b/Documentation/networking/netconsole.txt
index 5962f45..1aaa738 100644
--- a/Documentation/networking/netconsole.txt
+++ b/Documentation/networking/netconsole.txt
@@ -34,6 +34,12 @@ Examples:
 
  insmod netconsole netconsole=@/,@10.0.0.2/
 
+It also supports logging to multiple remote agents by specifying
+parameters for the multiple agents separated by semicolons and the
+complete string enclosed in "quotes", thusly:
+
+ modprobe netconsole netconsole="@/,@10.0.0.2/;@/eth1,[EMAIL PROTECTED]/"
+
 Built-in netconsole starts immediately after the TCP stack is
 initialized and attempts to bring up the supplied dev at the supplied
 address.
diff --git a/drivers/net/netconsole.c b/drivers/net/netconsole.c
index 5557098..458c4d6 100644
--- a/drivers/net/netconsole.c
+++ b/drivers/net/netconsole.c
@@ -62,44 +62,93 @@ static int __init option_setup(char *opt)
 __setup("netconsole=", option_setup);
 #endif /* MODULE */
 
+/* Linked list of all configured targets */
+static LIST_HEAD(target_list);
+
+/* This needs to be a spinlock because write_msg() cannot sleep */
+static DEFINE_SPINLOCK(target_list_lock);
+
 /**
  * struct netconsole_target - Represents a configured netconsole target.
+ * @list:  Links this target into the target_list.
  * @np:The netpoll structure for this target.
  */
 struct netconsole_target {
+   struct list_headlist;
struct netpoll  np;
 };
 
-static struct netconsole_target default_target = {
-   .np = {
-   .name   = "netconsole",
-   .dev_name   = "eth0",
-   .local_port = 6665,
-   .remote_port= ,
-   .remote_mac = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff},
-   },
-};
+/* Allocate new target and setup netpoll for it */
+static struct netconsole_target *alloc_target(char *target_config)
+{
+   int err = -ENOMEM;
+   struct netconsole_target *nt;
+
+   /* Allocate and initialize with defaults */
+   nt = kzalloc(sizeof(*nt), GFP_KERNEL);
+   if (!nt) {
+   printk(KERN_ERR "netconsole: failed to allocate memory\n");
+   goto fail;
+   }
+
+   nt->np.name = "netconsole";
+   strlcpy(nt->np.dev_name, "eth0", IFNAMSIZ);
+   nt->np.local_port = 6665;
+   nt->np.remote_port = ;
+   memset(nt->np.remote_mac, 0xff, ETH_ALEN);
+
+   /* Parse parameters and setup netpoll */
+   err = netpoll_parse_options(>np, target_config);
+   if (err)
+   goto fail;
+
+   err = netpoll_setup(>np);
+   if (err)
+   goto fail;
+
+   return nt;
+
+fail:
+   kfree(nt);
+   return ERR_PTR(err);
+}
+
+/* Cleanup netpoll for given target and free it */
+static void free_target(struct netconsole_target *nt)
+{
+   netpoll_cleanup(>np);
+   kfree(nt);
+}
 
 /* Handle network interface device notifications */
 static int netconsole_netdev_event(struct notifier_block *this,
   unsigned long event,
   void *ptr)
 {
+   unsigned long flags;
+   struct netconsole_target *nt;
struct net_device *dev = ptr;
-   struct netconsole_target *nt = _target;
 
-   if (nt->np.dev == dev) {
-   switch (event) {
-   case NETDEV_CHANGEADDR:
-   memcpy(nt->np.local_mac, dev->dev_addr, 

[PATCH v3 -mm 3/9] netconsole: Simplify boot/module option setup logic

2007-07-29 Thread Satyam Sharma
From: Satyam Sharma <[EMAIL PROTECTED]>

[3/9] netconsole: Simplify boot/module option setup logic

Presently, boot/module parameters are set up quite differently for the
case of built-in netconsole (__setup() -> obsolete_checksetup() ->
netpoll_parse_options() -> strlen(config) == 0 in init_netconsole())
vs modular netconsole (module_param_string() -> string copied to the
config variable -> strlen(config) != 0 init_netconsole() ->
netpoll_parse_options()).

This patch makes both of them similar by doing exactly the equivalent
of a module_param_string() in option_setup() also -- just copying the
param string passed from the kernel command line into "config" variable.
So, strlen(config) != 0 in both cases, and netpoll_parse_options() is
always called from init_netconsole(), thus making the setup logic for
both cases similar.

Now, option_setup() is only ever called / used for the built-in case,
so we put it inside a #ifndef MODULE, otherwise gcc will complain about
option_setup() being "defined but not used". Also, the "configured"
variable is redundant with this patch and hence removed.

Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
Signed-off-by: Keiichi Kii <[EMAIL PROTECTED]>
Acked-by: Matt Mackall <[EMAIL PROTECTED]>

---

 drivers/net/netconsole.c |   27 ++-
 1 files changed, 14 insertions(+), 13 deletions(-)

diff --git a/drivers/net/netconsole.c b/drivers/net/netconsole.c
index 2c2aef1..e56aa6c 100644
--- a/drivers/net/netconsole.c
+++ b/drivers/net/netconsole.c
@@ -53,6 +53,15 @@ static char config[MAX_PARAM_LENGTH];
 module_param_string(netconsole, config, MAX_PARAM_LENGTH, 0);
 MODULE_PARM_DESC(netconsole, " [EMAIL 
PROTECTED]/[dev],[tgt-port]@/[tgt-macaddr]\n");
 
+#ifndefMODULE
+static int __init option_setup(char *opt)
+{
+   strlcpy(config, opt, MAX_PARAM_LENGTH);
+   return 1;
+}
+__setup("netconsole=", option_setup);
+#endif /* MODULE */
+
 static struct netpoll np = {
.name   = "netconsole",
.dev_name   = "eth0",
@@ -60,7 +69,6 @@ static struct netpoll np = {
.remote_port= ,
.remote_mac = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff},
 };
-static int configured;
 
 static void write_msg(struct console *con, const char *msg, unsigned int len)
 {
@@ -85,26 +93,19 @@ static struct console netconsole = {
.write  = write_msg,
 };
 
-static int __init option_setup(char *opt)
-{
-   configured = !netpoll_parse_options(, opt);
-   return 1;
-}
-
-__setup("netconsole=", option_setup);
-
 static int __init init_netconsole(void)
 {
int err = 0;
 
-   if (strnlen(config, MAX_PARAM_LENGTH))
-   option_setup(config);
-
-   if (!configured) {
+   if (!strnlen(config, MAX_PARAM_LENGTH)) {
printk(KERN_INFO "netconsole: not configured, aborting\n");
goto out;
}
 
+   err = netpoll_parse_options(, config);
+   if (err)
+   goto out;
+
err = netpoll_setup();
if (err)
goto out;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v3 -mm 4/9] netconsole: Use netif_running() in write_msg()

2007-07-29 Thread Satyam Sharma
From: Satyam Sharma <[EMAIL PROTECTED]>

[4/9] netconsole: Use netif_running() in write_msg()

Avoid unnecessarily disabling interrupts and calling netpoll_send_udp()
if the corresponding local interface is not up.

Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
Acked-by: Keiichi Kii <[EMAIL PROTECTED]>
Cc: Matt Mackall <[EMAIL PROTECTED]>

---

 drivers/net/netconsole.c |   18 +-
 1 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/net/netconsole.c b/drivers/net/netconsole.c
index e56aa6c..75cb761 100644
--- a/drivers/net/netconsole.c
+++ b/drivers/net/netconsole.c
@@ -75,16 +75,16 @@ static void write_msg(struct console *con, const char *msg, 
unsigned int len)
int frag, left;
unsigned long flags;
 
-   local_irq_save(flags);
-
-   for (left = len; left;) {
-   frag = min(left, MAX_PRINT_CHUNK);
-   netpoll_send_udp(, msg, frag);
-   msg += frag;
-   left -= frag;
+   if (netif_running(np.dev)) {
+   local_irq_save(flags);
+   for (left = len; left;) {
+   frag = min(left, MAX_PRINT_CHUNK);
+   netpoll_send_udp(, msg, frag);
+   msg += frag;
+   left -= frag;
+   }
+   local_irq_restore(flags);
}
-
-   local_irq_restore(flags);
 }
 
 static struct console netconsole = {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v3 -mm 5/9] netconsole: Add some useful tips to documentation

2007-07-29 Thread Satyam Sharma
From: Satyam Sharma <[EMAIL PROTECTED]>

[5/9] netconsole: Add some useful tips to documentation

Add some useful general-purpose tips. Also suggest solution for the frequent
problem of console loglevel set too low numerically (i.e. for high priority
messages only) on the sender.

Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
Acked-by: Keiichi Kii <[EMAIL PROTECTED]>
Acked-by: Matt Mackall <[EMAIL PROTECTED]>

---

 Documentation/networking/netconsole.txt |   25 +
 1 files changed, 25 insertions(+), 0 deletions(-)

diff --git a/Documentation/networking/netconsole.txt 
b/Documentation/networking/netconsole.txt
index 1caa6c7..5962f45 100644
--- a/Documentation/networking/netconsole.txt
+++ b/Documentation/networking/netconsole.txt
@@ -44,11 +44,36 @@ WARNING: the default target ethernet setting uses the 
broadcast
 ethernet address to send packets, which can cause increased load on
 other systems on the same ethernet segment.
 
+TIP: some LAN switches may be configured to suppress ethernet broadcasts
+so it is advised to explicitly specify the remote agents' MAC addresses
+from the config parameters passed to netconsole.
+
+TIP: to find out the MAC address of, say, 10.0.0.2, you may try using:
+
+ ping -c 1 10.0.0.2 ; /sbin/arp -n | grep 10.0.0.2
+
+TIP: in case the remote logging agent is on a separate LAN subnet than
+the sender, it is suggested to try specifying the MAC address of the
+default gateway (you may use /sbin/route -n to find it out) as the
+remote MAC address instead.
+
 NOTE: the network device (eth1 in the above case) can run any kind
 of other network traffic, netconsole is not intrusive. Netconsole
 might cause slight delays in other traffic if the volume of kernel
 messages is high, but should have no other impact.
 
+NOTE: if you find that the remote logging agent is not receiving or
+printing all messages from the sender, it is likely that you have set
+the "console_loglevel" parameter (on the sender) to only send high
+priority messages to the console. You can change this at runtime using:
+
+ dmesg -n 8
+
+or by specifying "debug" on the kernel command line at boot, to send
+all kernel messages to the console. A specific value for this parameter
+can also be set using the "loglevel" kernel boot option. See the
+dmesg(8) man page and Documentation/kernel-parameters.txt for details.
+
 Netconsole was designed to be as instantaneous as possible, to
 enable the logging of even the most critical kernel bugs. It works
 from IRQ contexts as well, and does not enable interrupts while
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v3 -mm 2/9] netconsole: Remove bogus check

2007-07-29 Thread Satyam Sharma
From: Satyam Sharma <[EMAIL PROTECTED]>

[2/9] netconsole: Remove bogus check

The (!np.dev) check in write_msg() is bogus (always false), because:
np.dev is set by netpoll_setup(), which is called by init_netconsole()
before register_console(), so write_msg() cannot be triggered unless
netpoll_setup() successfully set np.dev. Also np.dev cannot go away
from under us, because netpoll_setup() grabs us reference on it. So
let's remove the bogus check.

Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
Acked-by: Keiichi Kii <[EMAIL PROTECTED]>
Acked-by: Matt Mackall <[EMAIL PROTECTED]>

---

 drivers/net/netconsole.c |3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/drivers/net/netconsole.c b/drivers/net/netconsole.c
index f1c2a2d..2c2aef1 100644
--- a/drivers/net/netconsole.c
+++ b/drivers/net/netconsole.c
@@ -67,9 +67,6 @@ static void write_msg(struct console *con, const char *msg, 
unsigned int len)
int frag, left;
unsigned long flags;
 
-   if (!np.dev)
-   return;
-
local_irq_save(flags);
 
for (left = len; left;) {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v3 -mm 1/9] netconsole: Cleanups, codingstyle, prettyfication

2007-07-29 Thread Satyam Sharma
From: Satyam Sharma <[EMAIL PROTECTED]>

[1/9] netconsole: Cleanups, codingstyle, prettyfication

(1) Remove unwanted headers.
(2) Mark __init and __exit as appropriate.
(3) Various trivial codingstyle and prettification stuff.

Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
Signed-off-by: Keiichi Kii <[EMAIL PROTECTED]>
Acked-by: Matt Mackall <[EMAIL PROTECTED]>

---

 drivers/net/netconsole.c |   55 ++---
 1 files changed, 27 insertions(+), 28 deletions(-)

diff --git a/drivers/net/netconsole.c b/drivers/net/netconsole.c
index 69233f6..f1c2a2d 100644
--- a/drivers/net/netconsole.c
+++ b/drivers/net/netconsole.c
@@ -35,35 +35,32 @@
  /
 
 #include 
-#include 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
-#include 
-#include 
 #include 
 
 MODULE_AUTHOR("Maintainer: Matt Mackall <[EMAIL PROTECTED]>");
 MODULE_DESCRIPTION("Console driver for network interfaces");
 MODULE_LICENSE("GPL");
 
-static char config[256];
-module_param_string(netconsole, config, 256, 0);
+#define MAX_PARAM_LENGTH   256
+#define MAX_PRINT_CHUNK1000
+
+static char config[MAX_PARAM_LENGTH];
+module_param_string(netconsole, config, MAX_PARAM_LENGTH, 0);
 MODULE_PARM_DESC(netconsole, " [EMAIL 
PROTECTED]/[dev],[tgt-port]@/[tgt-macaddr]\n");
 
 static struct netpoll np = {
-   .name = "netconsole",
-   .dev_name = "eth0",
-   .local_port = 6665,
-   .remote_port = ,
-   .remote_mac = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff},
+   .name   = "netconsole",
+   .dev_name   = "eth0",
+   .local_port = 6665,
+   .remote_port= ,
+   .remote_mac = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff},
 };
-static int configured = 0;
-
-#define MAX_PRINT_CHUNK 1000
+static int configured;
 
 static void write_msg(struct console *con, const char *msg, unsigned int len)
 {
@@ -75,7 +72,7 @@ static void write_msg(struct console *con, const char *msg, 
unsigned int len)
 
local_irq_save(flags);
 
-   for(left = len; left; ) {
+   for (left = len; left;) {
frag = min(left, MAX_PRINT_CHUNK);
netpoll_send_udp(, msg, frag);
msg += frag;
@@ -86,12 +83,12 @@ static void write_msg(struct console *con, const char *msg, 
unsigned int len)
 }
 
 static struct console netconsole = {
-   .name = "netcon",
-   .flags = CON_ENABLED | CON_PRINTBUFFER,
-   .write = write_msg
+   .name   = "netcon",
+   .flags  = CON_ENABLED | CON_PRINTBUFFER,
+   .write  = write_msg,
 };
 
-static int option_setup(char *opt)
+static int __init option_setup(char *opt)
 {
configured = !netpoll_parse_options(, opt);
return 1;
@@ -99,28 +96,30 @@ static int option_setup(char *opt)
 
 __setup("netconsole=", option_setup);
 
-static int init_netconsole(void)
+static int __init init_netconsole(void)
 {
-   int err;
+   int err = 0;
 
-   if(strlen(config))
+   if (strnlen(config, MAX_PARAM_LENGTH))
option_setup(config);
 
-   if(!configured) {
-   printk("netconsole: not configured, aborting\n");
-   return 0;
+   if (!configured) {
+   printk(KERN_INFO "netconsole: not configured, aborting\n");
+   goto out;
}
 
err = netpoll_setup();
if (err)
-   return err;
+   goto out;
 
register_console();
printk(KERN_INFO "netconsole: network logging started\n");
-   return 0;
+
+out:
+   return err;
 }
 
-static void cleanup_netconsole(void)
+static void __exit cleanup_netconsole(void)
 {
unregister_console();
netpoll_cleanup();
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v3 -mm 0/9] netconsole: Multiple targets and dynamic reconfigurability

2007-07-29 Thread Satyam Sharma
[0/9] netconsole: Multiple targets and dynamic reconfigurability

This is v3 of the patchset, the previous versions are available at:
http://lkml.org/lkml/2007/7/4/107
http://lkml.org/lkml/2007/7/10/78

Diffed against 2.6.23-rc1-git6 (6c8dca5d as of writing), but applies
successfully to 2.6.23-rc1-mm1 as well.

Patches 1-5 are okay-to-apply to current mainline -git, I think.

Patches 6-9 introduce the new functionality and are requested for
inclusion in -mm.

[1/9] netconsole: Cleanups, codingstyle, prettyfication
[2/9] netconsole: Remove bogus check
[3/9] netconsole: Simplify boot/module option setup logic
[4/9] netconsole: Use netif_running() in write_msg()
[5/9] netconsole: Add some useful tips to documentation
[6/9] netconsole: Introduce netconsole_target
[7/9] netconsole: Introduce netconsole_netdev_notifier
[8/9] netconsole: Support multiple logging targets
[9/9] netconsole: Support dynamic reconfiguration using configfs

Changes since v2:
=

* "enabled" must be defined outside #ifdef NETCONSOLE_DYNAMIC

* Some simple enhancements to documentation

* Drop the use of "unlikely" from a condition where I'd got the
  common case wrong

About this patchset:


What?

Support multiple remote logging targets in netconsole. Also, ability to
dynamically add or remove targets or modify parameters (IP, port, remote
MAC address) of targets at runtime, from userspace, using configfs.

Why?

>From Keiichi Kii's original post:

[...] current netconsole is not flexible. For example, if you want to change
ip address for logging agent, in the case of built-in netconsole, you can't
change config except for changing boot parameter and rebooting your system,
or in the case of module netconsole, you need to remove it and reload
with different parameters. [...] and we have been losing serial console
port with PCs and Servers.

(... and especially laptops, I would add.)


Satyam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] mips: qemu network work again

2007-07-29 Thread Kyungmin Park
After kernel 2.6.21, the qemu of mips with nfsroot is not working.
There are too much WATCHDOG timeout.
I try to find what makes it not working and I found it.
After Ingo Monlar's patch "[PATCH] genirq: do not mask interrupts by default" 
[1], it's not working.
To solve this, we also have to register the IRQ disable field in MIPS, as x86 
does.

1. http://www.uwsg.iu.edu/hypermail/linux/kernel/0701.3/1892.html

Signed-off-by: Kyungmin Park <[EMAIL PROTECTED]>

--
diff --git a/arch/mips/kernel/i8259.c b/arch/mips/kernel/i8259.c
index 2345160..b6c3080 100644
--- a/arch/mips/kernel/i8259.c
+++ b/arch/mips/kernel/i8259.c
@@ -36,6 +36,7 @@ void mask_and_ack_8259A(unsigned int);
 static struct irq_chip i8259A_chip = {
.name   = "XT-PIC",
.mask   = disable_8259A_irq,
+   .disable= disable_8259A_irq,
.unmask = enable_8259A_irq,
.mask_ack   = mask_and_ack_8259A,
 };

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[SPARC32] NULL pointer derefference

2007-07-29 Thread Mark Fortescue

Hi All,

Unfortunatly Sparc32 sun4c low level memory management apears to be 
incompatible with commit b6a2fea39318e43fee84fa7b0b90d68bed92d2ba

mm: variable length argument support.

For some reason, this commit corrupts the memory used by the low level 
context/pte handling ring buffers in arch/sparc/mm/sun4c (in 
add_ring_ordered, head->next becomes set to a NULL pointer).


I had a quick look at http://www.linux-mm.org to see if there were any 
diagrams that show what is going on in the memory management systems, to 
see if there was something that I could use to help me work out what is 
going on, but I could not see any.


Can any one help?

Regards
Mark Fortescue.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] tiny sched_getaffinity cleanup

2007-07-29 Thread Ulrich Drepper
Unless I'm missing something quite tricky here's another tiny cleanup.  The
generated code is not affected (gcc is smart enough) but for people looking
over the code it is just irritating to have the extra conditional.


Signed-off-by: Ulrich Drepper <[EMAIL PROTECTED]>

--- kernel/sched.c  2007-07-26 14:54:53.0 -0700
+++ kernel/sched.c-new  2007-07-29 19:12:16.0 -0700
@@ -4464,10 +4464,8 @@ long sched_getaffinity(pid_t pid, cpumas
 out_unlock:
read_unlock(_lock);
mutex_unlock(_hotcpu_mutex);
-   if (retval)
-   return retval;
 
-   return 0;
+   return retval;
 }
 
 /**
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [GIT PATCH] SCSI bug fixes for 2.6.23-rc1

2007-07-29 Thread Jeff Garzik

James Bottomley wrote:

On Sun, 2007-07-29 at 21:04 -0400, Jeff Garzik wrote:

James Bottomley wrote:

msleep_interruptible -> ssleep is a
change with zero practical impact for this driver,

eh, how do you figure?

A signal can clearly cause the abort-related functions to delay far 
shorter than the driver wishes.


The msleep_interruptible() in arcmsr_wait_msgint_ready() probably isn't 
fatal -- unless it's there to ensure the hardware isn't pounded -- but 
again, a signal can cause a CPU-wasting busy loop that could last for 
quite a while (in CPU terms).


I didn't say the usage wasn't a bad example or couldn't cause problems
in certain cases.  I said "zero practical effect".  This is because the
two possible threads that enter these routines already have all user
signals blocked.


Ah!  Understood.

Jeff



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [GIT PATCH] SCSI bug fixes for 2.6.23-rc1

2007-07-29 Thread James Bottomley
On Sun, 2007-07-29 at 21:04 -0400, Jeff Garzik wrote:
> James Bottomley wrote:
> > msleep_interruptible -> ssleep is a
> > change with zero practical impact for this driver,
> 
> eh, how do you figure?
> 
> A signal can clearly cause the abort-related functions to delay far 
> shorter than the driver wishes.
> 
> The msleep_interruptible() in arcmsr_wait_msgint_ready() probably isn't 
> fatal -- unless it's there to ensure the hardware isn't pounded -- but 
> again, a signal can cause a CPU-wasting busy loop that could last for 
> quite a while (in CPU terms).

I didn't say the usage wasn't a bad example or couldn't cause problems
in certain cases.  I said "zero practical effect".  This is because the
two possible threads that enter these routines already have all user
signals blocked.

James


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Power Management framework proposal

2007-07-29 Thread Matthew Garrett
On Sun, Jul 29, 2007 at 03:00:07PM -0700, [EMAIL PROTECTED] wrote:

> yes it is, and each type of device is growing it's own, incompatible, 
> interfaces for controlling things like this. I was aiming to do two 
> things.

Anything playing with power management needs to be aware of the 
limitations of the hardware. Many devices have reduced functionality 
when in reduced power states, and it's vital that the caller be aware of 
that. There's no way to express that information in a consistent way 
because the limitations vary widely between different types of device. 
So, given that software will need to be aware of the different special 
cases for different types of hardware, there's very little cost to each 
of them exposing a different interface.

-- 
Matthew Garrett | [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] Make lguest compile with CONFIG_BLOCK=n and CONFIG_NET=n

2007-07-29 Thread Gabriel C
Rusty Russell wrote:
> On Sun, 2007-07-29 at 17:18 +0200, Gabriel C wrote:
>> Hi Rusty,
>>
>> Lguest should depend on BLOCK too , without BLOCK set I get this error:
> 
> Hi Gabriel,
> 
>   Thanks for the report!  It's probably better to fix this properly
> rather than hack it as I did for NET.
> 

You are welcome :)

Yes your solution is better :)


Gabriel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] Doc: DMA-API update

2007-07-29 Thread Randy Dunlap
From: Randy Dunlap <[EMAIL PROTECTED]>

Fix typos and update function parameters.

Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
 Documentation/DMA-API.txt |   79 ++
 1 file changed, 38 insertions(+), 41 deletions(-)

--- linux-2.6.23-rc1-git6.orig/Documentation/DMA-API.txt
+++ linux-2.6.23-rc1-git6/Documentation/DMA-API.txt
@@ -26,7 +26,7 @@ Part Ia - Using large dma-coherent buffe
 
 void *
 dma_alloc_coherent(struct device *dev, size_t size,
-dma_addr_t *dma_handle, int flag)
+dma_addr_t *dma_handle, gfp_t flag)
 void *
 pci_alloc_consistent(struct pci_dev *dev, size_t size,
 dma_addr_t *dma_handle)
@@ -38,7 +38,7 @@ to make sure to flush the processor's wr
 devices to read that memory.)
 
 This routine allocates a region of  bytes of consistent memory.
-it also returns a  which may be cast to an unsigned
+It also returns a  which may be cast to an unsigned
 integer the same width as the bus and used as the physical address
 base of the region.
 
@@ -52,21 +52,21 @@ The simplest way to do that is to use th
 
 The flag parameter (dma_alloc_coherent only) allows the caller to
 specify the GFP_ flags (see kmalloc) for the allocation (the
-implementation may chose to ignore flags that affect the location of
+implementation may choose to ignore flags that affect the location of
 the returned memory, like GFP_DMA).  For pci_alloc_consistent, you
 must assume GFP_ATOMIC behaviour.
 
 void
-dma_free_coherent(struct device *dev, size_t size, void *cpu_addr
+dma_free_coherent(struct device *dev, size_t size, void *cpu_addr,
   dma_addr_t dma_handle)
 void
-pci_free_consistent(struct pci_dev *dev, size_t size, void *cpu_addr
+pci_free_consistent(struct pci_dev *dev, size_t size, void *cpu_addr,
   dma_addr_t dma_handle)
 
 Free the region of consistent memory you previously allocated.  dev,
 size and dma_handle must all be the same as those passed into the
 consistent allocate.  cpu_addr must be the virtual address returned by
-the consistent allocate
+the consistent allocate.
 
 
 Part Ib - Using small dma-coherent buffers
@@ -77,9 +77,9 @@ To get this part of the dma_ API, you mu
 Many drivers need lots of small dma-coherent memory regions for DMA
 descriptors or I/O buffers.  Rather than allocating in units of a page
 or more using dma_alloc_coherent(), you can use DMA pools.  These work
-much like a struct kmem_cache, except that they use the dma-coherent allocator
+much like a struct kmem_cache, except that they use the dma-coherent allocator,
 not __get_free_pages().  Also, they understand common hardware constraints
-for alignment, like queue heads needing to be aligned on N byte boundaries.
+for alignment, like queue heads needing to be aligned on N-byte boundaries.
 
 
struct dma_pool *
@@ -102,15 +102,15 @@ crossing restrictions, pass 0 for alloc;
 from this pool must not cross 4KByte boundaries.
 
 
-   void *dma_pool_alloc(struct dma_pool *pool, int gfp_flags,
+   void *dma_pool_alloc(struct dma_pool *pool, gfp_t gfp_flags,
dma_addr_t *dma_handle);
 
-   void *pci_pool_alloc(struct pci_pool *pool, int gfp_flags,
+   void *pci_pool_alloc(struct pci_pool *pool, gfp_t gfp_flags,
dma_addr_t *dma_handle);
 
 This allocates memory from the pool; the returned memory will meet the size
 and alignment requirements specified at creation time.  Pass GFP_ATOMIC to
-prevent blocking, or if it's permitted (not in_interrupt, not holding SMP 
locks)
+prevent blocking, or if it's permitted (not in_interrupt, not holding SMP 
locks),
 pass GFP_KERNEL to allow blocking.  Like dma_alloc_coherent(), this returns
 two values:  an address usable by the cpu, and the dma address usable by the
 pool's device.
@@ -123,7 +123,7 @@ pool's device.
dma_addr_t addr);
 
 This puts memory back into the pool.  The pool is what was passed to
-the pool allocation routine; the cpu and dma addresses are what
+the pool allocation routine; the cpu (vaddr) and dma addresses are what
 were returned when that routine allocated the memory being freed.
 
 
@@ -209,18 +209,18 @@ Notes:  Not all memory regions in a mach
 API.  Further, regions that appear to be physically contiguous in
 kernel virtual space may not be contiguous as physical memory.  Since
 this API does not provide any scatter/gather capability, it will fail
-if the user tries to map a non physically contiguous piece of memory.
+if the user tries to map a non-physically contiguous piece of memory.
 For this reason, it is recommended that memory mapped by this API be
-obtained only from sources which guarantee to be physically contiguous
+obtained only from sources which guarantee it to be physically contiguous
 (like kmalloc).
 
 Further, the physical address of the memory must be within the
 dma_mask of the 

Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)

2007-07-29 Thread Matthew Hawkins
On 7/30/07, John <[EMAIL PROTECTED]> wrote:
> I understand that, I was just wondering if the FPS scales the same natively
> vs. Wine as I typically only run native games.  I have been hesitant to move
> over to CFS due to reports of 3D issues and wanted to see if you had numbers
> in regards to CFS vs. SD.

John, the numbers Ingo makes and the numbers you make will no doubt be
different (unless by some fantastic freak of nature you both have
identical systems).  Take this opportunity to do this testing yourself
so in case there is some improvement to make, it can be done for
2.6.23.  Nobody can benchmark your system but you.

Remember to set CONFIG_HZ to 1000

-- 
Matt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] Make lguest compile with CONFIG_BLOCK=n and CONFIG_NET=n

2007-07-29 Thread Rusty Russell
On Mon, 2007-07-30 at 06:18 +0530, Satyam Sharma wrote:
> On 7/30/07, Rusty Russell <[EMAIL PROTECTED]> wrote:
> > +config LGUEST_NET
> > +   tristate
> > +   depends on LGUEST_GUEST && NET
> 
> default y ?

Thanks, that does work better.  Clean configs get an "N" otherwise 8(

> I /think/ the default "y" would also automatically become "m" if any of the
> dependencies are modules ... probably need to test this, though.

No, it doesn't seem to.  But LGUEST_GUEST is a bool anyway, so it's OK.

Thanks!
Rusty.
==
Make lguest compile with CONFIG_BLOCK=n and CONFIG_NET=n

Gabriel C reports lguest doesn't compile with CONFIG_BLOCK=n.  Fix
this by introducing a config var for the block device, which depends
on LGUEST && BLOCK.  Do the same for the net driver, rather then
depending gratuitously on CONFIG_NET.

Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>

diff -r 9e987fcabb16 drivers/block/Makefile
--- a/drivers/block/MakefileMon Jul 30 09:47:25 2007 +1000
+++ b/drivers/block/MakefileMon Jul 30 10:02:32 2007 +1000
@@ -31,4 +31,4 @@ obj-$(CONFIG_BLK_DEV_UB)  += ub.o
 obj-$(CONFIG_BLK_DEV_UB)   += ub.o
 
 obj-$(CONFIG_XEN_BLKDEV_FRONTEND)  += xen-blkfront.o
-obj-$(CONFIG_LGUEST_GUEST) += lguest_blk.o
+obj-$(CONFIG_LGUEST_BLOCK) += lguest_blk.o
diff -r 9e987fcabb16 drivers/lguest/Kconfig
--- a/drivers/lguest/KconfigMon Jul 30 09:47:25 2007 +1000
+++ b/drivers/lguest/KconfigMon Jul 30 10:03:39 2007 +1000
@@ -1,6 +1,6 @@ config LGUEST
 config LGUEST
tristate "Linux hypervisor example code"
-   depends on X86 && PARAVIRT && NET && EXPERIMENTAL && !X86_PAE
+   depends on X86 && PARAVIRT && EXPERIMENTAL && !X86_PAE
select LGUEST_GUEST
select HVC_DRIVER
---help---
@@ -18,3 +18,13 @@ config LGUEST_GUEST
  The guest needs code built-in, even if the host has lguest
  support as a module.  The drivers are tiny, so we build them
  in too.
+
+config LGUEST_NET
+   tristate
+   default y
+   depends on LGUEST_GUEST && NET
+
+config LGUEST_BLOCK
+   default y
+   tristate
+   depends on LGUEST_GUEST && BLOCK
diff -r 9e987fcabb16 drivers/net/Makefile
--- a/drivers/net/Makefile  Mon Jul 30 09:47:25 2007 +1000
+++ b/drivers/net/Makefile  Mon Jul 30 10:02:22 2007 +1000
@@ -177,7 +177,7 @@ obj-$(CONFIG_HPLANCE) += hplance.o 7990.
 obj-$(CONFIG_HPLANCE) += hplance.o 7990.o
 obj-$(CONFIG_MVME147_NET) += mvme147.o 7990.o
 obj-$(CONFIG_EQUALIZER) += eql.o
-obj-$(CONFIG_LGUEST_GUEST) += lguest_net.o
+obj-$(CONFIG_LGUEST_NET) += lguest_net.o
 obj-$(CONFIG_MIPS_JAZZ_SONIC) += jazzsonic.o
 obj-$(CONFIG_MIPS_AU1X00_ENET) += au1000_eth.o
 obj-$(CONFIG_MIPS_SIM_NET) += mipsnet.o


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [GIT PATCH] SCSI bug fixes for 2.6.23-rc1

2007-07-29 Thread Jeff Garzik

James Bottomley wrote:

msleep_interruptible -> ssleep is a
change with zero practical impact for this driver,


eh, how do you figure?

A signal can clearly cause the abort-related functions to delay far 
shorter than the driver wishes.


The msleep_interruptible() in arcmsr_wait_msgint_ready() probably isn't 
fatal -- unless it's there to ensure the hardware isn't pounded -- but 
again, a signal can cause a CPU-wasting busy loop that could last for 
quite a while (in CPU terms).


Jeff


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] CPU online file permission

2007-07-29 Thread Ulrich Drepper
Is there a reason why the "online" file in the subdirectories for the CPUs
in /sys/devices/system isn't world-readable?  I cannot imagine it to be
security relevant especially now that a getcpu() syscall can be used to
determine what CPUa  thread runs on.

The file is useful to correctly implement the sysconf() function to return
the number of online CPUs.  In the presence of hotplug we currently cannot
provide this information.  The patch below should to it.


Signed-off-by: Ulrich Drepper <[EMAIL PROTECTED]>

--- drivers/base/cpu.c  2007-02-20 12:01:31.0 -0800
+++ drivers/base/cpu.c-new  2007-07-29 17:52:58.0 -0700
@@ -53,7 +53,7 @@
ret = count;
return ret;
 }
-static SYSDEV_ATTR(online, 0600, show_online, store_online);
+static SYSDEV_ATTR(online, 0644, show_online, store_online);
 
 static void __devinit register_cpu_control(struct cpu *cpu)
 {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 0/3] core_pattern: cleaned up repost/continuing post of core_pattern enhancements

2007-07-29 Thread Neil Horman
On Mon, Jul 30, 2007 at 07:45:39AM +0800, Eugene Teo wrote:
> Hi Martin,
> 
> Martin Pitt wrote:
> > Eugene Teo [2007-07-29 21:03 +0800]:
>  Also, it is probably good to think how we can "drop privileges" while 
>  piping
>  the core dump output to an external program. A malicious user can 
>  potentially
>  use it as a possible backdoor since anything that is executed by 
>  "|program" will
>  be executed with root privileges.
> 
> >>> It was my understanding that apport already did this.
> >> I haven't looked at apport yet, but are you talking about the userspace 
> >> portion of
> >> apport or the kernel changes in the Ubuntu kernel?
> > 
> > Similarly to Neil's patches, the Ubuntu kernel calls the userspace
> > helper as root, too. Apport drops privileges to the target process as
> > soon as possible (there are a few things it needs to do before, like
> > opening an fd to the crash file in /var/crash/ if that is only
> > writeable by root).
> 
> Just sharing some thoughts. Wouldn't it be more logical to drop the 
> privileges first,
> then call the userspace helper program? I know that this will limit tools 
> like apport
> to be able to read and/or write files that are only writable by root, but 
> there ought
> to be a better way to do this? What if the program piped is not a legitimate 
> program?
> 
We could do that I suppose, but /proc//* contains
informatino apport (and other apps need) to help diagnose problems during a
crash.  To provide that information, we would then need to build out
infrastructure to pipe that information in-band through the pipe (perhaps
through ELF notes).  Doable yes, but certainly not a small patch (consider
piping all of the files in /proc/ as ELF notes).

Regarding security, and the use of non-legit programs: If the program pointed to
by core pattern does not exist, then the exec simply fails, and the core is
lost.  Beyond that, core_pattern is only writable by root, and its teh sysadmins
responsibility to ensure that it points to valid and secured program.

> Also, maybe it is good to make this portion of the code optional too, so that 
> if no
> one is using this "ispipe" feature, we just turn it off.
> 
you mean like a build time config option? I'm not sure I see lots of value,
although, it seems like it would straightforward enough to do if you feel
strongly about it.

Regards
Neil

> Eugene

-- 
/***
 *Neil Horman
 *Software Engineer
 *Red Hat, Inc.
 [EMAIL PROTECTED]
 *gpg keyid: 1024D / 0x92A74FA1
 *http://pgp.mit.edu
 ***/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [GIT PATCH] SCSI bug fixes for 2.6.23-rc1

2007-07-29 Thread James Bottomley
On Sun, 2007-07-29 at 18:51 -0400, Jeff Garzik wrote:
> James Bottomley wrote:
> > This is basically a set of bug fixes with a few minor cleanups thrown
> > in.  There are also a few bsg fixes we're taking through this tree
> > because SCSI is the current sole consumer. The reason for the huge size
> > is the lindent of the advansys driver along with a few cleanups.
> > 
> > The patch is available here:
> > 
> > master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6.git
> 
> 
> You missed
> [SCSI] arcmsr: Fix hardware wait loops

Waiting for maintainer ack ... msleep_interruptible -> ssleep is a
change with zero practical impact for this driver, so I think we can
afford to wait.

Nick is usually pretty good ... but I'll add it to scsi-pending just in
case.

James


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] Make lguest compile with CONFIG_BLOCK=n and CONFIG_NET=n

2007-07-29 Thread Satyam Sharma
On 7/30/07, Rusty Russell <[EMAIL PROTECTED]> wrote:
> [...]
> Gabriel C reports lguest doesn't compile with CONFIG_BLOCK=n.  Fix
> this by introducing a config var for the block device, which depends
> on LGUEST && BLOCK.  Do the same for the net driver, rather then
> depending gratuitously on CONFIG_NET.
> [...]
> diff -r 9e987fcabb16 drivers/lguest/Kconfig
> --- a/drivers/lguest/KconfigMon Jul 30 09:47:25 2007 +1000
> +++ b/drivers/lguest/KconfigMon Jul 30 10:03:39 2007 +1000
> @@ -1,6 +1,6 @@ config LGUEST
>  config LGUEST
> tristate "Linux hypervisor example code"
> -   depends on X86 && PARAVIRT && NET && EXPERIMENTAL && !X86_PAE
> +   depends on X86 && PARAVIRT && EXPERIMENTAL && !X86_PAE
> select LGUEST_GUEST
> select HVC_DRIVER
> ---help---
> @@ -18,3 +18,11 @@ config LGUEST_GUEST
>   The guest needs code built-in, even if the host has lguest
>   support as a module.  The drivers are tiny, so we build them
>   in too.
> +
> +config LGUEST_NET
> +   tristate
> +   depends on LGUEST_GUEST && NET

default y ?

> +
> +config LGUEST_BLOCK
> +   tristate
> +   depends on LGUEST_GUEST && BLOCK

default y ?

I /think/ the default "y" would also automatically become "m" if any of the
dependencies are modules ... probably need to test this, though.


Satyam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 09/68] 0 -> NULL, for arch/m68knommu

2007-07-29 Thread Greg Ungerer

Hi Yoann,

Yoann Padioleau wrote:

When comparing a pointer, it's clearer to compare it to NULL than to 0.

Signed-off-by: Yoann Padioleau <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]


Acked-by: Greg Ungerer <[EMAIL PROTECTED]>



Cc: [EMAIL PROTECTED]
---

 comempci.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/m68knommu/kernel/comempci.c b/arch/m68knommu/kernel/comempci.c
index 6ee00ef..528517e 100644
--- a/arch/m68knommu/kernel/comempci.c
+++ b/arch/m68knommu/kernel/comempci.c
@@ -736,7 +736,7 @@ #endif
 
 	/* Find a free spot to put this handler */

for (i = 0; (i < COMEM_MAXPCI); i++) {
-   if (pci_irqlist[i].handler == 0) {
+   if (pci_irqlist[i].handler == NULL) {
pci_irqlist[i].handler = handler;
pci_irqlist[i].device = device;
pci_irqlist[i].dev_id = dev_id;




--

Greg Ungerer  --  Chief Software Dude   EMAIL: [EMAIL PROTECTED]
Secure Computing CorporationPHONE:   +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] Make lguest compile with CONFIG_BLOCK=n and CONFIG_NET=n

2007-07-29 Thread Rusty Russell
On Sun, 2007-07-29 at 17:18 +0200, Gabriel C wrote:
> Hi Rusty,
> 
> Lguest should depend on BLOCK too , without BLOCK set I get this error:

Hi Gabriel,

Thanks for the report!  It's probably better to fix this properly
rather than hack it as I did for NET.

Linus, please apply:

Gabriel C reports lguest doesn't compile with CONFIG_BLOCK=n.  Fix
this by introducing a config var for the block device, which depends
on LGUEST && BLOCK.  Do the same for the net driver, rather then
depending gratuitously on CONFIG_NET.

Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>

diff -r 9e987fcabb16 drivers/block/Makefile
--- a/drivers/block/MakefileMon Jul 30 09:47:25 2007 +1000
+++ b/drivers/block/MakefileMon Jul 30 10:02:32 2007 +1000
@@ -31,4 +31,4 @@ obj-$(CONFIG_BLK_DEV_UB)  += ub.o
 obj-$(CONFIG_BLK_DEV_UB)   += ub.o
 
 obj-$(CONFIG_XEN_BLKDEV_FRONTEND)  += xen-blkfront.o
-obj-$(CONFIG_LGUEST_GUEST) += lguest_blk.o
+obj-$(CONFIG_LGUEST_BLOCK) += lguest_blk.o
diff -r 9e987fcabb16 drivers/lguest/Kconfig
--- a/drivers/lguest/KconfigMon Jul 30 09:47:25 2007 +1000
+++ b/drivers/lguest/KconfigMon Jul 30 10:03:39 2007 +1000
@@ -1,6 +1,6 @@ config LGUEST
 config LGUEST
tristate "Linux hypervisor example code"
-   depends on X86 && PARAVIRT && NET && EXPERIMENTAL && !X86_PAE
+   depends on X86 && PARAVIRT && EXPERIMENTAL && !X86_PAE
select LGUEST_GUEST
select HVC_DRIVER
---help---
@@ -18,3 +18,11 @@ config LGUEST_GUEST
  The guest needs code built-in, even if the host has lguest
  support as a module.  The drivers are tiny, so we build them
  in too.
+
+config LGUEST_NET
+   tristate
+   depends on LGUEST_GUEST && NET
+
+config LGUEST_BLOCK
+   tristate
+   depends on LGUEST_GUEST && BLOCK
diff -r 9e987fcabb16 drivers/net/Makefile
--- a/drivers/net/Makefile  Mon Jul 30 09:47:25 2007 +1000
+++ b/drivers/net/Makefile  Mon Jul 30 10:02:22 2007 +1000
@@ -177,7 +177,7 @@ obj-$(CONFIG_HPLANCE) += hplance.o 7990.
 obj-$(CONFIG_HPLANCE) += hplance.o 7990.o
 obj-$(CONFIG_MVME147_NET) += mvme147.o 7990.o
 obj-$(CONFIG_EQUALIZER) += eql.o
-obj-$(CONFIG_LGUEST_GUEST) += lguest_net.o
+obj-$(CONFIG_LGUEST_NET) += lguest_net.o
 obj-$(CONFIG_MIPS_JAZZ_SONIC) += jazzsonic.o
 obj-$(CONFIG_MIPS_AU1X00_ENET) += au1000_eth.o
 obj-$(CONFIG_MIPS_SIM_NET) += mipsnet.o


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 0/2] Introduce CONFIG_HIBERNATION and CONFIG_SUSPEND (updated)

2007-07-29 Thread Linus Torvalds


Ok, I took this, and modified Len's patch to re-introduce ACPI_SLEEP on 
top of it (I took the easy way out, and just made PM_SLEEP imply 
ACPI_SLEEP, which should make everything come out right. I could have 
dropped ACPI_SLEEP entirely in favour of PM_SLEEP, but that would have 
implied changing more of Len's patch than I was really comfy with).

Len, Rafael, please do check that the end result looks ok. 

I suspect ACPI could now take the PM_SLEEP/SUSPEND/HIBERNATE details into 
account, and that some of the code is not necessary when HIBERNATE is not 
selected, for example, but I'm not at all sure that it's worth it being 
very fine-grained.

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] Remove fs.h from mm.h

2007-07-29 Thread Linus Torvalds


On Mon, 30 Jul 2007, Alexey Dobriyan wrote:
> 
> Cross-compile tested without regressions on my two usual configs and (sigh):
> 
> alpha  arm-mx1adsmips-bigsur  powerpc-ebony
..

Heh. 

Kudos for going above and beyond.

"But where is blackfin and frv?"

Thanks,

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] m68knommu: Get rid of duplicate include

2007-07-29 Thread Greg Ungerer

Hi Jesper,

Jesper Juhl wrote:
This patch removes the duplicate inclusion of asm/irq.h 
from arch/m68knommu/platform/5206e/config.c


You can add my acked by:

Acked-by: Greg Ungerer <[EMAIL PROTECTED]>



Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---

 arch/m68knommu/platform/5206e/config.c |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/arch/m68knommu/platform/5206e/config.c 
b/arch/m68knommu/platform/5206e/config.c
index 4ab614f..425703f 100644
--- a/arch/m68knommu/platform/5206e/config.c
+++ b/arch/m68knommu/platform/5206e/config.c
@@ -20,7 +20,6 @@
 #include 
 #include 
 #include 
-#include 
 
 /***/
 






--

Greg Ungerer  --  Chief Software Dude   EMAIL: [EMAIL PROTECTED]
Secure Computing CorporationPHONE:   +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Linus 2.6.23-rc1

2007-07-29 Thread Linus Torvalds


On Mon, 30 Jul 2007, George Sescher wrote:
> 
> He said having reality checks is a good thing. He's encouraging some
> poor bastard to maintain plugsched out of mainline to have SD or
> whatever to compare to.

My bad, it was me who  misread that (I didn't react to the name, I was 
thinking people were talking about maintaining SD that way).

Mea culpa.

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 0/3] core_pattern: cleaned up repost/continuing post of core_pattern enhancements

2007-07-29 Thread Eugene Teo
Hi Martin,

Martin Pitt wrote:
> Eugene Teo [2007-07-29 21:03 +0800]:
 Also, it is probably good to think how we can "drop privileges" while 
 piping
 the core dump output to an external program. A malicious user can 
 potentially
 use it as a possible backdoor since anything that is executed by 
 "|program" will
 be executed with root privileges.

>>> It was my understanding that apport already did this.
>> I haven't looked at apport yet, but are you talking about the userspace 
>> portion of
>> apport or the kernel changes in the Ubuntu kernel?
> 
> Similarly to Neil's patches, the Ubuntu kernel calls the userspace
> helper as root, too. Apport drops privileges to the target process as
> soon as possible (there are a few things it needs to do before, like
> opening an fd to the crash file in /var/crash/ if that is only
> writeable by root).

Just sharing some thoughts. Wouldn't it be more logical to drop the privileges 
first,
then call the userspace helper program? I know that this will limit tools like 
apport
to be able to read and/or write files that are only writable by root, but there 
ought
to be a better way to do this? What if the program piped is not a legitimate 
program?

Also, maybe it is good to make this portion of the code optional too, so that 
if no
one is using this "ispipe" feature, we just turn it off.

Eugene
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Linus 2.6.23-rc1

2007-07-29 Thread George Sescher
> On Mon, 30 Jul 2007, George Sescher wrote:
> > 
> >
> > You're advocating plugsched now?

On 30/07/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> I'd suggest people here take a look at the code. It's not what Ingo was
> saying, and it's not what the code is set up to do. He's just stating that
> the way he split up the files, it's actually easier from a patching
> standpoint to just create a new file to include instead of
> "kernel/sched_fair.c".



Ingo's origiinal comment:

On 30/07/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> i'd encourage you to do it - in fact i already tried to prod Peter
> Williams into doing exactly that ;) The more reality checks a scheduler
> has, the better.

He said having reality checks is a good thing. He's encouraging some
poor bastard to maintain plugsched out of mainline to have SD or
whatever to compare to. I did not say I advocated anything whatsoever.
I was asking if this is what Ingo is suggesting people use their
energy doing. Not good enough for mainline, but definitely worth
keeping around and good enough for... no idea what. I was asking Ingo
that.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: cpufreq scaling appears not to work on overclocked systems

2007-07-29 Thread Dave Jones
On Sun, Jul 29, 2007 at 03:16:45PM -0600, Berck E. Nash wrote:

 > I'm running a Core2 Duo 1.86GHz overclocked to 2.56GHz.  Everything is
 > normal with cpufreq scaling disabled.  With cpufreq scaling enabled in
 > the kernel, using any governor, /proc/cpuinfo indicates a maximum of the
 > rated frequency rather than the actual frequency.

FAQ.
The BIOS contains hard coded tables of frequencies.
Just because you changed the clocks on which those tables
are based doesn't mean the tables will change.

Not a bug.

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Fwd: [PATCH] Reboot Dreamcast under software control

2007-07-29 Thread Paul Mundt
On Mon, Jul 30, 2007 at 12:05:31AM +0100, Adrian McMenamin wrote:
> On Mon, 2007-07-30 at 07:50 +0900, Paul Mundt wrote:
> > On Sun, Jul 29, 2007 at 07:25:21PM +0100, Adrian McMenamin wrote:
> > > diff --git a/arch/sh/kernel/process.c b/arch/sh/kernel/process.c
> > > index 6334a4c..6f5e9e4 100644
> > > --- a/arch/sh/kernel/process.c
> > > +++ b/arch/sh/kernel/process.c
> > > @@ -97,6 +97,11 @@ void cpu_idle(void)
> > > 
> > >  void machine_restart(char * __unused)
> > >  {
> > > +
> > > +#ifdef CONFIG_SH_DREAMCAST
> > > +   /*reboot the Dreamcast under software control*/
> > > +   writel(0x7611, 0xA05F6890);
> > > +#endif
> > > /* SR.BL=1 and invoke address error to let CPU reset (manual 
> > > reset) */
> > > asm volatile("ldc %0, sr\n\t"
> > >  "mov.l @%1, %0" : : "r" (0x1000), "r" 
> > > (0x8001));
> > 
> > No, if you want to do this, at least use a function pointer and leave
> > this as the default implementation. The dreamcast presumably only needs
> > this magic write anyways, rather than the SR.BL trick.
> > 
> 
> Well, when I tested it, it did have a "return" in after the call and it
> worked - but I took that out as it looked like code bloat to me :)
> 
> Explain what you mean by using a function pointer and I'll do that.
> 
Look at the other implementations that are overloaded by the boards.
machine_power_off, the idle loop, etc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Linus 2.6.23-rc1

2007-07-29 Thread Linus Torvalds


On Mon, 30 Jul 2007, George Sescher wrote:
> 
> 
> You're advocating plugsched now?

I'd suggest people here take a look at the code. It's not what Ingo was 
saying, and it's not what the code is set up to do. He's just stating that 
the way he split up the files, it's actually easier from a patching 
standpoint to just create a new file to include instead of 
"kernel/sched_fair.c".

But quite frankly, I've seen a lot of totally stupid flamage, and very 
little actual sense in this discussion. People probably didn't even look 
at the patches. Did you?

For example, how hard is it for people to just admit that CFS actually 
does better than SD on a number of things? Including very much on the 
desktop. 

Ingo posted numbers. Look at those numbers, and then I would suggest some 
people could seriously consider just shutting up. I've seen too many 
idiotic people who claim that Con got treated unfairly, without those 
people admitting that maybe I had a point when I said that we have had a 
scheduler maintainer for years that actually knows what he's doing.

And no, it has never been about "desktop" vs "servers", or similar 
claptrap. It's been about improving the scheduler.

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Fwd: [PATCH] Reboot Dreamcast under software control

2007-07-29 Thread Adrian McMenamin
On Mon, 2007-07-30 at 07:50 +0900, Paul Mundt wrote:
> On Sun, Jul 29, 2007 at 07:25:21PM +0100, Adrian McMenamin wrote:
> > diff --git a/arch/sh/kernel/process.c b/arch/sh/kernel/process.c
> > index 6334a4c..6f5e9e4 100644
> > --- a/arch/sh/kernel/process.c
> > +++ b/arch/sh/kernel/process.c
> > @@ -97,6 +97,11 @@ void cpu_idle(void)
> > 
> >  void machine_restart(char * __unused)
> >  {
> > +
> > +#ifdef CONFIG_SH_DREAMCAST
> > +   /*reboot the Dreamcast under software control*/
> > +   writel(0x7611, 0xA05F6890);
> > +#endif
> > /* SR.BL=1 and invoke address error to let CPU reset (manual reset) 
> > */
> > asm volatile("ldc %0, sr\n\t"
> >  "mov.l @%1, %0" : : "r" (0x1000), "r" 
> > (0x8001));
> 
> No, if you want to do this, at least use a function pointer and leave
> this as the default implementation. The dreamcast presumably only needs
> this magic write anyways, rather than the SR.BL trick.
> 

Well, when I tested it, it did have a "return" in after the call and it
worked - but I took that out as it looked like code bloat to me :)

Explain what you mean by using a function pointer and I'll do that.

Adrian
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Linus 2.6.23-rc1

2007-07-29 Thread George Sescher
> * Kasper Sandberg <[EMAIL PROTECTED]> wrote:
> > [...] As far as im concerned, i may be forced to unofficially maintain
> > SD for my own systems(allthough lots in the gaming community is bound
> > to be interrested, as it does make games lots better)

On 30/07/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> i'd encourage you to do it - in fact i already tried to prod Peter
> Williams into doing exactly that ;) The more reality checks a scheduler
> has, the better. [ Btw., after the obvious initial merging trouble it
> should be much easier to keep SD maintained against future upstream
> kernels due to the policy modularity that CFS introduces. (and which
> policy-modularity should also help reduce the size and complexity of the
> SD patch.) ]



You're advocating plugsched now?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] powerpc: clean out a bunch of duplicate includes

2007-07-29 Thread Benjamin Herrenschmidt
On Mon, 2007-07-30 at 00:18 +0200, Jesper Juhl wrote:
> Hi,
> 
> Here's a patch to clean out a bunch of duplicate includes from 
> arch/powerpc/
> 
> Please consider for inclusion.

Ah.. historical stuff stacking up :-)

> 
> Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>

Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>

> ---
> 
>  arch/powerpc/kernel/btext.c|1 -
>  arch/powerpc/kernel/crash.c|1 -
>  arch/powerpc/kernel/iommu.c|1 -
>  arch/powerpc/kernel/prom.c |1 -
>  arch/powerpc/kernel/time.c |1 -
>  arch/powerpc/mm/hash_utils_64.c|1 -
>  arch/powerpc/mm/hugetlbpage.c  |3 ---
>  arch/powerpc/mm/init_32.c  |1 -
>  arch/powerpc/mm/mem.c  |1 -
>  arch/powerpc/platforms/52xx/mpc52xx_pic.c  |1 -
>  arch/powerpc/platforms/chrp/setup.c|1 -
>  arch/powerpc/platforms/chrp/smp.c  |1 -
>  arch/powerpc/platforms/iseries/setup.c |1 -
>  arch/powerpc/platforms/powermac/low_i2c.c  |1 -
>  arch/powerpc/platforms/powermac/udbg_adb.c |1 -
>  arch/powerpc/platforms/pseries/lpar.c  |1 -
>  16 files changed, 0 insertions(+), 18 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/btext.c b/arch/powerpc/kernel/btext.c
> index e7b6846..3ef51fb 100644
> --- a/arch/powerpc/kernel/btext.c
> +++ b/arch/powerpc/kernel/btext.c
> @@ -11,7 +11,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> diff --git a/arch/powerpc/kernel/crash.c b/arch/powerpc/kernel/crash.c
> index 37658ea..77c749a 100644
> --- a/arch/powerpc/kernel/crash.c
> +++ b/arch/powerpc/kernel/crash.c
> @@ -24,7 +24,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  
>  #include 
>  #include 
> diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
> index c08ceca..e4ec6ee 100644
> --- a/arch/powerpc/kernel/iommu.c
> +++ b/arch/powerpc/kernel/iommu.c
> @@ -30,7 +30,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
> index a38197b..0028fe6 100644
> --- a/arch/powerpc/kernel/prom.c
> +++ b/arch/powerpc/kernel/prom.c
> @@ -52,7 +52,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  
>  #ifdef DEBUG
>  #define DBG(fmt...) printk(KERN_ERR fmt)
> diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
> index 727a669..c85d9b0 100644
> --- a/arch/powerpc/kernel/time.c
> +++ b/arch/powerpc/kernel/time.c
> @@ -72,7 +72,6 @@
>  #include 
>  #include 
>  #endif
> -#include 
>  
>  /* keep track of when we need to update the rtc */
>  time_t last_rtc_update;
> diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
> index bc7b0ce..c2bf404 100644
> --- a/arch/powerpc/mm/hash_utils_64.c
> +++ b/arch/powerpc/mm/hash_utils_64.c
> @@ -49,7 +49,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  
> diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
> index 4835f73..ba5f12a 100644
> --- a/arch/powerpc/mm/hugetlbpage.c
> +++ b/arch/powerpc/mm/hugetlbpage.c
> @@ -22,11 +22,8 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  
> -#include 
> -
>  #define NUM_LOW_AREAS(0x1UL >> SID_SHIFT)
>  #define NUM_HIGH_AREAS   (PGTABLE_RANGE >> HTLB_AREA_SHIFT)
>  
> diff --git a/arch/powerpc/mm/init_32.c b/arch/powerpc/mm/init_32.c
> index e1f5ded..d65995a 100644
> --- a/arch/powerpc/mm/init_32.c
> +++ b/arch/powerpc/mm/init_32.c
> @@ -41,7 +41,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  
> diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
> index f0e7eed..32dcfc9 100644
> --- a/arch/powerpc/mm/mem.c
> +++ b/arch/powerpc/mm/mem.c
> @@ -42,7 +42,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> diff --git a/arch/powerpc/platforms/52xx/mpc52xx_pic.c 
> b/arch/powerpc/platforms/52xx/mpc52xx_pic.c
> index fbfff95..8c464c5 100644
> --- a/arch/powerpc/platforms/52xx/mpc52xx_pic.c
> +++ b/arch/powerpc/platforms/52xx/mpc52xx_pic.c
> @@ -22,7 +22,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> diff --git a/arch/powerpc/platforms/chrp/setup.c 
> b/arch/powerpc/platforms/chrp/setup.c
> index 373de4c..dde5ef4 100644
> --- a/arch/powerpc/platforms/chrp/setup.c
> +++ b/arch/powerpc/platforms/chrp/setup.c
> @@ -32,7 +32,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  
>  #include 
> diff --git a/arch/powerpc/platforms/chrp/smp.c 
> b/arch/powerpc/platforms/chrp/smp.c
> index 3ea0eb7..a137d13 100644
> --- a/arch/powerpc/platforms/chrp/smp.c
> +++ b/arch/powerpc/platforms/chrp/smp.c
> @@ -29,7 +29,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  
> diff 

Re: RFC: Remove the arm26 port

2007-07-29 Thread ian
On Sun, 2007-07-29 at 13:50 +0200, Adrian Bunk wrote:
> Considering the state of the arm26 port, I do hereby suggest to remove 
> it from the Linx kernel since it's far from a usable state and doesn't 
> seem to come back into a usable state.
> 
> If anyone wants to work on getting this port back into a usable state in 
> the forseeable future he should speak up now.

Hi guys.

Obviously I havent had time to work on the port in some time now - I am
ok with it being dropped - the work of splitting it out wont be lost and
until its fixed up, its just in other peoples way.

If I get time to work on it in future, I'll let you all know.

-Ian

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] drivers/bluetooth/hci_ldisc.c: fix possible NULL dereferences

2007-07-29 Thread Eugene Teo
Hi Marcel,

Marcel Holtmann wrote:
>> Commit 22ad42033b7d2b3d7928fba9f89d1c7f8a3c9581 did not completely fix all 
>> the possible NULL dereferences. Besides hci_uart_close(), we also need to 
>> make sure that hdev is valid before calling hci_{unregister,free}_dev().
> 
> I don't see any issue. Without HCI_UART_PROTO_SET, the hdev will never
> be registered. So no need to protect it twice.

Correct me if I am wrong. HCI_UART_PROTO_SET bit is only set if 
hci_uart_tty_ioctl()
is called with HCIUARTSETPROTO. Is it possible for the HCI device to be 
registered
and then unregistered without setting the HCI_UART_PROTO_SET bit in hdev->flags?

Thanks,
Eugene
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] sh64: arch/sh64/kernel/signal.h - duplicate include removal

2007-07-29 Thread Paul Mundt
On Mon, Jul 30, 2007 at 12:44:00AM +0200, Jesper Juhl wrote:
> This patch removes the duplicate inclusion of linux/personality.h 
> from arch/sh64/kernel/signal.c
> 
> Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>

Acked-by: Paul Mundt <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [GIT PATCH] SCSI bug fixes for 2.6.23-rc1

2007-07-29 Thread Jeff Garzik

James Bottomley wrote:

This is basically a set of bug fixes with a few minor cleanups thrown
in.  There are also a few bsg fixes we're taking through this tree
because SCSI is the current sole consumer. The reason for the huge size
is the lindent of the advansys driver along with a few cleanups.

The patch is available here:

master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6.git



You missed
[SCSI] arcmsr: Fix hardware wait loops

Jeff


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [Linux-usb-users] [REGRESSION] 2.6.23-rc1: uhci_hcd. irq 4: nobody cared

2007-07-29 Thread Alan Stern
On Sun, 29 Jul 2007, Mark Hindley wrote:

> On Sun, Jul 29, 2007 at 11:19:47AM -0400, Alan Stern wrote:
> > On Sun, 29 Jul 2007, Mark Hindley wrote:
> > 
> > > Hi,
> > > 
> > > I have just tried 2.6.23-rc1 on my Acer Aspire 1350.
> > > 
> > > On boot I get the following error as the uhci_hcd module is loaded:
> > > 
> > > Jul 28 18:23:20 mercury kernel: ACPI: PCI Interrupt :00:10.0[A] -> 
> > > Link [LNKA] -> GSI 4 (level, low) -> IRQ 4
> > > Jul 28 18:23:20 mercury kernel: uhci_hcd :00:10.0: UHCI Host 
> > > Controller
> > > Jul 28 18:23:20 mercury kernel: uhci_hcd :00:10.0: new USB bus 
> > > registered, assigned bus number 2
> > > Jul 28 18:23:20 mercury kernel: irq 4: nobody cared (try booting with the 
> > > "irqpoll" option)
> > 
> > Did it work okay with older kernels?  What does /proc/interrupts say in 
> > both 2.6.23-rc1 and in a working kernel?
> 
> No boot error with 2.6.22.1.
> 
> On 2.6.22.1:
>CPU0   
>   0:  12312XT-PIC-XTtimer
>   1:286XT-PIC-XTi8042
>   2:  0XT-PIC-XTcascade
>   4:434XT-PIC-XTuhci_hcd:usb2, [EMAIL 
> PROTECTED]::01:00.0
>   5:   2000XT-PIC-XTyenta, uhci_hcd:usb3, wifi0
>   6:  3XT-PIC-XTfloppy
>   7:  3XT-PIC-XTparport0
>   8:  4XT-PIC-XTrtc
>   9:  0XT-PIC-XTuhci_hcd:usb4, VIA82XX-MODEM, VIA8233
>  10:843XT-PIC-XTacpi
>  11:  0XT-PIC-XTehci_hcd:usb1
>  12:123XT-PIC-XTi8042
>  14:  10951XT-PIC-XTide0
>  15: 53XT-PIC-XTide1
> NMI:770 
> LOC: 120091 
> ERR:  0
> MIS:  0
> 
> On 2.6.23-rc1:
>CPU0   
>   0:   8616XT-PIC-XTtimer
>   1:183XT-PIC-XTi8042
>   2:  0XT-PIC-XTcascade
>   4:   8233XT-PIC-XTuhci_hcd:usb1, [EMAIL 
> PROTECTED]::01:00.0
>   5:   4948XT-PIC-XTuhci_hcd:usb2, yenta, wifi0
>   6:  3XT-PIC-XTfloppy
>   7: 22XT-PIC-XTparport0
>   8:  4XT-PIC-XTrtc
>   9:  0XT-PIC-XTuhci_hcd:usb3, VIA82XX-MODEM, VIA8233
>  10:854XT-PIC-XTacpi
>  11:  0XT-PIC-XTehci_hcd:usb4
>  12:123XT-PIC-XTi8042
>  14:  12202XT-PIC-XTide0
>  15: 53XT-PIC-XTide1
> NMI:809 
> LOC: 150284 
> ERR:  1
> MIS:  0

No significant differences.  :-(

Well, about all I can suggest is bisection.  And don't assume that this 
problem was caused by a change to the USB stack.  It could be a change 
in the interrupt-handling core or a change to the driver for one of the 
other devices sharing the IRQ.

It might even be caused by a change in the order the modules are 
loaded, which has nothing to do with the kernel directly.  In fact, it 
might be worth checking this possibility first.  For example, it's 
clear that 2.6.22 loaded ehci-hcd before uhci-hcd whereas 2.6.23-rc1 
did the reverse.  And yenta vs. uhci-hcd is different.

Alan Stern

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Fwd: [PATCH] Reboot Dreamcast under software control

2007-07-29 Thread Paul Mundt
On Sun, Jul 29, 2007 at 07:25:21PM +0100, Adrian McMenamin wrote:
> diff --git a/arch/sh/kernel/process.c b/arch/sh/kernel/process.c
> index 6334a4c..6f5e9e4 100644
> --- a/arch/sh/kernel/process.c
> +++ b/arch/sh/kernel/process.c
> @@ -97,6 +97,11 @@ void cpu_idle(void)
> 
>  void machine_restart(char * __unused)
>  {
> +
> +#ifdef CONFIG_SH_DREAMCAST
> +   /*reboot the Dreamcast under software control*/
> +   writel(0x7611, 0xA05F6890);
> +#endif
> /* SR.BL=1 and invoke address error to let CPU reset (manual reset) */
> asm volatile("ldc %0, sr\n\t"
>  "mov.l @%1, %0" : : "r" (0x1000), "r" (0x8001));

No, if you want to do this, at least use a function pointer and leave
this as the default implementation. The dreamcast presumably only needs
this magic write anyways, rather than the SR.BL trick.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] sh64: arch/sh64/kernel/signal.h - duplicate include removal

2007-07-29 Thread Jesper Juhl
Hi,

This patch removes the duplicate inclusion of linux/personality.h 
from arch/sh64/kernel/signal.c


Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---

diff --git a/arch/sh64/kernel/signal.c b/arch/sh64/kernel/signal.c
index 0bb4a8f..79fc48c 100644
--- a/arch/sh64/kernel/signal.c
+++ b/arch/sh64/kernel/signal.c
@@ -25,7 +25,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] Remove fs.h from mm.h

2007-07-29 Thread Alexey Dobriyan
0) Remove fs.h from mm.h. For this,
1) Uninline vma_wants_writenotify(). It's pretty huge anyway.
2) Add back fs.h or less bloated headers (err.h) to files that need it.

As result, on x86_64 allyesconfig, fs.h dependencies cut down from 3929 files
rebuilt down to 3444 (-12.3%).

Cross-compile tested without regressions on my two usual configs and (sigh):

alpha  arm-mx1adsmips-bigsur  powerpc-ebony
alpha-allnoconfig  arm-neponset  mips-capcellapowerpc-g5
alpha-defconfigarm-netwinder mips-cobalt  powerpc-holly
alpha-up   arm-netx  mips-db1000  powerpc-iseries
armarm-ns9xxxmips-db1100  powerpc-linkstation
arm-assabetarm-omap_h2_1610  mips-db1200  powerpc-lite5200
arm-at91rm9200dk   arm-onearmmips-db1500  powerpc-maple
arm-at91rm9200ek   arm-picotux200mips-db1550  powerpc-mpc7448_hpc2
arm-at91sam9260ek  arm-pleb  mips-ddb5477 powerpc-mpc8272_ads
arm-at91sam9261ek  arm-pnx4008   mips-decstation  powerpc-mpc8313_rdb
arm-at91sam9263ek  arm-pxa255-idpmips-e55 powerpc-mpc832x_mds
arm-at91sam9rlek   arm-realview  mips-emma2rh powerpc-mpc832x_rdb
arm-ateb9200   arm-realview-smp  mips-excite  powerpc-mpc834x_itx
arm-badge4 arm-rpc   mips-fulong  powerpc-mpc834x_itxgp
arm-carmevaarm-s3c2410   mips-ip22powerpc-mpc834x_mds
arm-cerfcube   arm-shannon   mips-ip27powerpc-mpc836x_mds
arm-clps7500   arm-shark mips-ip32powerpc-mpc8540_ads
arm-collie arm-simpadmips-jazzpowerpc-mpc8544_ds
arm-corgi  arm-spitz mips-jmr3927 powerpc-mpc8560_ads
arm-csb337 arm-trizeps4  mips-malta   powerpc-mpc8568mds
arm-csb637 arm-versatile mips-mipssim powerpc-mpc85xx_cds
arm-ebsa110i386  mips-mpc30x  powerpc-mpc8641_hpcn
arm-edb7211i386-allnoconfig  mips-msp71xx powerpc-mpc866_ads
arm-em_x270i386-defconfigmips-ocelot  powerpc-mpc885_ads
arm-ep93xx i386-up   mips-pb1100  powerpc-pasemi
arm-footbridge ia64  mips-pb1500  powerpc-pmac32
arm-fortunet   ia64-allnoconfig  mips-pb1550  powerpc-ppc64
arm-h3600  ia64-bigsur   mips-pnx8550-jbs powerpc-prpmc2800
arm-h7201  ia64-defconfigmips-pnx8550-stb810  powerpc-ps3
arm-h7202  ia64-gensparsemips-qemupowerpc-pseries
arm-hackkitia64-sim  mips-rbhma4200   powerpc-up
arm-integrator ia64-sn2  mips-rbhma4500   s390
arm-iop13xxia64-tigermips-rm200   s390-allnoconfig
arm-iop32x ia64-up   mips-sb1250-swarms390-defconfig
arm-iop33x ia64-zx1  mips-seads390-up
arm-ixp2000m68k  mips-tb0219  sparc
arm-ixp23xxm68k-amigamips-tb0226  sparc-allnoconfig
arm-ixp4xx m68k-apollo   mips-tb0287  sparc-defconfig
arm-jornada720 m68k-atarimips-workpad sparc-up
arm-kafa   m68k-bvme6000 mips-wrppmc  sparc64
arm-kb9202 m68k-hp300mips-yosemitesparc64-allnoconfig
arm-ks8695 m68k-mac  parisc   sparc64-defconfig
arm-lart   m68k-mvme147  parisc-allnoconfig   sparc64-up
arm-lpd270 m68k-mvme16x  parisc-defconfig um-x86_64
arm-lpd7a400   m68k-q40  parisc-upx86_64
arm-lpd7a404   m68k-sun3 powerpc  x86_64-allnoconfig
arm-lubbockm68k-sun3xpowerpc-cell x86_64-defconfig
arm-lusl7200   mips  powerpc-celleb   x86_64-up
arm-mainstone  mips-atlaspowerpc-chrp32

Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
---

 arch/alpha/kernel/smp.c|1 
 arch/arm/kernel/setup.c|1 
 arch/arm/kernel/smp.c  |1 
 arch/frv/kernel/sys_frv.c  |1 
 arch/i386/kernel/microcode.c   |1 
 arch/i386/kernel/sys_i386.c|1 
 arch/i386/kernel/sysenter.c|1 
 arch/ia64/kernel/init_task.c   |1 
 arch/m68k/kernel/process.c |1 
 arch/m68k/kernel/sys_m68k.c|1 
 arch/mips/kernel/smp.c |1 
 arch/mips/kernel/syscall.c |1 
 arch/parisc/hpux/fs.c  |1 
 arch/parisc/kernel/init_task.c |1 
 arch/parisc/kernel/process.c   |1 
 arch/parisc/kernel/smp.c   |1 
 arch/powerpc/kernel/syscalls.c |1 
 arch/powerpc/lib/rheap.c   |1 
 arch/powerpc/oprofile/cell/spu_task_sync.c |

[PATCH] ia64: Remove a few duplicate includes

2007-07-29 Thread Jesper Juhl
(sorry about the duplicate mail, forgot a recipient first time)

Hi,


This patch removes a few duplicate includes from arch/ia64/


Please consider merging :-)



Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---

 arch/ia64/ia32/sys_ia32.c   |1 -
 arch/ia64/kernel/setup.c|1 -
 arch/ia64/sn/kernel/setup.c |1 -
 3 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/arch/ia64/ia32/sys_ia32.c b/arch/ia64/ia32/sys_ia32.c
index af10462..a3405b3 100644
--- a/arch/ia64/ia32/sys_ia32.c
+++ b/arch/ia64/ia32/sys_ia32.c
@@ -34,7 +34,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/ia64/kernel/setup.c b/arch/ia64/kernel/setup.c
index 7cecd29..cd9a37a 100644
--- a/arch/ia64/kernel/setup.c
+++ b/arch/ia64/kernel/setup.c
@@ -60,7 +60,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #if defined(CONFIG_SMP) && (IA64_CPU_SIZE > PAGE_SIZE)
 # error "struct cpuinfo_ia64 too big!"
diff --git a/arch/ia64/sn/kernel/setup.c b/arch/ia64/sn/kernel/setup.c
index 684b1c9..1f38a3a 100644
--- a/arch/ia64/sn/kernel/setup.c
+++ b/arch/ia64/sn/kernel/setup.c
@@ -25,7 +25,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] powerpc: clean out a bunch of duplicate includes

2007-07-29 Thread Jesper Juhl
Hi,

Here's a patch to clean out a bunch of duplicate includes from 
arch/powerpc/

Please consider for inclusion.


Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---

 arch/powerpc/kernel/btext.c|1 -
 arch/powerpc/kernel/crash.c|1 -
 arch/powerpc/kernel/iommu.c|1 -
 arch/powerpc/kernel/prom.c |1 -
 arch/powerpc/kernel/time.c |1 -
 arch/powerpc/mm/hash_utils_64.c|1 -
 arch/powerpc/mm/hugetlbpage.c  |3 ---
 arch/powerpc/mm/init_32.c  |1 -
 arch/powerpc/mm/mem.c  |1 -
 arch/powerpc/platforms/52xx/mpc52xx_pic.c  |1 -
 arch/powerpc/platforms/chrp/setup.c|1 -
 arch/powerpc/platforms/chrp/smp.c  |1 -
 arch/powerpc/platforms/iseries/setup.c |1 -
 arch/powerpc/platforms/powermac/low_i2c.c  |1 -
 arch/powerpc/platforms/powermac/udbg_adb.c |1 -
 arch/powerpc/platforms/pseries/lpar.c  |1 -
 16 files changed, 0 insertions(+), 18 deletions(-)

diff --git a/arch/powerpc/kernel/btext.c b/arch/powerpc/kernel/btext.c
index e7b6846..3ef51fb 100644
--- a/arch/powerpc/kernel/btext.c
+++ b/arch/powerpc/kernel/btext.c
@@ -11,7 +11,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/powerpc/kernel/crash.c b/arch/powerpc/kernel/crash.c
index 37658ea..77c749a 100644
--- a/arch/powerpc/kernel/crash.c
+++ b/arch/powerpc/kernel/crash.c
@@ -24,7 +24,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include 
 #include 
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index c08ceca..e4ec6ee 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -30,7 +30,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index a38197b..0028fe6 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -52,7 +52,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #ifdef DEBUG
 #define DBG(fmt...) printk(KERN_ERR fmt)
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index 727a669..c85d9b0 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -72,7 +72,6 @@
 #include 
 #include 
 #endif
-#include 
 
 /* keep track of when we need to update the rtc */
 time_t last_rtc_update;
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index bc7b0ce..c2bf404 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -49,7 +49,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index 4835f73..ba5f12a 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -22,11 +22,8 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
-#include 
-
 #define NUM_LOW_AREAS  (0x1UL >> SID_SHIFT)
 #define NUM_HIGH_AREAS (PGTABLE_RANGE >> HTLB_AREA_SHIFT)
 
diff --git a/arch/powerpc/mm/init_32.c b/arch/powerpc/mm/init_32.c
index e1f5ded..d65995a 100644
--- a/arch/powerpc/mm/init_32.c
+++ b/arch/powerpc/mm/init_32.c
@@ -41,7 +41,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index f0e7eed..32dcfc9 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -42,7 +42,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_pic.c 
b/arch/powerpc/platforms/52xx/mpc52xx_pic.c
index fbfff95..8c464c5 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_pic.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_pic.c
@@ -22,7 +22,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/powerpc/platforms/chrp/setup.c 
b/arch/powerpc/platforms/chrp/setup.c
index 373de4c..dde5ef4 100644
--- a/arch/powerpc/platforms/chrp/setup.c
+++ b/arch/powerpc/platforms/chrp/setup.c
@@ -32,7 +32,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include 
diff --git a/arch/powerpc/platforms/chrp/smp.c 
b/arch/powerpc/platforms/chrp/smp.c
index 3ea0eb7..a137d13 100644
--- a/arch/powerpc/platforms/chrp/smp.c
+++ b/arch/powerpc/platforms/chrp/smp.c
@@ -29,7 +29,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
diff --git a/arch/powerpc/platforms/iseries/setup.c 
b/arch/powerpc/platforms/iseries/setup.c
index 13a8b19..fad493e 100644
--- a/arch/powerpc/platforms/iseries/setup.c
+++ b/arch/powerpc/platforms/iseries/setup.c
@@ -41,7 +41,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/powerpc/platforms/powermac/low_i2c.c 
b/arch/powerpc/platforms/powermac/low_i2c.c
index efdf5eb..da2007e 100644
--- a/arch/powerpc/platforms/powermac/low_i2c.c
+++ 

Re: Reading a bad sector does not report failure as 'read error' but hangs PC with 'Machine Check Exception'

2007-07-29 Thread Hendrik .
Ok, I did actually not copy the coreret code in the
mcelog, leaving me some errors about the Northbridge.
If I do it again it gives me something else. I made 2
digital photo's of 2 lockups when it happened and this
is the result of the tool, the TSC is different in
both errors, the rest is the same:


CPU 0 4 northbridge TSC b7d4a144d0 
  Northbridge Watchdog error
   bit57 = processor context corrupt
   bit61 = error uncorrected
  bus error 'generic participation, request timed out
  generic error mem transaction
  generic access, level generic'
STATUS b2070f0f MCGSTATUS 4
This is not a software problem!

CPU 0 4 northbridge TSC c4dd3a549f 
  Northbridge Watchdog error
   bit57 = processor context corrupt
   bit61 = error uncorrected
  bus error 'generic participation, request timed out
  generic error mem transaction
  generic access, level generic'
STATUS b2070f0f MCGSTATUS 4
This is not a software problem!


It's a bit strange but if I copy the results from my
first post I get the Northbridge error, perhaps
because there is an 'enter' between the first line
with the 'bank 4' and the 'b2070f0f' line. The
mcelog tool handles this different from the error in 1
line. 

Regards,
Hendrik


   

Got a little couch potato? 
Check out fun summer activities for kids.
http://search.yahoo.com/search?fr=oni_on_mail=summer+activities+for+kids=bz
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 2/2] Introduce CONFIG_SUSPEND

2007-07-29 Thread Rafael J. Wysocki
On Sunday, 29 July 2007 23:30, Richard Hughes wrote:
> On Sun, 2007-07-29 at 23:36 +0200, Rafael J. Wysocki wrote:
> > On Sunday, 29 July 2007 23:18, Adrian Bunk wrote:
> > > On Sun, Jul 29, 2007 at 11:17:20PM +0200, Rafael J. Wysocki wrote:
> > > > On Sunday, 29 July 2007 22:40, Adrian Bunk wrote:
> > > > > On Sun, Jul 29, 2007 at 02:38:05PM +0200, Rafael J. Wysocki wrote:
> > > > > >...
> > > > > > +config SUSPEND
> > > > > > +   bool "Suspend"
> > > > >  "Suspend to RAM"
> > > > 
> > > > Not only.  This also includes "standby".
> > > 
> > > Whatever it includes - please tell it to the user in the prompt.
> > > 
> > > Technical issues are important, but it's often forgotten how many 
> > > problems people run into because the description of a kconfig option 
> > > could have been better.
> > 
> > Sure.  Please see the updated patch I've just sent. :-)
> 
> So are you guys using:
> 
> "standby" = idle state, ~0.5 seconds
> "suspend" = sleep to ram, ~10 seconds
> "hibernate" = sleep to disk, ~30 seconds

Something like this, but "suspend" is not reserved as a name of specific state.

The second state is usually referred to as "suspend to RAM" or "STR" and is
denoted by "mem" in /sys/power/state, if implemented.  Moreover, "standby" and
"mem" are both entered using the same code path, so they may generally be
referred to as "suspend" states.

The times aren't strictly defined for "mem" and "standby", too.  The general
rule is that the times for "mem" are greater then for "standby" and the power
drawn in "mem" is smaller than the power drawn in "standby", but the exact
values will always depend on the platform.  Apart from this, if the platform
supports only one "suspend" state, it decides if that's "mem" or "standby".

On ACPI systems "standby" and "mem" correspond to the S1 and S3 sleep states,
respectively.

Greetings,
Rafael
 

-- 
"Premature optimization is the root of all evil." - Donald Knuth
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 1/5] Use mutex instead of semaphore in the Host AP driver

2007-07-29 Thread Michael Buesch
On Sunday 29 July 2007 23:34, Matthias Kaehlcke wrote:
> The Host AP driver uses a semaphore as mutex. Use the mutex API
> instead of the (binary) semaphore.
> 
> Signed-off-by: Matthias Kaehlcke <[EMAIL PROTECTED]>
> 
> --
> 
> - res = down_interruptible(>rid_bap_sem);
> + res = mutex_lock_interruptible(>rid_bap_mtx);
>   if (res)
>   return res;
>  
> @@ -902,7 +902,7 @@ static int hfa384x_set_rid(struct net_device *dev, u16 
> rid, void *buf, int len)
>   /* RID len in words and +1 for rec.rid */
>   rec.len = cpu_to_le16(len / 2 + len % 2 + 1);
>  
> - res = down_interruptible(>rid_bap_sem);
> + res = mutex_lock_interruptible(>rid_bap_mtx);
>   if (res)
>   return res;
>  

Is res returned to userspace? If yes, that's not right.
On a interrupted mutex allocation you should return
-ERESTARTSYS to userspace.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Power Management framework proposal

2007-07-29 Thread david

On Fri, 27 Jul 2007, Pavel Machek wrote:


Hi!


example 1: a laptop screen

mode  capacity power description
000off
1  100  100full brightness
2   70   60half power to the backlight
3   50   35quarter power to the backlight
4   30   25eighth power to the backlight
55   10backlight off.

example 2: a front-panel display on a server (no
variable backlight
control)

mode capacity power description
0   00   off
1 100  100   backlight on
2  50   10   backlight off



the problem is: the person who SETS these needs to know
what they mean.


that's what the description is for. this info can be
provided by the driver as part of the list_modes()
function.


That's what /sys/class/backlight/ is for :-).


yes it is, and each type of device is growing it's own, incompatible, 
interfaces for controlling things like this. I was aiming to do two 
things.


1. head this off and try and get a more common api

2. simplify the confusion that there is with multiple functions needing to 
be implemented during the suspend/resume cycle by chaning them from 
independant suspend-only functions to being just part of the device 
settings



as someone who wrote (part of) a power policy manager;
sorry but you
take away information I need, and in addition the
different API's are
absolutely no big deal.


assuming that nobody else chimes in to disagree with you
I'll accept your judgement and drop the issue.


Just for the record, I agree with Arjan here.


oh well. sorry to take up everyone's time.

David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Sparc32 not working:2.6.23-rc1 (git commit 1e4dcd22efa7d24f637ab2ea3a77dd65774eb005)

2007-07-29 Thread Mark Fortescue



On Sun, 29 Jul 2007, Adrian Bunk wrote:


On Sun, Jul 29, 2007 at 07:26:29PM +0100, Mark Fortescue wrote:

...
I am going to try to cherry pick a set of commits to see if I can't get a
better idear of where the memory corruption on sun4c is coming from. Build
problems sue to the DMA changes make git bisecting un-usable untill I have
found out which patches fix the DMA build issues.


You have any known-good kernel?

Boot back into this kernel for bisecting and compiling the kernels for
bisecting there.



As I said, bisecting does not work if you can't build the kernel because 
of un-defined symbols spanning most of the revisions you are interested 
in.


I have isolated the revisions that do not build so I should be able to 
cerry pick a commit/commits that fixes the build issues. Once done, I will 
be able to investigate the original issue.


If it were practical to do a build test on all supported platforms before 
submitting patches then this would not be so much of an issue but ...



cu
Adrian

--

  "Is there not promise of rain?" Ling Tan asked suddenly out
   of the darkness. There had been need of rain for many days.
  "Only a promise," Lao Er said.
  Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] pci_ids: additional NFORCE MCP61 devices - (resend)

2007-07-29 Thread Indrek Kruusa
This patch adds the following 7 Nforce devices:

- LPC Bridge (MCP61_LPC_BRG)
- Memory Controller (MCP61_MC1)
- High Definition Audio (MCP61_HDA)
- USB Controller (MCP61_OHCI)
- USB Controller (MCP61_EHCI)
- PCI bridge (MCP61_PCI_BRG)
- Memory Controller (MCP61_MC2)

to the pci_ids.h file.

Signed-off-by: Indrek Kruusa <[EMAIL PROTECTED]>

lspci output on Gigabyte GA-M61SME-S2 (GF6100/NF405) can be seen from [1],[2]
 
thanks,
Indrek
 
__
 
[1] http://www.hot.ee/bzmeez/nv_mcp61_lspci-n.txt
[2] http://www.hot.ee/bzmeez/nv_mcp61_lspci-vv.txt



diff -pur linux-2.6.git1/include/linux/pci_ids.h 
linux-2.6_p/include/linux/pci_ids.h
--- linux-2.6.git1/include/linux/pci_ids.h  2007-07-29 20:48:28.0 
+0300
+++ linux-2.6_p/include/linux/pci_ids.h 2007-07-29 20:54:21.0 +0300
@@ -1206,13 +1206,20 @@
 #define PCI_DEVICE_ID_NVIDIA_QUADRO_FX_1100 0x034E
 #define PCI_DEVICE_ID_NVIDIA_NVENET_14  0x0372
 #define PCI_DEVICE_ID_NVIDIA_NVENET_15  0x0373
+#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_LPC_BRG   0x03E0
 #define PCI_DEVICE_ID_NVIDIA_NVENET_16  0x03E5
 #define PCI_DEVICE_ID_NVIDIA_NVENET_17  0x03E6
 #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_SATA  0x03E7
+#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_MC1   0x03EA
 #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_SMBUS0x03EB
 #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_IDE   0x03EC
 #define PCI_DEVICE_ID_NVIDIA_NVENET_18  0x03EE
 #define PCI_DEVICE_ID_NVIDIA_NVENET_19  0x03EF
+#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_HDA   0x03F0
+#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_OHCI  0x03F1
+#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_EHCI  0x03F2
+#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_PCI_BRG   0x03F3
+#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_MC2   0x03F5
 #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_SATA2 0x03F6
 #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_SATA3 0x03F7
 #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP65_SMBUS0x0446
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] mips: remove some duplicate includes

2007-07-29 Thread Jesper Juhl
Hi,

This patch removes some duplicate includes from arch/mips/


Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---

 arch/mips/kernel/signal32.c   |1 -
 arch/mips/lemote/lm2e/irq.c   |1 -
 arch/mips/mipssim/sim_setup.c |1 -
 3 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/arch/mips/kernel/signal32.c b/arch/mips/kernel/signal32.c
index 486b8e5..64b612a 100644
--- a/arch/mips/kernel/signal32.c
+++ b/arch/mips/kernel/signal32.c
@@ -18,7 +18,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/mips/lemote/lm2e/irq.c b/arch/mips/lemote/lm2e/irq.c
index 05693bc..3e0b7be 100644
--- a/arch/mips/lemote/lm2e/irq.c
+++ b/arch/mips/lemote/lm2e/irq.c
@@ -25,7 +25,6 @@
  */
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/mips/mipssim/sim_setup.c b/arch/mips/mipssim/sim_setup.c
index 17819b5..d012719 100644
--- a/arch/mips/mipssim/sim_setup.c
+++ b/arch/mips/mipssim/sim_setup.c
@@ -22,7 +22,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 2/3] core_pattern: allow passing of arguments to user mode helper when core_pattern is a pipe

2007-07-29 Thread Neil Horman
On Sun, Jul 29, 2007 at 09:03:29PM +0800, Eugene Teo wrote:
> Neil Horman wrote:
> [...]
> > +   /* core limit size */
> > +   case 'c':
> > +   rc = snprintf(out_ptr, out_end - out_ptr,
> > + "%lu", 
> > current->signal->rlim[RLIMIT_CORE].rlim_cur); 
> 
> Trailing space.
> 
> [...]
> > -   if(call_usermodehelper_pipe(corename+1, NULL, NULL, )) {
> > +   if(call_usermodehelper_pipe(corename+1, helper_argv, NULL, 
> > )) {
>^
> 
> Use tabs, and a missing space after '('.
> 
I think your reader is screwing up the patch.  The version that I sent, which I
have here, shows that as all tabs, no spaces.

As for the '(', yeah, that looks like its been there for awhile.  I'll clean it
all up when I address macro expansion, as per the conversation Martin and I have
been holding.

Regards
Neil
 
> Eugene

-- 
/***
 *Neil Horman
 *Software Engineer
 *Red Hat, Inc.
 [EMAIL PROTECTED]
 *gpg keyid: 1024D / 0x92A74FA1
 *http://pgp.mit.edu
 ***/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [linux-pm] Power Management framework proposal

2007-07-29 Thread david

sorry for the delay in responding

On Wed, 25 Jul 2007, Jerome Glisse wrote:

[EMAIL PROTECTED] wrote:

 On Wed, 25 Jul 2007, Jerome Glisse wrote:

>  On 7/24/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > >   For instance on graphics card you could do the following (maybe 
> >  more):

> > >   -change GPU clock
> > >   -change memory clock
> > >   -disable part of engine
> > >   -disable unit
> > >   i truly don't think you can make a common interface for all this, 
> >  more

> > >   over there might be constraint on how you can change things (GPU &
> > >   memory clock might need to follow a given ratio). So you definitely
> > >   need knowledge in the user space program to handle this.
> > 
> >  sure you can, just enumerate all the options the driver writer wants 
> >  to

> >   offer as options. yes this could be a lengthy list, so what?
> > 
> 
>  My point was that your interface by trying to fit square pegs into round 
>  hole
>  will fail to expose all subtility of each device which might in the end 
>  bring

>  to wrong power management decision. So i believe we can't sum up
>  power management to list of mode whose attribute are power consumption

& capacity.


 it's possible (which is part of the reason I started the thread), but so
 far there hasn't been anything identified that is a really bad fit.


Tell me how i do this in your model:
GPU/VRAM memory clock change power consumption of the card and
the power consumption is often not a trivial function of both of this 
parameters

(i even here simplify the problem by omitting pipeline shutdown). So how with
two different separate mode list (one for GPU speed another one for VRAM 
speed)

can you provide consumption information while this consumption depends on the
others settings. Then if you give as a solution to make only one list you end 
up

with a more bigger list than previously needed (nrGPUmodes * nrVRAMmodes)
do you expect the user to go through a lengthy list to find what he wants ?
(remember that we will have to add pipeline power off, pll tweaking or many
others way of saving power on such card).


yes I expect that it would be a large list in some conditions. but one 
purpose of this API is to make these options able to be discovered by 
software. right now nothing could be done at all without driver specific 
knowledge. even a lengthy list can be better then that.


presenting the list to the user directly is a last resort, only for 
experimentation or when nothing else wants to deal with devices of that 
type.


with a description field (which I didn't include initially, but seems 
obviously needed now) it should be fairly easy to create descriptions that 
let the software see that there are multiple factors involved.



So by choosing this power consumption as a unit of measure you end up
in non trivial case. There is also the question of overclocking


if the driver supports overclocking then list it in the modes (nothing 
says that % capacity couldn't go over 100% for example)


, and other points already identified where unfortunately a global 
design such as your proposal does not seems to fit properly: local power 
decision (ethernet, wifi card, ... can power down them self is they are 
doing nothings but the place where you can know this is the driver)


if they power themselves down with no notice to the system they should 
power themselves back up with no need for the rest of the system to tell 
them either. so this ca either be ignored or presented as a mode between 
off and on that enables this behavior.



, there is also the child/parent relation, how to
estimate power usage (on some configuration one device consumption can
be marginal toward all others things while on other this same device can be
the most power hungry device)... I see all this as bad fit.


ahh, here we see a disconnect. I was not intending for the power field to 
be that exact. there are just too many variables. for example: even for a 
cpu, the power used isn't exactly tied to the clock speed and voltage, the 
mix of commands that the cpu is running will affect the power it eats, 
sometimes by a significant amount. it was intended to be an ordering 
factor and approximate the power used so that things could make a 
peroformance/power tradeoff with a good chance of makeing a reasonable 
choice.


it's not intended for 'make this laptop use 24w of power instead of 25w of 
power'


>  And there is no way to design an abstraction given that all hw we will 
>  have
>  to deal with are too much different and do not follow any standard 
>  things

>  (beside ACPI there is other way to save power brightness, gpu/memory
>  clock, pll, ...) so i don't see how one might give a common view of 
>  things
>  which are fundamentally different in how they affect consumption (same 
>  end

>  result with many different paths leading to it).

 so you are saying that the power management software must know the details
 of each and every driver, and if you 

[PATCH] m68knommu: Get rid of duplicate include

2007-07-29 Thread Jesper Juhl
Hi,

This patch removes the duplicate inclusion of asm/irq.h 
from arch/m68knommu/platform/5206e/config.c


Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---

 arch/m68knommu/platform/5206e/config.c |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/arch/m68knommu/platform/5206e/config.c 
b/arch/m68knommu/platform/5206e/config.c
index 4ab614f..425703f 100644
--- a/arch/m68knommu/platform/5206e/config.c
+++ b/arch/m68knommu/platform/5206e/config.c
@@ -20,7 +20,6 @@
 #include 
 #include 
 #include 
-#include 
 
 /***/
 


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


  1   2   3   4   5   6   7   8   >