send_IPI_mask_bitmask() (Re: 2.6.21 known regressions (v2) (for -stable team))
On Saturday 28 April 2007 12:58, Thomas Gleixner wrote:
> On Sat, 2007-04-28 at 18:27 +0200, Michal Piotrowski wrote:
> > Hi all,
> >
> > Here is a list of known regressions reported after 2.6.21 release.
>
> Michal, thanks for stepping up !
>
> > Subject: 2.6.21 - BUG: at arch/i386/kernel/smp.c:177
> > send_IPI_mask_bitmask()
> > References : http://lkml.org/lkml/2007/4/27/621
> > Submitter : Jeff Chua <[EMAIL PROTECTED]>
> > Status : unknown
>
> Len,
>
> clockevents_notify() is called with the power verify information for an
> offline CPU. I can handle this in the clockevents code, but I think acpi
> is the correct place.
So the CONFIG_GENERIC_CLOCKEVENTS=y case is broken,
but the CONFIG_GENERIC_CLOCKEVENTS=n below is okay?
Not immediately clear why both cases can't fail.
Maybe Venki can explain.
-Len
static void acpi_propagate_timer_broadcast(struct acpi_processor *pr)
{
#ifdef CONFIG_GENERIC_CLOCKEVENTS
unsigned long reason;
reason = pr->power.timer_broadcast_on_state < INT_MAX ?
CLOCK_EVT_NOTIFY_BROADCAST_ON : CLOCK_EVT_NOTIFY_BROADCAST_OFF;
clockevents_notify(reason, >id);
#else
cpumask_t mask = cpumask_of_cpu(pr->id);
if (pr->power.timer_broadcast_on_state < INT_MAX)
on_each_cpu(switch_APIC_timer_to_ipi, , 1, 1);
else
on_each_cpu(switch_ipi_to_APIC_timer, , 1, 1);
#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/
Re: [patch] CFS scheduler, -v6
Hi, On Sun, Apr 29, 2007 at 03:18:32AM +0200, Kasper Sandberg wrote: > Okay so i've tried with cfs 7 now, and the completely broken audio > behavior is fixed. > > The only things i really notice now is that gtk apps seems to redraw > somewhat slower, and renicing X doesent seem to be able to bring it on > par with SD or vanilla. > > And smoothness just doesent match SD, it may be abit better than > vanilla/staircase, i cant really definitively say, but SD just has the > smoothness factor which is extremely attractive. (...) I don't know if Mike still has problems with SD, but there are now several interesting reports of SD giving better feedback than CFS on real work. In my experience, CFS seems smoother on *technical* tests, which I agree that they do not really simulate real work. I really think that if we merged SD in 2.6.22, at least we could focus more on differences between it (which will become mainline) and CFS in order to improve CFS for later inclusion when mature enough. Or maybe only relevant parts of CFS will be merged into mainline later. But at least, testers will not have to patch anymore to report feedback with SD during -rc, and above all they would not compare anymore against old-vanilla, thus reducing the number of tests. Just my 2 cents, Willy - 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] i386: fix voyager build
This adds an smp_ops for voyager, and hooks things up appropriately.
This is the first baby-step to making subarch runtime switchable.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: James Bottomley <[EMAIL PROTECTED]>
Cc: Eric W. Biederman <[EMAIL PROTECTED]>
---
arch/i386/mach-voyager/voyager_smp.c | 73 --
1 file changed, 44 insertions(+), 29 deletions(-)
===
--- a/arch/i386/mach-voyager/voyager_smp.c
+++ b/arch/i386/mach-voyager/voyager_smp.c
@@ -28,7 +28,6 @@
#include
#include
#include
-#include
/* TLB state -- visible externally, indexed physically */
DEFINE_PER_CPU(struct tlb_state, cpu_tlbstate) cacheline_aligned = {
_mm, 0 };
@@ -423,7 +422,7 @@ find_smp_config(void)
VOYAGER_SUS_IN_CONTROL_PORT);
current_thread_info()->cpu = boot_cpu_id;
- write_pda(cpu_number, boot_cpu_id);
+ x86_write_percpu(cpu_number, boot_cpu_id);
}
/*
@@ -436,7 +435,7 @@ smp_store_cpu_info(int id)
*c = boot_cpu_data;
- identify_cpu(c);
+ identify_secondary_cpu(c);
}
/* set up the trampoline and return the physical address of the code */
@@ -460,7 +459,7 @@ start_secondary(void *unused)
/* external functions not defined in the headers */
extern void calibrate_delay(void);
- secondary_cpu_init();
+ cpu_init();
/* OK, we're in the routine */
ack_CPI(VIC_CPU_BOOT_CPI);
@@ -580,7 +579,9 @@ do_boot_cpu(__u8 cpu)
/* init_tasks (in sched.c) is indexed logically */
stack_start.esp = (void *) idle->thread.esp;
- init_gdt(cpu, idle);
+ init_gdt(cpu);
+ per_cpu(current_task, cpu) = idle;
+ early_gdt_descr.address = (unsigned long)get_cpu_gdt_table(cpu);
irq_ctx_init(cpu);
/* Note: Don't modify initial ss override */
@@ -884,8 +885,8 @@ smp_invalidate_interrupt(void)
/* This routine is called with a physical cpu mask */
static void
-flush_tlb_others (unsigned long cpumask, struct mm_struct *mm,
- unsigned long va)
+voyager_flush_tlb_others (unsigned long cpumask, struct mm_struct *mm,
+ unsigned long va)
{
int stuck = 5;
@@ -937,7 +938,7 @@ flush_tlb_current_task(void)
cpu_mask = cpus_addr(mm->cpu_vm_mask)[0] & ~(1 << smp_processor_id());
local_flush_tlb();
if (cpu_mask)
- flush_tlb_others(cpu_mask, mm, FLUSH_ALL);
+ voyager_flush_tlb_others(cpu_mask, mm, FLUSH_ALL);
preempt_enable();
}
@@ -959,7 +960,7 @@ flush_tlb_mm (struct mm_struct * mm)
leave_mm(smp_processor_id());
}
if (cpu_mask)
- flush_tlb_others(cpu_mask, mm, FLUSH_ALL);
+ voyager_flush_tlb_others(cpu_mask, mm, FLUSH_ALL);
preempt_enable();
}
@@ -980,7 +981,7 @@ void flush_tlb_page(struct vm_area_struc
}
if (cpu_mask)
- flush_tlb_others(cpu_mask, mm, va);
+ voyager_flush_tlb_others(cpu_mask, mm, va);
preempt_enable();
}
@@ -1076,12 +1077,13 @@ smp_call_function_interrupt(void)
[RETURNS] 0 on success, else a negative status code. Does not return until
remote CPUs are nearly ready to execute <> or are or have executed.
*/
-int
-smp_call_function (void (*func) (void *info), void *info, int retry,
- int wait)
+static int
+voyager_smp_call_function_mask (cpumask_t cpumask,
+ void (*func) (void *info), void *info,
+ int wait)
{
struct call_data_struct data;
- __u32 mask = cpus_addr(cpu_online_map)[0];
+ u32 mask = cpumask.bits[0];
mask &= ~(1
[PATCH] i386: move common parts of smp into their own file
Several parts of kernel/smp.c and smpboot.c are generally useful for
other subarchitectures and paravirt_ops implementations, so make them
available for reuse.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: James Bottomley <[EMAIL PROTECTED]>
Cc: Eric W. Biederman <[EMAIL PROTECTED]>
---
arch/i386/kernel/Makefile|1
arch/i386/kernel/smp.c | 65 +++---
arch/i386/kernel/smpboot.c | 22 ---
arch/i386/kernel/smpcommon.c | 79 ++
include/asm-i386/processor.h |4 ++
5 files changed, 90 insertions(+), 81 deletions(-)
===
--- a/arch/i386/kernel/Makefile
+++ b/arch/i386/kernel/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_MICROCODE) += microcode.o
obj-$(CONFIG_MICROCODE)+= microcode.o
obj-$(CONFIG_APM) += apm.o
obj-$(CONFIG_X86_SMP) += smp.o smpboot.o tsc_sync.o
+obj-$(CONFIG_SMP) += smpcommon.o
obj-$(CONFIG_X86_TRAMPOLINE) += trampoline.o
obj-$(CONFIG_X86_MPPARSE) += mpparse.o
obj-$(CONFIG_X86_LOCAL_APIC) += apic.o nmi.o
===
--- a/arch/i386/kernel/smp.c
+++ b/arch/i386/kernel/smp.c
@@ -468,7 +468,7 @@ void flush_tlb_all(void)
* it goes straight through and wastes no time serializing
* anything. Worst case is that we lose a reschedule ...
*/
-void native_smp_send_reschedule(int cpu)
+static void native_smp_send_reschedule(int cpu)
{
WARN_ON(cpu_is_offline(cpu));
send_IPI_mask(cpumask_of_cpu(cpu), RESCHEDULE_VECTOR);
@@ -547,9 +547,10 @@ static void __smp_call_function(void (*f
* You must not call this function with disabled interrupts or from a
* hardware interrupt handler or from a bottom half handler.
*/
-int native_smp_call_function_mask(cpumask_t mask,
- void (*func)(void *), void *info,
- int wait)
+static int
+native_smp_call_function_mask(cpumask_t mask,
+ void (*func)(void *), void *info,
+ int wait)
{
struct call_data_struct data;
cpumask_t allbutself;
@@ -600,60 +601,6 @@ int native_smp_call_function_mask(cpumas
return 0;
}
-/**
- * smp_call_function(): Run a function on all other CPUs.
- * @func: The function to run. This must be fast and non-blocking.
- * @info: An arbitrary pointer to pass to the function.
- * @nonatomic: Unused.
- * @wait: If true, wait (atomically) until function has completed on other
CPUs.
- *
- * Returns 0 on success, else a negative status code.
- *
- * If @wait is true, then returns once @func has returned; otherwise
- * it returns just before the target cpu calls @func.
- *
- * You must not call this function with disabled interrupts or from a
- * hardware interrupt handler or from a bottom half handler.
- */
-int smp_call_function(void (*func) (void *info), void *info, int nonatomic,
- int wait)
-{
- return smp_call_function_mask(cpu_online_map, func, info, wait);
-}
-EXPORT_SYMBOL(smp_call_function);
-
-/**
- * smp_call_function_single - Run a function on another CPU
- * @cpu: The target CPU. Cannot be the calling CPU.
- * @func: The function to run. This must be fast and non-blocking.
- * @info: An arbitrary pointer to pass to the function.
- * @nonatomic: Unused.
- * @wait: If true, wait until function has completed on other CPUs.
- *
- * Returns 0 on success, else a negative status code.
- *
- * If @wait is true, then returns once @func has returned; otherwise
- * it returns just before the target cpu calls @func.
- */
-int smp_call_function_single(int cpu, void (*func) (void *info), void *info,
-int nonatomic, int wait)
-{
- /* prevent preemption and reschedule on another processor */
- int ret;
- int me = get_cpu();
- if (cpu == me) {
- WARN_ON(1);
- put_cpu();
- return -EBUSY;
- }
-
- ret = smp_call_function_mask(cpumask_of_cpu(cpu), func, info, wait);
-
- put_cpu();
- return ret;
-}
-EXPORT_SYMBOL(smp_call_function_single);
-
static void stop_this_cpu (void * dummy)
{
local_irq_disable();
@@ -671,7 +618,7 @@ static void stop_this_cpu (void * dummy)
* this function calls the 'stop' function on all other CPUs in the system.
*/
-void native_smp_send_stop(void)
+static void native_smp_send_stop(void)
{
/* Don't deadlock on the call lock in panic */
int nolock = !spin_trylock(_lock);
===
--- a/arch/i386/kernel/smpboot.c
+++ b/arch/i386/kernel/smpboot.c
@@ -99,9 +99,6 @@ EXPORT_SYMBOL(x86_cpu_to_apicid);
u8 apicid_2_node[MAX_APICID];
-DEFINE_PER_CPU(unsigned long, this_cpu_off);
-EXPORT_PER_CPU_SYMBOL(this_cpu_off);
-
/*
* Trampoline 80x86
vmstat: use our own timer events
vmstat is currently using the cache reaper to periodically bring the
statistics up to date. The cache reaper does only exists in SLUB
as a way to provide compatibility with SLAB. This patch removes
the vmstat calls from the slab allocators and provides its own
handling.
The advantage is also that we can use a different frequency for the
updates. Refreshing vm stats is a pretty fast job so we can run this
every second and stagger this by only one tick. This will lead to
some overlap in large systems. F.e a system running at 250 HZ with
1024 processors will have 4 vm updates occurring at once.
However, the vm stats update only accesses per node information.
It is only necessary to stagger the vm statistics updates per
processor in each node. Vm counter updates occurring on distant
nodes will not cause cacheline contention.
We could implement an alternate approach that runs the first processor
on each node at the second and then each of the other processor on a
node on a subsequent tick. That may be useful to keep a large amount
of the second free of timer activity. Maybe the timer folks will have
some feedback on this one?
CC: Arjan van de Ven <[EMAIL PROTECTED]>
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
include/linux/vmstat.h |3 ---
mm/slab.c |1 -
mm/slub.c |1 -
mm/vmstat.c| 39 +++
4 files changed, 35 insertions(+), 9 deletions(-)
Index: slub/mm/slab.c
===
--- slub.orig/mm/slab.c 2007-04-28 19:35:19.0 -0700
+++ slub/mm/slab.c 2007-04-28 19:35:26.0 -0700
@@ -4155,7 +4155,6 @@ next:
check_irq_on();
mutex_unlock(_chain_mutex);
next_reap_node();
- refresh_cpu_vm_stats(smp_processor_id());
out:
/* Set up the next iteration */
schedule_delayed_work(work, round_jiffies_relative(REAPTIMEOUT_CPUC));
Index: slub/mm/slub.c
===
--- slub.orig/mm/slub.c 2007-04-28 19:35:28.0 -0700
+++ slub/mm/slub.c 2007-04-28 19:36:12.0 -0700
@@ -2514,7 +2514,6 @@ static DEFINE_PER_CPU(struct delayed_wor
static void cache_reap(struct work_struct *unused)
{
next_reap_node();
- refresh_cpu_vm_stats(smp_processor_id());
schedule_delayed_work(&__get_cpu_var(reap_work),
REAPTIMEOUT_CPUC);
}
Index: slub/include/linux/vmstat.h
===
--- slub.orig/include/linux/vmstat.h2007-04-28 19:30:01.0 -0700
+++ slub/include/linux/vmstat.h 2007-04-28 19:36:38.0 -0700
@@ -213,8 +213,6 @@ extern void dec_zone_state(struct zone *
extern void __dec_zone_state(struct zone *, enum zone_stat_item);
void refresh_cpu_vm_stats(int);
-void refresh_vm_stats(void);
-
#else /* CONFIG_SMP */
/*
@@ -261,7 +259,6 @@ static inline void __dec_zone_page_state
#define mod_zone_page_state __mod_zone_page_state
static inline void refresh_cpu_vm_stats(int cpu) { }
-static inline void refresh_vm_stats(void) { }
#endif
#endif /* _LINUX_VMSTAT_H */
Index: slub/mm/vmstat.c
===
--- slub.orig/mm/vmstat.c 2007-04-28 19:30:01.0 -0700
+++ slub/mm/vmstat.c2007-04-28 19:36:38.0 -0700
@@ -640,6 +640,22 @@ const struct seq_operations vmstat_op =
#endif /* CONFIG_PROC_FS */
#ifdef CONFIG_SMP
+static DEFINE_PER_CPU(struct delayed_work, vmstat_work);
+
+static void vmstat_update(struct work_struct *w)
+{
+ refresh_cpu_vm_stats(smp_processor_id());
+ schedule_delayed_work(&__get_cpu_var(vmstat_work), HZ);
+}
+
+static void __devinit start_cpu_timer(int cpu)
+{
+ struct delayed_work *vmstat_work = _cpu(vmstat_work, cpu);
+
+ INIT_DELAYED_WORK(vmstat_work, vmstat_update);
+ schedule_delayed_work_on(cpu, vmstat_work, HZ + cpu);
+}
+
/*
* Use the cpu notifier to insure that the thresholds are recalculated
* when necessary.
@@ -648,11 +664,21 @@ static int __cpuinit vmstat_cpuup_callba
unsigned long action,
void *hcpu)
{
+ long cpu = (long)hcpu;
+
switch (action) {
- case CPU_UP_PREPARE:
- case CPU_UP_PREPARE_FROZEN:
- case CPU_UP_CANCELED:
- case CPU_UP_CANCELED_FROZEN:
+ case CPU_ONLINE:
+ case CPU_ONLINE_FROZEN:
+ start_cpu_timer(cpu);
+ break;
+ case CPU_DOWN_PREPARE:
+ case CPU_DOWN_PREPARE_FROZEN:
+ cancel_rearming_delayed_work(_cpu(vmstat_work, cpu));
+ per_cpu(vmstat_work, cpu).work.func = NULL;
+ case CPU_DOWN_FAILED:
+ case CPU_DOWN_FAILED_FROZEN:
+ start_cpu_timer(cpu);
+ break;
case CPU_DEAD:
case CPU_DEAD_FROZEN:
refresh_zone_stat_thresholds();
@@ -668,8
Re: [patches] [PATCH] [21/22] x86_64: Extend bzImage protocol for relocatable bzImage
On Sat, Apr 28, 2007 at 02:46:18PM -0600, Eric W. Biederman wrote: > "H. Peter Anvin" <[EMAIL PROTECTED]> writes: > > > Eric W. Biederman wrote: > >> > >> The boot protocol change is in 2.6.21 for arch/i386. > >> > >> HPA looked at it a while ago. > >> > >> All it does is set a flag that tells a bootloader. > >> "Hey. I can run when loaded a non-default address, and this is what > >> you have to align me to." > >> > >> All relocation processing happens in the kernel itself. > >> > >> So it is all pretty trivial. > >> > > > > Indeed. We *did* find some problems with Grub with the early versions, > > those were addressed. > > We found some failures that weren't root caused so we went to this > more conservative version. > > RHEL5 is actually shipping the original version of these patches if I > recall correctly. > Yes, RHEL5 is shipping original version of patches where an where and ELF header has been added to describe bzImage. Thanks Vivek - 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: [-mm patch] make drivers/misc/thinkpad_acpi:fan_mutex static
On Sun, 29 Apr 2007, Adrian Bunk wrote: > Forward declarations of static functions (if required) and actual > variables (like fan_mutex) belong into the C file, not the header. Very well. I will fix the mess for 2.6.23, or, time permitting, 2.6.22. > > Maybe I should just break the driver into multiple files in a subdirectory? > > That would certainly make it *much* cleaner... > > But even more in this case, you will not want to have actual variables > or prototypes of static functions in the header file. I would not have to, in that case. The driver would be much easier to write, and I will need to break it in two for an alsa module anyway, might as well break it in one subdriver per file. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh - 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: [TESTING NEEDED] drivers/serial/sunzilog: Interrupt enable before ISR handler installed
Your patch is extremely mangled, please try to email it to yourself and apply it if in doubt. Furthermore, the comment your patch adds is unnecessary. That kind of text belongs in the changelog comment, not the code. The changelog is also where you'll get credit for your change. There is no reason to play Napoleon in the source files any more now that we have proper source control and history all these years. :-) Please fix all of this up and resubmit, thank you. - 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: Back to the future.
On Apr 28, 2007, at 19:45:01, Linus Torvalds wrote: On Sun, 29 Apr 2007, Rafael J. Wysocki wrote: Well, I'm not sure whether or not that still would have been the case if we had stopped to freeze kernel threads for the hibernation/suspend. Did you miss the email where Paul pointed out that Mac/PowerPC didn't use to do any of this? And apparently never had any issues with it? And probably worked more reliably several years ago than suspend/hibernation does _today_? Still works pretty reliably; the last time my PowerBook G4 was rebooted was 6 weeks ago. Once every 60 suspends or so the kernel USB driver gets really confused and doesn't wake up the USB controller properly, leading to dead keyboard/mouse, but other than that I never have problems. I wouldn't be surprised if I could comment out 90% of the "suspend" code and still have it work, the hardware in is is incredibly robust. I can even swap batteries while it's in suspend-to-RAM, as long as I do it in less than 45 sec or so; I get around 6-7 days of suspend-to-RAM time on a full charge. 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: Linux 2.6.21
From: Adrian Bunk <[EMAIL PROTECTED]> Date: Sun, 29 Apr 2007 01:04:16 +0200 > Bugzilla has an email interface. > Andrew forwards bugs from Bugzilla to developers. Therefore, bugzilla only works at all when Andrew forwards things around by-hand. - 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 2.6.21
From: "Markus Rechberger" <[EMAIL PROTECTED]> Date: Sun, 29 Apr 2007 00:58:09 +0200 > On 4/29/07, Linus Torvalds <[EMAIL PROTECTED]> wrote: > > > > > > On Sat, 28 Apr 2007, Adrian Bunk wrote: > > > > > > We are already quite good at ignoring bug reports that come through > > > linux-kernel, and it's an _advantage_ of the kernel Bugzilla to see more > > > than 1600 open bugs because this tells how bad we are at handling bugs. > > > > No, it just shows that bugzilla doesn't matter for most of the kernel. > > > > Don't say that "bugzilla tells how bad we are at handling bugs". It tells > > how bad *bugzilla* is for handling bugs, nothing more. > > > > I totally disagree here, bugzilla is a very good tool. No, Bugzilla really does suck, and I personally refuse to use it when I have a choice. And guess what? You better be concerned about that because I maintain all of the networking code :-) It puts the onus FAR too much on the developer and not enough on the reporter and other minions. We have a small resource of developers, yet lots of users, bug reporters, and minions, so something that doesn't take advantage of the larger resource we have is going to not function efficiently at all. Yet that is what bugzilla does. It's made way too much work for me every time I'm come in contact with it, it wastes my time instead of making good use of it. As a developer I do not want to get pounded with emails containing state changes and other bullshit that typically comes with being assigned to or on the CC of a bugzilla entry. I don't want to be reminded that a bug hasn't been touched in weeks, if the reporter doesn't care I don't care and I'll work on things that people do care about. It makes me delete all the bugzilla email, even the ones with important information in them, because it's rediculious to have to sift through all of that crap. People only use bugzilla because it is well understood and nothing better has reached critical mass yet. - 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 2.6.21
On Sat, 28 Apr 2007 17:07:30 -0700 (PDT) Linus Torvalds <[EMAIL PROTECTED]> wrote: > On Sat, 28 Apr 2007, Martin J. Bligh wrote: > > > > Go to http://bugzilla.kernel.org. Hit query. Find the box that says > > "Bug Changes, Only bugs changed in the last __ days". Stick 7 in it. > > > > 74 bugs found. > > > > Not hard to do. > > And what part of the "directed" did you miss? > > Do you really expect me to go there every day to look at all bugs? That's > nbot a bug tracker. That's just a noise-maker. > > It needs to be email, not some "mouse around for 30 seconds and type > thing", and it needs to be *directed*. Preferably with somebody who > actually did some manual scanning over it and spent a few minutes just > looking at whether it looks like a worthy bug. > > In other words: we shouldn't have all developers wasting time doing this. yup. > It would be much better to have _one_ person (or a group of people) doing > it, I am doing that. It's only 5-10 a day - routing them to the relevant culprit is very little work. It's also very little work for said culprits to totally ignore said routing, which is a tougher problem. - 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 5/7] blackfin arch: convert most blackfin specific spi register settings to common spi framework settings
(mostly drop the MSTR bit as our bus handles that and convert CHPA/CPOL into
SPI_MODE_#)
Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
---
arch/blackfin/mach-bf533/boards/cm_bf533.c |4 +--
arch/blackfin/mach-bf533/boards/ezkit.c |4 +--
arch/blackfin/mach-bf533/boards/stamp.c | 10 ++
arch/blackfin/mach-bf537/boards/cm_bf537.c |8 ++---
arch/blackfin/mach-bf537/boards/generic_board.c |5 +--
arch/blackfin/mach-bf537/boards/pnav10.c| 16 -
arch/blackfin/mach-bf537/boards/stamp.c | 37 ++
arch/blackfin/mach-bf561/boards/cm_bf561.c |7 +---
arch/blackfin/mach-bf561/boards/ezkit.c |1 -
9 files changed, 36 insertions(+), 56 deletions(-)
diff --git a/arch/blackfin/mach-bf533/boards/cm_bf533.c
b/arch/blackfin/mach-bf533/boards/cm_bf533.c
index 8cf7865..23a7f60 100644
--- a/arch/blackfin/mach-bf533/boards/cm_bf533.c
+++ b/arch/blackfin/mach-bf533/boards/cm_bf533.c
@@ -71,21 +71,18 @@ static struct flash_platform_data bfin_spi_flash_data = {
/* SPI flash chip (m25p64) */
static struct bfin5xx_spi_chip spi_flash_chip_info = {
- .ctl_reg = 0x1C00, /* with enable bit unset */
.enable_dma = 0, /* use dma transfer with this chip*/
.bits_per_word = 8,
};
/* SPI ADC chip */
static struct bfin5xx_spi_chip spi_adc_chip_info = {
- .ctl_reg = 0x1500,
.enable_dma = 1, /* use dma transfer with this chip*/
.bits_per_word = 16,
};
#if defined(CONFIG_SND_BLACKFIN_AD1836) ||
defined(CONFIG_SND_BLACKFIN_AD1836_MODULE)
static struct bfin5xx_spi_chip ad1836_spi_chip_info = {
- .ctl_reg = 0x1000,
.enable_dma = 0,
.bits_per_word = 16,
};
@@ -100,6 +97,7 @@ static struct spi_board_info bfin_spi_board_info[]
__initdata = {
.chip_select = 1, /* Framework chip select. On
STAMP537 it is SPISSEL1*/
.platform_data = _spi_flash_data,
.controller_data = _flash_chip_info,
+ .mode = SPI_MODE_3,
},{
.modalias = "bfin_spi_adc", /* Name of spi_driver for this
device */
.max_speed_hz = 625, /* max spi clock (SCK) speed in HZ
*/
diff --git a/arch/blackfin/mach-bf533/boards/ezkit.c
b/arch/blackfin/mach-bf533/boards/ezkit.c
index 59970f7..747298e 100644
--- a/arch/blackfin/mach-bf533/boards/ezkit.c
+++ b/arch/blackfin/mach-bf533/boards/ezkit.c
@@ -105,7 +105,6 @@ static struct flash_platform_data bfin_spi_flash_data = {
/* SPI flash chip (m25p64) */
static struct bfin5xx_spi_chip spi_flash_chip_info = {
- .ctl_reg = 0x1C00, /* with enable bit unset */
.enable_dma = 0, /* use dma transfer with this chip*/
.bits_per_word = 8,
};
@@ -114,7 +113,6 @@ static struct bfin5xx_spi_chip spi_flash_chip_info = {
#if defined(CONFIG_SPI_ADC_BF533) || defined(CONFIG_SPI_ADC_BF533_MODULE)
/* SPI ADC chip */
static struct bfin5xx_spi_chip spi_adc_chip_info = {
- .ctl_reg = 0x1000,
.enable_dma = 1, /* use dma transfer with this chip*/
.bits_per_word = 16,
};
@@ -122,7 +120,6 @@ static struct bfin5xx_spi_chip spi_adc_chip_info = {
#if defined(CONFIG_SND_BLACKFIN_AD1836) ||
defined(CONFIG_SND_BLACKFIN_AD1836_MODULE)
static struct bfin5xx_spi_chip ad1836_spi_chip_info = {
- .ctl_reg = 0x1000,
.enable_dma = 0,
.bits_per_word = 16,
};
@@ -138,6 +135,7 @@ static struct spi_board_info bfin_spi_board_info[]
__initdata = {
.chip_select = 2, /* Framework chip select. On STAMP537 it is
SPISSEL2*/
.platform_data = _spi_flash_data,
.controller_data = _flash_chip_info,
+ .mode = SPI_MODE_3,
},
#endif
diff --git a/arch/blackfin/mach-bf533/boards/stamp.c
b/arch/blackfin/mach-bf533/boards/stamp.c
index 891118b..d7b3a5d 100644
--- a/arch/blackfin/mach-bf533/boards/stamp.c
+++ b/arch/blackfin/mach-bf533/boards/stamp.c
@@ -128,7 +128,6 @@ static struct flash_platform_data bfin_spi_flash_data = {
/* SPI flash chip (m25p64) */
static struct bfin5xx_spi_chip spi_flash_chip_info = {
- .ctl_reg = 0x1C00, /* with enable bit unset */
.enable_dma = 0, /* use dma transfer with this chip*/
.bits_per_word = 8,
};
@@ -137,7 +136,6 @@ static struct bfin5xx_spi_chip spi_flash_chip_info = {
#if defined(CONFIG_SPI_ADC_BF533) || defined(CONFIG_SPI_ADC_BF533_MODULE)
/* SPI ADC chip */
static struct bfin5xx_spi_chip spi_adc_chip_info = {
- .ctl_reg = 0x1000,
.enable_dma = 1, /* use dma transfer with this chip*/
.bits_per_word = 16,
};
@@ -145,7 +143,6 @@ static struct bfin5xx_spi_chip spi_adc_chip_info = {
#if defined(CONFIG_SND_BLACKFIN_AD1836) ||
defined(CONFIG_SND_BLACKFIN_AD1836_MODULE)
static struct bfin5xx_spi_chip ad1836_spi_chip_info = {
- .ctl_reg = 0x1000,
.enable_dma = 0,
[PATCH 4/7] blackfin arch: need linux/tty.h header for console_init() prototype
Signed-off-by: Bryan Wu <[EMAIL PROTECTED]> --- arch/blackfin/kernel/setup.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/blackfin/kernel/setup.c b/arch/blackfin/kernel/setup.c index 724fd7a..342bb8d 100644 --- a/arch/blackfin/kernel/setup.c +++ b/arch/blackfin/kernel/setup.c @@ -34,6 +34,7 @@ #include #include #include +#include #include #include -- 1.5.1.2 - 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.21-git2] sk_buff changes break Cisco VPN client
From: Roland Dreier <[EMAIL PROTECTED]> Date: Sat, 28 Apr 2007 14:05:27 -0700 > However I can suggest vpnc (http://www.unix-ag.uni-kl.de/~massar/vpnc/) > as an alternative. I'm not forced to use Cisco VPN access any more, > but when I tried it, vpnc was tons better than the Cisco product. Also, and I know this might be a COMPLETE SHOCK to some people, but we do have a full in-kernel IPSEC stack and using it with openswan to connect to VPNs works perfectly fine. I use it every day. It's quite amusing that people use a userland IPSEC implementation via VPNC, in spite of this. - 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] mm/memory.c: remove warning from an uninitialized spinlock. was: Re: 2.6.21-rc7-mm2
On Sun, 29 Apr 2007 00:48:37 +0100 Andy Whitcroft <[EMAIL PROTECTED]> wrote: > > +++ a/mm/memory.c > > @@ -1455,7 +1455,7 @@ static int apply_to_pte_range(struct mm_ > > pte_t *pte; > > int err; > > struct page *pmd_page; > > - spinlock_t *ptl; > > + spinlock_t *ptl = ptl; /* Suppress gcc warning */ > > > > pte = (mm == _mm) ? > > pte_alloc_kernel(pmd, addr) : > > _ > > > > Perhaps we should have some kind definition helper. > > #define suppress_unused(x) x = x > > spinlock_t *suppress_unused(ptl); > > Perhaps? I think so. It makes it clear what's happening and it allows us to change the implementation later on if the present trick stops working in later gcc. It also allows people to suppress the suppression (some have expressed concern that it can hide real bugs). But I lost (or didn't pursue) the bunfight^Wdiscussion last time this came around. - 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 7/7] blackfin spi controller driver: update according to David Brownell's review
(http://lkml.org/lkml/2007/4/16/333)
Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
---
drivers/spi/Kconfig | 11 +-
drivers/spi/Makefile |4 +-
drivers/spi/spi_bfin5xx.c | 345 -
3 files changed, 193 insertions(+), 167 deletions(-)
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 1ab2ed1..584ed9f 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -58,6 +58,12 @@ config SPI_ATMEL
This selects a driver for the Atmel SPI Controller, present on
many AT32 (AVR32) and AT91 (ARM) chips.
+config SPI_BFIN
+ tristate "SPI controller driver for ADI Blackfin5xx"
+ depends on SPI_MASTER && BFIN
+ help
+ This is the SPI controller master driver for Blackfin 5xx processor.
+
config SPI_BITBANG
tristate "Bitbanging SPI master"
depends on SPI_MASTER && EXPERIMENTAL
@@ -165,11 +171,6 @@ config SPI_SPIDEV
#
# Add new SPI protocol masters in alphabetical order above this line
#
-config SPI_BFIN
- tristate "SPI controller driver for ADI Blackfin5xx"
- depends on SPI_MASTER && BFIN
- help
- This is the SPI controller master driver for Blackfin 5xx processor.
# (slave support would go here)
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index f9dcdd1..4cc5e99 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -11,8 +11,9 @@ endif
obj-$(CONFIG_SPI_MASTER) += spi.o
# SPI master controller drivers (bus)
-obj-$(CONFIG_SPI_BITBANG) += spi_bitbang.o
obj-$(CONFIG_SPI_ATMEL)+= atmel_spi.o
+obj-$(CONFIG_SPI_BFIN) += spi_bfin5xx.o
+obj-$(CONFIG_SPI_BITBANG) += spi_bitbang.o
obj-$(CONFIG_SPI_BUTTERFLY)+= spi_butterfly.o
obj-$(CONFIG_SPI_IMX) += spi_imx.o
obj-$(CONFIG_SPI_PXA2XX) += pxa2xx_spi.o
@@ -20,7 +21,6 @@ obj-$(CONFIG_SPI_OMAP_UWIRE) += omap_uwire.o
obj-$(CONFIG_SPI_MPC83xx) += spi_mpc83xx.o
obj-$(CONFIG_SPI_S3C24XX_GPIO) += spi_s3c24xx_gpio.o
obj-$(CONFIG_SPI_S3C24XX) += spi_s3c24xx.o
-obj-$(CONFIG_SPI_BFIN) += spi_bfin5xx.o
# ... add above this line ...
# SPI protocol drivers (device/link on bus)
diff --git a/drivers/spi/spi_bfin5xx.c b/drivers/spi/spi_bfin5xx.c
index ab6781a..2bbbe50 100644
--- a/drivers/spi/spi_bfin5xx.c
+++ b/drivers/spi/spi_bfin5xx.c
@@ -76,7 +76,6 @@ DEFINE_SPI_REG(SHAW, 0x18)
#define QUEUE_RUNNING 0
#define QUEUE_STOPPED 1
int dma_requested;
-char chip_select_flag;
struct driver_data {
/* Driver model hookup */
@@ -175,8 +174,9 @@ static int flush(struct driver_data *drv_data)
unsigned long limit = loops_per_jiffy << 1;
/* wait for stop and clear stat */
- do {
- } while (!(read_STAT() & BIT_STAT_SPIF) && limit--);
+ while (!(read_STAT() & BIT_STAT_SPIF) && limit--)
+ continue;
+
write_STAT(BIT_STAT_CLR);
return limit;
@@ -192,42 +192,50 @@ static void restore_state(struct driver_data *drv_data)
bfin_spi_disable(drv_data);
pr_debug("restoring spi ctl state\n");
-#if defined(CONFIG_BF534)||defined(CONFIG_BF536)||defined(CONFIG_BF537)
- if (chip->chip_select_num == 1) {
- pr_debug("set for chip select 1\n");
+#if defined(CONFIG_BF534) || defined(CONFIG_BF536) || defined(CONFIG_BF537)
+ pr_debug("chip select number is %d\n", chip->chip_select_num);
+
+ switch (chip->chip_select_num) {
+ case 1:
bfin_write_PORTF_FER(bfin_read_PORTF_FER() | 0x3c00);
SSYNC();
-
- } else if (chip->chip_select_num == 2 || chip->chip_select_num == 3) {
- pr_debug("set for chip select 2\n");
+ break;
+
+ case 2:
+ case 3:
bfin_write_PORT_MUX(bfin_read_PORT_MUX() | PJSE_SPI);
SSYNC();
bfin_write_PORTF_FER(bfin_read_PORTF_FER() | 0x3800);
SSYNC();
-
- } else if (chip->chip_select_num == 4) {
+ break;
+
+ case 4:
bfin_write_PORT_MUX(bfin_read_PORT_MUX() | PFS4E_SPI);
SSYNC();
bfin_write_PORTF_FER(bfin_read_PORTF_FER() | 0x3840);
SSYNC();
-
- } else if (chip->chip_select_num == 5) {
+ break;
+
+ case 5:
bfin_write_PORT_MUX(bfin_read_PORT_MUX() | PFS5E_SPI);
SSYNC();
bfin_write_PORTF_FER(bfin_read_PORTF_FER() | 0x3820);
SSYNC();
+ break;
- } else if (chip->chip_select_num == 6) {
+ case 6:
bfin_write_PORT_MUX(bfin_read_PORT_MUX() | PFS6E_SPI);
SSYNC();
bfin_write_PORTF_FER(bfin_read_PORTF_FER() | 0x3810);
SSYNC();
-
- } else if (chip->chip_select_num ==
[PATCH 6/7] blackfin serial core driver: UART1 should depend on BF534/BF536/BF537, remove experimental marking from on-chip serial core driver and make options less wordy.
Signed-off-by: Bryan Wu <[EMAIL PROTECTED]> --- drivers/serial/Kconfig | 12 ++-- 1 files changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig index 3484834..e8efe93 100644 --- a/drivers/serial/Kconfig +++ b/drivers/serial/Kconfig @@ -513,8 +513,8 @@ config SERIAL_SA1100_CONSOLE kernel at boot time.) config SERIAL_BFIN - tristate "Blackfin serial port support (EXPERIMENTAL)" - depends on BFIN && EXPERIMENTAL + tristate "Blackfin serial port support" + depends on BFIN select SERIAL_CORE select SERIAL_BFIN_UART0 if (BF531 || BF532 || BF533 || BF561) help @@ -529,7 +529,7 @@ config SERIAL_BFIN_CONSOLE select SERIAL_CORE_CONSOLE choice - prompt "Blackfin UART Mode" + prompt "UART Mode" depends on SERIAL_BFIN default SERIAL_BFIN_DMA help @@ -537,14 +537,14 @@ choice of CPUs config SERIAL_BFIN_DMA - bool "Blackfin UART DMA mode" + bool "DMA mode" depends on DMA_UNCACHED_1M help This driver works under DMA mode. If this option is selected, the blackfin simple dma driver is also enabled. config SERIAL_BFIN_PIO - bool "Blackfin UART PIO mode" + bool "PIO mode" help This driver works under PIO mode. @@ -581,7 +581,7 @@ config UART0_RTS_PIN config SERIAL_BFIN_UART1 bool "Enable UART1" - depends on SERIAL_BFIN && BF537 + depends on SERIAL_BFIN && (BF534 || BF536 || BF537) help Enable UART1 -- 1.5.1.2 - 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 2/7] blackfin arch: fix bug refuse to boot if rootfs image is not attached when MTD_UCLINUX is selected
Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
---
arch/blackfin/kernel/setup.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/blackfin/kernel/setup.c b/arch/blackfin/kernel/setup.c
index 76e1f10..6a2190f 100644
--- a/arch/blackfin/kernel/setup.c
+++ b/arch/blackfin/kernel/setup.c
@@ -293,6 +293,11 @@ void __init setup_arch(char **cmdline_p)
memory_end -= mtd_size;
+ if (mtd_size == 0) {
+ console_init();
+ panic("Don't boot kernel without rootfs attached.\n");
+ }
+
/* Relocate MTD image to the top of memory after the uncached memory
area */
dma_memcpy((char *)memory_end, __bss_stop, mtd_size);
--
1.5.1.2
-
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 3/7] blackfin arch: move revid function into global headers as inline functions
Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
---
arch/blackfin/kernel/setup.c| 72 +++---
include/asm-blackfin/mach-bf533/bf533.h |2 +-
include/asm-blackfin/mach-bf537/bf537.h |2 +-
include/asm-blackfin/mach-bf561/bf561.h |2 +-
include/asm-blackfin/processor.h| 25 +++
5 files changed, 45 insertions(+), 58 deletions(-)
diff --git a/arch/blackfin/kernel/setup.c b/arch/blackfin/kernel/setup.c
index 6a2190f..724fd7a 100644
--- a/arch/blackfin/kernel/setup.c
+++ b/arch/blackfin/kernel/setup.c
@@ -121,34 +121,6 @@ void bf53x_relocate_l1_mem(void)
}
-/* Get the DSP Revision ID */
-static u_int get_dsp_rev_id(void)
-{
- u_int id;
- id = bfin_read_DSPID() & 0x;
-#if defined(CONFIG_BF561)
- id>>=8;
-#endif
- return id;
-}
-
-static inline u_int get_compiled_rev_id(void)
-{
-#if defined(CONFIG_BF_REV_0_0)
- return 0;
-#elif defined(CONFIG_BF_REV_0_1)
- return 1;
-#elif defined(CONFIG_BF_REV_0_2)
- return 2;
-#elif defined(CONFIG_BF_REV_0_3)
- return 3;
-#elif defined(CONFIG_BF_REV_0_4)
- return 4;
-#elif defined(CONFIG_BF_REV_0_5)
- return 5;
-#endif
-}
-
/*
* Initial parsing of the command line. Currently, we support:
* - Controlling the linux memory size: mem=xxx[KMG]
@@ -196,7 +168,7 @@ static __init void parse_cmdline_early(char *cmdline_p)
void __init setup_arch(char **cmdline_p)
{
- int bootmap_size, id;
+ int bootmap_size;
unsigned long l1_length, sclk, cclk;
#ifdef CONFIG_MTD_UCLINUX
unsigned long mtd_phys = 0;
@@ -329,30 +301,23 @@ void __init setup_arch(char **cmdline_p)
init_mm.brk = (unsigned long)0;
init_leds();
- id = get_dsp_rev_id();
-
- printk(KERN_INFO
- "Blackfin support (C) 2004-2006 Analog Devices, Inc.\n");
- printk(KERN_INFO "Compiled for ADSP-%s Rev. 0.%d\n", CPU,
- get_compiled_rev_id());
- if (id != get_compiled_rev_id())
- printk(KERN_ERR
- "Warning: Compiled for Rev %d, but running on Rev %d\n",
- get_compiled_rev_id(), id );
- if (id < SUPPORTED_DSPID)
- printk(KERN_ERR
- "Warning: Unsupported Chip Revision ADSP-%s Rev. 0.%d
detected\n",
- CPU, id);
- printk(KERN_INFO
- "Blackfin uClinux support by http://blackfin.uclinux.org/\n;);
+
+ printk(KERN_INFO "Blackfin support (C) 2004-2007 Analog Devices,
Inc.\n");
+ printk(KERN_INFO "Compiled for ADSP-%s Rev 0.%d\n", CPU,
bfin_compiled_revid());
+ if (bfin_revid() != bfin_compiled_revid())
+ printk(KERN_ERR "Warning: Compiled for Rev %d, but running on
Rev %d\n",
+ bfin_compiled_revid(), bfin_revid());
+ if (bfin_revid() < SUPPORTED_REVID)
+ printk(KERN_ERR "Warning: Unsupported Chip Revision ADSP-%s Rev
0.%d detected\n",
+ CPU, bfin_revid());
+ printk(KERN_INFO "Blackfin Linux support by
http://blackfin.uclinux.org/\n;);
printk(KERN_INFO "Processor Speed: %lu MHz core clock and %lu Mhz
System Clock\n",
cclk / 100, sclk / 100);
#if defined(ANOMALY_05000273)
if ((cclk >> 1) <= sclk)
- printk(KERN_ERR
- "\n\n\nANOMALY_05000273: CCLK must be >= 2*SCLK
!!!\n\n\n");
+ printk("\n\n\nANOMALY_05000273: CCLK must be >= 2*SCLK
!!!\n\n\n");
#endif
printk(KERN_INFO "Board Memory: %ldMB\n", physical_mem_end >> 20);
@@ -778,21 +743,19 @@ EXPORT_SYMBOL(get_sclk);
static int show_cpuinfo(struct seq_file *m, void *v)
{
char *cpu, *mmu, *fpu, *name;
-#ifdef CONFIG_BLKFIN_CACHE_LOCK
- int lock;
-#endif
+ uint32_t revid;
u_long cclk = 0, sclk = 0;
- u_int id, dcache_size = 0, dsup_banks = 0;
+ u_int dcache_size = 0, dsup_banks = 0;
cpu = CPU;
mmu = "none";
fpu = "none";
+ revid = bfin_revid();
name = bfin_board_name;
cclk = get_cclk();
sclk = get_sclk();
- id = get_dsp_rev_id();
seq_printf(m, "CPU:\t\tADSP-%s Rev. 0.%d\n"
"MMU:\t\t%s\n"
@@ -801,7 +764,7 @@ static int show_cpuinfo(struct seq_file *m, void *v)
"System Clock:\t%9lu Hz\n"
"BogoMips:\t%lu.%02lu\n"
"Calibration:\t%lu loops\n",
- cpu, id, mmu, fpu,
+ cpu, revid, mmu, fpu,
cclk,
sclk,
(loops_per_jiffy * HZ) / 50,
@@ -856,8 +819,7 @@ static int show_cpuinfo(struct seq_file *m, void *v)
dsup_banks, BLKFIN_DSUBBANKS, BLKFIN_DWAYS,
BLKFIN_DLINES);
#ifdef CONFIG_BLKFIN_CACHE_LOCK
- lock = read_iloc();
- switch (lock) {
+ switch (read_iloc()) {
case WAY0_L:
[PATCH 0/7] blackfin arch and driver patches update against 2.6.21-rc7-mm2
* Some bugfixes in blackfin arch patch, serial core patch * Update blackfin spi controller driver patch accoding to David Brownell's review - 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 1/7] blackfin arch: fix coding style in ints-priority-sc C file
Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
---
arch/blackfin/mach-common/ints-priority-sc.c | 77 +++--
1 files changed, 34 insertions(+), 43 deletions(-)
diff --git a/arch/blackfin/mach-common/ints-priority-sc.c
b/arch/blackfin/mach-common/ints-priority-sc.c
index c30726b..34b6228 100644
--- a/arch/blackfin/mach-common/ints-priority-sc.c
+++ b/arch/blackfin/mach-common/ints-priority-sc.c
@@ -329,11 +329,9 @@ static unsigned int bfin_gpio_irq_startup(unsigned int irq)
u16 gpionr = irq - IRQ_PF0;
if (!(gpio_enabled[gpio_bank(gpionr)] & gpio_bit(gpionr))) {
-
ret = gpio_request(gpionr, NULL);
- if(ret)
+ if (ret)
return ret;
-
}
gpio_enabled[gpio_bank(gpionr)] |= gpio_bit(gpionr);
@@ -355,55 +353,49 @@ static int bfin_gpio_irq_type(unsigned int irq, unsigned
int type)
unsigned int ret;
u16 gpionr = irq - IRQ_PF0;
+ if (type == IRQ_TYPE_PROBE) {
+ /* only probe unenabled GPIO interrupt lines */
+ if (gpio_enabled[gpio_bank(gpionr)] & gpio_bit(gpionr))
+ return 0;
+ type = IRQ_TYPE_EDGE_RISING | IRQ_TYPE_EDGE_FALLING;
+ }
- if (type == IRQ_TYPE_PROBE) {
- /* only probe unenabled GPIO interrupt lines */
- if (gpio_enabled[gpio_bank(gpionr)] & gpio_bit(gpionr))
- return 0;
- type = IRQ_TYPE_EDGE_RISING | IRQ_TYPE_EDGE_FALLING;
-
- }
-
- if (type & (IRQ_TYPE_EDGE_RISING | IRQ_TYPE_EDGE_FALLING |
- IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_LEVEL_LOW)) {
-
+ if (type & (IRQ_TYPE_EDGE_RISING | IRQ_TYPE_EDGE_FALLING |
+ IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_LEVEL_LOW))
+ {
if (!(gpio_enabled[gpio_bank(gpionr)] & gpio_bit(gpionr))) {
-
ret = gpio_request(gpionr, NULL);
- if(ret)
+ if (ret)
return ret;
-
- }
-
- gpio_enabled[gpio_bank(gpionr)] |= gpio_bit(gpionr);
- } else {
- gpio_enabled[gpio_bank(gpionr)] &= ~gpio_bit(gpionr);
- return 0;
}
+ gpio_enabled[gpio_bank(gpionr)] |= gpio_bit(gpionr);
+ } else {
+ gpio_enabled[gpio_bank(gpionr)] &= ~gpio_bit(gpionr);
+ return 0;
+ }
- set_gpio_dir(gpionr, 0);
- set_gpio_inen(gpionr, 1);
-
+ set_gpio_dir(gpionr, 0);
+ set_gpio_inen(gpionr, 1);
- if (type & (IRQ_TYPE_EDGE_RISING | IRQ_TYPE_EDGE_FALLING)) {
- gpio_edge_triggered[gpio_bank(gpionr)] |=
gpio_bit(gpionr);
- set_gpio_edge(gpionr, 1);
- } else {
- set_gpio_edge(gpionr, 0);
- gpio_edge_triggered[gpio_bank(gpionr)] &=
~gpio_bit(gpionr);
- }
+ if (type & (IRQ_TYPE_EDGE_RISING | IRQ_TYPE_EDGE_FALLING)) {
+ gpio_edge_triggered[gpio_bank(gpionr)] |= gpio_bit(gpionr);
+ set_gpio_edge(gpionr, 1);
+ } else {
+ set_gpio_edge(gpionr, 0);
+ gpio_edge_triggered[gpio_bank(gpionr)] &= ~gpio_bit(gpionr);
+ }
- if ((type & (IRQ_TYPE_EDGE_RISING | IRQ_TYPE_EDGE_FALLING))
- == (IRQ_TYPE_EDGE_RISING | IRQ_TYPE_EDGE_FALLING))
- set_gpio_both(gpionr, 1);
- else
- set_gpio_both(gpionr, 0);
+ if ((type & (IRQ_TYPE_EDGE_RISING | IRQ_TYPE_EDGE_FALLING))
+ == (IRQ_TYPE_EDGE_RISING | IRQ_TYPE_EDGE_FALLING))
+ set_gpio_both(gpionr, 1);
+ else
+ set_gpio_both(gpionr, 0);
- if ((type & (IRQ_TYPE_EDGE_FALLING | IRQ_TYPE_LEVEL_LOW)))
- set_gpio_polar(gpionr, 1); /* low or falling edge
denoted by one */
- else
- set_gpio_polar(gpionr, 0); /* high or rising edge
denoted by zero */
+ if ((type & (IRQ_TYPE_EDGE_FALLING | IRQ_TYPE_LEVEL_LOW)))
+ set_gpio_polar(gpionr, 1); /* low or falling edge denoted
by one */
+ else
+ set_gpio_polar(gpionr, 0); /* high or rising edge denoted
by zero */
SSYNC();
@@ -416,7 +408,6 @@ static int bfin_gpio_irq_type(unsigned int irq, unsigned
int type)
}
-
static struct irq_chip bfin_gpio_irqchip = {
.ack = bfin_gpio_ack_irq,
.mask = bfin_gpio_mask_irq,
--
1.5.1.2
-
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
Re: [ckrm-tech] [PATCH 1/9] Containers (V9): Basic container framework
+static ssize_t container_read_uint(struct container *cont, struct cftype *cft,
+ struct file *file,
+ char __user *buf, size_t nbytes,
+ loff_t *ppos)
+{
+ char tmp[64];
+ u64 val = cft->read_uint(cont, cft);
+ int len = sprintf(tmp, "%llu", val);
This sprintf is giving me the following compiler warnings:
kernel/container.c: In function 'container_read_uint':
kernel/container.c:1025: warning: format '%llu' expects type 'long long
unsigned int', but argument 3 has type 'u64'
kernel/container.c:1025: warning: format '%llu' expects type 'long long
unsigned int', but argument 3 has type 'u64'
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[EMAIL PROTECTED]> 1.925.600.0401
-
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 2.6.21
On Sun, 29 Apr 2007 08:11:30 +1000 Neil Brown <[EMAIL PROTECTED]> wrote: > On Saturday April 28, [EMAIL PROTECTED] wrote: > > > > Yes, human involvement from someone with half a brain would be better. > > Andrew does a lot of that. Not a particularly good use of talent really. > > but still. > > I think more than half a brain is needed to do this well. You need a > reasonable understanding of how all the bits of the kernel work > together so that you have a good chance of sending the bug in the right > direction. You need a good understanding of the kernel community and > various sub communities so that you know who might be both able and > willing to deal with the bug. And it wouldn't hurt to have a good > over-view of the current 'hot' areas of the kernel so you know if it > is really worth suggesting "try with the latest -mm" or not. > And you need good people skills. > > So I think you really need a lot of up-to-date knowledge to do this > well. Because of Andrew's position as a funnel, he has a lot of that > knowledge. yup > It would be really nice if he had some help though. Amen, Brother Neil. > And I > really think that would mean finding someone in the community who > would rather be coding (and currently are) and convincing them that > there is a higher calling for them. Finding someone out side or on > the edge of the community is less likely to be effective. http://www.google.com/support/jobs/bin/answer.py?answer=53317 This is a fully funded regular full-time position @google's Mountain View HQ, sitting within nagging range of myself, doing precisely what you describe. Unfortunately the recruiting has been a bit tricky - this is not a typical job and it's a funny mixture of bureaucracy/politics/social engineering and programming. People who are skilled in both areas, are, ah, uncommon. But it will happen eventually. Meanwhile I - ensure that all bugzilla reports are routed to the relevant maintainer - ensure that all those who reported bugs via email are later asked to raise bugzilla reports if it didn't get fixed (but I only monitor one list!) - continue to file away all the real-looking bugzillas with the intention of generating aggregated reports, but you know how it is. - 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: [-mm patch] make drivers/misc/thinkpad_acpi:fan_mutex static
On Sat, Apr 28, 2007 at 04:58:21PM -0300, Henrique de Moraes Holschuh wrote: > On Sat, 28 Apr 2007, Adrian Bunk wrote: >... > > BTW: Prototypes for static versions and static variables in a header > > file are really wrong, but the mess is bigger than what I'm > > willing to clean up... > > It is a private header file, only one file uses it and it is not supposed to > be used by any other file ever, either. I can certainly do a cleaning up > and a lot can be removed (at least 70% of it), but the driver is not linear > (it is some infrastructure and various subdrivers) and there is a bunch of > stuff that will need forward declarations regardless. Forward declarations of static functions (if required) and actual variables (like fan_mutex) belong into the C file, not the header. > Maybe I should just break the driver into multiple files in a subdirectory? > That would certainly make it *much* cleaner... But even more in this case, you will not want to have actual variables or prototypes of static functions in the header file. > > --- linux-2.6.21-rc7-mm2/drivers/misc/thinkpad_acpi.h.old 2007-04-27 > > 00:55:58.0 +0200 > > +++ linux-2.6.21-rc7-mm2/drivers/misc/thinkpad_acpi.h 2007-04-28 > > 01:32:54.0 +0200 > > @@ -382,7 +382,7 @@ > > static u8 fan_control_desired_level; > > static int fan_watchdog_maxinterval; > > > > -struct mutex fan_mutex; > > +static struct mutex fan_mutex; > > > > static acpi_handle fans_handle, gfan_handle, sfan_handle; > > > Henrique Holschuh 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 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] ibmtr_cs: fix hang on eject
Sent this patch a few weeks ago to the addresses listed for Token Ring
maintainers. No response, and the linux-tr@ address bounced. Resent
here in case someone wants to pick it up. Perhaps a MAINTAINERS edit
might be in order also.
- Paul
Ejecting a PCMCIA IBM Token Ring card that has not had its dev->open()
called will reliably trigger an uninitialized spinlock oops when spinlock
debugging is enabled. The system then hangs, occasionally softlockup
oopsing. Apparently ibmtr.c:tok_interrupt() doesn't expect to be called
before tok_open(), but tok_interrupt() gets called anyway when the card is
ejected. So, set an already-existing flag which causes tok_interrupt() to
bail out early upon card ejection. Tested by inserting and removing the
PCMCIA card several times.
Patch against 2.6.21-rc6.
Signed-off-by: Paul Walmsley <[EMAIL PROTECTED]>
---
dev/drivers/net/pcmcia/ibmtr_cs.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
Index: linux/dev/drivers/net/pcmcia/ibmtr_cs.c
===
--- linux.orig/dev/drivers/net/pcmcia/ibmtr_cs.c
+++ linux/dev/drivers/net/pcmcia/ibmtr_cs.c
@@ -189,16 +189,20 @@ static void ibmtr_detach(struct pcmcia_d
{
struct ibmtr_dev_t *info = link->priv;
struct net_device *dev = info->dev;
+struct tok_info *ti = netdev_priv(dev);
DEBUG(0, "ibmtr_detach(0x%p)\n", link);
+
+/*
+ * When the card removal interrupt hits tok_interrupt(),
+ * bail out early, so we don't crash the machine
+ */
+ti->sram_phys |= 1;
if (link->dev_node)
unregister_netdev(dev);
-{
- struct tok_info *ti = netdev_priv(dev);
- del_timer_sync(&(ti->tr_timer));
-}
+del_timer_sync(&(ti->tr_timer));
ibmtr_release(link);
-
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] use mutex instead of semaphore in Sony PI driver
On Tuesday 24 April 2007 20:22, Mattia Dongili wrote: > Acked-by: Mattia Dongili <[EMAIL PROTECTED]> applied. thanks, -Len - 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: [-mm patch] make drivers/misc/thinkpad_acpi:fan_mutex static
> > This patch makes the needlessly global fan_mutex static. applied. thanks, -Len - 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] crypto: Remove pointless padlock module
Simon Arlott wrote: When this is compiled in it is run too early to do anything useful: [6.052000] padlock: No VIA PadLock drivers have been loaded. [6.052000] padlock: Using VIA PadLock ACE for AES algorithm. [6.052000] padlock: Using VIA PadLock ACE for SHA1/SHA256 algorithms. When it's a module it isn't doing anything special, the same functionality can be provided in userspace by "probeall padlock padlock-aes padlock-sha" in modules.conf if it is required. Signed-off-by: Simon Arlott <[EMAIL PROTECTED]> Cc: Herbert Xu <[EMAIL PROTECTED]> Cc: Michal Ludvig <[EMAIL PROTECTED]> --- drivers/crypto/Kconfig | 16 ++-- drivers/crypto/Makefile |1 - drivers/crypto/padlock.c | 58 -- 3 files changed, 3 insertions(+), 72 deletions(-) delete mode 100644 drivers/crypto/padlock.c diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig index ff8c4be..f85cecc 100644 --- a/drivers/crypto/Kconfig +++ b/drivers/crypto/Kconfig @@ -1,10 +1,10 @@ menu "Hardware crypto devices" config CRYPTO_DEV_PADLOCK -tristate "Support for VIA PadLock ACE" -depends on X86_32 +bool "Support for VIA PadLock ACE" +depends on CRYPTO && X86_32 All of drivers/crypto/Kconfig already depends on CRYPTO, so just depends on X86_32 should be enough. +default y select CRYPTO_ALGAPI -default m help Some VIA processors come with an integrated crypto engine (so called VIA PadLock ACE, Advanced Cryptography Engine) -- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - 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/9] Containers (V9): Generic Process Containers
> - decide whether "Containers" is an acceptable name for the system > given its usage by some other development groups, or whether something > else (ProcessSets? ResourceGroups? TaskGroups?) would be better I place in nomination: tasksets However this would conflict with the taskset utility in Robert Loves schedutils package. The 'taskset' command "is used to set or retrieve the CPU affinity of a running process given its PID or to launch a new COMMAND with a given CPU affinity." The various alternatives you listed all have the advantage of stating both that we have a container/group/set/collection/... of something, and -what- that something might be - process/resource/task/... "tasksets" is the shortest spelling I could think of for such a compond "Something-Collection" form. If the conflict with the schedutils utility is a concern, then the next best alternative would be: taskgroups This is the next shortest way to spell this "Something-Collection" form. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 1.925.600.0401 - 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: suspend2 merge (was Re: [Suspend2-devel] Re: CFS and suspend2: hang in atomic copy)
Matthew Garrett wrote: > On Sat, Apr 28, 2007 at 12:15:50PM -0700, David Lang wrote: >> with dynaticks now in the kernel it may even be possible to have the idle >> process decide that the next event is far enough away that it should >> suspend-to-ram until that point. > > This would be ideal (and it's broadly what the OLPC guys are aiming for, > I think), but on most platforms you're looking at at least a second or > so to resume. As far as I know, we're still looking at ~60 ticks a > second at best for an average desktop, so that's not going to be a win. As long as the system has a clear idea of how long it will take to resume, it can schedule a wakeup for a reasonable amount of time before that. Ideally, a completely unused system might not need a tick for several seconds. However, I agree that it doesn't make sense to add such functionality to the kernel until someone can show a system that can actually wait that long between ticks. - Josh Triplett - 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: [stable] 2.6.21 known regressions (v2) (for -stable team)
On Sat, Apr 28, 2007 at 11:21:54PM +0200, Krzysztof Halasa wrote: > Greg KH <[EMAIL PROTECTED]> writes: > > >> Also, assignation of ttyUSB#'s is volatile depending on phase of the > >> moon when booted. > > > > That's always been the case, ever since the 2.2 kernel releases. Please > > use udev if you want persistent device names for your tty USB devices. > > I don't know how udev (or anything) could help here. AFAIK the > converters have no serial numbers and no other means to > differentiate. Some do have serial numbers, and others do not. You can also use hints on which port they are plugged into, which is usually the best way to name these types of things persistently. thanks, greg k-h - 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] UIO patches for 2.6.21
On Sat, Apr 28, 2007 at 10:31:37PM +0200, Thomas Gleixner wrote: > On Sat, 2007-04-28 at 21:15 +0100, Alan Cox wrote: > > > > I have a political question, if I have a user space driver, is my > > > > kernel > > > > tainted or not? > > > > > > Surely not. By using the kernel's userspace interface, you create no > > > "derived work" of the kernel. See COPYING in the root directory of the > > > kernel sources for details. > > > > That only covers normal system calls - but I don't think thats what is > > relevant, taints are for debug assistance not politics. > > > > I think we should have a taint flag for UIO type drivers. Not for any > > licensing or political reason but for the simple fact it means that there > > may be other complexities to debugging - and not the same one as a binary > > module. Probably we want the same marker for mmap /dev/mem too. > > I agree, if we make it entirely clear that the flag is nonpolitical. Hm, I don't know, what makes this different from the fact that we can mmap PCI device space today through the proc and sysfs entries? That's how X gets direct access to the hardware for a number of different cards, and that's pretty much the same thing as the UIO interface is doing. Unless you think we should also use the same "taint" flag on those accesses too, and if so, I have no objection. thanks, greg k-h - 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: PCI Express MMCONFIG and BIOS Bug messages..
Chuck Ebbert wrote: Robert Hancock wrote: I've seen a lot of systems (including brand new Xeon-based servers from IBM and HP) that output messages on boot like: PCI: BIOS Bug: MCFG area at f000 is not E820-reserved PCI: Not using MMCONFIG. So Microsoft is explicitly telling the BIOS developers that there is no need to reserve the MMCONFIG space in the E820 table because Windows doesn't care. On that basis it doesn't seem like a valid check to require it to be so reserved, then. Really, I think we should be basing this check on whether the corresponding memory range is reserved in the ACPI resources, like Windows expects. This does require putting more fingers into ACPI from this early boot stage, though.. Intel had posted patches to do exactly that, but they were rejected. I don't remember why now... I tried adapting a patch by Rajesh Shah to do this for current kernels: http://lkml.org/lkml/2006/6/23/365 It walks through all the motherboard resource devices and tries to pull out the resource settings for all of them using the _CRS method. (Depending on how you do the probing, the _STA method is called as well, either before or after.) From my limited ACPI knowledge, the problem is that the PCI MMCONFIG initialization is called before the main ACPI interpreter is enabled, and these control methods may try to access operation regions who don't have handlers set up for them yet, so a bunch of "no handler for region" errors show up. I think some earlier version of this patch was in -mm for a while back in 2.6.18 times, I actually complained about it back then because it falsely detected the region wasn't reserved on my system since it bailed out on the first such error before it found the reservation. On my system it turns out that the device called EXPL that has the MCFG table reservation in it has the addresses statically defined in the _CRS method and doesn't need to access any regions, so if you make the search continue on after errors, it does actually work, but there's probably no guarantee that all systems will have the MCFG reservation statically defined like this, and we can't have all those ACPI errors from other devices clogging the logs either. So essentially if we want to do this check based on ACPI resource reservations, we need to be able to execute control methods at the point that MMCONFIG is set up. Is there a reason why this can't be made possible (like by moving the necessary parts of ACPI initialization earlier)? -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.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: [patch] CFS scheduler, -v6
Okay so i've tried with cfs 7 now, and the completely broken audio behavior is fixed. The only things i really notice now is that gtk apps seems to redraw somewhat slower, and renicing X doesent seem to be able to bring it on par with SD or vanilla. And smoothness just doesent match SD, it may be abit better than vanilla/staircase, i cant really definitively say, but SD just has the smoothness factor which is extremely attractive. This is with 3d stuff, like through wine or natively on linux, under load(and even just minor things like using a browser or other things, like spamasassin), vanilla/staircase(not rsdl or sd)/cfs will go down in FPS, but at the same time stutter, it goes down to around the same fps under same load, as SD, but SD is completely smooth. Im not sure im describing properly, but say it takes 35fps for the 3d stuff to seem perfect, the fps monitor updates once every 1 or two seconds, showing average fps(havent looked at the code, but i assume it spans those 1-2 seconds), usually i have like 60 fps, but under load it can go down to 35, but under anything but SD its not smooth, it will do the 35 fps, but i suspect it does it in chunks, for example it will skip for 200 ms and then hurry to display the 35 frames. This means it does get the workload done, but not in a very plesant matter, and its here i see SD as being in such a high league that its really impossible to describe the results with any other word than Perfect. mvh. Kasper Sandberg - 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: suspend2 merge (was Re: [Suspend2-devel] Re: CFS and suspend2: hang in atomic copy)
On Sat, Apr 28, 2007 at 12:15:50PM -0700, David Lang wrote: > with dynaticks now in the kernel it may even be possible to have the idle > process decide that the next event is far enough away that it should > suspend-to-ram until that point. This would be ideal (and it's broadly what the OLPC guys are aiming for, I think), but on most platforms you're looking at at least a second or so to resume. As far as I know, we're still looking at ~60 ticks a second at best for an average desktop, so that's not going to be a win. -- 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: [ANNOUNCE] battery2 git repository
On Sat, Apr 28, 2007 at 12:08:04PM -0700, Andrew Morton wrote: > On Sat, 28 Apr 2007 16:31:29 +0400 Anton Vorontsov <[EMAIL PROTECTED]> wrote: > > > On Sat, Apr 28, 2007 at 04:51:48AM -0700, Andrew Morton wrote: > > > On Fri, 27 Apr 2007 03:29:02 +0400 Anton Vorontsov <[EMAIL PROTECTED]> > > > wrote: > > > > > > > To not confuse with David own battery-2.6 repository, it's called > > > > battery2-2.6, and can be found here: > > > > > > > > http://git.infradead.org/?p=users/cbou/battery2-2.6.git;a=summary > > > > > > > > You can get it using "git clone --reference linux-2.6 \ > > > > git://git.infradead.org/users/cbou/battery2-2.6.git" command. > > > > > > i386 `make allmodconfig': > > > > > > ERROR: "battery_is_external_power_supplied" > > > [drivers/battery/ds2760_battery.ko] undefined! > > > ERROR: "battery_unregister" [drivers/battery/ds2760_battery.ko] undefined! > > > ERROR: "battery_register" [drivers/battery/ds2760_battery.ko] undefined! > > > ERROR: "battery_status_changed" [drivers/battery/ds2760_battery.ko] > > > undefined! > > > > :-/ > > > > It should be fixed 37 hours ago by > > > > http://git.infradead.org/?p=users/cbou/battery2-2.6.git;a=commit;h=cbb1e1b9e3a2cbf62ce4c13ef95d146ebc5e7274 > > I had that. I just did a fresh fetch and it still happens %-[ ]|floor Andrew, I'm wondering if "make clean" would help... I'm not lying, it works here. :-/ > akpm2:/usr/src/25> cd /usr/src/git26 > akpm2:/usr/src/git26> cat .git/branches/git-battery > git://git.infradead.org/users/cbou/battery2-2.6.git > akpm2:/usr/src/git26> git-fetch git-battery > akpm2:/usr/src/git26> git-checkout git-battery > Switched to branch "git-battery" > akpm2:/usr/src/git26> setenv ARCH i386 > akpm2:/usr/src/git26> make allmodconfig > /dev/null > akpm2:/usr/src/git26> make vmlinux modules I've done these steps, 1:1, copy-pasted, assuming that git26 is Linus' tree. So, I have: cbou:~/linux-2.6$ git log --pretty=oneline | head -n 15 045e09c3c8c71d41e9b2d98f2781cf0fa19ac3f9 Apple PMU Battery Kconfig: should also depend on BATTERY 8a7c6667b37e9fe407f68c4a53b8ff90e375d06a pda_power: fix copy-paste artifact 5f2a90ceccd3cc25a607c5658e986d07aa660a40 apm_power: add ability to calculate capacity using energy ed2702e9eedb16c65017cbd1313fdc7ee3f2c5ff pmu_battery: Apple PMU battery initial commit d38e1fb5612d950d64d09b2513af85edaa696d71 battery: add "model_name" and "present" attributes cbb1e1b9e3a2cbf62ce4c13ef95d146ebc5e7274 battery: fix modular build c565f9872f7f84f5e62b5ec1c90f140d443b756c ds2760_battery: use less "#ifdefs" fe0c0cd7c0f98f479b2d2895194460139cec566a ds2760 W1 slave bbb555a9edc8c5610ec5351bf984b6477d7486d4 remove "#if 0" from find_bus function, export it. ed061df82fbbb6d2228e9d1d5051a6f70b6849bd 1-Wire ds2760 chip battery driver a3e39e1b92d5cbe4a51be5f33208868dcf14da35 APM emulation driver for class batteries 8f6b1c2027c967ac9fe69a2cca74a0e682189e5a Universal battery class fa1099f32ef0d2dc64b09a1de034167cf0db1f37 pda power driver a9d7bc2ccadd2b6cb7eee75664c73fb75c58fa08 External power framework de46c33745f5e2ad594c72f2cf5f490861b16ce1 Linux 2.6.21 cbou:~/linux-2.6$ git status # On branch git-battery nothing to commit (working directory clean) > > WARNING: "battery_is_external_power_supplied" > [drivers/battery/ds2760_battery.ko] undefined! > WARNING: "battery_unregister" [drivers/battery/ds2760_battery.ko] undefined! > WARNING: "battery_register" [drivers/battery/ds2760_battery.ko] undefined! > WARNING: "battery_status_changed" [drivers/battery/ds2760_battery.ko] > undefined! > make[1]: *** [__modpost] Error 1 And logs: cbou:~/linux-2.6$ export ARCH=i386 cbou:~/linux-2.6$ make allmodconfig > /dev/null cbou:~/linux-2.6$ make vmlinux modules ... CC [M] drivers/battery/battery_core.o CC [M] drivers/battery/battery_sysfs.o CC [M] drivers/battery/battery_leds.o LD [M] drivers/battery/battery.o CC [M] drivers/battery/ds2760_battery.o LD drivers/block/built-in.o CC [M] drivers/block/floppy.o ... LD drivers/power/built-in.o CC [M] drivers/power/external_power.o CC [M] drivers/power/pda_power.o ... CC drivers/battery/battery.mod.o LD [M] drivers/battery/battery.ko CC drivers/battery/ds2760_battery.mod.o LD [M] drivers/battery/ds2760_battery.ko CC drivers/block/DAC960.mod.o LD [M] drivers/block/DAC960.ko CC drivers/block/aoe/aoe.mod.o ... CC drivers/power/external_power.mod.o LD [M] drivers/power/external_power.ko CC drivers/power/pda_power.mod.o LD [M] drivers/power/pda_power.ko ... LD [M] sound/usb/snd-usb-lib.ko CC sound/usb/usx2y/snd-usb-usx2y.mod.o LD [M] sound/usb/usx2y/snd-usb-usx2y.ko cbou:~/linux-2.6$ Here is my setup: cbou:~$ make -v GNU Make 3.81 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This program built
Re: [PATCH] i386: init early_gdt_descr and idle task properly on voyager
On Sunday 29 April 2007 02:21:27 Jeremy Fitzhardinge wrote: > Initialize early_gdt_descr and idle task properly. > > [ Incremental fix for "i386: introduce voyager smp_ops, fix voyager build" ] Please do a merged patch again and I'm waiting for it being tested. -Andi - 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 2.6.21
On 4/29/07, Bob Tracy <[EMAIL PROTECTED]> wrote: Linus Torvalds wrote: > On Sun, 29 Apr 2007, Markus Rechberger wrote: > > How else should bugs get handled, sending them to the lkml? > > Actually, looking at Adrian's regression lists, yes. lkml worked better > than bugzilla did. By at _least_ a factor of two. Since 1992, lkml (with "Cc:" to the appropriate subsystem mailing list if applicable) and the presumed responsible parties are the only channels I've used to report the bugs I encounter. since there are subsystems out there which are managed separatly this doesn't work out. I wasn't happy when I noticed that patches got applied to the sourcecode I contributed without notifying me while I still worked on that code separatly It was moreover the fault of the subsystem maintainer to not notify me back then but a centralized bugreporting (as bugzilla) tool would at least have notified me, or I would have been able to see the suggested changes there. But I agree with that if you're only 1 level far away from the linux kernel. Other methods come and go, but old habits die hard, particularly when they have a knack for producing the desired result. Historically, requiring a developer to fire up a GUI to read a bug report decreases the chance that bug report will be noticed. The development community can do whatever flips its collective switch as far as tracking bugs, but the bugs have to be reported and noticed before tracking becomes a meaningful activity. One more thought and I'll get off your screens... We've steadfastly resisted making lkml and friends subscriber-only mailing lists precisely because we don't want to miss a potential bug report because a would-be submitter isn't subscribed. If people aren't looking for bug reports here, what's the point? it's just easy to miss something here, if an ext3 bug comes in and all people who're involved in the ext3 filesytem are on vacation I'm sure they won't read all the mails which came in during a week, now take a part of the kernel which is smaller than the ext3 filesystem (eg. usb gadgets, smaller drivers) Markus - 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.21.stable PATCH] ACPI: Fix 2.6.21 boot regression on P4/HT
Up through 2.6.20 we cleared the FADT.CSTATE_CONTROL field
for FADT versions before r3, because it made no sense
for that reserved field to be set for pre-ACPI 2.0 systems.
It turns out that not clearing this field exposes
Linux to SMM BIOS failures, so do the same in 2.6.21.
http://bugzilla.kernel.org/show_bug.cgi?id=8346
Signed-off-by: Len Brown <[EMAIL PROTECTED]>
---
diff --git a/drivers/acpi/tables/tbfadt.c b/drivers/acpi/tables/tbfadt.c
index 807c711..d341491 100644
--- a/drivers/acpi/tables/tbfadt.c
+++ b/drivers/acpi/tables/tbfadt.c
@@ -347,6 +347,20 @@ static void acpi_tb_convert_fadt(void)
acpi_gbl_xpm1b_enable.space_id =
acpi_gbl_FADT.xpm1a_event_block.space_id;
}
+ /*
+* _CST object and C States change notification start with
+* ACPI 2.0 (FADT r3). Although the field should be Reserved
+* and 0 before then, some pre-r3 FADT set this field and
+* it results in SMM-related boot failures. For them, clear it.
+*/
+ if ((acpi_gbl_FADT.header.revision < 3) &&
+ (acpi_gbl_FADT.cst_control != 0)) {
+ ACPI_WARNING((AE_INFO,
+ "Ignoring BIOS FADT r%u C-state control",
+ acpi_gbl_FADT.header.revision));
+ acpi_gbl_FADT.cst_control = 0;
+ }
+
}
/**
-
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: maturity levels: a first pass
Robert P. J. Day wrote: > + This feature gives you the ability to de-select entire sets of > + kernel features based on how they've been tagged with the > + "maturity" directive. Why expose the end-user to implementation details like "been tagged with the 'maturity' directive"? ... > +config MATURITY_DEPRECATED > + bool "Display DEPRECATED features." ... Maybe you rather want bool "Allow to select DEPRECATED features." because MATURITY_DEPRECATED=N probably means "Do not allow to select DEPRECATED features" which implies that deprecated features will be deselected. In your wording, MATURITY_DEPRECATED=N would be just "Do not display DEPRECATED features" which is probably less than what you want it to be. That said, I don't know if the approach is going into the right direction. For example, the way you are starting it requires updates to all Kconfig UIs/scripts, to work correctly. Otherwise, users could select ACTIVATE_MATURITY but the tags would still be ignored. Another approach could be to - continue to use "config EXPERIMENTAL" and "depends on EXPERIMENTAL" and extend it for OBSOLETE, and if you cannot resist, for DEPRECATED, - extend interactive UIs like xconfig and menuconfig and oldconfig to display an EXPERIMENTAL sign alongside the title of an option which depends on EXPERIMENTAL, - delete occurrences of the string EXPERIMENTAL from titles of options and help texts, - vice versa for OBSOLETE, and if you cannot resist, for DEPRECATED. This does what you want while it keeps contents separate from presentation and avoids to extend the Kconfig language. A simple Kconfig language without presentational ballast allows for creation of a multitude of fine-tuned configurator UIs/scripts, which can be extended by all sorts of features, e.g. better support in dealing with obsolete configuration options. -- Stefan Richter -=-=-=== -=-- ===-= http://arcgraph.de/sr/ - 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: random thoughts on DEPRECATED and OBSOLETE
Robert P. J. Day wrote:
> * deprecated: while a feature is still supported, its use is
> discouraged because there is a better alternative that you should
> consider migrating to at your convenience.
IOW "discouraged, no {mid,long}-term commitment, alternative available,
supported"
> * obsolete: while a feature is still in the tree, it is no longer
> supported and no one should need it anymore, and everyone *should* be
> using the better alternative at this point.
IOW "discouraged, no {mid,long}-term commitment, alternative available,
*un*supported"
Note, that's different from http://kerneltrap.org/node/7593 --- the
supported bit is new. Why would I officially support what I deprecate?
Also, why don't we just adopt what "deprecated" and "obsolete" mean in
real life? (English dictionaries say, one means "disapproved", the
other means "outdated" or "no longer in use".) And if you don't find
these meanings applicable, other terms should be chosen whose
established meaning better matches what you want to express.
[...]
> there is an obvious timeline for features:
>
> normal -> deprecated -> obsolete
That wasn't clear (to me) from your earlier definitions.
IOW "normal" -> "obsolete and deprecated, phase 1" -> "obsolete and
deprecated, phase 2" (using the real-life meanings of the terms here)
with the fine distinction that there is still support available in phase
1, however curious that is.
Besides, I find it unfeasible to divide a feature removal process into
two phases. (I was involved in feature removals before and continue to
be involved in them.)
[...]
> in any event, i don't want to drag this out too much longer.
At least my pestering seems to lead to increasing precision in your
wordings. And believe me, precision in a feature removal process is
valuable for each party involved.
--
Stefan Richter
-=-=-=== -=-- ===-=
http://arcgraph.de/sr/
-
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 2.6.21
On 4/29/07, Linus Torvalds <[EMAIL PROTECTED]> wrote: On Sun, 29 Apr 2007, Markus Rechberger wrote: > > I totally disagree here, bugzilla is a very good tool. If someone is > too lazy to look at it it's his problem. You must be doing things very differently from a lot of other people if you think that's the case. Well I'm behind the stuff I'm doing because I'm interested in it. And if some bugs are introduced by my work or derived by my work I'd like to get them cleaned up in the end. If I see that someone reports bugs which doesn't really address my work at all I just forward them to the subsystem/maintainer who's "in charge" (if someone can say it that way for an open source project) > Kernel Janitors can pick out some bugs which aren't addressed by > anyone or got left behind. IF that happened, it would actually be great. That's what I'm arguing for. And it was basically what Adrian was doing! I'm very sure that happens maybe it's just not visible to everyone because there are so many open issues. (I just take myself as an example here, I didn't do too much with other bugs but at least some of my work closed 5 other bugs this year beside the bugreports I'm getting directly) > How else should bugs get handled, sending them to the lkml? Actually, looking at Adrian's regression lists, yes. lkml worked better than bugzilla did. By at _least_ a factor of two. Yes Adrian did a very good job with collecting every bugreport and sending the mails to all corresponding subsystems. > I'm 100% sure some bugreports will also get lost then, but on the lkml > they'll very likely remain lost whereas in the bugzilla they'll remain > as open. What's the difference between bugzilla and lkml.org? Both have search buttons. Both archive the old stuff. Both can be pointed to. Both have search buttons yes, but the lkml doesn't leave an unread mail open ontop of the lkml as bugzilla does if you look for open bugs in a subsystem. > what are your suggestions to improve a bugreporting tool, I'm very > sure that many people, especially people who want to get into existing > projects here, would love to contribute. I don't know what the perfect setup is, but I do know that bugzilla is very close to be totally useless for the top-level maintainers. Try to think like a person who doesn't maintain *one* specific file in the kernel, but who can actually make a good judgement about a lot of things, or at least funnel a problem report to the right person? And now, imagine that that person is also fairly busy (exactly *because* he's not looking at a single file, he may be maintaining a huge subsystem that has multiple submaintainers etc). And ask yourself whether bugzilla really helps. bugzilla keeps the bugs open at least, at the lkml I use to skip days sometimes. Many people who consider themself as maintainer of a subsystem are assigned to a subsection on bugzilla, if it really doesn't work out we have to change the corresponding maintainer. If that maintainer doesn't know where to go with that bugreport he can easily send it to the lkml and some people will recognize the sender/email and pay extra attention to it (that's just how I think about it) > I'd say this is a personal opinion, some people will get along with it > and some of them will not... I think bugzilla really only works for very "directed" issues. If you already know exactly which driver is affected (which is often wrong anyway: some of the bugs that were due timer breakage got blamed as disk hangs!) it's almost totally useless. And yes, maybe that's why you have a much higher opinion of bugzilla than I do. To _me_ bugzilla is a total mess. There's absolutely _zero_ useful information there. And I'm pretty certain that is true of a *lot* of other people too. But if you have a small project, or you maintain a very specific (and clearly delineated) part of a big project, bugzilla probably looks a lot more palatable. well are there any bugs that cannot be forwarded/directed to a corresponding maintainer? Maybe I don't see something here, can you point me out to a bugreport which cannot be handled at all? As a reference I'll take following bugreport: http://thread.gmane.org/gmane.linux.kernel/521185 the bug doesn't even mention what device is affected, asking for further detailed information (dmesg) shows up what's left at least.. (in the meanwhile the bug even got solved) Markus - 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: random thoughts on DEPRECATED and OBSOLETE
Robert P. J. Day wrote: > i think this online definition matches what i have in mind: > > http://www.google.com/search?hl=en=GGGL,GGGL:2006-10,GGGL:en=en=define:Deprecated=X=glossary_definition=title "Definitions of Deprecated on the Web: [...] This term is used to refer to /obsolete/ structures that should not be used for new applications". Emphasis is mine. I can agree with this and the other definitions at this search result. > p.s. just FYI, even *i'm* getting bored of this. :-) I thought so. :-) -- Stefan Richter -=-=-=== -=-- ===-= http://arcgraph.de/sr/ - 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] i386: init early_gdt_descr and idle task properly on voyager
Initialize early_gdt_descr and idle task properly. [ Incremental fix for "i386: introduce voyager smp_ops, fix voyager build" ] Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]> Cc: James Bottomley <[EMAIL PROTECTED]> Cc: Eric W. Biederman <[EMAIL PROTECTED]> --- arch/i386/kernel/smpboot.c |3 --- arch/i386/mach-voyager/voyager_smp.c |2 ++ include/asm-i386/processor.h |3 +++ 3 files changed, 5 insertions(+), 3 deletions(-) === --- a/arch/i386/kernel/smpboot.c +++ b/arch/i386/kernel/smpboot.c @@ -763,9 +763,6 @@ static inline struct task_struct * alloc #define alloc_idle_task(cpu) fork_idle(cpu) #endif -/* Defined in head.S */ -extern struct Xgt_desc_struct early_gdt_descr; - static int __cpuinit do_boot_cpu(int apicid, int cpu) /* * NOTE - on most systems this is a PHYSICAL apic ID, but on multiquad === --- a/arch/i386/mach-voyager/voyager_smp.c +++ b/arch/i386/mach-voyager/voyager_smp.c @@ -580,6 +580,8 @@ do_boot_cpu(__u8 cpu) stack_start.esp = (void *) idle->thread.esp; init_gdt(cpu); + per_cpu(current_task, cpu) = idle; + early_gdt_descr.address = (unsigned long)get_cpu_gdt_table(cpu); irq_ctx_init(cpu); /* Note: Don't modify initial ss override */ === --- a/include/asm-i386/processor.h +++ b/include/asm-i386/processor.h @@ -749,6 +749,9 @@ extern void enable_sep_cpu(void); extern void enable_sep_cpu(void); extern int sysenter_setup(void); +/* Defined in head.S */ +extern struct Xgt_desc_struct early_gdt_descr; + extern void cpu_set_gdt(int); extern void switch_to_new_gdt(void); extern void cpu_init(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/
Re: Linux 2.6.21
Linus Torvalds wrote: > On Sun, 29 Apr 2007, Markus Rechberger wrote: > > How else should bugs get handled, sending them to the lkml? > > Actually, looking at Adrian's regression lists, yes. lkml worked better > than bugzilla did. By at _least_ a factor of two. Since 1992, lkml (with "Cc:" to the appropriate subsystem mailing list if applicable) and the presumed responsible parties are the only channels I've used to report the bugs I encounter. Other methods come and go, but old habits die hard, particularly when they have a knack for producing the desired result. Historically, requiring a developer to fire up a GUI to read a bug report decreases the chance that bug report will be noticed. The development community can do whatever flips its collective switch as far as tracking bugs, but the bugs have to be reported and noticed before tracking becomes a meaningful activity. One more thought and I'll get off your screens... We've steadfastly resisted making lkml and friends subscriber-only mailing lists precisely because we don't want to miss a potential bug report because a would-be submitter isn't subscribed. If people aren't looking for bug reports here, what's the point? --Bob Tracy [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: Linux 2.6.21
On Sun, 29 Apr 2007, Neil Brown wrote: > > I think more than half a brain is needed to do this well. You need a > reasonable understanding of how all the bits of the kernel work > together so that you have a good chance of sending the bug in the right > direction. Yes. However, even if you just end up summarizing the current outstanding issues (and are not able to necessarily point to the right person), I suspect that all the top-level maintainers would be interested in it. As long as it's a "summary report twice a week" kind of thing. In fact, I suspect a lot of non-maintainers would be interested too! And if you then have some way for people to add commentary (and directing) to entries, you might start out not knowing where some bugreport should go, but you'll have people able to forward them. I end up doing that fairly regularly - adding people to the Cc when I'm involved in a bug, and we suddenly notice that "hey, it looks like it's a timer" issue or something, and we end up adding Ingo and Thomas Gleixner to the cc. This, btw, is why email is *so* much nicer than a web interface. A web interface is always "a single person looking at it". An email, on the other hand, is always "you can bounce it to make _another_ person look at it". But I agree that the more involved in the kernel the initiating person has been (at least to *some* degree), the better. No question. I just don't think it necessarily needs to be a hugely core person. Anybody who has been reading lkml for the last few months will already know a lot of the people involved in different subsystems! 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: Linux 2.6.21
On Sat, 28 Apr 2007, Martin J. Bligh wrote: > > Go to http://bugzilla.kernel.org. Hit query. Find the box that says > "Bug Changes, Only bugs changed in the last __ days". Stick 7 in it. > > 74 bugs found. > > Not hard to do. And what part of the "directed" did you miss? Do you really expect me to go there every day to look at all bugs? That's nbot a bug tracker. That's just a noise-maker. It needs to be email, not some "mouse around for 30 seconds and type thing", and it needs to be *directed*. Preferably with somebody who actually did some manual scanning over it and spent a few minutes just looking at whether it looks like a worthy bug. In other words: we shouldn't have all developers wasting time doing this. It would be much better to have _one_ person (or a group of people) doing it, and actually turnign your "Not hard to do" into real information, rather than just random data. Adrian did. The good news is that it looks like now that people are aware of it, we hopefully have others who will help do this kind of thing. 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: Linux 2.6.21
On Sat, Apr 28, 2007 at 04:40:31PM -0700, Linus Torvalds wrote: >... > What's the difference between bugzilla and lkml.org? Both have search > buttons. Both archive the old stuff. Both can be pointed to. Mailing lists don't track bugs. The _only_ reason why I originally started regression lists was because several kernel developers were spreading the fairy tale "noone tests -rc kernels". This was only possible because so many bug reports to linux-kernel never get any reply, and are therefore lost. After I started the regression lists, it suddenly turned out how many people test -rc kernels, and that even with regression lists at least weekly, it still often took weeks ontil some developer even started debugging a regression. So what's the difference between bugzilla and lkml.org? In Bugzilla we are able to see how bad our bug handling is... > Linus 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 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: Back to the future.
Hi. On Sat, 2007-04-28 at 16:45 -0700, Linus Torvalds wrote: > > On Sun, 29 Apr 2007, Rafael J. Wysocki wrote: > > > > OK, more precisely: fs-related threads should not try to process their > > queues, > > etc., after the snapshot is done, because that may cause some fs data to be > > written at that time and then the fs in question may be corrupted after the > > restore. Not all of the I/O in general, fs data. > > But that's not true _either_. That's only true because right now I think > we cannot even suspend to a swapfile (I might be wrong). > > If you have a swapfile on a filesystem, you'd need those fs queues > running! For Suspend2, and I think for swsusp too, we bmap the locations when allocating the storage, and then submit our own bios. Even if swsusp isn't using this method, I'm pretty sure the swap code does bmapping at swapon time to avoid raciness later. > > Well, I'm not sure whether or not that still would have been the case if we > > had > > stopped to freeze kernel threads for the hibernation/suspend. > > Did you miss the email where Paul pointed out that Mac/PowerPC didn't use > to do any of this? And apparently never had any issues with it? And > probably worked more reliably several years ago than suspend/hibernation > does _today_? > > Ie we do have history of _not_ freezing things. The freezing came later, > and came with the subsystem that had more problems.. It also came because of problems. Not working perfectly isn't necessarily a sign of a faulty reason for being added in the first place. I should also add, not freezing things is fine if you're happy with getting half an image at most. If you want a full just-as-if-I'd-never-turned-the-power-off image, you need freezing so that you can have some pages which can be saved before others are atomically copied, to ensure the whole image is consistent. Nigel signature.asc Description: This is a digitally signed message part
Re: Linux 2.6.21
On Sun, 29 Apr 2007, Adrian Bunk wrote: > > Bugzilla has an email interface. > Andrew forwards bugs from Bugzilla to developers. Yes. And if you search around, you'll even see that I occasionally use it. But it's useful only once the bug has been assigned and somebody has actually *looked* at it. The fact that some people do this is a big credit (Andrew, Dave J etc) > There might be small room for improvements, but I don't see how > man-power or technology could make a big difference in this area. I'm talking about getting the developers to _look_ at the bugs in the first place. Bugzilla is not very good at that, because it has no useful interfaces for doing so (unless you can specify your area of interest so exactly that you can actually set yourself up as a maintainer of one particular area). Almost none of the subtle (and thus harder) bugs tend to fall into that kind of nice category. For example, look at suspend/resume bugs. Do you realize that 99% of them are device driver issues, but how the heck do you connect a "my laptop does't resume" to the _right_ device driver maintainer? And do you realize (and acknowledge) that it would be total madness to send all suspend/resume bugs to _everybody_ who maintains any device driver at all? See? THAT is the problem with bugzilla. It only works for the "easy" cases. It works for the case where a reporter can say with certainty that the reason his machine doesn't boot is a particular network device driver (like the sis900 regression we had in 2.6.21). But once you know the subarea that precisely, bugzilla doesn't even help you that much, and it's likely easier and more productive to just send email directly to the right person and cc Jeff and netdev or something! > "*once* you've found and gotten the right developer involved" is the > real problem, not how to track bugs. And I agree 100%. And bugzilla does *nothing* here. > *This* is *the* problem. > And no change in bug tracking will help with this problem. So why are you pushing bugzilla? There are actually better bug trackers around. One of them is "google". For oopses, one of the thngs I do is to put in the most relevant information (backtrace etc) into google, and ask google to try to find the pattern. That sometimes actually does pretty well - you can get a real feel for "oh, there's a pattern here - they're all AMD machines with the NVidia chipset" kind of thing. Bugzilla doesn't offer anything even remotely as useful. It's the "big picture" that tends to be hard to find. And that's what *you* gave with the regression report. A summary. You even noted some of the patterns, so people actually had them already somewhat pre-sorted. THAT is what we want. But another way to get the "high-level picture" is to actually just say "what's active now". And that's why I think the whole "1600 open bug-reports" kind of thing is useless. Bugzilla does *not* have mail interfaces for that kind of "these 50 bugs were actively reported on and unresolved" in the last week summaries! (And if it did, it would still almost certainly need some human care and understanding) 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: Please revert [PATCH] user of the jiffies rounding patch: Slab
On Sat, 2007-04-28 at 16:35 -0700, Christoph Lameter wrote: > Hmmm... Yes but that looks like it comes from a different function. Slab > calls > > __round_jiffies_relative(HZ, cpu)) > > And its description says: > > /** > * > * The exact rounding is skewed for each processor to avoid all > * processors firing at the exact same time, which could lead > * to lock contention or spurious cache line bouncing. > This is exactly the wrong thing to do. is it? - 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] mm/memory.c: remove warning from an uninitialized spinlock. was: Re: 2.6.21-rc7-mm2
Andrew Morton wrote: > On Thu, 26 Apr 2007 20:25:19 +0200 > Borislav Petkov <[EMAIL PROTECTED]> wrote: > >> Remove build warning mm/memory.c:1491: warning: 'ptl' may be used >> uninitialized in this function. >> The spinlock pointer is assigned to null since it gets overwritten right >> away in >> pte_alloc_map_lock(). >> >> Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]> >> --- >> >> Index: linux-mm/mm/memory.c >> === >> --- linux-mm.orig/mm/memory.c2007-04-26 19:57:14.0 +0200 >> +++ linux-mm/mm/memory.c 2007-04-26 20:00:30.0 +0200 >> @@ -1488,7 +1488,7 @@ >> pte_t *pte; >> int err; >> struct page *pmd_page; >> - spinlock_t *ptl; >> + spinlock_t *ptl = NULL; >> >> pte = (mm == _mm) ? >> pte_alloc_kernel(pmd, addr) : >> > > yes, I've been staring unhappily at this for some time. > > Your change adds seven bytes of text to this function for no runtime > benefit, just to fix a build-time warning. It's a general problem. > > > Often we just leave the warning in place and curse gcc each time it flies > past. Sometimes the code can be restructured in a sensible fashion to > avoid the warning; often it cannot. > > But I don't think I want to put up with a warning coming out of core MM all > the time so let's go with the following silliness which adds no additional > runtime cost. > > --- > a/mm/memory.c~add-apply_to_page_range-which-applies-a-function-to-a-pte-range-fix > +++ a/mm/memory.c > @@ -1455,7 +1455,7 @@ static int apply_to_pte_range(struct mm_ > pte_t *pte; > int err; > struct page *pmd_page; > - spinlock_t *ptl; > + spinlock_t *ptl = ptl; /* Suppress gcc warning */ > > pte = (mm == _mm) ? > pte_alloc_kernel(pmd, addr) : > _ > Perhaps we should have some kind definition helper. #define suppress_unused(x) x = x spinlock_t *suppress_unused(ptl); Perhaps? -apw - 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] i386: introduce voyager smp_ops, fix voyager build
Jeremy Fitzhardinge wrote: > Eric W. Biederman wrote: > >> Unless I have missed something early_gdt_descr still needs to be updated. >> >> > > The patch is on top of Andi's current queue, which includes quite a few > boot-time gdt setup cleanups. early_gdt_descr has gone. Hm, I was thinking of something else. Checking... J - 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: Back to the future.
On Sun, 29 Apr 2007, Rafael J. Wysocki wrote: > > OK, more precisely: fs-related threads should not try to process their queues, > etc., after the snapshot is done, because that may cause some fs data to be > written at that time and then the fs in question may be corrupted after the > restore. Not all of the I/O in general, fs data. But that's not true _either_. That's only true because right now I think we cannot even suspend to a swapfile (I might be wrong). If you have a swapfile on a filesystem, you'd need those fs queues running! > Well, I'm not sure whether or not that still would have been the case if we > had > stopped to freeze kernel threads for the hibernation/suspend. Did you miss the email where Paul pointed out that Mac/PowerPC didn't use to do any of this? And apparently never had any issues with it? And probably worked more reliably several years ago than suspend/hibernation does _today_? Ie we do have history of _not_ freezing things. The freezing came later, and came with the subsystem that had more problems.. 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] CFS scheduler, -v7
28 Nis 2007 Cts tarihinde, Ingo Molnar şunları yazmıştı: > * S.Çağlar Onur <[EMAIL PROTECTED]> wrote: > > If you want some more output/info etc. please just say, i have both v6 > > and v7 available. > > could you try the auto-renice patch ontop of -v7: > > http://people.redhat.com/mingo/cfs-scheduler/sched-cfs-auto-renice.patch > > does this make it behave like -v6? Ingo, please ignore my first report until i found a proper way to reproduce the slowness cause currently CFS-v7, CFS-v7 + "renice patch", CFS-v7 + renice + your private mail suggestions and CFS-v6 + "PI support for futexes patch" seems works equally (which is a good thing so X renicing seems really not needed, and there were no regression instead of my daydreams) or im too tired to understand the differences. -- S.Çağlar Onur <[EMAIL PROTECTED]> http://cekirdek.pardus.org.tr/~caglar/ Linux is like living in a teepee. No Windows, no Gates and an Apache in house! signature.asc Description: This is a digitally signed message part.
[PATCH] crypto: Remove pointless padlock module
When this is compiled in it is run too early to do anything useful:
[6.052000] padlock: No VIA PadLock drivers have been loaded.
[6.052000] padlock: Using VIA PadLock ACE for AES algorithm.
[6.052000] padlock: Using VIA PadLock ACE for SHA1/SHA256 algorithms.
When it's a module it isn't doing anything special, the same functionality
can be provided in userspace by "probeall padlock padlock-aes padlock-sha"
in modules.conf if it is required.
Signed-off-by: Simon Arlott <[EMAIL PROTECTED]>
Cc: Herbert Xu <[EMAIL PROTECTED]>
Cc: Michal Ludvig <[EMAIL PROTECTED]>
---
drivers/crypto/Kconfig | 16 ++--
drivers/crypto/Makefile |1 -
drivers/crypto/padlock.c | 58 --
3 files changed, 3 insertions(+), 72 deletions(-)
delete mode 100644 drivers/crypto/padlock.c
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index ff8c4be..f85cecc 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -1,10 +1,10 @@
menu "Hardware crypto devices"
config CRYPTO_DEV_PADLOCK
- tristate "Support for VIA PadLock ACE"
- depends on X86_32
+ bool "Support for VIA PadLock ACE"
+ depends on CRYPTO && X86_32
+ default y
select CRYPTO_ALGAPI
- default m
help
Some VIA processors come with an integrated crypto engine
(so called VIA PadLock ACE, Advanced Cryptography Engine)
@@ -14,16 +14,6 @@ config CRYPTO_DEV_PADLOCK
The instructions are used only when the CPU supports them.
Otherwise software encryption is used.
- Selecting M for this option will compile a helper module
- padlock.ko that should autoload all below configured
- algorithms. Don't worry if your hardware does not support
- some or all of them. In such case padlock.ko will
- simply write a single line into the kernel log informing
- about its failure but everything will keep working fine.
-
- If you are unsure, say M. The compiled module will be
- called padlock.ko
-
config CRYPTO_DEV_PADLOCK_AES
tristate "PadLock driver for AES algorithm"
depends on CRYPTO_DEV_PADLOCK
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index 6059cf8..d070030 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -1,4 +1,3 @@
-obj-$(CONFIG_CRYPTO_DEV_PADLOCK) += padlock.o
obj-$(CONFIG_CRYPTO_DEV_PADLOCK_AES) += padlock-aes.o
obj-$(CONFIG_CRYPTO_DEV_PADLOCK_SHA) += padlock-sha.o
obj-$(CONFIG_CRYPTO_DEV_GEODE) += geode-aes.o
diff --git a/drivers/crypto/padlock.c b/drivers/crypto/padlock.c
deleted file mode 100644
index d6d7dd5..000
--- a/drivers/crypto/padlock.c
+++ /dev/null
@@ -1,58 +0,0 @@
-/*
- * Cryptographic API.
- *
- * Support for VIA PadLock hardware crypto engine.
- *
- * Copyright (c) 2006 Michal Ludvig <[EMAIL PROTECTED]>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include "padlock.h"
-
-static int __init padlock_init(void)
-{
- int success = 0;
-
- if (crypto_has_cipher("aes-padlock", 0, 0))
- success++;
-
- if (crypto_has_hash("sha1-padlock", 0, 0))
- success++;
-
- if (crypto_has_hash("sha256-padlock", 0, 0))
- success++;
-
- if (!success) {
- printk(KERN_WARNING PFX "No VIA PadLock drivers have been
loaded.\n");
- return -ENODEV;
- }
-
- printk(KERN_NOTICE PFX "%d drivers are available.\n", success);
-
- return 0;
-}
-
-static void __exit padlock_fini(void)
-{
-}
-
-module_init(padlock_init);
-module_exit(padlock_fini);
-
-MODULE_DESCRIPTION("Load all configured PadLock algorithms.");
-MODULE_LICENSE("GPL");
-MODULE_AUTHOR("Michal Ludvig");
-
--
1.5.0.1
--
Simon Arlott
-
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 2.6.21
On Sun, 29 Apr 2007, Markus Rechberger wrote: > > I totally disagree here, bugzilla is a very good tool. If someone is > too lazy to look at it it's his problem. You must be doing things very differently from a lot of other people if you think that's the case. > Kernel Janitors can pick out some bugs which aren't addressed by > anyone or got left behind. IF that happened, it would actually be great. That's what I'm arguing for. And it was basically what Adrian was doing! > How else should bugs get handled, sending them to the lkml? Actually, looking at Adrian's regression lists, yes. lkml worked better than bugzilla did. By at _least_ a factor of two. > I'm 100% sure some bugreports will also get lost then, but on the lkml > they'll very likely remain lost whereas in the bugzilla they'll remain > as open. What's the difference between bugzilla and lkml.org? Both have search buttons. Both archive the old stuff. Both can be pointed to. > what are your suggestions to improve a bugreporting tool, I'm very > sure that many people, especially people who want to get into existing > projects here, would love to contribute. I don't know what the perfect setup is, but I do know that bugzilla is very close to be totally useless for the top-level maintainers. Try to think like a person who doesn't maintain *one* specific file in the kernel, but who can actually make a good judgement about a lot of things, or at least funnel a problem report to the right person? And now, imagine that that person is also fairly busy (exactly *because* he's not looking at a single file, he may be maintaining a huge subsystem that has multiple submaintainers etc). And ask yourself whether bugzilla really helps. > I'd say this is a personal opinion, some people will get along with it > and some of them will not... I think bugzilla really only works for very "directed" issues. If you already know exactly which driver is affected (which is often wrong anyway: some of the bugs that were due timer breakage got blamed as disk hangs!) it's almost totally useless. And yes, maybe that's why you have a much higher opinion of bugzilla than I do. To _me_ bugzilla is a total mess. There's absolutely _zero_ useful information there. And I'm pretty certain that is true of a *lot* of other people too. But if you have a small project, or you maintain a very specific (and clearly delineated) part of a big project, bugzilla probably looks a lot more palatable. 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: random thoughts on DEPRECATED and OBSOLETE
On Sun, 29 Apr 2007, Stefan Richter wrote: > I see a discussion on OBSOLETE vs. BROKEN there, which even ended in > a consensus, but I do not see an explicit discussion on OBSOLETE vs. > DEPRECATED. i think this online definition matches what i have in mind: http://www.google.com/search?hl=en=GGGL,GGGL:2006-10,GGGL:en=en=define:Deprecated=X=glossary_definition=title "A deprecated element or attribute is one that has been outdated by newer constructs. Deprecated elements are defined in the reference manual in appropriate locations, but are clearly marked as deprecated. Deprecated elements may become obsolete in future versions of HTML. We recommend that authors avoid using deprecated elements and attributes whenever practical." note carefully how deprecated elements can still be used, but their use is discouraged and they *may become obsolete*. that's exactly what i was getting at. deprecated stuff *might* still be used; obsolete stuff *shouldn't* be used. rday p.s. just FYI, even *i'm* getting bored of this. :-) - 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: Please revert [PATCH] user of the jiffies rounding patch: Slab
On Sat, 28 Apr 2007, Arjan van de Ven wrote: > Christoph Lameter wrote: > > The slab reaper takes global locks. If one makes all cache reapers fire at > > the same time as this patch does then there will be a lot of contention that > > may result lots of interrupt holdoffs since some locks are taken > > with interrupts disabled. The vm statistics counters are updated > > and will content for global cachelines if this is done. > > > I'd suggest to use a staggered per cpu approach instead that runs multiple > > per cpu timers at once. But every batch of these timers must be run at an > > offset from each other. Not at the same time please. > > from kernel/timer.c > > 107 > 108 /* > 109 * We don't want all cpus firing their timers at once hitting the > 110 * same lock or cachelines, so we skew each extra cpu with an > extra > 111 * 3 jiffies. This 3 jiffies came originally from the mm/ code > which > 112 * already did this. > 113 * The skew is done by adding 3*cpunr, then round, then subtract > this > 114 * extra offset again. > 115 */ > 116 j += cpu * 3; > > > isn't 3 jiffies distance per cpu enough for this already ?? > That's what it used to be before as well... Hmmm... Yes but that looks like it comes from a different function. Slab calls __round_jiffies_relative(HZ, cpu)) And its description says: /** * __round_jiffies_relative - function to round jiffies to a full second * @j: the time in (relative) jiffies that should be rounded * @cpu: the processor number on which the timeout will happen * * __round_jiffies_relative() rounds a time delta in the future (in jiffies) * up or down to (approximately) full seconds. This is useful for timers * for which the exact time they fire does not matter too much, as long as * they fire approximately every X seconds. * * By rounding these timers to whole seconds, all such timers will fire * at the same time, rather than at various times spread out. The goal * of this is to have the CPU wake up less, which saves power. * * The exact rounding is skewed for each processor to avoid all * processors firing at the exact same time, which could lead * to lock contention or spurious cache line bouncing. * * The return value is the rounded version of the @j parameter. */ This is exactly the wrong thing to do. - 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: random thoughts on DEPRECATED and OBSOLETE
On Sun, 29 Apr 2007, Stefan Richter wrote: > (Although if a certain number of kernel components is > inappropriately labeled, the facility becomes useless of course.) well, sure, but if someone chooses to use a tool incorrectly, there's really no way to stop them. and i'm guessing that that sort of thing would be quickly self-correcting based on peer pressure. incorrectly tagged features should become obvious fairly quickly when builds start to break in unexpected ways. > You said "it's not just presentational markup", I said "it is". :-) no, it's not just presentational markup. it's also a selection or filtering utility, which i consider distinct from markup. maybe we're just disagreeing on semantics, so let's not flog this distinction. > I see a discussion on OBSOLETE vs. BROKEN there, which even ended in > a consensus, but I do not see an explicit discussion on OBSOLETE vs. > DEPRECATED. The only definition of DEPRECATED I see there is yours, > and as it is worded, it is largely overlapping with the definition > of OBSOLETE (which, as it is laid down in that thread, is mostly > yours too) --- but it is not actually conflicting with it. in a previous discussion, the definitions were pretty much as follows: * deprecated: while a feature is still supported, its use is discouraged because there is a better alternative that you should consider migrating to at your convenience. * obsolete: while a feature is still in the tree, it is no longer supported and no one should need it anymore, and everyone *should* be using the better alternative at this point. IMHO, there is a clear distinction between those two definitions. they are not orthogonal, they are mutually exclusive. put another way, there is an obvious timeline for features: normal -> deprecated -> obsolete quite simply, based on the above, you can't be deprecated and obsolete at the same time. in any event, i don't want to drag this out too much longer. i think the proposal is reasonably clear, now it remains to be seen if enough people think it's worth implementing. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - 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: PANIC: 2.6.21-rc7-mm2, Kernel access of bad area, sig: 11
On Sat, 28 Apr 2007, William Heimbigner wrote: On Sat, 28 Apr 2007, Andrew Morton wrote: On Sat, 28 Apr 2007 21:40:19 + (GMT) William Heimbigner <[EMAIL PROTECTED]> wrote: > This bug occurs in linux-2.6.21-rc7-mm2, and does not occur in > 2.6.21-rc7 > ARCH is powerpc > > dmesg output, captured via netconsole: > [0.00] Using PowerMac machine description > [0.00] Total memory = 128MB; using 256kB for hash table (at > c7fc) > [0.00] Linux version 2.6.21-rc7-mm2 ([EMAIL PROTECTED]) (gcc version > 4.1.1 (Gentoo 4.1.1-r3)) #3 SMP PREEMPT Sat Apr 28 14:29:54 CDT 2007 > [0.00] Found UniNorth memory controller & host bridge @ > 0xf800 revision: 0xc0 > [0.00] Mapped at 0xfdfc > [0.00] Found a Pangea mac-io controller, rev: 0, mapped at > 0xfdf4 > [0.00] PowerMac motherboard: iMac "Flower Power" It ran OK on my G5. Can you send the config please? grep -v "is not set" .config: # # Automatically generated make config: don't edit # Linux kernel version: 2.6.21-rc7-mm2 # Sat Apr 28 14:04:08 2007 # CONFIG_PPC_PM_NEEDS_RTC_LIB=y CONFIG_PPC32=y CONFIG_PPC_MERGE=y CONFIG_MMU=y CONFIG_GENERIC_HARDIRQS=y CONFIG_IRQ_PER_CPU=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_ILOG2_U32=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_PPC=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_NVRAM=y CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_PPC_OF=y CONFIG_PPC_UDBG_16550=y CONFIG_GENERIC_TBSYNC=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # # Processor support # CONFIG_CLASSIC32=y CONFIG_6xx=y CONFIG_PPC_FPU=y CONFIG_ALTIVEC=y CONFIG_PPC_STD_MMU=y CONFIG_PPC_STD_MMU_32=y CONFIG_SMP=y CONFIG_NR_CPUS=2 CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" CONFIG_SWAP=y CONFIG_SWAP_PREFETCH=y CONFIG_SYSVIPC=y CONFIG_IPC_NS=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_SYSFS_DEPRECATED=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_PROC_SMAPS=y CONFIG_PROC_CLEAR_REFS=y CONFIG_PROC_PAGEMAP=y CONFIG_PROC_KPAGEMAP=y CONFIG_SLUB=y CONFIG_RT_MUTEXES=y CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_KMOD=y CONFIG_STOP_MACHINE=y # # Block layer # CONFIG_BLOCK=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_CFQ=y CONFIG_DEFAULT_IOSCHED="cfq" # # Platform support # CONFIG_PPC_MULTIPLATFORM=y CONFIG_PPC_CHRP=y CONFIG_PPC_PMAC=y CONFIG_PPC_NATIVE=y CONFIG_MPIC=y CONFIG_PPC_I8259=y CONFIG_PPC_RTAS=y CONFIG_RTAS_PROC=y CONFIG_PPC_MPC106=y # # CPU Frequency support # CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_TABLE=y CONFIG_CPU_FREQ_STAT=y CONFIG_CPU_FREQ_STAT_DETAILS=y CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=y CONFIG_CPU_FREQ_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_ONDEMAND=y CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y CONFIG_CPU_FREQ_PMAC=y CONFIG_TAU=y # # Kernel options # CONFIG_HZ_1000=y CONFIG_HZ=1000 CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y CONFIG_BINFMT_ELF=y CONFIG_HOTPLUG_CPU=y CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_KEXEC=y CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_RESOURCES_64BIT=y CONFIG_ZONE_DMA_FLAG=1 CONFIG_ADAPTIVE_READAHEAD=y CONFIG_DEBUG_READAHEAD=y CONFIG_PROC_DEVICETREE=y CONFIG_PM=y CONFIG_PM_DEBUG=y CONFIG_PM_SYSFS_DEPRECATED=y CONFIG_SECCOMP=y CONFIG_ISA_DMA_API=y # # Bus options # CONFIG_ISA=y CONFIG_ZONE_DMA=y CONFIG_GENERIC_ISA_DMA=y CONFIG_PPC_INDIRECT_PCI=y CONFIG_PCI=y CONFIG_PCI_DOMAINS=y CONFIG_PCIEPORTBUS=y CONFIG_PCCARD=y CONFIG_PCMCIA=y CONFIG_PCMCIA_LOAD_CIS=y CONFIG_CARDBUS=y # # PC-card bridges # CONFIG_PCMCIA_PROBE=y # # Advanced setup # # # Default settings for advanced configuration options are used # CONFIG_HIGHMEM_START=0xfe00 CONFIG_LOWMEM_SIZE=0x3000 CONFIG_KERNEL_START=0xc000 CONFIG_TASK_SIZE=0x8000 CONFIG_BOOT_LOAD=0x0080 # # Networking # CONFIG_NET=y # # Networking options # CONFIG_PACKET=y CONFIG_UNIX=y CONFIG_XFRM=y
Re: Linux 2.6.21
On Sun, 29 Apr 2007, Adrian Bunk wrote: > > That's exactly where Linus' "drop any bug reports that are more than a > week old" suggestion is completely flawed - no matter what the submitter > does, how often he tests latest kernels, noone will help him. You talk, but what do you actually *suggest*? Talk is cheap. You use to do the walk too, but you've already said that you're not interested in that any more. So excuse me if I'm not impressed. The thing is, bugzilla is totally broken because it's designed to help track bugs, but it's *not* designed to actually handle the much harder problem, which is to actually get the *right* developers to be aware of the *right* bugs! And both of those "right"s are important. Spamming everybody will just mean that everybody tunes them out. And spamming even the right developers with useless bugreports will also just cause them to tune out the good ones. The thing is, the "tracking bugs" part that bugzilla _can_ do is also totally _useless_ without that much more important phase, namely the "connect the parties". That's what you really used to do. You made developers connect to the reports, because your reports were _useful_ and not overly noisy. But go back and look - did you notice that once you connect the dots, it turns out that bugzilla itself isn't all that wonderful. Quite a lot of your regression reports had other ways of pointing to the problems, including very much mailing list archive pointers etc! So bugzilla isn't actually all it's touted to be even _once_ the connection between reporter and developer has been established. I really don't see why you are so hung up about bugzilla, when your own regression reports didn't generally point to it all that often! (I just went back and double-checked: you had more than twice as many pointers to kernel mailing list archives than you had pointers to bugzilla in the one series I looked at. And I'm _not_ saying that's wrong at all: I think the mailing list is actually likely to be at LEAST as useful as bugzilla is as a bug-tracker!) And bugzilla actually falls down even more than the mailing list does for the whole (and MUCH MORE IMPORTANT!) phase of connecting developers to bug reports. And THAT is really the problem here. And no, I don't actually think that automatically closing entries that haven't gotten any attention in the last two weeks would "fix" bugzilla. But I think that it might actually make people (a) more likely to look into bugzilla (and thus maybe improve the "connecting" developers/reporters thing) (b) act as a trivial noise-removal thing, because it would give preferential treatment to people who are diligent about their bug-reports and are willing to follow up on them and it would also remove the noise that comes from obvious things that broke and got fixed. But I think the real fix is to have real humans that help de-noisify the bug reports. Let's call them the "bunk" group, just to pick a random four-letter combination. The kinds of people who help turn the mindless noise that is bugzilla (and the kernel mailing list) into directed _information_. No, nothing is ever going to be perfect. And "filtering" the noise will inevitably also end up dropping real information. But not filtering it will guarantee that even more is dropped. 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] x86: fix PSE pagetable construction
Eric W. Biederman wrote: > Except for Xen my patch should work incrementally. Yes, your patch is good. I have it in my series followed by the appropriate Xen patch, and it boots OK both Xen and native. J - 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] crypto: Use padlock.ko only as a module
On 28/04/07 23:37, Randy Dunlap wrote: On Sat, 28 Apr 2007 17:44:42 +0100 Simon Arlott wrote: The padlock.ko module is completely useless when compiled in because it can't do anything and gets run too early to output anything useful. --- a/drivers/crypto/Makefile +++ b/drivers/crypto/Makefile @@ -1,4 +1,6 @@ -obj-$(CONFIG_CRYPTO_DEV_PADLOCK) += padlock.o +ifeq ($(CONFIG_CRYPTO_DEV_PADLOCK),m) +obj-m += padlock.o +endif obj-$(CONFIG_CRYPTO_DEV_PADLOCK_AES) += padlock-aes.o obj-$(CONFIG_CRYPTO_DEV_PADLOCK_SHA) += padlock-sha.o obj-$(CONFIG_CRYPTO_DEV_GEODE) += geode-aes.o I think that we prefer to enforce config symbols in Kconfig files, not in Makefiles. E.g., No, that would cause the wrong behaviour in this case. The two modules that depend on it for no reason work fine compiled in. Ideally I'd just remove that module completely, all it does is trigger the loading of the other two modules when modules are used - so I'll submit a patch for that instead. --- drivers/crypto/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-2621-pv.orig/drivers/crypto/Kconfig +++ linux-2621-pv/drivers/crypto/Kconfig @@ -2,7 +2,7 @@ menu "Hardware crypto devices" config CRYPTO_DEV_PADLOCK tristate "Support for VIA PadLock ACE" - depends on X86_32 + depends on X86_32 && m select CRYPTO_ALGAPI default m help -- Simon Arlott - 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: random thoughts on DEPRECATED and OBSOLETE
Am 28.04.2007 15:25 schrieb Robert P. J. Day: > http://fsdev.net/wiki/index.php?title=Maturity_levels You note: > DEPRECATED and OBSOLETE at the very least, whose definitions should be > reasonably obvious. The obviousness is in the eye of the beholder. :-) For the sake of us non-native speakers, the definitions might bear spelling out. I know I've had my understanding of those two terms significantly adjusted during the last discussion of them. Thanks, Tilman -- Tilman Schmidt E-Mail: [EMAIL PROTECTED] Bonn, Germany - In theory, there is no difference between theory and practice. In practice, there is. signature.asc Description: OpenPGP digital signature
Re: [PATCH] i386: introduce voyager smp_ops, fix voyager build
Eric W. Biederman wrote: > Unless I have missed something early_gdt_descr still needs to be updated. > The patch is on top of Andi's current queue, which includes quite a few boot-time gdt setup cleanups. early_gdt_descr has gone. J - 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 2.6.21
On Sunday, 29 April 2007 00:33, Adrian Bunk wrote: > On Sun, Apr 29, 2007 at 08:11:30AM +1000, Neil Brown wrote: > > On Saturday April 28, [EMAIL PROTECTED] wrote: > >... > > > As Andrew has pointed out before though - even though he forwards > > > the bugs, nobody does anything with it. The sad truth seems to be > > > that people have very little interest in fixing bugs when they are > > > reported - it's not sexy, I guess. > > > > Not sexy, and also not at all easy. A lot of the interesting bugs > > seem to be subtle interactions between separate parts of the kernel - > > one part making an assumption or exhibiting a behaviour that the other > > part didn't expect. And we all know that writing bug^Wcode is easier > > than removing bugs. I can spend hour and hours reading through code > > trying to get the big picture, and end up finding a one-line change > > that then needs documenting, testing and external review. It's not > > easy. > > > > > I'm still unconvinced the users or the tool are the problem, but if it > > > makes you happier, we can do that. > > > > No, they aren't the problem. Bugs are the problem. But they might be > > a more effective part of the solution. > > > > My perception of the kernel bugzilla is that visibility is very low. > > > > I think there is value in weekly reminders, and I wouldn't mind seeing > > a weekly Email on linux-kernel with something like a list of open bugs > > that have not seen any activity in between 1 and 2 weeks. It might > > get someone out-of-area interested, and might be noticed by someone > > who thinks they are in-area and get them wondering why they didn't > > find out when the bug was first reported. > > The 100 kB email limit has to be lifted for this... > > More seriously, there are > 1000 open bugs in the kernel Bugzilla > without any activity during the last 2 weeks. > > The problem is usually either "Not sexy, and also not at all easy." or > "no maintainer". Please add "limited human resources" to this list. Greetings, Rafael - 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 2.6.21
On Sat, Apr 28, 2007 at 03:33:39PM -0700, Linus Torvalds wrote: > > > On Sat, 28 Apr 2007, Adrian Bunk wrote: > > > > We are already quite good at ignoring bug reports that come through > > linux-kernel, and it's an _advantage_ of the kernel Bugzilla to see more > > than 1600 open bugs because this tells how bad we are at handling bugs. > > No, it just shows that bugzilla doesn't matter for most of the kernel. > > Don't say that "bugzilla tells how bad we are at handling bugs". It tells > how bad *bugzilla* is for handling bugs, nothing more. > > Trying to play politics by pointing to bugzilla is pointless. Bugzilla is > used for a few subsystems (ACPI seems to use it actively, for example), > but I doubt most developers use it. > > Would be be good to have a better bug-tracking setup? Yes. But I think it > takes man-power, and it would take something *fundamentally* better than > bugzilla. Bugzilla has an email interface. Andrew forwards bugs from Bugzilla to developers. There might be small room for improvements, but I don't see how man-power or technology could make a big difference in this area. > Maybe the new "http://kernelnewbies.org/known_regressions; thing will > evolve to something worth tracking. Right now, bugzilla isn't it (although > it can be a useful tracking place for individual bugs, *once* you've found > and gotten the right developer involved - but that's a huge step that > bugzilla generally does *not* do for us). "*once* you've found and gotten the right developer involved" is the real problem, not how to track bugs. And not only a developer active in this area, more important a developer who knows the subsystem/driver involved *and is willing to work on bug reports*. *This* is *the* problem. And no change in bug tracking will help with this problem. > Linus 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 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: Back to the future.
On Saturday, 28 April 2007 23:25, Linus Torvalds wrote: > > On Sat, 28 Apr 2007, Rafael J. Wysocki wrote: > > > > > > The freezer has *caused* those deadlocks (eg by stopping threads that > > > were > > > needed for the suspend writeouts to succeed!), not solved them. > > > > I can't remember anything like this, but I believe you have a specific test > > case in mind. > > Ehh.. Why do you thik we _have_ that PF_NOFREEZE thing in the first place? Well, I don't know why exactly it had been originally introduced. Currently, it is used by the threads that should be running after the snapshot is done (they are not only I/O threads). > Rafael, you really don't know what you're talking about, do you? I think I know. > Just _look_ at them. It's the IO threads etc that shouldn't be frozen, > exactly *because* they do IO. You claim that kernel threads shouldn't do > IO, but that's the point: if you cannot do IO when snapshotting to disk, > here's a damn big clue for you: how do you think that snapshot is going to > get written? OK, more precisely: fs-related threads should not try to process their queues, etc., after the snapshot is done, because that may cause some fs data to be written at that time and then the fs in question may be corrupted after the restore. Not all of the I/O in general, fs data. Still, that alone probably is not a good enough reason for freezing all kernel threads. > I *guarantee* you that we've had a lot more problems with threads that > should *not* have been frozen than with those hypothetical threads that > you think should have been frozen. Well, I'm not sure whether or not that still would have been the case if we had stopped to freeze kernel threads for the hibernation/suspend. I just see potential problems that I've mentioned in the previous message and I don't see any evidence that they cannot occur. Greetings, Rafael - 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 2.6.21
On 4/29/07, Linus Torvalds <[EMAIL PROTECTED]> wrote: On Sat, 28 Apr 2007, Adrian Bunk wrote: > > We are already quite good at ignoring bug reports that come through > linux-kernel, and it's an _advantage_ of the kernel Bugzilla to see more > than 1600 open bugs because this tells how bad we are at handling bugs. No, it just shows that bugzilla doesn't matter for most of the kernel. Don't say that "bugzilla tells how bad we are at handling bugs". It tells how bad *bugzilla* is for handling bugs, nothing more. I totally disagree here, bugzilla is a very good tool. If someone is too lazy to look at it it's his problem. Kernel Janitors can pick out some bugs which aren't addressed by anyone or got left behind. I also found some bugs there which could have been solved by anyone here, the matter is just that many people aren't interested in mainly bug fixing and many also work on different other topics here. How else should bugs get handled, sending them to the lkml? I'm 100% sure some bugreports will also get lost then, but on the lkml they'll very likely remain lost whereas in the bugzilla they'll remain as open. Trying to play politics by pointing to bugzilla is pointless. Bugzilla is used for a few subsystems (ACPI seems to use it actively, for example), but I doubt most developers use it. as for the em28xx I actively use it, but I also set up a mailinglist etc. and there are many supporters already... Would be be good to have a better bug-tracking setup? Yes. But I think it takes man-power, and it would take something *fundamentally* better than bugzilla. what are your suggestions to improve a bugreporting tool, I'm very sure that many people, especially people who want to get into existing projects here, would love to contribute. Maybe the new "http://kernelnewbies.org/known_regressions; thing will evolve to something worth tracking. Right now, bugzilla isn't it (although it can be a useful tracking place for individual bugs, *once* you've found and gotten the right developer involved - but that's a huge step that bugzilla generally does *not* do for us). I'd say this is a personal opinion, some people will get along with it and some of them will not... Markus - 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 2.6.21
On Sat, Apr 28, 2007 at 09:27:01PM +0100, Russell King wrote: > On Sat, Apr 28, 2007 at 09:53:20PM +0200, Adrian Bunk wrote: > > We are already quite good at ignoring bug reports that come through > > linux-kernel, and it's an _advantage_ of the kernel Bugzilla to see more > > than 1600 open bugs because this tells how bad we are at handling bugs. > > How many thousand bug reports have been ignored during the same time on > > linux-kernel? > > However, look at this bug: > > http://bugme.osdl.org/show_bug.cgi?id=7760 > > It's outside my knowledge to be able to fix for various reasons: >... > I'm personally very tempted to close it as "won't fix" (I wish there was > a "can't fix" category.) >... So this is a completely debugged bug in a well-maintained subsystem (no matter what the status in Bugzilla is). The problem is that the other 1600 open bugs aren't in this state. > I'm no longer serial maintainer. Bug IDs after about 7000 reflect bugs > submitted since I've resigned my serial maintainership, and therefore > I've ignored them. >... That's one of the problems: Unmaintained subsystems. Since you stepped down as serial maintainer (and it's your right as maintainer to do so), the serial subsystem is unmaintained. That's exactly where Linus' "drop any bug reports that are more than a week old" suggestion is completely flawed - no matter what the submitter does, how often he tests latest kernels, noone will help him. > It's far easier to ignore bug reports in bugzilla > than it is to get categories reassigned (to whom? - dunno) or even > deleted (if no one steps up presumably that's what needs to happen?) >... New subsystems always get default owners like [EMAIL PROTECTED], and people interested in such bugs can edit their preferences to watching all (pseudo) users in whose bugs they are interested. [EMAIL PROTECTED] [1] would be the logical defult owner. > Russell King cu Adrian [1] or @linux-foundation.org -- "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 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: bug in RLIMIT_SIGPENDING
I don't think there is any reason to think the accounting is wrong. The accounted number of queue entries is 1. The -1 (~0ul) displayed is the maximum for your process, which is RLIM_INFINITY. Nothing in what you've reported so far points positively towards a signals issue per se. First, you should see if you simply have a livelock situation. That is, your signal handler is running many times and never letting fork complete. Try setting the itimer to a much larger value like one second, and see if the problem still occurs. If not, you may just be having timer signals going off too fast to finish a fork in between. If this is the case and it seems like fork should not take as long as it does, then you can look into how long fork is really taking and why. If in fact your signal handler does not run many times, then the issue is stranger. Thanks, Roland - 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: High Resolution Timer DOS
On Sat, 28 Apr 2007, Lee Revell wrote: On 4/28/07, Thomas Gleixner <[EMAIL PROTECTED]> wrote: Well, it is not really a DoS. The rescheduling of the process is limited by the scheduler and the available CPU time (depending on the number of runnable tasks in the system). Shouldn't an unprivileged process be rate limited somehow to avoid flooding the machine with interrupts? We restrict nonroot users from setting the RTC interrupt rate higher than 64Hz for a similar reason (granted, this limit dates back to the 486 days and should probably be increased to 1024 Hz). Isn't that what /etc/security/limits.conf is for? Just limit the CPU usage. Root and SCHED_FIFO tasks could be exempt from rate limiting, to avoid the need to introduce a new rlimit which would take years for userspace to catch up to. Lee William Heimbigner [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: Linux 2.6.21
On Sunday April 29, [EMAIL PROTECTED] wrote: > On Sun, Apr 29, 2007 at 08:11:30AM +1000, Neil Brown wrote: > > > > I think there is value in weekly reminders, and I wouldn't mind seeing > > a weekly Email on linux-kernel with something like a list of open bugs > > that have not seen any activity in between 1 and 2 weeks. It might > > get someone out-of-area interested, and might be noticed by someone > > who thinks they are in-area and get them wondering why they didn't > > find out when the bug was first reported. > > The 100 kB email limit has to be lifted for this... > > More seriously, there are > 1000 open bugs in the kernel Bugzilla > without any activity during the last 2 weeks. I meant "between 1 and 2 weeks" - so each bug hits linux-kernel once, any only if no-one seem to care. If I ask for bugs changed in the last 7 days I get 80 If I ask for bugs changed in the last 14 days I get 114. So today, that list would have (114-80) = 34 bug, which I think it is manageable to glance through and think "Would I like to care". NeilBrown - 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: [ext3][kernels >= 2.6.20.7 at least] KDE going comatose when FS is under heavy write load (massive starvation)
On Sat, Apr 28, 2007 at 07:37:17AM +0200, Mikulas Patocka wrote: SpadFS doesn't write to unallocated parts like log filesystems (LFS) or phase tree filesystems (TUX2); it writes inside normal used structures, but it marks each structure with generation tags --- when it updates global table of tags, it atomically makes several structures valid. I don't know about this idea being used elsewhere. So how is this generation structure organized ? paper ? Paper is in CITSA 2006 proceedings (but you likely don't have them and I signed some statement that I can't post it elsewhere :-( ) Basicly the idea is this: * you have array containing 65536 32-bit numbers --- crash count table --- that array is on disk and in memory (see struct __spadfs->cct in my sources) * you have 16-bit value --- crash count, that value is on disk and in memory too (see struct __spadfs->cc) * On mount, you load crash count table and crash count from disk to memory. You increment carsh count on disk (but leave old in memory). You increment one entry in crash count table - cct[cc] in memory, but leave old on disk. * On sync you write all metadata buffers, do write barrier, write one sector of crash count table from memory to disk and do write barrier again. * On unmount, you sync and decrement crash count on disk. --- so crash count counts crashes --- it is increased each time you mount and don't unmount. Consistency of structures: * Each directory entry has two tags --- 32-bit transaction count (txc) and 16-bit crash count(cc). * You create directory entry with entry->txc = fs->txc[fs->cc] and entry->cc = fs->cc * Directory entry is considered valid if fs->txc[entry->cc] >= entry->txc (see macro CC_VALID) * If the directory entry is not valid, it is skipped during directory scan, as if it wasn't there --- so you create a directory entry and its valid. If the system crashes, it will load crash count table from disk and there's one-less value than entry->txc, so the entry will be invalid. It will also run with increased cc, so it will never touch txc at an old index, so the entry will be valid forever. --- if you sync, you write crash count table to disk and directory entry will be atomically made valid forever (because values in crash count table never decrease) In my implementation, the top bit of entry->txc is used to mark whether the entry is scheduled for adding or delete, so that you can atomically add one directory entry and delete other. Space allocation bitmaps or lists are managed in such a way that there are two copies and cc/txc pair determining which one is valid. Files are extended in such a way that each file has two "size" entries and cc/txc pair denoting which one is valid, so that you can atomically extend/truncate file and mark its space allocated/freed in bitmaps or lists (BTW. this cc/txc pair is the same one that denotes if the directory entry is valid and another bit determines one of these two functions --- to save space). Mikulas - 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: High Resolution Timer DOS
On 4/28/07, Thomas Gleixner <[EMAIL PROTECTED]> wrote: Well, it is not really a DoS. The rescheduling of the process is limited by the scheduler and the available CPU time (depending on the number of runnable tasks in the system). Shouldn't an unprivileged process be rate limited somehow to avoid flooding the machine with interrupts? We restrict nonroot users from setting the RTC interrupt rate higher than 64Hz for a similar reason (granted, this limit dates back to the 486 days and should probably be increased to 1024 Hz). Root and SCHED_FIFO tasks could be exempt from rate limiting, to avoid the need to introduce a new rlimit which would take years for userspace to catch up to. Lee - 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] crypto: Use padlock.ko only as a module
On Sat, 28 Apr 2007 17:44:42 +0100 Simon Arlott wrote: > The padlock.ko module is completely useless when compiled in > because it can't do anything and gets run too early to output > anything useful: > > [6.052000] padlock: No VIA PadLock drivers have been loaded. > [6.052000] padlock: Using VIA PadLock ACE for AES algorithm. > [6.052000] padlock: Using VIA PadLock ACE for SHA1/SHA256 algorithms. > > Signed-off-by: Simon Arlott <[EMAIL PROTECTED]> > Cc: Herbert Xu <[EMAIL PROTECTED]> > --- > drivers/crypto/Makefile |4 +++- > 1 files changed, 3 insertions(+), 1 deletions(-) > > diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile > index 6059cf8..f0f7a73 100644 > --- a/drivers/crypto/Makefile > +++ b/drivers/crypto/Makefile > @@ -1,4 +1,6 @@ > -obj-$(CONFIG_CRYPTO_DEV_PADLOCK) += padlock.o > +ifeq ($(CONFIG_CRYPTO_DEV_PADLOCK),m) > +obj-m += padlock.o > +endif > obj-$(CONFIG_CRYPTO_DEV_PADLOCK_AES) += padlock-aes.o > obj-$(CONFIG_CRYPTO_DEV_PADLOCK_SHA) += padlock-sha.o > obj-$(CONFIG_CRYPTO_DEV_GEODE) += geode-aes.o > -- I think that we prefer to enforce config symbols in Kconfig files, not in Makefiles. E.g., --- drivers/crypto/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-2621-pv.orig/drivers/crypto/Kconfig +++ linux-2621-pv/drivers/crypto/Kconfig @@ -2,7 +2,7 @@ menu "Hardware crypto devices" config CRYPTO_DEV_PADLOCK tristate "Support for VIA PadLock ACE" - depends on X86_32 + depends on X86_32 && m select CRYPTO_ALGAPI default m help --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - 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 2.6.21
On Sat, 28 Apr 2007, Adrian Bunk wrote: > > We are already quite good at ignoring bug reports that come through > linux-kernel, and it's an _advantage_ of the kernel Bugzilla to see more > than 1600 open bugs because this tells how bad we are at handling bugs. No, it just shows that bugzilla doesn't matter for most of the kernel. Don't say that "bugzilla tells how bad we are at handling bugs". It tells how bad *bugzilla* is for handling bugs, nothing more. Trying to play politics by pointing to bugzilla is pointless. Bugzilla is used for a few subsystems (ACPI seems to use it actively, for example), but I doubt most developers use it. Would be be good to have a better bug-tracking setup? Yes. But I think it takes man-power, and it would take something *fundamentally* better than bugzilla. Maybe the new "http://kernelnewbies.org/known_regressions; thing will evolve to something worth tracking. Right now, bugzilla isn't it (although it can be a useful tracking place for individual bugs, *once* you've found and gotten the right developer involved - but that's a huge step that bugzilla generally does *not* do for us). 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: Linux 2.6.21
On Sun, Apr 29, 2007 at 08:11:30AM +1000, Neil Brown wrote: > On Saturday April 28, [EMAIL PROTECTED] wrote: >... > > As Andrew has pointed out before though - even though he forwards > > the bugs, nobody does anything with it. The sad truth seems to be > > that people have very little interest in fixing bugs when they are > > reported - it's not sexy, I guess. > > Not sexy, and also not at all easy. A lot of the interesting bugs > seem to be subtle interactions between separate parts of the kernel - > one part making an assumption or exhibiting a behaviour that the other > part didn't expect. And we all know that writing bug^Wcode is easier > than removing bugs. I can spend hour and hours reading through code > trying to get the big picture, and end up finding a one-line change > that then needs documenting, testing and external review. It's not > easy. > > > I'm still unconvinced the users or the tool are the problem, but if it > > makes you happier, we can do that. > > No, they aren't the problem. Bugs are the problem. But they might be > a more effective part of the solution. > > My perception of the kernel bugzilla is that visibility is very low. > > I think there is value in weekly reminders, and I wouldn't mind seeing > a weekly Email on linux-kernel with something like a list of open bugs > that have not seen any activity in between 1 and 2 weeks. It might > get someone out-of-area interested, and might be noticed by someone > who thinks they are in-area and get them wondering why they didn't > find out when the bug was first reported. The 100 kB email limit has to be lifted for this... More seriously, there are > 1000 open bugs in the kernel Bugzilla without any activity during the last 2 weeks. The problem is usually either "Not sexy, and also not at all easy." or "no maintainer". Technology can assist, but there are non-technical problems you can't solve through technology. > NeilBrown 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 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: random thoughts on DEPRECATED and OBSOLETE
Robert P. J. Day wrote: > On Sat, 28 Apr 2007, Stefan Richter wrote: >> And that benefit is...? :-) ... > if you're not convinced, there's nothing else i can think of to say > that will persuade you. It didn't come across this way, sorry, but I didn't ask a priori to be persuaded, but rather because I thought your argument (at the wiki site) could be enhanced by pointing out the concrete applications of the facility. When I visited the page, it only explained how the facility works, not what the end-use is. [...] >> But it can be controversial whether a piece of code >> deserves one of these labels. > > in the first place, that would be *entirely* the decision of the > maintainer, just as it is now. but nothing says that starting to tag > stuff has to affect you in any way. there should be a top-level > selection that lets you even *activate* the maturity level settings as > part of your configuration. (Although if a certain number of kernel components is inappropriately labeled, the facility becomes useless of course.) [...] >> "maturity" is just like "depends on" with the added feature that UIs >> are supposed to print the flag onto the screen even if the user did >> not enable a debug mode of the UI. >> >> It's really nothing more. [...] > sure, i have no disagreement with that. (um ... was there something > there i was supposed to address? it just sounded like you were > clarifying what we were talking about.) You said "it's not just presentational markup", I said "it is". :-) [deprecated and obsolete exclusive?] >> DEPRECATED = "I don't want you to build or run this if you can >> possibly avoid it." >> >> OBSOLETE = "There is other stuff which does more or less the same, >> and this here could go away in the future." > > nope. we've been down this road before, and the consensus was that > something could be one of deprecated or obsolete, but not both. i can > re-post those definitions if you want, or you could read about them > here: > > http://kerneltrap.org/node/7593 I see a discussion on OBSOLETE vs. BROKEN there, which even ended in a consensus, but I do not see an explicit discussion on OBSOLETE vs. DEPRECATED. The only definition of DEPRECATED I see there is yours, and as it is worded, it is largely overlapping with the definition of OBSOLETE (which, as it is laid down in that thread, is mostly yours too) --- but it is not actually conflicting with it. Note, another classification system can be found in Documentation/ABI/README. That one also features the category "obsolete", but does not include a category "deprecated". This is beneficial because it doesn't leave room for disagreeing interpretations like ours, nor for any overlap in the definitions like in those at the end of the thread you referenced. -- Stefan Richter -=-=-=== -=-- ===-- http://arcgraph.de/sr/ - 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-2.6.21 hangs during post boot initialization phase
On Sat, Apr 28, 2007 at 09:50:00AM +1000, Peter Williams wrote: > Neil Horman wrote: > >On Sat, Apr 28, 2007 at 12:28:28AM +1000, Peter Williams wrote: > >>Neil Horman wrote: > >>>On Fri, Apr 27, 2007 at 04:05:11PM +1000, Peter Williams wrote: > > > >Damn, This is what happens when I try to do things too quickly. I missed > >one > >spot in my last patch where I replaced skb with rx_skb. Its not critical, > >but > >it should improve sis900 performance by quite a bit. This applies on top > >of the > >last two patches. Sorry about that. > > > >Thanks & Regards > >Neil > > > >Signed-off-by: Neil Horman <[EMAIL PROTECTED]> > > > > > > sis900.c |2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > >diff --git a/drivers/net/sis900.c b/drivers/net/sis900.c > >index 7e44939..db59dce 100644 > >--- a/drivers/net/sis900.c > >+++ b/drivers/net/sis900.c > >@@ -1790,7 +1790,7 @@ static int sis900_rx(struct net_device *net_dev) > > /* give the socket buffer to upper layers */ > > rx_skb = sis_priv->rx_skbuff[entry]; > > skb_put(rx_skb, rx_size); > >-skb->protocol = eth_type_trans(rx_skb, net_dev); > >+rx_skb->protocol = eth_type_trans(rx_skb, net_dev); > > netif_rx(rx_skb); > > > > /* some network statistics */ > > My system also boots OK after I add this patch. Can't tell whether it's > improved the performance or not. I've had other report of performance degradation (frames thrown out for not having a valid protocol assigned to them). This patch may not improve your performance per se, but it will certainly not hurt, and its correct (for the same reason that using a separate skb pointer is correct in all the other lines in this clause. Thanks, and sorry again for all the headache. Neil - 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: PANIC: 2.6.21-rc7-mm2, Kernel access of bad area, sig: 11
On Sat, 28 Apr 2007, Andrew Morton wrote: On Sat, 28 Apr 2007 21:40:19 + (GMT) William Heimbigner <[EMAIL PROTECTED]> wrote: This bug occurs in linux-2.6.21-rc7-mm2, and does not occur in 2.6.21-rc7 ARCH is powerpc dmesg output, captured via netconsole: [0.00] Using PowerMac machine description [0.00] Total memory = 128MB; using 256kB for hash table (at c7fc) [0.00] Linux version 2.6.21-rc7-mm2 ([EMAIL PROTECTED]) (gcc version 4.1.1 (Gentoo 4.1.1-r3)) #3 SMP PREEMPT Sat Apr 28 14:29:54 CDT 2007 [0.00] Found UniNorth memory controller & host bridge @ 0xf800 revision: 0xc0 [0.00] Mapped at 0xfdfc [0.00] Found a Pangea mac-io controller, rev: 0, mapped at 0xfdf4 [0.00] PowerMac motherboard: iMac "Flower Power" It ran OK on my G5. Can you send the config please? grep -v "is not set" .config: # # Automatically generated make config: don't edit # Linux kernel version: 2.6.21-rc7-mm2 # Sat Apr 28 14:04:08 2007 # CONFIG_PPC_PM_NEEDS_RTC_LIB=y CONFIG_PPC32=y CONFIG_PPC_MERGE=y CONFIG_MMU=y CONFIG_GENERIC_HARDIRQS=y CONFIG_IRQ_PER_CPU=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_ILOG2_U32=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_PPC=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_NVRAM=y CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_PPC_OF=y CONFIG_PPC_UDBG_16550=y CONFIG_GENERIC_TBSYNC=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # # Processor support # CONFIG_CLASSIC32=y CONFIG_6xx=y CONFIG_PPC_FPU=y CONFIG_ALTIVEC=y CONFIG_PPC_STD_MMU=y CONFIG_PPC_STD_MMU_32=y CONFIG_SMP=y CONFIG_NR_CPUS=2 CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" CONFIG_SWAP=y CONFIG_SWAP_PREFETCH=y CONFIG_SYSVIPC=y CONFIG_IPC_NS=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_SYSFS_DEPRECATED=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_PROC_SMAPS=y CONFIG_PROC_CLEAR_REFS=y CONFIG_PROC_PAGEMAP=y CONFIG_PROC_KPAGEMAP=y CONFIG_SLUB=y CONFIG_RT_MUTEXES=y CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_KMOD=y CONFIG_STOP_MACHINE=y # # Block layer # CONFIG_BLOCK=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_CFQ=y CONFIG_DEFAULT_IOSCHED="cfq" # # Platform support # CONFIG_PPC_MULTIPLATFORM=y CONFIG_PPC_CHRP=y CONFIG_PPC_PMAC=y CONFIG_PPC_NATIVE=y CONFIG_MPIC=y CONFIG_PPC_I8259=y CONFIG_PPC_RTAS=y CONFIG_RTAS_PROC=y CONFIG_PPC_MPC106=y # # CPU Frequency support # CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_TABLE=y CONFIG_CPU_FREQ_STAT=y CONFIG_CPU_FREQ_STAT_DETAILS=y CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=y CONFIG_CPU_FREQ_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_ONDEMAND=y CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y CONFIG_CPU_FREQ_PMAC=y CONFIG_TAU=y # # Kernel options # CONFIG_HZ_1000=y CONFIG_HZ=1000 CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y CONFIG_BINFMT_ELF=y CONFIG_HOTPLUG_CPU=y CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_KEXEC=y CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_RESOURCES_64BIT=y CONFIG_ZONE_DMA_FLAG=1 CONFIG_ADAPTIVE_READAHEAD=y CONFIG_DEBUG_READAHEAD=y CONFIG_PROC_DEVICETREE=y CONFIG_PM=y CONFIG_PM_DEBUG=y CONFIG_PM_SYSFS_DEPRECATED=y CONFIG_SECCOMP=y CONFIG_ISA_DMA_API=y # # Bus options # CONFIG_ISA=y CONFIG_ZONE_DMA=y CONFIG_GENERIC_ISA_DMA=y CONFIG_PPC_INDIRECT_PCI=y CONFIG_PCI=y CONFIG_PCI_DOMAINS=y CONFIG_PCIEPORTBUS=y CONFIG_PCCARD=y CONFIG_PCMCIA=y CONFIG_PCMCIA_LOAD_CIS=y CONFIG_CARDBUS=y # # PC-card bridges # CONFIG_PCMCIA_PROBE=y # # Advanced setup # # # Default settings for advanced configuration options are used # CONFIG_HIGHMEM_START=0xfe00 CONFIG_LOWMEM_SIZE=0x3000 CONFIG_KERNEL_START=0xc000 CONFIG_TASK_SIZE=0x8000 CONFIG_BOOT_LOAD=0x0080 # # Networking # CONFIG_NET=y # # Networking options # CONFIG_PACKET=y CONFIG_UNIX=y CONFIG_XFRM=y CONFIG_XFRM_USER=y CONFIG_NET_KEY=y CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_FIB_HASH=y CONFIG_SYN_COOKIES=y CONFIG_INET_AH=y CONFIG_INET_ESP=y CONFIG_INET_TUNNEL=m
Re: Linux 2.6.21
On Saturday April 28, [EMAIL PROTECTED] wrote: > > Yes, human involvement from someone with half a brain would be better. > Andrew does a lot of that. Not a particularly good use of talent really. > but still. I think more than half a brain is needed to do this well. You need a reasonable understanding of how all the bits of the kernel work together so that you have a good chance of sending the bug in the right direction. You need a good understanding of the kernel community and various sub communities so that you know who might be both able and willing to deal with the bug. And it wouldn't hurt to have a good over-view of the current 'hot' areas of the kernel so you know if it is really worth suggesting "try with the latest -mm" or not. And you need good people skills. So I think you really need a lot of up-to-date knowledge to do this well. Because of Andrew's position as a funnel, he has a lot of that knowledge. It would be really nice if he had some help though. And I really think that would mean finding someone in the community who would rather be coding (and currently are) and convincing them that there is a higher calling for them. Finding someone out side or on the edge of the community is less likely to be effective. > > As Andrew has pointed out before though - even though he forwards > the bugs, nobody does anything with it. The sad truth seems to be > that people have very little interest in fixing bugs when they are > reported - it's not sexy, I guess. Not sexy, and also not at all easy. A lot of the interesting bugs seem to be subtle interactions between separate parts of the kernel - one part making an assumption or exhibiting a behaviour that the other part didn't expect. And we all know that writing bug^Wcode is easier than removing bugs. I can spend hour and hours reading through code trying to get the big picture, and end up finding a one-line change that then needs documenting, testing and external review. It's not easy. > I'm still unconvinced the users or the tool are the problem, but if it > makes you happier, we can do that. No, they aren't the problem. Bugs are the problem. But they might be a more effective part of the solution. My perception of the kernel bugzilla is that visibility is very low. I think there is value in weekly reminders, and I wouldn't mind seeing a weekly Email on linux-kernel with something like a list of open bugs that have not seen any activity in between 1 and 2 weeks. It might get someone out-of-area interested, and might be noticed by someone who thinks they are in-area and get them wondering why they didn't find out when the bug was first reported. NeilBrown - 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: High Resolution Timer DOS
On Sat, 2007-04-28 at 23:53 +0200, matthieu castet wrote:
> Hi,
>
> some programs need to do some short of busyloop. It was often
> implemented as :
>
> while (1) {
> if (can_do_stuff) {
> do_stuff();
> }
> else
> //sleep a very short of time
> usleep(1);
> }
>
> usleep(1) or equivalent where used instead of sched_yield, because of
> some priority issue. IIRC doing sched_yield, make the process appears
> like an interactive process, so it has better priority and get call more
> often.
>
> But now if high res timer are enabled, these programs while cause
> something like a DOS : the context switch per second will be bigger than
> 500 000 and the cpu usage will be very high.
Well, it is not really a DoS. The rescheduling of the process is limited
by the scheduler and the available CPU time (depending on the number of
runnable tasks in the system).
>From the spec:
Implementations may place limitations on the granularity of timer
values. For each interval timer, if the requested timer value requires a
finer granularity than the implementation supports, the actual timer
value shall be rounded up to the next supported value.
The !HIGHRES enabled kernel rounds this up to the HZ interval, the
HIGHRES enabled kernel grants the request for this short sleep.
The program gets what it asked for: a stupid sleep value.
tglx
-
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.21-rc7-mm2 crash: Eeek! page_mapcount(page) went negative! (-1)
On Sat, 28 Apr 2007, Andrew Morton wrote: > > It seems wildly screwed up that we have a PageReserved() page with a pfn of > zero (!) which claims to be in a reiserfs mapping, only it isn't attached > to a reiserfs file. How the heck did that happen? It's "simply" that it somehow got a spurious page table entry 0001. Great that it's so reproducible, I take that to mean this one is not bad RAM. Your request for a bisection is just what we want, thanks. Hugh - 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: PANIC: 2.6.21-rc7-mm2, Kernel access of bad area, sig: 11
On Sat, 28 Apr 2007 21:40:19 + (GMT) William Heimbigner <[EMAIL PROTECTED]> wrote: > This bug occurs in linux-2.6.21-rc7-mm2, and does not occur in 2.6.21-rc7 > ARCH is powerpc > > dmesg output, captured via netconsole: > [0.00] Using PowerMac machine description > [0.00] Total memory = 128MB; using 256kB for hash table (at c7fc) > [0.00] Linux version 2.6.21-rc7-mm2 ([EMAIL PROTECTED]) (gcc version > 4.1.1 (Gentoo 4.1.1-r3)) #3 SMP PREEMPT Sat Apr 28 14:29:54 CDT 2007 > [0.00] Found UniNorth memory controller & host bridge @ 0xf800 > revision: 0xc0 > [0.00] Mapped at 0xfdfc > [0.00] Found a Pangea mac-io controller, rev: 0, mapped at 0xfdf4 > [0.00] PowerMac motherboard: iMac "Flower Power" It ran OK on my G5. Can you send the config please? > ... > [ 27.030444] input: PMU as /class/input/input4 > [ 27.052675] ReiserFS: hda4: found reiserfs format "3.6" with standard > journal > [ 27.058960] ReiserFS: hda4: using ordered data mode > [ 27.078108] ReiserFS: hda4: journal params: device hda4, size 8192, > journal first block 18, max trans len 1024, max batch 900, max commit age 30, > max trans age 30 > [ 27.099024] ReiserFS: hda4: checking transaction log (hda4) > [ 27.195147] ReiserFS: hda4: Using r5 hash to sort names > [ 27.201477] VFS: Mounted root (reiserfs filesystem) readonly. > [ 27.207715] Freeing unused kernel memory: 248k init > [ 156.166766] Oops: Kernel access of bad area, sig: 11 [#1] > [ 156.167014] PREEMPT SMP NR_CPUS=2 DEBUG_PAGEALLOC PowerMac > [ 156.167267] Modules linked in: nfsd exportfs pmac_zilog serial_core > ohci1394 ieee1394 uninorth_agp > [ 156.167711] NIP: c0068ce4 LR: c0068cdc CTR: > [ 156.167892] REGS: c0583a40 TRAP: 0300 Not tainted (2.6.21-rc7-mm2) > [ 156.168118] MSR: 1032 CR: 42202022 XER: > [ 156.168467] DAR: , DSISR: 4200 > [ 156.168617] TASK = c0550260[0] 'swapper' THREAD: c0582000 CPU: 0 > [ 156.168840] GPR00: c0583af0 c0550260 0783 c059bc88 0001 > c0488ec0 c059bc80 > [ 156.169272] GPR08: c0460713 c0488e77 c0488b70 3da3 > 0023f96c c059 > [ 156.169705] GPR16: c059 0023f964 c059 1032 > c0583eb0 c059 > [ 156.170145] GPR24: c0583b18 c0583b28 c000a1e4 > c0583b2c c059bc80 > [ 156.170594] NIP [c0068ce4] kallsyms_lookup+0x64/0xa4 > [ 156.170806] LR [c0068cdc] kallsyms_lookup+0x5c/0xa4 > [ 156.170997] Call Trace: > [ 156.171093] [c0583af0] [c0068cb4] kallsyms_lookup+0x34/0xa4 (unreliable) > [ 156.171384] --- Exception: c0583bb0 at 0xc0583ba0 > [ 156.171578] LR = draw_byte+0x34/0x1d0 > [ 156.171723] [c0583b10] [c002ebd0] xmon_show_stack+0x2b8/0x330 (unreliable) > [ 156.172017] [c0583c10] [c003053c] cmds+0xa20/0x1600 > [ 156.172235] [c0583ca0] [c0031448] xmon_core+0x32c/0x734 > [ 156.172452] [c0583d60] [c00319fc] xmon+0x2c/0x68 > [ 156.172647] [c0583e20] [c0031b40] xmon_irq+0x50/0x6c > [ 156.172856] [c0583e40] [c0073828] handle_IRQ_event+0x5c/0xb0 > [ 156.173090] [c0583e60] [c00755dc] handle_fasteoi_irq+0xac/0x174 > [ 156.17] [c0583e80] [c0006be4] do_IRQ+0xec/0x130 > [ 156.179644] [c0583ea0] [c0014fe8] ret_from_except+0x0/0x14 > [ 156.185827] --- Exception: 501 at cpu_idle here>+0xfc/0x1dc > LR = cpu_idle+0xfc/0x1dc > [c0583f60] [c000a24c] cpu_idle+0x164/0x1dc (unreliable) > [c0583f80] [c0003cc4] rest_init+0x74/0x88 > [c0583fa0] [c050fb68] start_kernel+0x310/0x394 > [c0583ff0] [37b4] 0x37b4 > > This occurs after pressing the programmer switch to generate an NMI. Can you expand on this? Do you mean that hitting the NMI switch is what caused this crash? Does a G5 have a programmer switch? If so, how does this programmer switch it? If you compiled with CONFIG_DEBUG_INFO could you please do gdb vmlinux (gdb) l *0xc0068ce4 Patches which touch kallsyms.c in -mm are: extend-print_symbol-capability simplify-module_get_kallsym-by-dropping-length-arg simplify-kallsyms_lookup fix-race-between-rmmod-and-cat-proc-kallsyms fix-race-between-cat-proc-wchan-and-rmmod-et-al fix-race-between-cat-proc-slab_allocators-and-rmmod kallsyms-cleanup-use-seq_release_private-where-appropriate - 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/
bug in RLIMIT_SIGPENDING
summary: there seems to be a bug in RLIMIT_SIGPENDING accounting that
can cause it to go negative. associated with this fact, the given
process may get stuck forever trying to enter a 'clone' syscall.
long version:
- several people have experienced this problem of Xorg hanging forever
(100% cpu usage) trying to enter the 'clone' syscall to execute
xkbcomp.
- the syscall is aborted with ERESTARTNOINTR because there is a
SIGALRM signal pending. status shows:
SigQ: 1/18446744073709551615
SigPnd:
ShdPnd: 2000
SigBlk:
SigIgn: 00301000
SigCgt: 61c06ecb
note the weird SigQ value, is 64 bits' -1 for RLIMIT_SIGPENDING.
- the signal handler is executed (as confirmed under gdb).
- kernel will then force reentering the syscall by means of the
following code in handle_signal():
case -ERESTARTNOINTR:
regs->rax = regs->orig_rax;
regs->rip -= 2;
break;
- this effectively puts user space in a kind of spinlock that never ends.
- the code that sets signal handler is quoted here from Xorg gitweb:
1529 #define SMART_SCHEDULE_SIGNAL SIGALRM
(...)
1588 bzero ((char *) , sizeof(struct sigaction));
1589
1590 /* Set up the timer signal function */
1591 act.sa_handler = SmartScheduleTimer;
1592 sigemptyset (_mask);
1593 sigaddset (_mask, SMART_SCHEDULE_SIGNAL);
1594 if (sigaction (SMART_SCHEDULE_SIGNAL, , 0) < 0)
1595 {
1596 perror ("sigaction for smart scheduler");
1597 return FALSE;
1598 }
- the code that sets the timer is quoted here from Xorg gitweb:
1548 Bool
1549 SmartScheduleStartTimer (void)
1550 {
1551 #ifdef SMART_SCHEDULE_POSSIBLE
1552 struct itimervaltimer;
1553
1554 SmartScheduleTimerStopped = FALSE;
1555 timer.it_interval.tv_sec = 0;
1556 timer.it_interval.tv_usec = SmartScheduleInterval * 1000;
1557 timer.it_value.tv_sec = 0;
1558 timer.it_value.tv_usec = SmartScheduleInterval * 1000;
1559 return setitimer (ITIMER_REAL, , 0) >= 0;
1560 #endif
1561 return FALSE;
1562 }
- having this negative rlimit may cause problem to the
__sigqueue_alloc() kernel function. however, as far as i can see, this
would possibly prevent new signals from being enqueued - not existing
ones from being dequeued/cleared/whatever.
- bugzilla entry for the complete investigation can be seen here:
https://bugs.freedesktop.org/show_bug.cgi?id=10525
thanks,
Miguel
-
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: [ext3][kernels >= 2.6.20.7 at least] KDE going comatose when FS is under heavy write load (massive starvation)
On Sat, Apr 28, 2007 at 07:37:17AM +0200, Mikulas Patocka wrote: > SpadFS doesn't write to unallocated parts like log filesystems (LFS) or > phase tree filesystems (TUX2); it writes inside normal used structures, > but it marks each structure with generation tags --- when it updates > global table of tags, it atomically makes several structures valid. I > don't know about this idea being used elsewhere. So how is this generation structure organized ? paper ? bill - 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] i386: introduce voyager smp_ops, fix voyager build
Jeremy Fitzhardinge <[EMAIL PROTECTED]> writes: > This adds an smp_ops for voyager, and hooks things up appropriately. > This is the first baby-step to making subarch runtime switchable. Unless I have missed something early_gdt_descr still needs to be updated. Eric - 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/
High Resolution Timer DOS
Hi,
some programs need to do some short of busyloop. It was often
implemented as :
while (1) {
if (can_do_stuff) {
do_stuff();
}
else
//sleep a very short of time
usleep(1);
}
usleep(1) or equivalent where used instead of sched_yield, because of
some priority issue. IIRC doing sched_yield, make the process appears
like an interactive process, so it has better priority and get call more
often.
But now if high res timer are enabled, these programs while cause
something like a DOS : the context switch per second will be bigger than
500 000 and the cpu usage will be very high.
I don't know if such problem are already know, but I believe a warning
about such issues should be in the Kconfig description.
Matthieu
-
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/
irks with bugzilla (was Re: Linux 2.6.21)
Russell King wrote: > On Sat, Apr 28, 2007 at 09:53:20PM +0200, Adrian Bunk wrote: >> We are already quite good at ignoring bug reports that come through >> linux-kernel, and it's an _advantage_ of the kernel Bugzilla to see more >> than 1600 open bugs because this tells how bad we are at handling bugs. >> How many thousand bug reports have been ignored during the same time on >> linux-kernel? > > However, look at this bug: > > http://bugme.osdl.org/show_bug.cgi?id=7760 > > It's outside my knowledge to be able to fix for various reasons: [...] http://bugzilla.kernel.org/faq.cgi says, although it doesn't make a lot of sense: "Q. If a bug has an owner does that mean they are working on it? A. No. If it is not in the ASSIGNED state then no one is working on it. The owner defaults to the subsytem maintainer. However, anyone who wants to submit a patch or add more info to a bug can do so. If the bug is reassigned to someone then the owner field will reflect that change." So the "owner" field is bogus per default. It would be better if the bugzilla admins used only meta-addresses instead of a person's address for any automatically filled-in "owner" field, unless a person specifically wants to assume this automatic owner role. I for example am not automatic owner of IEEE 1394 bugs; [EMAIL PROTECTED] is. And I am watching this pseudo owner. So in fact, the "owner" field should be replaced by - a mail exploder for each component which can be watched by interested people, - an "assignee" field which is filled in when a bug is assigned to a person. Now that I am at it, another quote from http://bugzilla.kernel.org/faq.cgi : "Q. What does a subsystem maintainer do? A. He or She will track new bugs and assign them to people or reject it for various reasons. They periodically check to make sure things are getting worked on and review fixes to make sure they are well written." A maintainer in the project called linux kernel will almost never assign bugs to people (besides to himself). He could if he employed or otherwise supervised people to assign bugs to. This especially applies to so-called "subsystem maintainers in kernel tracker", which are not what many people think "subsystem maintainers" are: "Q. Why are the subsystem maintainers in kernel tracker sometimes different than the person listed in the MAINTAINER file? A. The subsystem maintainers in kernel tracker are volunteers to help track bugs in an area they are interested in. Sometimes they are the same person as on kernel.org sometimes they are not. There are still some categories with no maintainers so more volunteers are needed." Another quibble: This FAQ I'm quoting can be reached from the cover page of bugzilla.kernel.org, i.e. from http://bugzilla.kernel.org/. However, none of the other web pages of this site link to http://bugzilla.kernel.org/. Same for the bugme-admin contact. Because I find bugzilla.kernel.org quite useful for myself, I filed these complaints of mine under http://bugzilla.kernel.org/show_bug.cgi?id=8396 http://bugzilla.kernel.org/show_bug.cgi?id=8397 http://bugzilla.kernel.org/show_bug.cgi?id=8394 in hope that they are taken into consideration by those who maintain the site. -- Stefan Richter -=-=-=== -=-- ===-- http://arcgraph.de/sr/ - 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/
PANIC: 2.6.21-rc7-mm2, Kernel access of bad area, sig: 11
This bug occurs in linux-2.6.21-rc7-mm2, and does not occur in 2.6.21-rc7 ARCH is powerpc dmesg output, captured via netconsole: [0.00] Using PowerMac machine description [0.00] Total memory = 128MB; using 256kB for hash table (at c7fc) [0.00] Linux version 2.6.21-rc7-mm2 ([EMAIL PROTECTED]) (gcc version 4.1.1 (Gentoo 4.1.1-r3)) #3 SMP PREEMPT Sat Apr 28 14:29:54 CDT 2007 [0.00] Found UniNorth memory controller & host bridge @ 0xf800 revision: 0xc0 [0.00] Mapped at 0xfdfc [0.00] Found a Pangea mac-io controller, rev: 0, mapped at 0xfdf4 [0.00] PowerMac motherboard: iMac "Flower Power" [0.00] Found UniNorth PCI host bridge at 0xf000. Firmware bus number: 0->0 [0.00] Found UniNorth PCI host bridge at 0xf200. Firmware bus number: 0->0 [0.00] Found UniNorth PCI host bridge at 0xf400. Firmware bus number: 0->0 [0.00] via-pmu: Server Mode is enabled [0.00] PMU driver v2 initialized for Core99, firmware: 0c [0.00] nvram: Checking bank 0... [0.00] nvram: gen0=498, gen1=499 [0.00] nvram: Active bank is: 1 [0.00] nvram: OF partition at 0x210 [0.00] nvram: XP partition at 0x [0.00] nvram: NR partition at 0x [0.00] Zone PFN ranges: [0.00] DMA 0 ->32768 [0.00] Normal 32768 ->32768 [0.00] Movable zone start PFN for each node [0.00] early_node_map[1] active PFN ranges [0.00] 0:0 ->32768 [0.00] Built 1 zonelists, mobility grouping on. Total pages: 32512 [0.00] Kernel command line: root=/dev/hda4 ro real_root=/dev/hda4 [EMAIL PROTECTED]/eth0,[EMAIL PROTECTED]/00:11:09:3C:07:C2 [0.00] netconsole: local port [0.00] netconsole: local IP 192.168.0.3 [0.00] netconsole: interface eth0 [0.00] netconsole: remote port [0.00] netconsole: remote IP 192.168.0.8 [0.00] netconsole: remote ethernet address 00:11:09:3c:07:c2 [0.00] mpic: Setting up MPIC " MPIC 1 " version 1.2 at 8004, max 4 CPUs [0.00] mpic: ISU size: 64, shift: 6, mask: 3f [0.00] mpic: Initializing for 64 sources [0.00] PID hash table entries: 512 (order: 9, 2048 bytes) [0.00] GMT Delta read from XPRAM: 0 minutes, DST: on [ 18.626246] Console: colour dummy device 80x25 [ 18.626620] console handover: boot [udbg0] -> real [tty0] [ 18.627059] [ 18.627073] | Locking API testsuite: [ 18.627083] [ 18.627098] | spin |wlock |rlock |mutex | wsem | rsem | [ 18.627113] -- [ 18.627140] A-A deadlock:failed|failed| ok |failed|failed|failed| [ 18.627204] A-B-B-A deadlock:failed|failed| ok |failed|failed|failed| [ 18.627265] A-B-B-C-C-A deadlock:failed|failed| ok |failed|failed|failed| [ 18.627327] A-B-C-A-B-C deadlock:failed|failed| ok |failed|failed|failed| [ 18.627389] A-B-B-C-C-D-D-A deadlock:failed|failed| ok |failed|failed|failed| [ 18.627457] A-B-C-D-B-D-D-A deadlock:failed|failed| ok |failed|failed|failed| [ 18.627524] A-B-C-D-B-C-D-A deadlock:failed|failed| ok |failed|failed|failed| [ 18.627592] double unlock: ok | ok |failed| ok |failed|failed| [ 18.627645] initialize held:failed|failed|failed|failed|failed|failed| [ 18.627703] bad unlock order: ok | ok | ok | ok | ok | ok | [ 18.627763] -- [ 18.627785] recursive read-lock: | ok | |failed| [ 18.627825]recursive read-lock #2: | ok | |failed| [ 18.627865] mixed read-write-lock: |failed| |failed| [ 18.627911] mixed write-read-lock: |failed| |failed| [ 18.627951] -- [ 18.627974] hard-irqs-on + irq-safe-A/12:failed|failed| ok | [ 18.628011] soft-irqs-on + irq-safe-A/12:failed|failed| ok | [ 18.628049] hard-irqs-on + irq-safe-A/21:failed|failed| ok | [ 18.628084] soft-irqs-on + irq-safe-A/21:failed|failed| ok | [ 18.628120]sirq-safe-A => hirqs-on/12:failed|failed| ok | [ 18.628156]sirq-safe-A => hirqs-on/21:failed|failed| ok | [ 18.628192] hard-safe-A + irqs-on/12:failed|failed| ok | [ 18.628229] soft-safe-A + irqs-on/12:failed|failed| ok | [ 18.628266] hard-safe-A +
maturity levels: a first pass
off the top of my head, this is what the interface might look like. diff --git a/init/Kconfig b/init/Kconfig index b170aa1..5c8529c 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -40,6 +40,26 @@ config EXPERIMENTAL you say Y here, you will be offered the choice of using features or drivers that are currently considered to be in the alpha-test phase. +config ACTIVATE_MATURITY + bool "Activate maturity attribute selection" + ---help--- + This feature gives you the ability to de-select entire sets of + kernel features based on how they've been tagged with the + "maturity" directive. + + If you choose not to activate this feature, then the Kconfig + "maturity" directives have no effect on the configuration. + +config MATURITY_DEPRECATED + bool "Display DEPRECATED features." + depends on ACTIVATE_MATURITY + default y + +config MATURITY_OBSOLETE + bool "Display OBSOLETE features." + depends on ACTIVATE_MATURITY + default y + config BROKEN bool -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - 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: [00/17] Large Blocksize Support V3
On Sat, 28 Apr 2007 12:19:56 -0700 William Lee Irwin III <[EMAIL PROTECTED]> wrote: > I'm skeptical, however, that the contiguity gains will compensate for > the CPU required to do such with the pcp lists. It wouldn't surprise me if approximate contiguity is a pretty common case in the pcp lists. Recaim isn't very important here: most pages get freed in truncate and particularly unmap_vmas. If the allocator is handing out pages in reasonably contiguous fashion (and it does, and we're talking about strengthening that) then I'd expect that very often we end up freeing pages which have a lot of locality too. So the sort of tricks which you're discussing might get a pretty good hit rate. otoh, it's not obvious to me that there's a lot to be gained here. If we repeatedly call the buddy allocator freeing contiguous order-0 pages, all the data structures which are needed to handle those should be in L1 cache and the buddy itself becomes our point-of-collection, if you see what I mean. Dunno. Profiling should tell? - 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: Back to the future.
On Sat, 28 Apr 2007, Rafael J. Wysocki wrote: > > > > The freezer has *caused* those deadlocks (eg by stopping threads that were > > needed for the suspend writeouts to succeed!), not solved them. > > I can't remember anything like this, but I believe you have a specific test > case in mind. Ehh.. Why do you thik we _have_ that PF_NOFREEZE thing in the first place? Rafael, you really don't know what you're talking about, do you? Just _look_ at them. It's the IO threads etc that shouldn't be frozen, exactly *because* they do IO. You claim that kernel threads shouldn't do IO, but that's the point: if you cannot do IO when snapshotting to disk, here's a damn big clue for you: how do you think that snapshot is going to get written? I *guarantee* you that we've had a lot more problems with threads that should *not* have been frozen than with those hypothetical threads that you think should have been frozen. 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/
Please revert [PATCH] user of the jiffies rounding patch: Slab
The slab reaper takes global locks. If one makes all cache reapers fire at the same time as this patch does then there will be a lot of contention that may result lots of interrupt holdoffs since some locks are taken with interrupts disabled. The vm statistics counters are updated and will content for global cachelines if this is done. The approach is fine up to 2 cpus. With 2 cpus we can schedule one cache reaper on each cpu each second. So I guess that this was not noticed. For 16 cpus we are already scheduling 8 parallel cache reapers every second. In a 512 cpu system desaster strikes with 256 cache reapers being fired off at the same time each second Git commit http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=2b2842146cb4105877c2be51d3857ec61ebd4ff9 This is in 2.6.20 / 2.6.21. I'd suggest to use a staggered per cpu approach instead that runs multiple per cpu timers at once. But every batch of these timers must be run at an offset from each other. Not at the same time please. - 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: [stable] 2.6.21 known regressions (v2) (for -stable team)
Greg KH <[EMAIL PROTECTED]> writes: >> Also, assignation of ttyUSB#'s is volatile depending on phase of the >> moon when booted. > > That's always been the case, ever since the 2.2 kernel releases. Please > use udev if you want persistent device names for your tty USB devices. I don't know how udev (or anything) could help here. AFAIK the converters have no serial numbers and no other means to differentiate. -- Krzysztof Halasa - 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.21-git2] sk_buff changes break Cisco VPN client
On Sat, 28 Apr 2007 22:38:45 +0200 "Alessandro Suardi" <[EMAIL PROTECTED]> wrote: > skb_set_timestamp I can figure out, but the rest is a bit > too hard for me... if anyone has already an idea of how > to fix this, I'd be most grateful. > > Cisco VPN client builds and works fine under 2.6.21 vanilla. Perhaps if cisco included full source they could get their code merged, in the meantime why not throw it away and use vpnclient like everyone else ? - 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.21-git2] sk_buff changes break Cisco VPN client
On 4/28/07, Roland Dreier <[EMAIL PROTECTED]> wrote: This is really a problem for Cisco support, not the kernel people. (And despite my email address I really have no idea who looks after the VPN client). It's ok, I know it's "not a kernel issue". I just asked over here because I saw network code already converted to the new sk_buff code, and hoped someone could hint to a solution; I don't think it'd be extremely fruitful to ask Cisco since I'm already running a patched version of their latest official Linux release, which hasn't been updated for quite a while. However I can suggest vpnc (http://www.unix-ag.uni-kl.de/~massar/vpnc/) as an alternative. I'm not forced to use Cisco VPN access any more, but when I tried it, vpnc was tons better than the Cisco product. vpnc only started supporting hybrid-auth as of very, very recently; I used it before my company network turned to hybrid-auth-only several months ago. It's in my sights to go back to test vpnc-0.4.0 with the hybrid-auth support patch in the near future. But in the meantime I'll be stuck with the Cisco VPN client. After clarifying all this, I'll respectfully ask again whether anyone has an idea about how to go fixing the five or so lines of the skb stuff impacted by the kernel changes - and will of course take no offense if nobody can help, while happily ignoring those who can only contribute what I do already know, that is - this isn't a kernel issue. Thanks again in advance, ciao, --alessandro "Did you get married but forgot to get divorced ?" (Danny and Dusty, 'The Good Old Days') - 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/
