[PATCH]: ioremap function balancing in init/cleanup sound/oss/dmasound/dmacound_awacs.c
-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
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
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
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
> > +/* > + * 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
> > +/* > + * 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
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
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
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
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
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
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
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
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
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
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
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
> +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
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
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
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
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
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
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
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
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
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
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?
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
[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
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:
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()
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
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
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
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
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
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
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
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
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
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
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
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
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
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()
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
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
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
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
[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
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
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
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
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
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
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
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
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)
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
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
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
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
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
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
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
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
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)
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
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
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
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
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
> 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
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
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
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
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
> * 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
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
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
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
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
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
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
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
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
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
(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
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'
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
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
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
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)
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)
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
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
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
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
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/