Reference: https://launchpad.net/bugs/175834 CC: linux-ide@vger.kernel.org Signed-off-by: Chuck Short <zulcss@ubuntu.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Ben Collins <ben.collins@canonical.com> --- drivers/ata/libata-core.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c index 9bef1a8..2664082 100644 --- a/drivers/ata/libata-core.c +++ b/drivers/ata/libata-cor...

EXPERIMENTAL and incomplete patch to make LOCKDEP behave better in the face of irq chaining, by annotating irqs with a lock_class which can reflect that hierarchy. This version of the patch is incomplete in at least two respects: - There's no spin_lock_irq_nested() primitive, so that locking calls on irq probing (yeech!) paths must ignore the annotations. ==> LOCKDEP feature is evidently missing: spin_lock_irq_nested(lock_ptr, lock_class) - We'd really need new API to declare the ...

[Empty message]

Hi Linus, Please pull from 'master' branch of git://git.kernel.org/pub/scm/linux/kernel/git/wim/linux-2.6-watchdog.git or if master.kernel.org hasn't synced up yet: master.kernel.org:/pub/scm/linux/kernel/git/wim/linux-2.6-watchdog.git This will update the following files: Documentation/watchdog/watchdog-api.txt | 38 +++++++++++++++++--------------- drivers/watchdog/w83697hf_wdt.c | 4 --- 2 files changed, 22 insertions(+), 20 deletions(-) with these Changes: Author: And...

Yes known problem. On some systems the self test interacts badly with the split mappings created by the PAT code I think. I don't have a fix yet. But you can ignore it for now -- should be harmless. Or disable CONFIG_CPA_DEBUG. -Andi --

FWIW, I have been working in this area extensively. Check out the 'irq-cleanups' and 'irq-remove' branches of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/misc-2.6.git NAK the rest. You should be using irq_handler_t for all these. (Coincedentally, doing so makes it easier for me to later on remove the almost-never-used 'irq' argument from all irq handlers) Jeff --

The others need to be irq_handler_t because that's the precise type that's being used in each particularly situation. Each time the code re-creates that definition creates a problem for future irq handler changes of any type, really. As I noted, I've fixed all this crap already, and read through each one of those drivers. Jeff --

This is ugly and unnecessary. Anything that does not use irq_handler_t is broken and should be fixed (as noted in last email, I think I've covered all this driver work already) And if by definition everything uses irq_handler_t, there is no need for any of this "check_either_type" silliness. Jeff --

Type safety is good but I doubt this would be worth the complexity. It has some benefits but there's much larger benefit in keeping things in straight C. People know that functions take fixed types and are also familiar with the convention of passing void * for callback arguments. IMHO, staying in line with those common knowledges easily trumps having type checking on interrupt handler. Also, how often do we see a bug where things go wrong because interrupt handler is given the wrong type of ar...

The compiler checks types, and we should use it (though note that when I typesafed the kthread code I didn't find any bugs, so safety arguments must be muted). The gratuitous casts back and forth are annoying and silly. The compatibility nightmare is one reason for the previous patch (which you True, but this is not about performance. It's about making code simpler and compiler-checkable. Rusty. --

Please pull from the 'upstream' branch of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git upstream to receive my 2.6.25 net driver queue into davem/net-2.6.25.git: Adam Baker (2): rt2x00: Unconstify rt2x00dev rt2x00: Place mutex around USB register access Adrian Bunk (4): drivers/net/netxen/: cleanups drivers/net/chelsio/: #if 0 unused functions ipg: add __devexit annotation e1000: remove no longer used code for pci read/write cfg ...

I searched around the archives and web and didn't find any reports on this [maybe just missed them?], so I MUST be doing something wrong/stupid. My config [included] may be the culprit. Apologies for the long cc list. I'm copying the kprobes and blktrace maintainers [addresses from MAINTAINERS] to verify that they're NOT seeing this problem. Problem: I see no sub-directories below /sys/kernel/debug on x86_64 even when ad hoc instrumentation [i.e., printk()s] claims that the subdir's and files ...

D'oh! [or something stronger] I KNEW it was something stupid. I thought it strange that there were no reports of something this glaring. That's why I took so long investigating before I finally asked. I've used debugfs+mmtrace on x86_64 in the past and I've had the debugfs mount in my test systems' fstab for so long that I don't even think about it [obviously!]. I moved to a different test system a couple of months ago and apparently brought over an old fstab patch. Sorry for the noise [he s...

on CONFIG_EFI, indeed :) Ingo --

Why are we rushing so much to do 64-bit paravirt that we are breaking working configurations? If the developement is going to be this chaotic, it should be done and tested out of tree until it can stabilize. I do not like having to continuously retest and review the x86 branch because the paravirt-ops are constantly in flux and the 32-bit code keeps breaking. We won't be doing 64-bit paravirt-ops for exactly this reason - is there a serious justification from the performance angle on modern 6...

what you see is a open feedback cycle conducted on lkml. People send patches for arch/x86, and we tell them if it breaks something. The bug was found before i pushed out the x86.git devel tree (and the fix is below - but this shouldnt matter to you because the bug never hit a public x86.git tree). Ingo Index: linux/include/asm-x86/paravirt.h =================================================================== --- linux.orig/include/asm-x86/paravirt.h +++ linux/include/asm-x86/paravirt.h...

Good catch, I know I don't test with CONFIG_EFI=y --

x86_64 lacks a native_init_IRQ() function, so we turn the arch's init_IRQ() function into a native construct Signed-off-by: Glauber de Oliveira Costa <gcosta@redhat.com> --- arch/x86/kernel/i8259_64.c | 4 +++- include/asm-x86/hw_irq_64.h | 1 + 2 files changed, 4 insertions(+), 1 deletions(-) diff --git a/arch/x86/kernel/i8259_64.c b/arch/x86/kernel/i8259_64.c index cba13e0..738517e 100644 --- a/arch/x86/kernel/i8259_64.c +++ b/arch/x86/kernel/i8259_64.c @@ -456,7 +456,9 @@ voi...

This patch adds room for read and write_cr8 functions back in pv_cpu_ops struct Signed-off-by: Glauber de Oliveira Costa <gcosta@redhat.com> --- include/asm-x86/paravirt.h | 15 +++++++++++++++ 1 files changed, 15 insertions(+), 0 deletions(-) diff --git a/include/asm-x86/paravirt.h b/include/asm-x86/paravirt.h index 7ff25c2..3e7ca42 100644 --- a/include/asm-x86/paravirt.h +++ b/include/asm-x86/paravirt.h @@ -101,6 +101,11 @@ struct pv_cpu_ops { unsigned long (*read_cr4)(void); ...

This patch fills in the read and write cr8 fields with their native version Signed-off-by: Glauber de Oliveira Costa <gcosta@redhat.com> --- arch/x86/kernel/paravirt.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c index c20b4f8..c67d331 100644 --- a/arch/x86/kernel/paravirt.c +++ b/arch/x86/kernel/paravirt.c @@ -319,6 +319,10 @@ struct pv_cpu_ops pv_cpu_ops = { .read_cr4 = native_read_cr4, .read_c...

This patch adds the __parainstructions section to vmlinux.lds.S. It's needed for the patching system. Signed-off-by: Glauber de Oliveira Costa <gcosta@redhat.com> --- arch/x86/kernel/vmlinux_64.lds.S | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/arch/x86/kernel/vmlinux_64.lds.S b/arch/x86/kernel/vmlinux_64.lds.S index 5ae8aa8..5e0300f 100644 --- a/arch/x86/kernel/vmlinux_64.lds.S +++ b/arch/x86/kernel/vmlinux_64.lds.S @@ -175,6 +175,14 @@ SECTIONS } ...

In theory other architectures could use a similar mechanism, but for now its x86 specific. J --

Hm, in my original patches I put the #ifdef CONFIG_X86_PAE below the PAGETABLE_LEVELS section. Does that work? Or is that an equivalent transform? --

I completely agree with you here. But, unless this page : http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html is not up-to-date anymore, there is no free attribute. Which is quite logical, actually, as such an attribute would be equivalent to simply marking the parameter of the function non-const. That's what I was alluding to, when speaking of a legitimate change (adding attribute malloc to kmalloc()) which would break another part of the kernel. Of course, we can also assume that...

Note that driver will likely do clock throttling on your CPU. Using that is usually a bad idea because it does not actually safe power. It's only intended to let the CPU cool down in some situations. -Andi --