CONFIG_SECTION_MISMATCH is replaced by CONFIG_DEBUG_SECTION_MISMATCH
CONFIG_SECTION_MISMATCH I supposed has been deprecated by CONFIG_DEBUG_SECTION_MISMATCH, as I found CONFIG_DEBUG_SECTION_MISMATCH in Makefile, Makefile.build and Makefile.modpost, but not the former symbol. Moreover, setting the symbol in .config, and followed by make oldconfig will result in the non-debug symbol disappearing, but not the debug version. Am I correct? Signed-off-by: Peter Teoh <[EMAIL PROTECTED]> --- scripts/mod/modpost.c.orig 2008-02-02 15:18:04.0 +0800 +++ scripts/mod/modpost.c 2008-02-02 15:18:47.0 +0800 @@ -1942,7 +1942,7 @@ int main(int argc, char **argv) "To see additional details select \"Enable full " "Section mismatch analysis\"\n" "in the Kernel Hacking menu " - "(CONFIG_SECTION_MISMATCH).\n", sec_mismatch_count); + "(CONFIG_DEBUG_SECTION_MISMATCH).\n", sec_mismatch_count); return err; } -- 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] ide-core: remove conditional compiling with MODULE in ide-core.c
use module_init/module_exit to replace the original cond-compiling, these
macros were well designed to deal module/built-in compiling.
the original __setup with null string was invalid and not executed,
__setup("", ide_setup);
however, with the current module_param mechanics, module parameters also can
be input on the kernel command line, with this style:
ide-core.options="ide=nodma hdd=cdrom idebus=..."
so Documentation/kernel-parameters.txt also updated.
Signed-off-by: Denis Cheng <[EMAIL PROTECTED]>
---
Documentation/kernel-parameters.txt | 11 +--
drivers/ide/ide.c | 55 ++
2 files changed, 25 insertions(+), 41 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index cf38689..c94730c 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -759,15 +759,8 @@ and is between 256 and 4096 characters. It is defined in
the file
icn=[HW,ISDN]
Format: [,[,[,]]]
- ide=[HW] (E)IDE subsystem
- Format: ide=nodma or ide=doubler or ide=reverse
- See Documentation/ide.txt.
-
- ide?= [HW] (E)IDE subsystem
- Format: ide?=noprobe or chipset specific parameters.
- See Documentation/ide.txt.
-
- idebus= [HW] (E)IDE subsystem - VLB/PCI bus speed
+ ide-core.options= [HW] (E)IDE subsystem
+ Format: ide-core.options="ide=nodma hdd=cdrom
idebus=..."
See Documentation/ide.txt.
idle= [X86]
diff --git a/drivers/ide/ide.c b/drivers/ide/ide.c
index ab9ca2b..28923ef 100644
--- a/drivers/ide/ide.c
+++ b/drivers/ide/ide.c
@@ -1654,6 +1654,25 @@ struct bus_type ide_bus_type = {
EXPORT_SYMBOL_GPL(ide_bus_type);
+static char *options;
+module_param(options, charp, S_IRUGO);
+MODULE_LICENSE("GPL");
+
+static void __init parse_options(char *line)
+{
+ char *next = line;
+
+ if (line == NULL || !*line)
+ return;
+ while ((line = next) != NULL) {
+ next = strchr(line, ' ');
+ if (next != NULL)
+ *next++ = 0;
+ if (!ide_setup(line))
+ printk(KERN_INFO "Unknown option '%s'\n", line);
+ }
+}
+
/*
* This is gets invoked once during initialization, to set *everything* up
*/
@@ -1661,6 +1680,8 @@ static int __init ide_init(void)
{
int ret;
+ parse_options(options);
+
printk(KERN_INFO "Uniform Multi-Platform E-IDE driver " REVISION "\n");
system_bus_speed = ide_system_bus_speed();
@@ -1681,32 +1702,7 @@ static int __init ide_init(void)
return 0;
}
-#ifdef MODULE
-static char *options = NULL;
-module_param(options, charp, 0);
-MODULE_LICENSE("GPL");
-
-static void __init parse_options (char *line)
-{
- char *next = line;
-
- if (line == NULL || !*line)
- return;
- while ((line = next) != NULL) {
- if ((next = strchr(line,' ')) != NULL)
- *next++ = 0;
- if (!ide_setup(line))
- printk (KERN_INFO "Unknown option '%s'\n", line);
- }
-}
-
-int __init init_module (void)
-{
- parse_options(options);
- return ide_init();
-}
-
-void __exit cleanup_module (void)
+static void __exit ide_exit(void)
{
int index;
@@ -1718,10 +1714,5 @@ void __exit cleanup_module (void)
bus_unregister(_bus_type);
}
-#else /* !MODULE */
-
-__setup("", ide_setup);
-
module_init(ide_init);
-
-#endif /* MODULE */
+module_exit(ide_exit);
--
1.5.3.8
--
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/3] x86: add include to cpu/intel.c
Fixes sparse warning: arch/x86/kernel/cpu/intel.c:48:15: warning: symbol 'ppro_with_ram_bug' was not declared. Should it be static? Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]> --- arch/x86/kernel/cpu/intel.c |1 + include/asm-x86/bugs.h |2 +- 2 files changed, 2 insertions(+), 1 deletions(-) diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c index d1c372b..fae31ce 100644 --- a/arch/x86/kernel/cpu/intel.c +++ b/arch/x86/kernel/cpu/intel.c @@ -13,6 +13,7 @@ #include #include #include +#include #include "cpu.h" diff --git a/include/asm-x86/bugs.h b/include/asm-x86/bugs.h index 3fcc30d..021cbdd 100644 --- a/include/asm-x86/bugs.h +++ b/include/asm-x86/bugs.h @@ -2,6 +2,6 @@ #define _ASM_X86_BUGS_H extern void check_bugs(void); -extern int ppro_with_ram_bug(void); +int ppro_with_ram_bug(void); #endif /* _ASM_X86_BUGS_H */ -- 1.5.4.rc4.1142.gf5a97 -- 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/3] x86: small sparse fix in process_32.c
arch/x86/kernel/process_32.c:254:43: warning: Using plain integer as NULL pointer Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]> --- arch/x86/kernel/process_32.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/x86/kernel/process_32.c b/arch/x86/kernel/process_32.c index 968371a..dabdbef 100644 --- a/arch/x86/kernel/process_32.c +++ b/arch/x86/kernel/process_32.c @@ -251,7 +251,7 @@ void cpu_idle_wait(void) * because it has nothing to do. * Give all the remaining CPUS a kick. */ - smp_call_function_mask(map, do_nothing, 0, 0); + smp_call_function_mask(map, do_nothing, NULL, 0); } while (!cpus_empty(map)); set_cpus_allowed(current, tmp); -- 1.5.4.rc4.1142.gf5a97 -- 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/3] x86: add function prototype to vm86.h
Global functions should include their prototypes.
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
include/asm-x86/vm86.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/asm-x86/vm86.h b/include/asm-x86/vm86.h
index a5edf51..b72b9a6 100644
--- a/include/asm-x86/vm86.h
+++ b/include/asm-x86/vm86.h
@@ -195,6 +195,7 @@ struct kernel_vm86_struct {
void handle_vm86_fault(struct kernel_vm86_regs *, long);
int handle_vm86_trap(struct kernel_vm86_regs *, long, int);
+struct pt_regs * save_v86_state(struct kernel_vm86_regs *);
struct task_struct;
void release_vm86_irqs(struct task_struct *);
--
1.5.4.rc4.1142.gf5a97
--
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] mmc: extend ricoh_mmc to support Ricoh RL5c476
Frank Seidel wrote:
> From: Frank Seidel <[EMAIL PROTECTED]>
>
> This patch (based on current linus git tree) adds support for
> the Ricoh RL5c476 chip: with this the mmc adapter that needs this
> disabler (R5C843) can also be handled correctly when it sits
> on a RL5c476.
Again, thanks a lot for investigating and finding the appropriate magic
incantations. My main comment is to please base this on top of my suspend/resume
patch which Pierre said he accepted but which isn't in his tree yet - I guess
he's busy offline right now - haven't heard from him in a while.
> Signed-off-by: Frank Seidel <[EMAIL PROTECTED]>
> ---
> drivers/mmc/host/ricoh_mmc.c | 91
> +++
> 1 file changed, 75 insertions(+), 16 deletions(-)
>
> --- a/drivers/mmc/host/ricoh_mmc.c
> +++ b/drivers/mmc/host/ricoh_mmc.c
> @@ -45,8 +45,10 @@ static int __devinit ricoh_mmc_probe(str
>const struct pci_device_id *ent)
> {
> u8 rev;
> + u8 ctrlfound = 0;
>
> struct pci_dev *fw_dev = NULL;
> + struct pci_dev *main_dev = NULL; /* for Ricoh RL5c476 II */
There's no need to have two pointers. One will do fine.
> BUG_ON(pdev == NULL);
> BUG_ON(ent == NULL);
> @@ -58,7 +60,47 @@ static int __devinit ricoh_mmc_probe(str
> pci_name(pdev), (int)pdev->vendor, (int)pdev->device,
> (int)rev);
>
> - while ((fw_dev = pci_get_device(PCI_VENDOR_ID_RICOH,
> PCI_DEVICE_ID_RICOH_R5C832, fw_dev))) {
> + /* disable mmc controller via main function (RL5C476) */
> + while ((main_dev =
> + pci_get_device(PCI_VENDOR_ID_RICOH,
> + PCI_DEVICE_ID_RICOH_RL5C476, main_dev))) {
> + if (PCI_SLOT(pdev->devfn) == PCI_SLOT(main_dev->devfn) &&
> + pdev->bus == main_dev->bus) {
> + u8 write_enable;
> + u8 write_target;
> + u8 disable;
> +
> + pci_read_config_byte(main_dev, 0xB7, );
> + if (disable & 0x02) {
> + printk(KERN_INFO DRIVER_NAME
> + ": Controller already disabled. " \
> + "Nothing to do.\n");
> + return -ENODEV;
> + }
> +
> + pci_read_config_byte(main_dev, 0x8E, _enable);
> + pci_write_config_byte(main_dev, 0x8E, 0xAA);
> + pci_read_config_byte(main_dev, 0x8D, _target);
> + pci_write_config_byte(main_dev, 0x8D, 0xB7);
> + pci_write_config_byte(main_dev, 0xB7, disable | 0x02);
> + pci_write_config_byte(main_dev, 0x8E, write_enable);
> + pci_write_config_byte(main_dev, 0x8D, write_target);
> +
> + pci_set_drvdata(pdev, main_dev);
> +
> + printk(KERN_INFO DRIVER_NAME
> + ": Controller is now disabled " \
> + "(via R5L5C476).\n");
> +
> + ctrlfound = 1;
> + break;
> + }
> + }
> +
> + /* disable mmc controller via firewire function (R5C832) */
> + while (!ctrlfound &&
> + (fw_dev = pci_get_device(PCI_VENDOR_ID_RICOH,
> + PCI_DEVICE_ID_RICOH_R5C832, fw_dev))) {
> if (PCI_SLOT(pdev->devfn) == PCI_SLOT(fw_dev->devfn) &&
> pdev->bus == fw_dev->bus) {
> u8 write_enable;
It feels like there's a bit too much code duplication going on here, but I think
that after you rebase the patch it'll look a lot tidier and I won't feel bad
about
it :-)
> @@ -67,7 +109,8 @@ static int __devinit ricoh_mmc_probe(str
> pci_read_config_byte(fw_dev, 0xCB, );
> if (disable & 0x02) {
> printk(KERN_INFO DRIVER_NAME
> -": Controller already disabled. Nothing
> to do.\n");
> + ": Controller already disabled. " \
> + "Nothing to do.\n");
> return -ENODEV;
> }
>
> @@ -79,15 +122,16 @@ static int __devinit ricoh_mmc_probe(str
> pci_set_drvdata(pdev, fw_dev);
>
> printk(KERN_INFO DRIVER_NAME
> -": Controller is now disabled.\n");
> +": Controller is now disabled (via R5C832).\n");
>
> - break;
> + ctrlfound = 1;
> }
> }
>
> - if (pci_get_drvdata(pdev) == NULL) {
> + if (!ctrlfound) {
> printk(KERN_WARNING DRIVER_NAME
> -": Main firewire function not found. Cannot disable
> controller.\n");
> +
Re: Problem with ata layer in 2.6.24
Kasper Sandberg wrote: > to put some timeline perspective into this. > i believe it was in 2005 i assembled the system, and when i realized it > was faulty, on old ide driver, i stopped using it - that miht have been > in beginning of 2006. then for almost a year i werent using it, hoping > to somehow fix it, but in january 2007 i think it was, atleast in the > very beginning of 2007, i hit upon the idea of trying libata, and ever > since the system has been running 24/7 - doing these errors around 2 > times a day. > > i have multiple times reported my problems to lkml, but nothing has > happened, i also tried to aproeach jgarzik direcly, but he was not > interested. > > i really hope this can be solved now, its a huge problem > > my fileserver has an asus k8v motherboard, with via chipset (k8t880 i > think it is, or something like it). currently using the promise > controller again(strangely enough all the timeouts seems to happen here, > and when the ITE was on, there, not the onboard one), in conjunction > with the onboard via. Timeouts are nasty to debug. It can be caused by whole range of different problems including transmission errors, bad power, faulty drive, mishandled media error, IRQ misrouting, dumb hardware bug. It's basically 'uh... I told the controller to do something but it never called me back'. If you see timeouts on multiple devices connected to different controllers, the chance is that you have problem somewhere else. The most likely culprit is bad power. Please... * Post the result of 'lspci -nn' and kernel log including full boot log and error messages. * Try to isolate the problem. ie. Does removing several number of drives fix the problem? If the problem is localized to certain device, what happens if you move it? Does the problem follow the drive or stay with the port? If the failing drives are SATA, it's a good idea to power some of the failing drives with a separate PSU and see whether anything is different. By trying to isolate the hardware problem, more can be learned about the error condition and even when the problem actually isn't hardware problem, it gives us much deeper insight of the problem and clues regarding where to look. Thanks. -- tejun -- 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 06/23 -v8] handle accurate time keeping over long delays
On Fri, 1 Feb 2008, Mathieu Desnoyers wrote: > > > > accumulated clock cycles. > > > > > > > > > > About this one.. we talked a lot about the importance of timekeeping at > > > the first Montreal Tracing Summit this week. Actually, someone > > > mentioned a very interesting point : in order to be able to synchronize > > > traces taken from the machine with traces taken on external hardware > > > (i.e. memory bus tracer on Freescale), taking the "real" counter value > > > rather that using the "cumulated cycles" approach (which creates a > > > virtual counted instead) would be better. > > > > > > So I would recommend using an algorithm that would return a clock value > > > which is the same as the underlying hardware counter. > > > > Hmm. It is an interesting issue. Clearly having the raw cycle value > > match up so hardware analysis could be mapped to software timestamps > > would be useful(although obscure) feature. However with the variety of > > clocksources, dealing properly with the clocksource wrap issue (ACPI PM > > for instance wraps about every 5 seconds) also has to be addressed. > > > > I think you were mentioning an idea that required some work on the read > > side to handle the wraps, basically managing the high order bits by > > hand. This sounds like it would be an additional feature that could be > > added on to the infrastructure being provided in the > > get_monotonic_cycles() patch. No? > > > > Yup, exactly. > > > > > However, all of the above is a separate issue then what this (the > > timekeeping over long delay) patch addresses, as it is not really > > directly related to the get_monotonic_cycles() patch, but instead allows > > for correct timekeeping, making update_wall_time() to function properly > > if it was deferred for longer then the clocksource's wrap time. > > > > I agree, that could apply on top of the monotonic cycles patch. It's > just a different way to see it : dealing with wrapping TSC bits, > returning the LSBs given by the hardware, rather than simply > accumulating time. This is what the patch I sent earlier (which I use in > LTTng) does. I currently expects 32 LSBs to be given by the hardware, > but it would be trivial to extend it to support any given number of > hardware LSBs. > So you are saying that you can trivally make it work with a clock that is, say 24 bits? And this same code can work if we boot up with a clock with 32 bits or more? -- Steve -- 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 21/23 -v8] Add markers to various events
5B On Thu, 31 Jan 2008, Mathieu Desnoyers wrote: > * Steven Rostedt ([EMAIL PROTECTED]) wrote: > > This patch adds markers to various events in the kernel. > > (interrupts, task activation and hrtimers) > > > > Hi Steven, > > I would propose the following standard for IRQ handler markers: > > trace_mark(kernel_irq_entry, "irq_id %u kernel_mode %u", irq, > (regs)?(!user_mode(regs)):(1)); Are you saying that two markers with the same name is ok? That would be great if that is true. > > trace_mark(kernel_irq_exit, MARK_NOARGS); My patches don't use this (yet) so I'm leaving out adding markers that are not used. I'm not disagreeing with adding these, it's just that a patch series should only add markers that are actually used. > > So we can know the elaspsed time in irq handlers and whether they are > nested on user of kernel code. > > The same for traps : > > trace_mark(kernel_arch_trap_entry, "trap_id %d ip #p%ld", trapnr, > instruction_pointer(regs)); > > Where we know the trap number and the instruction pointer that caused > the trap. Here again, we should put a : > > trace_mark(kernel_arch_trap_exit, MARK_NOARGS); > > At the end of the trap handlers. > > It makes automatic analysis _much_ easier than trying to gather each and > every handler instrumentation which would have a different name... > -- Steve -- 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] modify incorrected word in comment of clear_active_flags
I think is was a mistake. clear_active_flags is just called by shrink_inactive_list. --- mm/vmscan.c.orig 2008-02-02 15:21:52.0 +0900 +++ mm/vmscan.c 2008-02-02 15:20:46.0 +0900 @@ -761,7 +761,7 @@ static unsigned long isolate_lru_pages(u } /* - * clear_active_flags() is a helper for shrink_active_list(), clearing + * clear_active_flags() is a helper for shrink_inactive_list(), clearing * any active bits from the pages in the list. */ static unsigned long clear_active_flags(struct list_head *page_list) -- Kinds regards, barrios -- 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] add support for dynamic ticks and preempt rcu
[
Resending this patch because no one commented on it (besides Paul)
and I'm thinking it got lost in the noise.
Without this patch, preempt RCU is broken when NO_HZ is configured.
]
The PREEMPT-RCU can get stuck if a CPU goes idle and NO_HZ is set.
The idle CPU will not progress the RCU through its grace period
and a synchronize_rcu my get stuck. Without this patch I have
a box that will not boot when PREEMPT_RCU and NO_HZ are set.
That same box boots fine with this patch.
Note: This patch came directly from the -rt patch where it
has been tested for several months.
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
Signed-off-by: Paul E. McKenney <[EMAIL PROTECTED]>
---
include/linux/hardirq.h| 10 ++
include/linux/rcuclassic.h |3
include/linux/rcupreempt.h | 22
kernel/rcupreempt.c| 224 -
kernel/softirq.c |1
kernel/time/tick-sched.c |3
6 files changed, 259 insertions(+), 4 deletions(-)
Index: linux-compile.git/kernel/rcupreempt.c
===
--- linux-compile.git.orig/kernel/rcupreempt.c 2008-01-29 11:03:21.0
-0500
+++ linux-compile.git/kernel/rcupreempt.c 2008-01-29 11:10:08.0
-0500
@@ -23,6 +23,10 @@
* to Suparna Bhattacharya for pushing me completely away
* from atomic instructions on the read side.
*
+ * - Added handling of Dynamic Ticks
+ * Copyright 2007 - Paul E. Mckenney <[EMAIL PROTECTED]>
+ * - Steven Rostedt <[EMAIL PROTECTED]>
+ *
* Papers: http://www.rdrop.com/users/paulmck/RCU
*
* Design Document: http://lwn.net/Articles/253651/
@@ -409,6 +413,212 @@ static void __rcu_advance_callbacks(stru
}
}
+#ifdef CONFIG_NO_HZ
+
+DEFINE_PER_CPU(long, dynticks_progress_counter) = 1;
+static DEFINE_PER_CPU(long, rcu_dyntick_snapshot);
+static DEFINE_PER_CPU(int, rcu_update_flag);
+
+/**
+ * rcu_irq_enter - Called from Hard irq handlers and NMI/SMI.
+ *
+ * If the CPU was idle with dynamic ticks active, this updates the
+ * dynticks_progress_counter to let the RCU handling know that the
+ * CPU is active.
+ */
+void rcu_irq_enter(void)
+{
+ int cpu = smp_processor_id();
+
+ if (per_cpu(rcu_update_flag, cpu))
+ per_cpu(rcu_update_flag, cpu)++;
+
+ /*
+* Only update if we are coming from a stopped ticks mode
+* (dynticks_progress_counter is even).
+*/
+ if (!in_interrupt() &&
+ (per_cpu(dynticks_progress_counter, cpu) & 0x1) == 0) {
+ /*
+* The following might seem like we could have a race
+* with NMI/SMIs. But this really isn't a problem.
+* Here we do a read/modify/write, and the race happens
+* when an NMI/SMI comes in after the read and before
+* the write. But NMI/SMIs will increment this counter
+* twice before returning, so the zero bit will not
+* be corrupted by the NMI/SMI which is the most important
+* part.
+*
+* The only thing is that we would bring back the counter
+* to a postion that it was in during the NMI/SMI.
+* But the zero bit would be set, so the rest of the
+* counter would again be ignored.
+*
+* On return from the IRQ, the counter may have the zero
+* bit be 0 and the counter the same as the return from
+* the NMI/SMI. If the state machine was so unlucky to
+* see that, it still doesn't matter, since all
+* RCU read-side critical sections on this CPU would
+* have already completed.
+*/
+ per_cpu(dynticks_progress_counter, cpu)++;
+ /*
+* The following memory barrier ensures that any
+* rcu_read_lock() primitives in the irq handler
+* are seen by other CPUs to follow the above
+* increment to dynticks_progress_counter. This is
+* required in order for other CPUs to correctly
+* determine when it is safe to advance the RCU
+* grace-period state machine.
+*/
+ smp_mb(); /* see above block comment. */
+ /*
+* Since we can't determine the dynamic tick mode from
+* the dynticks_progress_counter after this routine,
+* we use a second flag to acknowledge that we came
+* from an idle state with ticks stopped.
+*/
+ per_cpu(rcu_update_flag, cpu)++;
+ /*
+* If we take an NMI/SMI now, they will also increment
+* the rcu_update_flag, and will not update the
+* dynticks_progress_counter on
Re: PCI: Remove users of pci_enable_device_bars()
Linux Kernel Mailing List wrote:
Commit: 0948391641918b95d8d96c15089eb5ac156850b3
PCI: Remove users of pci_enable_device_bars()
This patch converts users of pci_enable_device_bars() to the new
pci_enable_device_{io,mem} interface.
The new API fits nicely, except maybe for the QLA case where a bit of
code re-organization might be a good idea but I prefer sticking to the
simple patch as I don't have hardware to test on.
I'll also need some feedback on the cs5520 change.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
--- a/drivers/ata/pata_cs5520.c
+++ b/drivers/ata/pata_cs5520.c
@@ -229,7 +229,7 @@ static int __devinit cs5520_init_one(struct pci_dev *pdev,
const struct pci_devi
return -ENOMEM;
/* Perform set up for DMA */
- if (pci_enable_device_bars(pdev, 1<<2)) {
+ if (pci_enable_device_io(pdev)) {
printk(KERN_ERR DRV_NAME ": unable to configure BAR2.\n");
return -ENODEV;
}
diff --git a/drivers/ide/pci/cs5520.c b/drivers/ide/pci/cs5520.c
index 6ec00b8..10adc49 100644
--- a/drivers/ide/pci/cs5520.c
+++ b/drivers/ide/pci/cs5520.c
@@ -156,8 +156,14 @@ static int __devinit cs5520_init_one(struct pci_dev *dev,
const struct pci_devic
ide_setup_pci_noise(dev, d);
/* We must not grab the entire device, it has 'ISA' space in its
- BARS too and we will freak out other bits of the kernel */
- if (pci_enable_device_bars(dev, 1<<2)) {
+* BARS too and we will freak out other bits of the kernel
+*
+* pci_enable_device_bars() is going away. I replaced it with
+* IO only enable for now but I'll need confirmation this is
+* allright for that device. If not, it will need some kind of
+* quirk. --BenH.
+*/
+ if (pci_enable_device_io(dev)) {
printk(KERN_WARNING "%s: Unable to enable 55x0.\n", d->name);
return -ENODEV;
}
So... did the feedback mentioned in the commit log ever appear? :)
Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] PCI subsystem: AMD SATA IDE mode quirk
Cai, Crane wrote:
From: Crane Cai <[EMAIL PROTECTED]>
PCI: modify SATA IDE mode quirk
When initialize and resume, SB600/700/800 need to set SATA mode
correctly.
Signed-off-by: Crane Cai <[EMAIL PROTECTED]>
--- a/drivers/pci/quirks.c 2007-09-24 14:16:32.0 -0400
+++ b/drivers/pci/quirks.c 2008-02-02 11:23:47.0 -0500
@@ -859,12 +859,13 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_IN
DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_82454NX,quirk_disable_pxb );
-static void __devinit quirk_sb600_sata(struct pci_dev *pdev)
+static void __devinit quirk_amd_ide_mode(struct pci_dev *pdev)
{
- /* set sb600 sata to ahci mode */
- if ((pdev->class >> 8) == PCI_CLASS_STORAGE_IDE) {
- u8 tmp;
+ /* set sb600/sb700/sb800 sata to ahci mode */
+ u8 tmp;
+ pci_read_config_byte(pdev, PCI_CLASS_DEVICE, );
+ if (tmp == 0x01) {
pci_read_config_byte(pdev, 0x40, );
pci_write_config_byte(pdev, 0x40, tmp|1);
pci_write_config_byte(pdev, 0x9, 1);
@@ -872,10 +873,13 @@ static void __devinit quirk_sb600_sata(s
pci_write_config_byte(pdev, 0x40, tmp);
pdev->class = PCI_CLASS_STORAGE_SATA_AHCI;
+ printk(KERN_INFO "PCI: set SATA to AHCI mode\n");
}
}
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATI,
PCI_DEVICE_ID_ATI_IXP600_SATA, quirk_sb600_sata);
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATI,
PCI_DEVICE_ID_ATI_IXP700_SATA, quirk_sb600_sata);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATI,
PCI_DEVICE_ID_ATI_IXP600_SATA, quirk_amd_ide_mode);
+DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_ATI,
PCI_DEVICE_ID_ATI_IXP600_SATA, quirk_amd_ide_mode);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATI,
PCI_DEVICE_ID_ATI_IXP700_SATA, quirk_amd_ide_mode);
+DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_ATI,
PCI_DEVICE_ID_ATI_IXP700_SATA, quirk_amd_ide_mode);
ACK
In the future, please also CC [EMAIL PROTECTED], as that's where
the ATA folks hang out :)
Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Integrating cpusets and cpu isolation [was Re: [CPUISOL] CPU isolation extensions]
Max wrote: > Here is the list of things of issues with sched_load_balance flag from CPU > isolation > perspective: A separate thread happened to start up on lkml.org, shortly after yours, that went into this in considerable detail. For example, the interaction of cpusets, sched_load_balance, sched_domains and real time scheduling is examined in some detail on this thread. Everyone participating on that thread learned something (we all came into it with less than a full picture of what's there.) I would encourage you to read it closely. For example, the scheduler code should not be trying to access per-cpuset attributes such as the sched_load_balance flag (you are correct that this would be difficult to do because of the locking; however by design, that is not to be done.) This thread begins at: scheduler scalability - cgroups, cpusets and load-balancing http://lkml.org/lkml/2008/1/29/60 Too bad we didn't think to include you in the CC list of that thread from the beginning. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 1.940.382.4214 -- 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] Fix fallout from PCI: PCIE ASPM support
Olof Johansson wrote: On Sat, Feb 02, 2008 at 05:06:42AM +, Linux Kernel Mailing List wrote: PCI: PCIE ASPM support This one broke almost all defconfigs on powerpc, since they enable CONFIG_EXPERIMENTAL and CONFIG_PCI, and this option defaults to y. Make it default to 'n' like most other options, and make it depend on ACPI. Take out the unneccessary default 'n' from the debug option as well. Is this actually ACPI-dependent? -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] PCI subsystem: AMD SATA IDE mode quirk
From: Crane Cai <[EMAIL PROTECTED]>
PCI: modify SATA IDE mode quirk
When initialize and resume, SB600/700/800 need to set SATA mode
correctly.
Signed-off-by: Crane Cai <[EMAIL PROTECTED]>
--- a/drivers/pci/quirks.c 2007-09-24 14:16:32.0 -0400
+++ b/drivers/pci/quirks.c 2008-02-02 11:23:47.0 -0500
@@ -859,12 +859,13 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_IN
DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_82454NX,quirk_disable_pxb );
-static void __devinit quirk_sb600_sata(struct pci_dev *pdev)
+static void __devinit quirk_amd_ide_mode(struct pci_dev *pdev)
{
- /* set sb600 sata to ahci mode */
- if ((pdev->class >> 8) == PCI_CLASS_STORAGE_IDE) {
- u8 tmp;
+ /* set sb600/sb700/sb800 sata to ahci mode */
+ u8 tmp;
+ pci_read_config_byte(pdev, PCI_CLASS_DEVICE, );
+ if (tmp == 0x01) {
pci_read_config_byte(pdev, 0x40, );
pci_write_config_byte(pdev, 0x40, tmp|1);
pci_write_config_byte(pdev, 0x9, 1);
@@ -872,10 +873,13 @@ static void __devinit quirk_sb600_sata(s
pci_write_config_byte(pdev, 0x40, tmp);
pdev->class = PCI_CLASS_STORAGE_SATA_AHCI;
+ printk(KERN_INFO "PCI: set SATA to AHCI mode\n");
}
}
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATI,
PCI_DEVICE_ID_ATI_IXP600_SATA, quirk_sb600_sata);
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATI,
PCI_DEVICE_ID_ATI_IXP700_SATA, quirk_sb600_sata);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATI,
PCI_DEVICE_ID_ATI_IXP600_SATA, quirk_amd_ide_mode);
+DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_ATI,
PCI_DEVICE_ID_ATI_IXP600_SATA, quirk_amd_ide_mode);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATI,
PCI_DEVICE_ID_ATI_IXP700_SATA, quirk_amd_ide_mode);
+DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_ATI,
PCI_DEVICE_ID_ATI_IXP700_SATA, quirk_amd_ide_mode);
/*
* Serverworks CSB5 IDE does not fully support native mode
--
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 patches] net driver updates #2
From: Jeff Garzik <[EMAIL PROTECTED]> Date: Fri, 1 Feb 2008 16:03:38 -0500 > Please pull from 'upstream2-davem' branch of This is now pulled and pushed back out to net-2.6 Thanks! -- 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 patches] net driver updates #2
From: Jeff Garzik <[EMAIL PROTECTED]> Date: Fri, 1 Feb 2008 16:03:38 -0500 > This submit is based on top of Linus's tree, since I'm not sure what's > going on with net-2.6.git and my previous (lost?) submission. > > These changes do /not/ include anything from the previous submission, > which was on top of net-2.6 -- but then you rebased, which probably made > everything more difficult. :) Can you respin the tree with that previus submission init? The best I'll be able to do is clone that entire tree in order to pick the patches out, and from here in Australia with a dodgy link I might not even finish before I have to get on a plane back home on Monday :-) I'll pull in this second set later tonight. -- 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] sis190: fix compile error section type conflict
Fix the following compile error:
drivers/net/sis190.c:329: error: sis190_pci_tbl causes a section type conflict
make[2]: *** [drivers/net/sis190.o] Error 1
make[1]: *** [drivers/net] Error 2
make: *** [drivers] Error 2
Signed-off-by: Li Zefan <[EMAIL PROTECTED]>
---
drivers/net/sis190.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/sis190.c b/drivers/net/sis190.c
index b570402..e48e4ad 100644
--- a/drivers/net/sis190.c
+++ b/drivers/net/sis190.c
@@ -326,7 +326,7 @@ static const struct {
{ "SiS 191 PCI Gigabit Ethernet adapter" },
};
-static struct pci_device_id sis190_pci_tbl[] __devinitdata = {
+static const struct pci_device_id sis190_pci_tbl[] __devinitdata = {
{ PCI_DEVICE(PCI_VENDOR_ID_SI, 0x0190), 0, 0, 0 },
{ PCI_DEVICE(PCI_VENDOR_ID_SI, 0x0191), 0, 0, 1 },
{ 0, },
--
1.5.4.rc3
--
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] Fix fallout from PCI: PCIE ASPM support
On Sat, Feb 02, 2008 at 05:06:42AM +, Linux Kernel Mailing List wrote: > PCI: PCIE ASPM support This one broke almost all defconfigs on powerpc, since they enable CONFIG_EXPERIMENTAL and CONFIG_PCI, and this option defaults to y. Make it default to 'n' like most other options, and make it depend on ACPI. Take out the unneccessary default 'n' from the debug option as well. Signed-off-by: Olof Johansson <[EMAIL PROTECTED]> diff --git a/drivers/pci/pcie/Kconfig b/drivers/pci/pcie/Kconfig index 60104cf..4393bb3 100644 --- a/drivers/pci/pcie/Kconfig +++ b/drivers/pci/pcie/Kconfig @@ -32,8 +32,7 @@ source "drivers/pci/pcie/aer/Kconfig" # config PCIEASPM bool "PCI Express ASPM support(Experimental)" - depends on PCI && EXPERIMENTAL - default y + depends on PCI && ACPI && EXPERIMENTAL help This enables PCI Express ASPM (Active State Power Management) and Clock Power Management. ASPM supports state L0/L0s/L1. @@ -42,7 +41,6 @@ config PCIEASPM config PCIEASPM_DEBUG bool "Debug PCI Express ASPM" depends on PCIEASPM - default n help This enables PCI Express ASPM debug support. It will add per-device interface to control ASPM. -- 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: Various Errors with recent GIT
On Friday 01 February 2008 23:42:47 Gabriel C wrote: > Daniel Hazelton wrote: > > Another problem is one I wasn't able to find any kind of trigger for, > > other than just running XChat. Every so often XChat would seem to freeze > > - but if run from the command line, switching to that terminal window and > > hitting "ctrl-c" would cause it to rapidly update and become responsive > > again. The freeze would happen at a random time interval that I couldn't > > figure out. > > I got that Xchat problem on i686 yesterday. > > I'm running 2.6.24-06481-gaa62999 right now with near 4h uptime and the > problem seems fixed. Hrm... I'll see about updating my local git tree and building a new kernel. With the x86 merger if it's fixed in 32bit it is probably also fixed in 64bit. The other problems are a bigger concern, though. I don't like seeing warnings in my logs - makes me worry about the long-term stability of my systems. And with the apparent problem in libata I'm not too sure I will be able to successfully boot into a new kernel - after all, the system just spins on trying and retrying the drive without any progress. (And it seems random, though it does appear that the trick to a successful boot is to get the hardware completely powered down - in other words, a completely cold boot) DRH > > DRH > > Gabriel -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. -- 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.24 compile error in drivers/net/b44.c
Add CCs: CC: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Li Zefan wrote: > drivers/net/b44.c: In function 'b44_remove_one': > drivers/net/b44.c:2231: error: implicit declaration of function > 'ssb_pcihost_set_power_state' > make[2]: *** [drivers/net/b44.o] Error 1 > make[1]: *** [drivers/net] Error 2 > > I think it is caused by: > > CONFIG_SSB_PCIHOST=n > CONFIG_B44=y > -- 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: Build error on PowerPC
On Sat, Feb 02, 2008 at 03:57:07AM +0100, Marcel Holtmann wrote: > Hi Olof, > > > Please define what kernel version and what config you're trying to > > build. > > it is the latest kernel for Linus' git and the config is kinda obviously > enabling the awacs.c driver. Anyway, the driver didn't make use of the > NVRAM call and thus removing that include is perfectly fine. Attached > patch fixes that issue. Sure, but it could have been dependent on other options around it (i.e. nvram-related ones). It's just good habit to include the info, that's all. > > Also, please cc [EMAIL PROTECTED] for powerpc issues. > > To be quite honest, it is highly likely that I forget the next time. > Good that you read LKML :) Well, sometimes I do, sometimes others do. It just might take longer for someone to stuble over it. :-) -Olof -- 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: Various Errors with recent GIT
Daniel Hazelton wrote: > > Another problem is one I wasn't able to find any kind of trigger for, other > than just running XChat. Every so often XChat would seem to freeze - but if > run from the command line, switching to that terminal window and > hitting "ctrl-c" would cause it to rapidly update and become responsive > again. > The freeze would happen at a random time interval that I couldn't figure out. > I got that Xchat problem on i686 yesterday. I'm running 2.6.24-06481-gaa62999 right now with near 4h uptime and the problem seems fixed. > DRH > Gabriel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ANNOUNCE] GIT 1.5.4
The latest feature release GIT 1.5.4 is available at the usual
places:
http://www.kernel.org/pub/software/scm/git/
git-1.5.4.tar.{gz,bz2}(tarball)
git-htmldocs-1.5.4.tar.{gz,bz2} (preformatted docs)
git-manpages-1.5.4.tar.{gz,bz2} (preformatted docs)
RPMS/$arch/git-*-1.5.4-1.$arch.rpm(RPM)
It has been an unusually long cycle. 5 months since the last
feature release 1.5.3 was really a bit too long.
But I hope it was worth waiting for. Thanks everybody for
working hard to improve it.
Changes since v1.5.3:
1595 non-merge commits
165 contributors
684 files changed, 70435 insertions, 28984 deletions
GIT v1.5.4 Release Notes
Removal
---
* "git svnimport" was removed in favor of "git svn". It is still there
in the source tree (contrib/examples) but unsupported.
* As git-commit and git-status have been rewritten, "git runstatus"
helper script lost all its users and has been removed.
Temporarily disabled
* "git http-push" is known not to work well with cURL library older
than 7.16, and we had reports of repository corruption. It is
disabled on such platforms for now. Unfortunately, 1.5.3.8 shares
the same issue. In other words, this does not mean you will be
fine if you stick to an older git release. For now, please do not
use http-push from older git with cURL older than 7.16 if you
value your data. A proper fix will hopefully materialize in
later versions.
Deprecation notices
---
* From v1.6.0, git will by default install dashed form of commands
(e.g. "git-commit") outside of users' normal $PATH, and will install
only selected commands ("git" itself, and "gitk") in $PATH. This
implies:
- Using dashed forms of git commands (e.g. "git-commit") from the
command line has been informally deprecated since early 2006, but
now it officially is, and will be removed in the future. Use
dash-less forms (e.g. "git commit") instead.
- Using dashed forms from your scripts, without first prepending the
return value from "git --exec-path" to the scripts' PATH, has been
informally deprecated since early 2006, but now it officially is.
- Use of dashed forms with "PATH=$(git --exec-path):$PATH; export
PATH" early in your script is not deprecated with this change.
Users are strongly encouraged to adjust their habits and scripts now
to prepare for this change.
* The post-receive hook was introduced in March 2007 to supersede
the post-update hook, primarily to overcome the command line length
limitation of the latter. Use of post-update hook will be deprecated
in future versions of git, starting from v1.6.0.
* "git lost-found" was deprecated in favor of "git fsck"'s --lost-found
option, and will be removed in the future.
* "git peek-remote" is deprecated, as "git ls-remote" was written in C
and works for all transports; "git peek-remote" will be removed in
the future.
* "git repo-config" which was an old name for "git config" command
has been supported without being advertised for a long time. The
next feature release will remove it.
* From v1.6.0, the repack.usedeltabaseoffset config option will default
to true, which will give denser packfiles (i.e. more efficient storage).
The downside is that git older than version 1.4.4 will not be able
to directly use a repository packed using this setting.
* From v1.6.0, the pack.indexversion config option will default to 2,
which is slightly more efficient, and makes repacking more immune to
data corruptions. Git older than version 1.5.2 may revert to version 1
of the pack index with a manual "git index-pack" to be able to directly
access corresponding pack files.
Updates since v1.5.3
* Comes with much improved gitk, with i18n.
* Comes with git-gui 0.9.2 with i18n.
* gitk is now merged as a subdirectory of git.git project, in
preparation for its i18n.
* progress displays from many commands are a lot nicer to the eye.
Transfer commands show throughput data.
* many commands that pay attention to per-directory .gitignore now do
so lazily, which makes the usual case go much faster.
* Output processing for '--pretty=format:' has been
optimized.
* Rename detection of diff family while detecting exact matches has
been greatly optimized.
* Rename detection of diff family tries to make more natural looking
pairing. Earlier, if multiple identical rename sources were
found in the preimage, the source used was picked pretty much at random.
* Value "true" for color.diff and color.status configuration used to
mean "always" (even when the output is not going to a terminal).
This has been corrected to mean the same thing as "auto".
* "git diff" Porcelain now respects
Re: [PATCH 0/10] generic thermal management
series applied to acpi-test. thanks, -Len On Thursday 17 January 2008 02:50, Zhang Rui wrote: > Hi, all, > > This patch series introduces a new generic thermal sysfs driver > which provides a set of interfaces for thermal zone devices (sensors) > and thermal cooling devices (fan, processor...) to register with the > thermal management solution and to be a part of it. > > And it also includes the implementation for ACPI thermal zone. > Standard sysfs I/F should be available for all ACPI thermal zones > with this patch series applied. > > Patch 01 creates the new generic thermal sysfs driver. >It defines two kinds of devices, thermal zone device and >thermal cooling device. >A thermal zone device usually contains a sensor to monitor the >temperature, several trip points and a bunch of cooling devices >associated with them. >A thermal cooling device is a device that can be throttled >to cool the system. >The generic thermal sysfs driver creates the standard sysfs I/F >for any registered thermal zone and thermal cooling device. >And binds the cooling devices to thermal zones if possible. > > Patch 02 registers ACPI thermal zone as thermal zone device. > > Patch 03 is a fix of violations of ACPI spec in ACPI thermal driver. > > Patch 04 registers ACPI Fan as thermal cooling device. > > Patch 05 registers ACPI Processor as thermal cooling device. > > Patch 06 registers ACPI Video LCD as thermal cooling device. >Because throttling the backlight of LCD can cool the system as well. > > Patch 09 creates a new platform specific driver, intel_menlow. >which is the thermal enhancement driver for intel menlow platform. >It programs the sensor of each thermal zone and registers the >intel memory controller (hardware id INT0002) as thermal cooling > device. > > Patch 07 08 and 10 are minor fixes, please refer to the changelog of each > patch. > > I've tested them and they work well on several systems. > I'd like to get some feedbacks from the list. Any comments are appreciated. :) > > Thanks, > Rui > > > -- > 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/ > -- 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: kernel panic on 2.6.24/iTCO_wdt not rebooting machine
I think i found issue, but not able to understand how to fix it.
I did small patch to make sure, that code able to change TCO_EN(bit 13) to 0.
It cannot change it, because TCO_LOCK bit is set. I
For example i did patch to see that:
--- /usr/src/linux-2.6.24/drivers/watchdog/iTCO_wdt.c 2008-01-25
00:58:37.0 +0200
+++ /WORK/globalosii/linux-embedded/drivers/watchdog/iTCO_wdt.c 2008-02-02
05:11:46.0 +0200
@@ -659,8 +659,13 @@
goto out;
}
val32 = inl(SMI_EN);
+ printk(KERN_INFO PFX "TCO_EN was %04lX\n", val32);
val32 &= 0xdfff;/* Turn off SMI clearing watchdog */
+ printk(KERN_INFO PFX "TCO_EN will try to set %04lX\n", val32);
outl(val32, SMI_EN);
+ val32 = inl(SMI_EN);
+ printk(KERN_INFO PFX "TCO_EN after set %04lX\n", val32);
+
release_region(SMI_EN, 4);
/* The TCO I/O registers reside in a 32-byte range pointed to by the
TCOBASE value */
and i got in dmesg
[ 589.913354] iTCO_wdt: TCO_EN was 203B
[ 589.913356] iTCO_wdt: TCO_EN will try to set 003B
[ 589.913360] iTCO_wdt: TCO_EN after set 203B
So this function will not work in some conditions, for example in my
situation. It is a bit dangerous, because as i understand function is
supposed to disable unexpected reboots during watchdog setup, so maybe must
be added check for TCO_LOCK bit, or just to check if value really has been
changed.
Also i dont understand code:
TCO1_STS for example, to clear bit's needs to write 1 to each one (it is not
WRITE, it is WRITECLEAR almost all of them, except Bit 0 on TCO1_STS which is
Read Only) (i read that in ICH9 datasheet). So outb(0, TCO1_STS), just will
not do anything.
TCO2_STS, bit 0 is responsible Intruder Detect on ICH8 and ICH9!!! Probably
it is not good to reset this bit.
Code:
/* Clear out the (probably old) status */
outb(0, TCO1_STS);
outb(3, TCO2_STS);
But that all small issues, and doesn't explain why it doesn't work. I did
small patch, and instead of resetting timer, i am getting current value of
timer.
Patch looks like this:
@@ -483,6 +484,7 @@
static ssize_t iTCO_wdt_write (struct file *file, const char __user *data,
size_t len, loff_t * ppos)
{
+ unsigned int val16;
/* See if we got the magic character 'V' and reload the timer */
if (len) {
if (!nowayout) {
@@ -503,7 +505,14 @@
}
/* someone wrote to us, we should reload the timer */
- iTCO_wdt_keepalive();
+ //iTCO_wdt_keepalive();
+ spin_lock(_wdt_private.io_lock);
+ val16 = inw(TCO_RLD);
+ val16 &= 0x3ff;
+ spin_unlock(_wdt_private.io_lock);
+
+ printk(KERN_INFO PFX "Remaining time %d\n", (val16 * 6) / 10);
+
[ 2505.979453] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.02 (26-Jul-2007)
[ 2505.980073] iTCO_wdt: TCO_EN was 203B
[ 2505.980076] iTCO_wdt: TCO_EN will try to set 003B
[ 2505.980083] iTCO_wdt: TCO_EN after set 203B
[ 2505.980085] iTCO_wdt: Found a ICH9R TCO device (Version=2, TCOBASE=0x0460)
[ 2505.980088] iTCO_wdt: TCO1_STS was
[ 2505.980090] iTCO_wdt: TCO2_STS was
[ 2505.980664] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
[ 2515.908192] iTCO_wdt: Remaining time 30
[ 2516.408459] iTCO_wdt: Remaining time 29
[ 2516.908687] iTCO_wdt: Remaining time 28
[ 2517.408917] iTCO_wdt: Remaining time 28
[ 2517.909144] iTCO_wdt: Remaining time 28
[ 2518.409373] iTCO_wdt: Remaining time 27
[ 2518.909601] iTCO_wdt: Remaining time 27
[ 2519.409829] iTCO_wdt: Remaining time 26
[ 2519.910057] iTCO_wdt: Remaining time 25
[ 2520.410287] iTCO_wdt: Remaining time 25
[ 2520.910515] iTCO_wdt: Remaining time 25
[ 2521.410745] iTCO_wdt: Remaining time 24
[ 2521.910972] iTCO_wdt: Remaining time 24
[ 2522.411201] iTCO_wdt: Remaining time 23
[ 2522.911429] iTCO_wdt: Remaining time 22
[ 2523.411658] iTCO_wdt: Remaining time 22
[ 2523.911886] iTCO_wdt: Remaining time 21
[ 2524.412115] iTCO_wdt: Remaining time 21
[ 2524.912343] iTCO_wdt: Remaining time 21
[ 2525.412573] iTCO_wdt: Remaining time 20
[ 2525.912801] iTCO_wdt: Remaining time 19
[ 2526.413030] iTCO_wdt: Remaining time 19
[ 2526.913258] iTCO_wdt: Remaining time 18
[ 2527.413487] iTCO_wdt: Remaining time 18
[ 2527.913715] iTCO_wdt: Remaining time 18
[ 2528.413944] iTCO_wdt: Remaining time 17
[ 2528.914172] iTCO_wdt: Remaining time 16
[ 2529.414401] iTCO_wdt: Remaining time 16
[ 2529.914629] iTCO_wdt: Remaining time 15
[ 2530.414859] iTCO_wdt: Remaining time 15
[ 2530.915087] iTCO_wdt: Remaining time 14
[ 2531.415315] iTCO_wdt: Remaining time 14
[ 2531.915544] iTCO_wdt: Remaining time 13
[ 2532.415773] iTCO_wdt: Remaining time 13
[ 2532.916001] iTCO_wdt: Remaining time 12
[ 2533.416230] iTCO_wdt: Remaining time 12
[ 2533.916459] iTCO_wdt: Remaining time 11
[ 2534.416688] iTCO_wdt: Remaining time 10
[
Re: Are Section mismatches out of control?
On Fri, Feb 01, 2008 at 10:51:14PM +0100, Jan Engelhardt wrote: > > On Feb 1 2008 12:10, Andi Kleen wrote: > >On Friday 01 February 2008 11:47:18 Sam Ravnborg wrote: > >> James said in a related posting that the Section mismatch > >> warnings were getting out of control. > > > >My question is: where are crashes? If the sections were > >really in such bad shape and since we poison (and sometimes > >even unmap) init after boot we should in theory see a lot > >of oops reports from this if there were really accesses to > >them after boot. > > > >Where are they? > > Perhaps still in RAM? Explicitly zero the area after unmapping, > maybe something happens. This is already doing (but not with zero). With DEBUG_RODATA it is even unmapped. -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: What's the status of x2APIC support in Linux kernel?
> Section 5 and section 9.5 describe 'I/OxAPIC'. I'm not sure if it is > already supported by Linux, I guess it is not. I'm not sure what the point of your questions is. Do you want to do something concrete or are you just interested in random buzzwords? Anyways as far as I know Linux supports the IO APICs implemented in all x86 chipsets fully. That is it doesn't use every possible feature they have, but I'm not aware of any particular limitation caused by Linux not supporting some IO APIC feature. The reason for the local x/APIC was that the original non x APIC did not support more than 8 logical CPUs being active in the system. Presumably IO xAPIC refers to the IO APIC without this limitation too. -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/
[PATCH 1/2] x86: add cpu init function defintions to cpu.h
cpu.h was already included everywhere needed.
Fixes following sparse warnings:
arch/x86/kernel/cpu/amd.c:343:12: warning: symbol 'amd_init_cpu' was not
declared. Should it be static?
arch/x86/kernel/cpu/cyrix.c:444:12: warning: symbol 'cyrix_init_cpu' was not
declared. Should it be static?
arch/x86/kernel/cpu/cyrix.c:456:12: warning: symbol 'nsc_init_cpu' was not
declared. Should it be static?
arch/x86/kernel/cpu/centaur.c:467:12: warning: symbol 'centaur_init_cpu' was
not declared. Should it be static?
arch/x86/kernel/cpu/transmeta.c:112:12: warning: symbol 'transmeta_init_cpu'
was not declared. Should it be static?
arch/x86/kernel/cpu/intel.c:296:12: warning: symbol 'intel_cpu_init' was not
declared. Should it be static?
arch/x86/kernel/cpu/nexgen.c:56:12: warning: symbol 'nexgen_init_cpu' was not
declared. Should it be static?
arch/x86/kernel/cpu/umc.c:22:12: warning: symbol 'umc_init_cpu' was not
declared. Should it be static?
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
arch/x86/kernel/cpu/common.c | 10 --
arch/x86/kernel/cpu/cpu.h|9 +
2 files changed, 9 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index b7b2142..d9313d9 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -623,16 +623,6 @@ cpumask_t cpu_initialized __cpuinitdata = CPU_MASK_NONE;
* They will insert themselves into the cpu_devs structure.
* Then, when cpu_init() is called, we can just iterate over that array.
*/
-
-extern int intel_cpu_init(void);
-extern int cyrix_init_cpu(void);
-extern int nsc_init_cpu(void);
-extern int amd_init_cpu(void);
-extern int centaur_init_cpu(void);
-extern int transmeta_init_cpu(void);
-extern int nexgen_init_cpu(void);
-extern int umc_init_cpu(void);
-
void __init early_cpu_init(void)
{
intel_cpu_init();
diff --git a/arch/x86/kernel/cpu/cpu.h b/arch/x86/kernel/cpu/cpu.h
index ad6527a..e0b38c3 100644
--- a/arch/x86/kernel/cpu/cpu.h
+++ b/arch/x86/kernel/cpu/cpu.h
@@ -27,3 +27,12 @@ extern void display_cacheinfo(struct cpuinfo_x86 *c);
extern void early_init_intel(struct cpuinfo_x86 *c);
extern void early_init_amd(struct cpuinfo_x86 *c);
+/* Specific CPU type init functions */
+int intel_cpu_init(void);
+int amd_init_cpu(void);
+int cyrix_init_cpu(void);
+int nsc_init_cpu(void);
+int centaur_init_cpu(void);
+int transmeta_init_cpu(void);
+int nexgen_init_cpu(void);
+int umc_init_cpu(void);
--
1.5.4.rc4.1142.gf5a97
--
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/2] x86: add cpu mtrr init function definitions to mtrr.h
mtrr.h was included everywhere needed. Fixes the following sparse
warnings. Also, the return types in the extern definitions were
incorrect.
arch/x86/kernel/cpu/mtrr/amd.c:113:12: warning: symbol 'amd_init_mtrr' was not
declared. Should it be static?
arch/x86/kernel/cpu/mtrr/cyrix.c:268:12: warning: symbol 'cyrix_init_mtrr' was
not declared. Should it be static?
arch/x86/kernel/cpu/mtrr/centaur.c:218:12: warning: symbol 'centaur_init_mtrr'
was not declared. Should it be static?
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
arch/x86/kernel/cpu/mtrr/main.c |4
arch/x86/kernel/cpu/mtrr/mtrr.h |4
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c
index 822d8f9..1e27b69 100644
--- a/arch/x86/kernel/cpu/mtrr/main.c
+++ b/arch/x86/kernel/cpu/mtrr/main.c
@@ -554,10 +554,6 @@ EXPORT_SYMBOL(mtrr_del);
* These should be called implicitly, but we can't yet until all the initcall
* stuff is done...
*/
-extern void amd_init_mtrr(void);
-extern void cyrix_init_mtrr(void);
-extern void centaur_init_mtrr(void);
-
static void __init init_ifs(void)
{
#ifndef CONFIG_X86_64
diff --git a/arch/x86/kernel/cpu/mtrr/mtrr.h b/arch/x86/kernel/cpu/mtrr/mtrr.h
index fb74a2c..2cc77eb 100644
--- a/arch/x86/kernel/cpu/mtrr/mtrr.h
+++ b/arch/x86/kernel/cpu/mtrr/mtrr.h
@@ -97,3 +97,7 @@ void mtrr_state_warn(void);
const char *mtrr_attrib_to_str(int x);
void mtrr_wrmsr(unsigned, unsigned, unsigned);
+/* CPU specific mtrr init functions */
+int amd_init_mtrr(void);
+int cyrix_init_mtrr(void);
+int centaur_init_mtrr(void);
--
1.5.4.rc4.1142.gf5a97
--
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/
Various Errors with recent GIT
In a recent (haven't tested the latest git, but I have tested one pulled down
1/29 - I think it's 24e1c13) I see the following errors when the AES crypto
module is loaded:
[ 27.786935] aes_x86_64: Unknown symbol crypto_it_tab
[ 27.786984] aes_x86_64: Unknown symbol crypto_aes_set_key
[ 27.787141] aes_x86_64: Unknown symbol crypto_fl_tab
[ 27.787187] aes_x86_64: Unknown symbol crypto_il_tab
[ 27.787232] aes_x86_64: Unknown symbol crypto_ft_tab
[ 27.625672] aes_x86_64: Unknown symbol crypto_it_tab
[ 27.625721] aes_x86_64: Unknown symbol crypto_aes_set_key
[ 27.625793] aes_x86_64: Unknown symbol crypto_fl_tab
[ 27.625838] aes_x86_64: Unknown symbol crypto_il_tab
[ 27.625883] aes_x86_64: Unknown symbol crypto_ft_tab
Another problem is one I wasn't able to find any kind of trigger for, other
than just running XChat. Every so often XChat would seem to freeze - but if
run from the command line, switching to that terminal window and
hitting "ctrl-c" would cause it to rapidly update and become responsive again.
The freeze would happen at a random time interval that I couldn't figure out.
The last two problems have different symptoms. With one the kernel would
sometimes spin unable to get a non-error return from the CD/DVD burner drive
in my laptop - it'd start at UDMA133 and rapidly devolve down to PIO0 and then
spin trying and retrying PIO0. The only part of the message I remember exactly
is { DRDY } on 90% of the messages once it switched to trying only the PIO
modes, although I have seen similar messages about this kind of error on the
list recently.
And the final error is one that I've been seeing since 2.6.24-rc6 and reported
as a secondary error in 2.6.24-rc7. The mac80211 system hits a warning when my
system initially brings my Wifi connection (iwlwifi is the driver) online. The
problem points to the following line:
WARN_ON_ONCE(((unsigned long)(skb->data + hdrlen)) & 3);
so it looks as though the initial packet from the device coming online and/or
registering with the network is corrupt. This does not happen when I boot
2.6.22 and load the pre-merge iwlwifi/mac80211 code and I do not have the time
or resources to bisect this problem at the moment or I would be trying to find
the cause. (This isn't a hardware problem like I initially thought, since the
code states that it's up to the driver to format the packet correctly - I
haven't been able to locate any changes to the iwlwifi code post import, (in
the recieve path that would have caused this, but the search was non
exhaustive) so I'm wondering if this might be a pre-existing bug...)
[ 49.960849] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[ 50.185438] WARNING: at net/mac80211/rx.c:1486 __ieee80211_rx()
[ 50.185446] Pid: 0, comm: swapper Not tainted 2.6.24-rc7-git #1
[ 50.185450]
[ 50.185451] Call Trace:
[ 50.185454][] :mac80211:__ieee80211_rx+0xc99/0xd60
[ 50.185509] [] _spin_unlock_irqrestore+0x16/0x40
[ 50.185526] [] :iwl3945:iwl_rx_queue_restock+0xca/0x170
[ 50.185533] [] _spin_unlock_irqrestore+0x16/0x40
[ 50.18] []
:mac80211:ieee80211_tasklet_handler+0xb8/0x120
[ 50.185570] [] tasklet_action+0x51/0xc0
[ 50.185576] [] _spin_unlock+0x14/0x40
[ 50.185583] [] __do_softirq+0x64/0xe0
[ 50.185592] [] call_softirq+0x1c/0x30
[ 50.185599] [] do_softirq+0x3d/0x90
[ 50.185605] [] irq_exit+0x88/0xa0
[ 50.185611] [] do_IRQ+0xc5/0x1b0
[ 50.185619] [] ret_from_intr+0x0/0xa
[ 50.185628][]
:processor:acpi_idle_enter_bm+0x273/0x2e3
[ 50.185647] [] :processor:acpi_idle_enter_bm+0x269/0x2e3
[ 50.185652] [] menu_select+0xad/0xe0
[ 50.185657] [] cpuidle_idle_call+0x95/0xd0
[ 50.185661] [] cpuidle_idle_call+0x0/0xd0
[ 50.185665] [] cpu_idle+0x73/0xe0
[ 50.185670] [] start_secondary+0x315/0x410
[ 50.185683]
(That's the complete warning from my 2.6.24-rc7 kernel... The following is the
complete warning from the 24e1c13 build)
[ 182.298665] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[ 182.359208] ppdev: user-space parallel port driver
[ 182.623816] [ cut here ]
[ 182.623826] WARNING: at net/mac80211/rx.c:1704
__ieee80211_rx_handle_packet+0x8e7/0x980 [mac80211]()
[ 182.623831] Modules linked in: ppdev acpi_cpufreq cpufreq_ondemand
cpufreq_powersave cpufreq_conservative cpufreq_userspace cpufreq_stats freq_t
able dock container sbs sbshc dm_crypt dm_mod ipv6 sbp2 parport_pc lp parport
arc4 ecb crypto_blkcipher iwl3945 mac80211 cfg80211 ata_generic snd_hda_intel
snd_hwdep snd_pcm_oss s
nd_pcm snd_page_alloc snd_mixer_oss snd_seq_dummy snd_seq_oss snd_seq_midi
snd_rawmidi snd_seq_midi_event sdhci serio_raw psmouse pcspkr iTCO_wdt
iTCO_vendor_support ricoh_mmc mmc
_core pata_acpi snd_seq snd_timer snd_seq_device video snd soundcore ac shpchp
pci_hotplug button battery intel_agp evdev ext3 jbd mbcache sg sd_mod ohci1394
ieee1394 ata_piix ahc
i tg3 libata scsi_mod ehci_hcd uhci_hcd usbcore
Re: [PATCH] Rationalise ACPI backlight implementation
On Monday 28 January 2008 00:10, Andrew Morton wrote: > On Mon, 28 Jan 2008 01:25:50 + Matthew Garrett <[EMAIL PROTECTED]> wrote: > > > On Sat, Jan 26, 2008 at 10:00:45PM -0800, Andrew Morton wrote: > > > - Create a new /sys node with a new name which has the new semantics. > > > > The semantics are the same as they always have been - values between 0 > > and max_brightness are valid values. If you've made assumptions about > > what max_brightness is, then that's a bug in the userspace application > > rather than a change in the semantics of the interface. > > > > WTH? My (utterly comedic chase-crap-around-the-tree) brightness script > was: > > ( > 0 sh -c "echo $1 > /proc/acpi/sony/brightness" > 0 sh -c "echo $1 > /proc/acpi/sony/brightness_default" > 0 sh -c "echo $1 > /sys/class/backlight/sony/brightness" > 0 sh -c "echo $1 > /sys/class/backlight/thinkpad_screen/brightness" > ) 2>/dev/null > > And yes, I had an rc.local command which assumed that 7 (later 8) is max > brightness. > > You cannot seriously tell me that if we are to change this range from 0-8 > up to 0-100 then this is not a backwards-incompatible change in > semantics. > > My /sys/class/backlight/ directory is presently empty. Rather than trying > to find out why, I think I'll just collapse in laughter. > > Guys, sort it out, please. I think that Matthew got it right. The generic API is unchanged, brightness goes from 0 to max_brighness. What he did was repair systems that use the acpi video driver (which none of akpm's examples above do) such that the generic API works for that case the same as it does with all other video drivers. Andrew, You might check if CONFIG_ACPI_VIDEO=m is set and you can load the "video" module. While the sony may be non-standard and not load, your thinkpad may work. 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] Rationalise ACPI backlight implementation
Applied.
thanks,
-Len
On Tuesday 25 December 2007 21:03, Matthew Garrett wrote:
> The sysfs backlight class provides no mechanism for querying the
> acceptable brightness for a backlight. The ACPI spec states that values
> are only valid if they are reported as available by the firmware. Since
> we can't provide that information to userspace, instead collapse the
> range to the number of actual values that can be set.
>
> Signed-off-by: Matthew Garrett <[EMAIL PROTECTED]>
>
> ---
>
> diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
> index 521645e..12b2adb 100644
> --- a/drivers/acpi/video.c
> +++ b/drivers/acpi/video.c
> @@ -296,18 +296,26 @@ static int acpi_video_device_set_state(struct
> acpi_video_device *device, int sta
> static int acpi_video_get_brightness(struct backlight_device *bd)
> {
> unsigned long cur_level;
> + int i;
> struct acpi_video_device *vd =
> (struct acpi_video_device *)bl_get_data(bd);
> acpi_video_device_lcd_get_level_current(vd, _level);
> - return (int) cur_level;
> + for (i=2; ibrightness->count; i++) {
> + if (vd->brightness->levels[i] == cur_level)
> + /* The first two entries are special - see page 575
> +of the ACPI spec 3.0 */
> + return i-2;
> + }
> + return 0;
> }
>
> static int acpi_video_set_brightness(struct backlight_device *bd)
> {
> - int request_level = bd->props.brightness;
> + int request_level = bd->props.brightness+2;
> struct acpi_video_device *vd =
> (struct acpi_video_device *)bl_get_data(bd);
> - acpi_video_device_lcd_set_level(vd, request_level);
> + acpi_video_device_lcd_set_level(vd,
> + vd->brightness->levels[request_level]);
> return 0;
> }
>
> @@ -656,7 +664,6 @@ static void acpi_video_device_find_cap(struct
> acpi_video_device *device)
> kfree(obj);
>
> if (device->cap._BCL && device->cap._BCM && device->cap._BQC &&
> max_level > 0){
> - unsigned long tmp;
> static int count = 0;
> char *name;
> name = kzalloc(MAX_NAME_LEN, GFP_KERNEL);
> @@ -664,11 +671,10 @@ static void acpi_video_device_find_cap(struct
> acpi_video_device *device)
> return;
>
> sprintf(name, "acpi_video%d", count++);
> - acpi_video_device_lcd_get_level_current(device, );
> device->backlight = backlight_device_register(name,
> NULL, device, _backlight_ops);
> - device->backlight->props.max_brightness = max_level;
> - device->backlight->props.brightness = (int)tmp;
> + device->backlight->props.max_brightness =
> device->brightness->count-3;
> + device->backlight->props.brightness =
> acpi_video_get_brightness(device->backlight);
> backlight_update_status(device->backlight);
>
> kfree(name);
>
--
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.22.y] {01**/17} - do_anonymous_page-race - series for stable kernel
On Sat, 2 Feb 2008, Oliver Pinter (Pint?r Oliv?r) wrote: > > NOT IN MAINLINE > > Linus it's go or drop it? I have no idea, because you've used some horrible and stupid attachment format that I can't even read. Patches should be inline so that people can see them and comment on them. 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: [2.6.22.y] {17**/17} - nopage-range-fix.patch (CVE-2008-0007) - series for stable kernel #2
On Sat, 2 Feb 2008, Oliver Pinter (Pint?r Oliv?r) wrote: > > Linus it's go or drop it? I should merge it, I was just a bit bummed that I think the right solution is to switch the bitfield meaning around. But the patch is certainly not wrong. 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: SiI 3512 Serial ATA Controller - kernel 2.6.23
Dan Nica wrote: > those errors apears only when I use the harddrives with > the sii controller and only when I make operation between > the onboard sata and the sii sata controller, operations between > ide and drives that are on sii works perfectly... Hmm.. Your drive is raising ABRT on writes. It can point to a number of things including media access error and transmission error. It's basically a catch-all bit. In the log, libata EH slowed down the device to udma33 without any effect so I don't think it's transmission error caused by cable misdetection or miswiring (mid connector connected to the only drive on the cable). What does 'smartctl -a' say about the drive? -- tejun -- 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: Build error on PowerPC
Hi Olof, > Please define what kernel version and what config you're trying to > build. it is the latest kernel for Linus' git and the config is kinda obviously enabling the awacs.c driver. Anyway, the driver didn't make use of the NVRAM call and thus removing that include is perfectly fine. Attached patch fixes that issue. > Also, please cc [EMAIL PROTECTED] for powerpc issues. To be quite honest, it is highly likely that I forget the next time. Good that you read LKML :) Regards Marcel [PATCH] Fix compilation of sound/ppc/awacs.c Including of asm/nvram.h in the awacs.c driver is not needed and it fixes the following compilation error: CC [M] sound/ppc/awacs.o In file included from sound/ppc/awacs.c:25: include/asm/nvram.h:62: error: field ‘partition’ has incomplete type make[2]: *** [sound/ppc/awacs.o] Error 1 make[1]: *** [sound/ppc] Error 2 make: *** [sound] Error 2 Signed-off-by: Marcel Holtmann <[EMAIL PROTECTED]> --- commit 5613f9f9aa321cf59915137cc611aea9fd95ed75 tree 3c55137ccc3d16e49b757a0e6135f32fb2086ae3 parent aa6299926950c8dfe2fea638276cad6def092bc9 author Marcel Holtmann <[EMAIL PROTECTED]> Sat, 02 Feb 2008 03:52:23 +0100 committer Marcel Holtmann <[EMAIL PROTECTED]> Sat, 02 Feb 2008 03:52:23 +0100 sound/ppc/awacs.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/sound/ppc/awacs.c b/sound/ppc/awacs.c index 8441e78..149c4aa 100644 --- a/sound/ppc/awacs.c +++ b/sound/ppc/awacs.c @@ -21,7 +21,6 @@ #include -#include #include #include #include
Re: Oops in evdev_disconnect for kernel 2.6.23.12
Berthold Cogel-2 wrote: > > Those two patches solved the oops. I can remove and reconnnect the > tablet without problems. > Dear Berthold, I saw that you have problems with Ooops in evdev_disconnect. My problem is similar I have a USB KVM switch and if I switch beetween computers U got a Oops in evdev_disconnect (the first one is Kernel 2.6.23.12 and the second Kernel 2.6.24, both has this problem). My question is, can you tell me which two patches you have applied to solve the problem? I didn't found the right thing? Thank you very much for your help. Regards Martin Bauer fyi: Feb 2 03:00:46 mrb usb 5-2.4: USB disconnect, address 4 Feb 2 03:00:46 mrb usb 5-2.4.1: USB disconnect, address 5 Feb 2 03:00:46 mrb usb 5-2.4.3: USB disconnect, address 6 Feb 2 03:00:46 mrb Unable to handle kernel paging request at 00100100 RIP: Feb 2 03:00:46 mrb [] evdev_disconnect+0x7e/0xb8 Feb 2 03:00:46 mrb PGD 72d22067 PUD 75e99067 PMD 0 Feb 2 03:00:46 mrb Oops: [1] PREEMPT SMP Feb 2 03:00:46 mrb CPU 0 Feb 2 03:00:46 mrb Modules linked in: vmnet(P) parport_pc parport vmmon(P) capi capifs nfsd exportfs pppoe pppox ppp_generic slhc bridge tun ipt_LOG xt_TCPMSS ipt_REJECT xt_state iptable_filter ipt_MASQUERADE xt_tcpudp iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nfnetlink ip_tables x_tables snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss cpufreq_ondemand acpi_cpufreq freq_table thermal snd_hda_intel processor nvidia(P) snd_pcm snd_timer b1pci b1dma snd b1 arcmsr kernelcapi soundcore sg button snd_page_alloc 8250_pnp i2c_i801 joydev pcspkr intel_agp nfs nfs_acl lockd sunrpc jfs scsi_wait_scan sbp2 ohci1394 ieee1394 sl811_hcd usbhid ff_memless ohci_hcd uhci_hcd usb_storage libusual ehci_hcd usbcore Feb 2 03:00:46 mrb Pid: 1001, comm: khubd Tainted: P 2.6.23-gentoo-r3 #1 Feb 2 03:00:46 mrb RIP: 0010:[] [] evdev_disconnect+0x7e/0xb8 Feb 2 03:00:46 mrb RSP: 0018:81007d3e3c60 EFLAGS: 00010216 Feb 2 03:00:46 mrb RAX: RBX: 000ffae8 RCX: Feb 2 03:00:46 mrb RDX: RSI: 81007e0be080 RDI: 1000 Feb 2 03:00:46 mrb RBP: 81007cc3a000 R08: 81007d3e2000 R09: 810001011da8 Feb 2 03:00:46 mrb R10: R11: 810072c25b98 R12: 81007cc3a088 Feb 2 03:00:46 mrb R13: 81007cc3a098 R14: 81007cc50470 R15: 81007cc5 Feb 2 03:00:46 mrb FS: () GS:80687000() knlGS: Feb 2 03:00:46 mrb CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b Feb 2 03:00:46 mrb CR2: 00100100 CR3: 73359000 CR4: 06e0 Feb 2 03:00:46 mrb DR0: DR1: DR2: Feb 2 03:00:46 mrb DR3: DR6: 0ff0 DR7: 0400 Feb 2 03:00:46 mrb Process khubd (pid: 1001, threadinfo 81007d3e2000, task 81007e0be080) Feb 2 03:00:46 mrb Stack: 81007d2a7000 81007d2a7000 81007d2a7918 81007d2a7940 Feb 2 03:00:46 mrb 810037f8c800 80464463 810037e82200 81007d96b890 Feb 2 03:00:46 mrb 81007d96b890 8049ea93 81007d91c030 81007d91c000 Feb 2 03:00:46 mrb Call Trace: Feb 2 03:00:46 mrb [] input_unregister_device +0x70/0x105 Feb 2 03:00:46 mrb [] hidinput_disconnect+0x3d/0x56 Feb 2 03:00:46 mrb [] :usbhid:hid_disconnect +0x8d/0xfd Feb 2 03:00:46 mrb [] :usbcore:usb_unbind_interface +0x3c/0x89 Feb 2 03:00:46 mrb [] __device_release_driver +0x8e/0xb0 Feb 2 03:00:46 mrb [] klist_devices_put+0x0/0xc Feb 2 03:00:46 mrb [] device_release_driver+0x2c/0x44 Feb 2 03:00:46 mrb [] bus_remove_device+0x89/0x9c Feb 2 03:00:46 mrb [] device_del+0x230/0x2bc Feb 2 03:00:46 mrb [] :usbcore:usb_disable_device +0x6f/0xe8 Feb 2 03:00:46 mrb [] :usbcore:usb_disconnect +0x96/0xfd Feb 2 03:00:46 mrb [] :usbcore:usb_disconnect +0x83/0xfd Feb 2 03:00:46 mrb [] :usbcore:hub_thread+0x3bc/0xb60 Feb 2 03:00:46 mrb [] autoremove_wake_function +0x0/0x2e Feb 2 03:00:46 mrb [] :usbcore:hub_thread+0x0/0xb60 Feb 2 03:00:46 mrb [] kthread+0x47/0x74 Feb 2 03:00:46 mrb [] child_rip+0xa/0x12 Feb 2 03:00:46 mrb [] kthread+0x0/0x74 Feb 2 03:00:46 mrb [] child_rip+0x0/0x12 Feb 2 03:00:46 mrb Feb 2 03:00:46 mrb Feb 2 03:00:46 mrb Code: 48 8b 83 18 06 00 00 0f 18 08 48 8d 83 18 06 00 00 4c 39 e0 Feb 2 03:00:46 mrb RIP [] evdev_disconnect+0x7e/0xb8 Feb 2 03:00:46 mrb RSP Feb 2 03:00:46 mrb CR2: 00100100 -- View this message in context: http://www.nabble.com/Oops-in-evdev_disconnect-for-kernel-2.6.23.12-tp14569588p15239145.html Sent from the linux-kernel mailing list archive at Nabble.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: What's the status of x2APIC support in Linux kernel?
On 2/1/08, Andi Kleen <[EMAIL PROTECTED]> wrote: > There are right no CPUs shipping which implement x2apic. Thanks for your information. > "Jike Song" <[EMAIL PROTECTED]> writes: > > Maybe. I have a question as well, what about the status of I/O > > xAPIC support in linux? If it is not supported yet, is there any > > effort to add it? I'm interested in that, hopefully can take part in > > the development. > > xAPIC has been supported forever. Thank you for your attention, Andi. Oh, what do I mean is "I/O xAPIC", but not the "local xAPIC" or xAPIC interrupt architecture introduced by Intel Pentium4 CPU. It seems that the "I/O xAPIC" hasn't been well documented yet, but some other document do have some description about it. Some Intel guys gave me an URL for the document: http://download.intel.com/technology/computing/vptech/Intel(r)_VT_for_Direct_IO.pdf Section 5 and section 9.5 describe 'I/OxAPIC'. I'm not sure if it is already supported by Linux, I guess it is not. -- Best Regards, Jike -- 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] wireless/ath5k: renamed to ath5k_pci_driver to fix Section mismatch warnings
the struct pci_driver refered ath5k_pci_id_table which in __devinit section,
the sparse tool suggest this renamed to "*driver", kills mismatch warnings.
Signed-off-by: Denis Cheng <[EMAIL PROTECTED]>
---
drivers/net/wireless/ath5k/base.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath5k/base.c
b/drivers/net/wireless/ath5k/base.c
index d6599d2..ddc8714 100644
--- a/drivers/net/wireless/ath5k/base.c
+++ b/drivers/net/wireless/ath5k/base.c
@@ -153,7 +153,7 @@ static int ath5k_pci_resume(struct pci_dev *pdev);
#define ath5k_pci_resume NULL
#endif /* CONFIG_PM */
-static struct pci_driver ath5k_pci_drv_id = {
+static struct pci_driver ath5k_pci_driver = {
.name = "ath5k_pci",
.id_table = ath5k_pci_id_table,
.probe = ath5k_pci_probe,
@@ -329,7 +329,7 @@ init_ath5k_pci(void)
ath5k_debug_init();
- ret = pci_register_driver(_pci_drv_id);
+ ret = pci_register_driver(_pci_driver);
if (ret) {
printk(KERN_ERR "ath5k_pci: can't register pci driver\n");
return ret;
@@ -341,7 +341,7 @@ init_ath5k_pci(void)
static void __exit
exit_ath5k_pci(void)
{
- pci_unregister_driver(_pci_drv_id);
+ pci_unregister_driver(_pci_driver);
ath5k_debug_finish();
}
--
1.5.3.8
--
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 22/27] quicklist: Set tlb->need_flush if pages are remaining in quicklist 0
On Fri, 2008-02-01 at 17:30 -0800, Christoph Lameter wrote: > On Fri, 1 Feb 2008, Justin M. Forbes wrote: > > > > > On Fri, 2008-02-01 at 16:39 -0800, Christoph Lameter wrote: > > > NO! Wrong fix. Was dropped from mainline. > > > > What is the right fix for the OOM issues with 2.6.22? Perhaps > > http://marc.info/?l=linux-mm=119973653803451=2 should be added to > > the queue in its place? The OOM issue in 2.6.22 is real, and should be > > addressed. > > Indeed that is the right fix. Greg, could we get that one added? We are already shipping it as our users have run into the OOM problem with 2.6.22.16 without this patch. Justin -- 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 02/22 -v7] Add basic support for gcc profiler instrumentation
On Fri, 1 Feb 2008, Paul E. McKenney wrote:
> > > > OK, fair enough. I'll explain it a bit more.
> > > >
> > > > How's this:
> > > >
> > > > /*
> > > > * We are entering ops into the mcount_list but another
> > > > * CPU might be walking that list. We need to make sure
> > > > * the ops->next pointer is valid before another CPU sees
> > > > * the ops pointer included into the mcount_list.
> > > > */
> > > >
> > >
> > > The above is my new comment. But Peter says that it's still not good
> > > enough and that all write memory barriers need read barriers.
> >
> > To clarify, either: full mb, rmb or read depend.
>
> This is true. A write barrier ensures that the writes remain ordered,
> but unless the reads are also ordered, the reader can still get confused.
> For example (assuming all variables are initially zero):
>
> writer:
>
> a = 1;
> smp_wmb(); /* or smp_mb() */
> b = 1;
>
> reader:
>
> tb = b;
> ta = a;
>
> The writer will (roughly speaking) execute the assignments in order,
> but the reader might not. If the reader executes the assignment from
> "a" first, it might see tb==1&==0. To prevent this, we do:
>
> reader:
>
> tb = b;
> smp_rmb(); /* or smp_mb() */
> ta = a;
>
> There are a lot of variations on this theme.
Yep, this is all clear, but not quite what this code does.
>
> > > Let me explain the situation here.
> > >
> > > We have a single link list called mcount_list that is walked when more
> > > than one function is registered by mcount. Mcount is called at the start
> > > of all C functions that are not annotated with "notrace". When more than
> > > one function is registered, mcount calls a loop function that does the
> > > following:
> > >
> > > notrace void mcount_list_func(unsigned long ip, unsigned long parent_ip)
> > > {
> > > struct mcount_ops *op = mcount_list;
> >
> > When thinking RCU, this would be rcu_dereference and imply a read
> > barrier.
> >
> > > while (op != _list_end) {
> > > op->func(ip, parent_ip);
> > > op = op->next;
> >
> > Same here; the rcu_dereference() would do the read depend barrier.
>
> Specifically:
>
> notrace void mcount_list_func(unsigned long ip, unsigned long parent_ip)
> {
> struct mcount_ops *op = rcu_dereference(mcount_list);
>
> while (op != _list_end) {
> op->func(ip, parent_ip);
> op = rcu_dereference(op->next);
>
> This assumes that you are using call_rcu(), synchronize_rcu(), or
> whatever to defer freeing/reuse of the ops structure.
One special part of this is that the ops structure is never to be freed
(this is documented). It should be a static read-mostly structure.
Since it is not to be freed, I did not export the registered functions to
keep modules from using it. I may later add an export that will cause the
module to increment it's usage count so that it may never be freed.
There's no guarantees that prevent the func from being called after it was
unregistered, nor should the users of this, ever touch the "next" pointer.
This makes things easy when you don't need to free ;-)
>
> > > };
> > > }
> > >
> > > A registered function must already have a "func" filled, and the mcount
> > > register code takes care of "next". It is documented that the calling
> > > function should "never" change next and always expect that the func can be
> > > called after it is unregistered. That's not the issue here.
> > >
> > > The issue is how to insert the ops into the list. I've done the following,
> > > as you can see in the code this text is inserted between.
> > >
> > >ops->next = mcount_list;
> > >smp_wmb();
> > >mcount_list = ops;
> > >
> > > The read side pair is the reading of ops to ops->next, which should imply
> > > a smp_rmb() just by the logic. But Peter tells me things like alpha is
> > > crazy enough to do better than that! Thus, I'm asking you.
>
> Peter is correct when he says that Alpha does not necessarily respect data
> dependencies. See the following URL for the official story:
>
> http://www.openvms.compaq.com/wizard/wiz_2637.html
>
> And I give an example hardware cache design that can result in this
> situation here:
>
>
> http://www.rdrop.com/users/paulmck/scalability/paper/ordering.2007.09.19a.pdf
>
> See the discussion starting with the "Why Reorder Memory Accesses?"
> heading in the second column of the first page.
>
> Strange, but true. It took an Alpha architect quite some time to
> convince me of this back in the late 90s. ;-)
>
> > > Can some arch have a reader where it receives ops->next before it received
> > > ops? This seems to me to be a phsyic arch, to know where ops->next is
> > > before it knows ops!
>
> The trick is that the machine might have a split cache, with (say)
> odd-numbered cache lines being processed by one half and even-numbered
> lines processed by the other half. If reading CPU has one half of the
>
linux-2.6.24 compile error in drivers/net/b44.c
drivers/net/b44.c: In function 'b44_remove_one': drivers/net/b44.c:2231: error: implicit declaration of function 'ssb_pcihost_set_power_state' make[2]: *** [drivers/net/b44.o] Error 1 make[1]: *** [drivers/net] Error 2 I think it is caused by: CONFIG_SSB_PCIHOST=n CONFIG_B44=y -- 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 22/27] quicklist: Set tlb->need_flush if pages are remaining in quicklist 0
On Fri, 2008-02-01 at 16:39 -0800, Christoph Lameter wrote: > NO! Wrong fix. Was dropped from mainline. What is the right fix for the OOM issues with 2.6.22? Perhaps http://marc.info/?l=linux-mm=119973653803451=2 should be added to the queue in its place? The OOM issue in 2.6.22 is real, and should be addressed. Justin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6.22.y] {17**/17} - nopage-range-fix.patch (CVE-2008-0007) - series for stable kernel #2
NOT IN MAINLINE
Linus it's go or drop it?
--
Thanks,
Oliver
From: Nick Piggin <[EMAIL PROTECTED]>
Subject: insufficient range checks of certain fault handlers (CVE-2008-0007)
References: 353207
Patch-upstream: not yet
This patch is a security fix for CVE-2008-0007. See bugzilla for details.
---
Index: linux-2.6.22/drivers/char/drm/drm_vm.c
===
--- linux-2.6.22.orig/drivers/char/drm/drm_vm.c
+++ linux-2.6.22/drivers/char/drm/drm_vm.c
@@ -520,6 +520,7 @@ static int drm_mmap_dma(struct file *fil
vma->vm_ops = _vm_dma_ops;
vma->vm_flags |= VM_RESERVED; /* Don't swap */
+ vma->vm_flags |= VM_DONTEXPAND;
vma->vm_file = filp; /* Needed for drm_vm_open() */
drm_vm_open_locked(vma);
@@ -669,6 +670,7 @@ static int drm_mmap_locked(struct file *
return -EINVAL; /* This should never happen. */
}
vma->vm_flags |= VM_RESERVED; /* Don't swap */
+ vma->vm_flags |= VM_DONTEXPAND;
vma->vm_file = filp; /* Needed for drm_vm_open() */
drm_vm_open_locked(vma);
Index: linux-2.6.22/kernel/relay.c
===
--- linux-2.6.22.orig/kernel/relay.c
+++ linux-2.6.22/kernel/relay.c
@@ -91,6 +91,7 @@ int relay_mmap_buf(struct rchan_buf *buf
return -EINVAL;
vma->vm_ops = _file_mmap_ops;
+ vma->vm_flags |= VM_DONTEXPAND;
vma->vm_private_data = buf;
buf->chan->cb->buf_mapped(buf, filp);
Index: linux-2.6.22/mm/mmap.c
===
--- linux-2.6.22.orig/mm/mmap.c
+++ linux-2.6.22/mm/mmap.c
@@ -2157,7 +2157,7 @@ int install_special_mapping(struct mm_st
vma->vm_start = addr;
vma->vm_end = addr + len;
- vma->vm_flags = vm_flags | mm->def_flags;
+ vma->vm_flags = vm_flags | mm->def_flags | VM_DONTEXPAND;
vma->vm_page_prot = protection_map[vma->vm_flags & 7];
vma->vm_ops = _mapping_vmops;
Index: linux-2.6.22/sound/oss/via82cxxx_audio.c
===
--- linux-2.6.22.orig/sound/oss/via82cxxx_audio.c
+++ linux-2.6.22/sound/oss/via82cxxx_audio.c
@@ -2104,6 +2104,7 @@ static struct page * via_mm_nopage (stru
{
struct via_info *card = vma->vm_private_data;
struct via_channel *chan = >ch_out;
+ unsigned long max_bufs;
struct page *dmapage;
unsigned long pgoff;
int rd, wr;
@@ -2127,14 +2128,11 @@ static struct page * via_mm_nopage (stru
rd = card->ch_in.is_mapped;
wr = card->ch_out.is_mapped;
-#ifndef VIA_NDEBUG
- {
- unsigned long max_bufs = chan->frag_number;
- if (rd && wr) max_bufs *= 2;
- /* via_dsp_mmap() should ensure this */
- assert (pgoff < max_bufs);
- }
-#endif
+ max_bufs = chan->frag_number;
+ if (rd && wr)
+ max_bufs *= 2;
+ if (pgoff >= max_bufs)
+ return NOPAGE_SIGBUS;
/* if full-duplex (read+write) and we have two sets of bufs,
* then the playback buffers come first, sez soundcard.c */
Index: linux-2.6.22/sound/usb/usx2y/usX2Yhwdep.c
===
--- linux-2.6.22.orig/sound/usb/usx2y/usX2Yhwdep.c
+++ linux-2.6.22/sound/usb/usx2y/usX2Yhwdep.c
@@ -88,7 +88,7 @@ static int snd_us428ctls_mmap(struct snd
us428->us428ctls_sharedmem->CtlSnapShotLast = -2;
}
area->vm_ops = _vm_ops;
- area->vm_flags |= VM_RESERVED;
+ area->vm_flags |= VM_RESERVED | VM_DONTEXPAND;
area->vm_private_data = hw->private_data;
return 0;
}
Index: linux-2.6.22/sound/usb/usx2y/usx2yhwdeppcm.c
===
--- linux-2.6.22.orig/sound/usb/usx2y/usx2yhwdeppcm.c
+++ linux-2.6.22/sound/usb/usx2y/usx2yhwdeppcm.c
@@ -728,7 +728,7 @@ static int snd_usX2Y_hwdep_pcm_mmap(stru
return -ENODEV;
}
area->vm_ops = _usX2Y_hwdep_pcm_vm_ops;
- area->vm_flags |= VM_RESERVED;
+ area->vm_flags |= VM_RESERVED | VM_DONTEXPAND;
area->vm_private_data = hw->private_data;
return 0;
}
Index: linux-2.6.22/drivers/char/mspec.c
===
--- linux-2.6.22.orig/drivers/char/mspec.c
+++ linux-2.6.22/drivers/char/mspec.c
@@ -265,7 +265,7 @@ mspec_mmap(struct file *file, struct vm_
vdata->refcnt = ATOMIC_INIT(1);
vma->vm_private_data = vdata;
- vma->vm_flags |= (VM_IO | VM_LOCKED | VM_RESERVED | VM_PFNMAP);
+ vma->vm_flags |= (VM_IO | VM_LOCKED | VM_RESERVED | VM_PFNMAP | VM_DONTEXPAND);
if (vdata->type == MSPEC_FETCHOP || vdata->type == MSPEC_UNCACHED)
vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
vma->vm_ops = _vm_ops;
Index: linux-2.6.22/sound/oss/emu10k1/audio.c
===
--- linux-2.6.22.orig/sound/oss/emu10k1/audio.c
+++ linux-2.6.22/sound/oss/emu10k1/audio.c
@@ -,7 +,7 @@ static int emu10k1_audio_mmap(struct fil
if (pgoffset + n_pages > max_pages)
return -EINVAL;
- vma->vm_flags |= VM_RESERVED;
+ vma->vm_flags |= VM_RESERVED | VM_DONTEXPAND;
vma->vm_ops = _mm_ops;
vma->vm_private_data = wave_dev;
return 0;
[2.6.22.y] {15/17} - nfs-unmount-leak.patch - series for stable kernel #2
mainline: 13ef7b69b54aa8ae4ed264d0bf41339737f8543a
--
Thanks,
Oliver
From: Trond Myklebust <[EMAIL PROTECTED]>
Date: Tue Dec 11 11:05:19 2007 -0500
Subject: NFSv2/v3: Fix a memory leak when using -onolock
Patch-mainline: 2.6.24
References: 336253
Neil Brown said:
> Hi Trond,
>
> We found that a machine which made moderately heavy use of
> 'automount' was leaking some nfs data structures - particularly the
> 4K allocated by rpc_alloc_iostats.
> It turns out that this only happens with filesystems with -onolock
> set.
> The problem is that if NFS_MOUNT_NONLM is set, nfs_start_lockd doesn't
> set server->destroy, so when the filesystem is unmounted, the
> ->client_acl is not shutdown, and so several resources are still
> held. Multiple mount/umount cycles will slowly eat away memory
> several pages at a time.
Signed-off-by: Trond Myklebust <[EMAIL PROTECTED]>
Acked-by: Neil Brown <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
---
fs/nfs/client.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- linux-2.6.22-SL103_BRANCH.orig/fs/nfs/client.c
+++ linux-2.6.22-SL103_BRANCH/fs/nfs/client.c
@@ -433,9 +433,6 @@ static int nfs_create_rpc_client(struct
*/
static void nfs_destroy_server(struct nfs_server *server)
{
- if (!IS_ERR(server->client_acl))
- rpc_shutdown_client(server->client_acl);
-
if (!(server->flags & NFS_MOUNT_NONLM))
lockd_down(); /* release rpc.lockd */
}
@@ -771,6 +768,9 @@ void nfs_free_server(struct nfs_server *
if (server->destroy != NULL)
server->destroy(server);
+
+ if (!IS_ERR(server->client_acl))
+ rpc_shutdown_client(server->client_acl);
if (!IS_ERR(server->client))
rpc_shutdown_client(server->client);
[2.6.22.y] {16/17} - nfsv4-MAXNAME-fix.diff - series for stable kernel #2
mainline: a16e92edcd0a2846455a30823e1bac964e743baa
--
Thanks,
Oliver
From: J. Bruce Fields <[EMAIL PROTECTED]>
Date: Fri, 28 Sep 2007 16:45:51 -0400
Subject: knfsd: query filesystem for NFSv4 getattr of FATTR4_MAXNAME
References: 271803
Patch-mainline: 2.6.24 (likely)
Without this we always return 2^32-1 as the the maximum namelength.
Signed-off-by: J. Bruce Fields <[EMAIL PROTECTED]>
Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
---
fs/nfsd/nfs4xdr.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
--- linux-2.6.22.orig/fs/nfsd/nfs4xdr.c
+++ linux-2.6.22/fs/nfsd/nfs4xdr.c
@@ -1453,7 +1453,8 @@ nfsd4_encode_fattr(struct svc_fh *fhp, s
err = vfs_getattr(exp->ex_mnt, dentry, );
if (err)
goto out_nfserr;
- if ((bmval0 & (FATTR4_WORD0_FILES_FREE | FATTR4_WORD0_FILES_TOTAL)) ||
+ if ((bmval0 & (FATTR4_WORD0_FILES_FREE | FATTR4_WORD0_FILES_TOTAL |
+ FATTR4_WORD0_MAXNAME)) ||
(bmval1 & (FATTR4_WORD1_SPACE_AVAIL | FATTR4_WORD1_SPACE_FREE |
FATTR4_WORD1_SPACE_TOTAL))) {
err = vfs_statfs(dentry, );
@@ -1699,7 +1700,7 @@ out_acl:
if (bmval0 & FATTR4_WORD0_MAXNAME) {
if ((buflen -= 4) < 0)
goto out_resource;
- WRITE32(~(u32) 0);
+ WRITE32(statfs.f_namelen);
}
if (bmval0 & FATTR4_WORD0_MAXREAD) {
if ((buflen -= 8) < 0)
[2.6.22.y] {14/17} - nfs-name-len-limit - series for stable kernel #2
mainline: 54af3bb543c071769141387a42deaaab5074da55
--
Thanks,
Oliver
Patch-mainline: 2.6.23
References: 325913
GIT: 54af3bb543c071769141387a42deaaab5074da55 Mon Sep 17 00:00:00 2001
From: Trond Myklebust <[EMAIL PROTECTED]>
Date: Fri, 28 Sep 2007 12:27:41 -0400
Subject: [PATCH] NFS: Fix an Oops in encode_lookup()
It doesn't look as if the NFS file name limit is being initialised correctly
in the struct nfs_server. Make sure that we limit whatever is being set in
nfs_probe_fsinfo() and nfs_init_server().
Also ensure that readdirplus and nfs4_path_walk respect our file name
limits.
Signed-off-by: Trond Myklebust <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
Acked-by: NeilBrown <[EMAIL PROTECTED]>
---
fs/nfs/client.c | 29 +++--
fs/nfs/dir.c |2 ++
fs/nfs/getroot.c |3 +++
3 files changed, 24 insertions(+), 10 deletions(-)
--- linux-2.6.22-SL103_BRANCH.orig/fs/nfs/client.c
+++ linux-2.6.22-SL103_BRANCH/fs/nfs/client.c
@@ -614,16 +614,6 @@ static int nfs_init_server(struct nfs_se
server->namelen = data->namlen;
/* Create a client RPC handle for the NFSv3 ACL management interface */
nfs_init_server_aclclient(server);
- if (clp->cl_nfsversion == 3) {
- if (server->namelen == 0 || server->namelen > NFS3_MAXNAMLEN)
- server->namelen = NFS3_MAXNAMLEN;
- if (!(data->flags & NFS_MOUNT_NORDIRPLUS))
- server->caps |= NFS_CAP_READDIRPLUS;
- } else {
- if (server->namelen == 0 || server->namelen > NFS2_MAXNAMLEN)
- server->namelen = NFS2_MAXNAMLEN;
- }
-
dprintk("<-- nfs_init_server() = 0 [new %p]\n", clp);
return 0;
@@ -820,6 +810,16 @@ struct nfs_server *nfs_create_server(con
error = nfs_probe_fsinfo(server, mntfh, );
if (error < 0)
goto error;
+ if (server->nfs_client->rpc_ops->version == 3) {
+ if (server->namelen == 0 || server->namelen > NFS3_MAXNAMLEN)
+ server->namelen = NFS3_MAXNAMLEN;
+ if (!(data->flags & NFS_MOUNT_NORDIRPLUS))
+ server->caps |= NFS_CAP_READDIRPLUS;
+ } else {
+ if (server->namelen == 0 || server->namelen > NFS2_MAXNAMLEN)
+ server->namelen = NFS2_MAXNAMLEN;
+ }
+
if (!(fattr.valid & NFS_ATTR_FATTR)) {
error = server->nfs_client->rpc_ops->getattr(server, mntfh, );
if (error < 0) {
@@ -1010,6 +1010,9 @@ struct nfs_server *nfs4_create_server(co
if (error < 0)
goto error;
+ if (server->namelen == 0 || server->namelen > NFS4_MAXNAMLEN)
+ server->namelen = NFS4_MAXNAMLEN;
+
BUG_ON(!server->nfs_client);
BUG_ON(!server->nfs_client->rpc_ops);
BUG_ON(!server->nfs_client->rpc_ops->file_inode_ops);
@@ -1082,6 +1085,9 @@ struct nfs_server *nfs4_create_referral_
if (error < 0)
goto error;
+ if (server->namelen == 0 || server->namelen > NFS4_MAXNAMLEN)
+ server->namelen = NFS4_MAXNAMLEN;
+
dprintk("Referral FSID: %llx:%llx\n",
(unsigned long long) server->fsid.major,
(unsigned long long) server->fsid.minor);
@@ -1141,6 +1147,9 @@ struct nfs_server *nfs_clone_server(stru
if (error < 0)
goto out_free_server;
+ if (server->namelen == 0 || server->namelen > NFS4_MAXNAMLEN)
+ server->namelen = NFS4_MAXNAMLEN;
+
dprintk("Cloned FSID: %llx:%llx\n",
(unsigned long long) server->fsid.major,
(unsigned long long) server->fsid.minor);
--- linux-2.6.22-SL103_BRANCH.orig/fs/nfs/dir.c
+++ linux-2.6.22-SL103_BRANCH/fs/nfs/dir.c
@@ -1163,6 +1163,8 @@ static struct dentry *nfs_readdir_lookup
}
if (!desc->plus || !(entry->fattr->valid & NFS_ATTR_FATTR))
return NULL;
+ if (name.len > NFS_SERVER(dir)->namelen)
+ return NULL;
/* Note: caller is already holding the dir->i_mutex! */
dentry = d_alloc(parent, );
if (dentry == NULL)
--- linux-2.6.22-SL103_BRANCH.orig/fs/nfs/getroot.c
+++ linux-2.6.22-SL103_BRANCH/fs/nfs/getroot.c
@@ -175,6 +175,9 @@ next_component:
path++;
name.len = path - (const char *) name.name;
+ if (name.len > NFS4_MAXNAMLEN)
+ return -ENAMETOOLONG;
+
eat_dot_dir:
while (*path == '/')
path++;
[2.6.22.y] {13/17} - nfs-fix-nfs-reval-fsid - series for stable kernel #2
mainline: a0356862bcbeb20acf64bc1a82d28a4c5bb957a7
--
Thanks,
Oliver
Patch-mainline: 2.6.24
References: 271803
GIT: a0356862bcbeb20acf64bc1a82d28a4c5bb957a7 Mon Sep 17 00:00:00 2001
From: Trond Myklebust <[EMAIL PROTECTED]>
Date: Tue, 5 Jun 2007 13:26:15 -0400
Subject: [PATCH] NFS: Fix nfs_reval_fsid()
We don't need to revalidate the fsid on the root directory. It suffices to
revalidate it on the current directory.
Signed-off-by: Trond Myklebust <[EMAIL PROTECTED]>
Acked-by: NeilBrown <[EMAIL PROTECTED]>
---
fs/nfs/dir.c |9 -
fs/nfs/inode.c |4 ++--
2 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
index 4948ec1..c02a796 100644
--- a/fs/nfs/dir.c
+++ b/fs/nfs/dir.c
@@ -897,14 +897,13 @@ int nfs_is_exclusive_create(struct inode *dir, struct nameidata *nd)
return (nd->intent.open.flags & O_EXCL) != 0;
}
-static inline int nfs_reval_fsid(struct vfsmount *mnt, struct inode *dir,
- struct nfs_fh *fh, struct nfs_fattr *fattr)
+static inline int nfs_reval_fsid(struct inode *dir, const struct nfs_fattr *fattr)
{
struct nfs_server *server = NFS_SERVER(dir);
if (!nfs_fsid_equal(>fsid, >fsid))
- /* Revalidate fsid on root dir */
- return __nfs_revalidate_inode(server, mnt->mnt_root->d_inode);
+ /* Revalidate fsid using the parent directory */
+ return __nfs_revalidate_inode(server, dir);
return 0;
}
@@ -946,7 +945,7 @@ static struct dentry *nfs_lookup(struct inode *dir, struct dentry * dentry, stru
res = ERR_PTR(error);
goto out_unlock;
}
- error = nfs_reval_fsid(nd->mnt, dir, , );
+ error = nfs_reval_fsid(dir, );
if (error < 0) {
res = ERR_PTR(error);
goto out_unlock;
diff --git a/fs/nfs/inode.c b/fs/nfs/inode.c
index 23ecf03..7bcb3df 100644
--- a/fs/nfs/inode.c
+++ b/fs/nfs/inode.c
@@ -961,8 +961,8 @@ static int nfs_update_inode(struct inode *inode, struct nfs_fattr *fattr)
goto out_changed;
server = NFS_SERVER(inode);
- /* Update the fsid if and only if this is the root directory */
- if (inode == inode->i_sb->s_root->d_inode
+ /* Update the fsid? */
+ if (S_ISDIR(inode->i_mode)
&& !nfs_fsid_equal(>fsid, >fsid))
server->fsid = fattr->fsid;
--
1.5.3.6
[2.6.22.y] {12/17} - nfsacl-retval.diff - series for stable kernel #2
mainline: ac8587dcb58e40dd336d99d60f852041e06cc3dd -- Thanks, Oliver From: J. Bruce Fields <[EMAIL PROTECTED]> Date: Fri, 2 Nov 2007 15:36:08 -0400 Subject: [PATCH] knfsd: fix spurious EINVAL errors on first access of new filesystem References: 340873 The v2/v3 acl code in nfsd is translating any return from fh_verify() to nfserr_inval. This is particularly unfortunate in the case of an nfserr_dropit return, which is an internal error meant to indicate to callers that this request has been deferred and should just be dropped pending the results of an upcall to mountd. Thanks to Roland <[EMAIL PROTECTED]> for bug report and data collection. Cc: Roland <[EMAIL PROTECTED]> Acked-by: Andreas Gruenbacher <[EMAIL PROTECTED]> Signed-off-by: J. Bruce Fields <[EMAIL PROTECTED]> Index: linux-2.6.23/fs/nfsd/nfs2acl.c === --- linux-2.6.23.orig/fs/nfsd/nfs2acl.c +++ linux-2.6.23/fs/nfsd/nfs2acl.c @@ -41,7 +41,7 @@ static __be32 nfsacld_proc_getacl(struct fh = fh_copy(>fh, >fh); if ((nfserr = fh_verify(rqstp, >fh, 0, MAY_NOP))) - RETURN_STATUS(nfserr_inval); + RETURN_STATUS(nfserr); if (argp->mask & ~(NFS_ACL|NFS_ACLCNT|NFS_DFACL|NFS_DFACLCNT)) RETURN_STATUS(nfserr_inval); Index: linux-2.6.23/fs/nfsd/nfs3acl.c === --- linux-2.6.23.orig/fs/nfsd/nfs3acl.c +++ linux-2.6.23/fs/nfsd/nfs3acl.c @@ -37,7 +37,7 @@ static __be32 nfsd3_proc_getacl(struct s fh = fh_copy(>fh, >fh); if ((nfserr = fh_verify(rqstp, >fh, 0, MAY_NOP))) - RETURN_STATUS(nfserr_inval); + RETURN_STATUS(nfserr); if (argp->mask & ~(NFS_ACL|NFS_ACLCNT|NFS_DFACL|NFS_DFACLCNT)) RETURN_STATUS(nfserr_inval);
[2.6.22.y] {10/17} - via-velocity-dont-oops-on-mtu-change-1 - series for stable kernel #2
mainline: bd7b3f34198071d8bec05180530c362f1800ba46
--
Thanks,
Oliver
--- Begin Message ---
[VIA_VELOCITY]: Don't oops on MTU change.
Simple mtu change when device is down.
Fix http://bugzilla.kernel.org/show_bug.cgi?id=9382.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
Acked-by: Jeff Mahoney <[EMAIL PROTECTED]>
---
drivers/net/via-velocity.c |5 +
1 file changed, 5 insertions(+)
--- a/drivers/net/via-velocity.c2008-01-03 15:18:35.0 -0500
+++ b/drivers/net/via-velocity.c2008-01-03 15:18:50.0 -0500
@@ -1798,6 +1798,11 @@ static int velocity_change_mtu(struct ne
return -EINVAL;
}
+ if (!netif_running(dev)) {
+ dev->mtu = new_mtu;
+ return 0;
+ }
+
if (new_mtu != oldmtu) {
spin_lock_irqsave(>lock, flags);
--- End Message ---
[2.6.22.y] {11/17} - via-velocity-dont-oops-on-mtu-change-2 - series for stable kernel #2
mainline: 48f6b053613b62fed7a2fe3255e5568260a8d615 -- Thanks, Oliver --- Begin Message --- via-velocity: don't oops on MTU change (resend) The VIA veloicty driver needs the following to allow changing MTU when down. The buffer size needs to be computed when device is brought up, not when device is initialized. This also fixes a bug where the buffer size was computed differently on change_mtu versus initial setting. Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]> Acked-by: Jeff Mahoney <[EMAIL PROTECTED]> --- drivers/net/via-velocity.c | 11 +++ 1 file changed, 3 insertions(+), 8 deletions(-) --- a/drivers/net/via-velocity.c2008-01-03 15:18:50.0 -0500 +++ b/drivers/net/via-velocity.c2008-01-03 15:22:18.0 -0500 @@ -1075,6 +1075,9 @@ static int velocity_init_rd_ring(struct int ret = -ENOMEM; unsigned int rsize = sizeof(struct velocity_rd_info) * vptr->options.numrx; + int mtu = vptr->dev->mtu; + + vptr->rx_buf_sz = (mtu <= ETH_DATA_LEN) ? PKT_BUF_SZ : mtu + 32; vptr->rd_info = kmalloc(rsize, GFP_KERNEL); if(vptr->rd_info == NULL) @@ -1733,8 +1736,6 @@ static int velocity_open(struct net_devi struct velocity_info *vptr = netdev_priv(dev); int ret; - vptr->rx_buf_sz = (dev->mtu <= 1504 ? PKT_BUF_SZ : dev->mtu + 32); - ret = velocity_init_rings(vptr); if (ret < 0) goto out; @@ -1813,12 +1814,6 @@ static int velocity_change_mtu(struct ne velocity_free_rd_ring(vptr); dev->mtu = new_mtu; - if (new_mtu > 8192) - vptr->rx_buf_sz = 9 * 1024; - else if (new_mtu > 4096) - vptr->rx_buf_sz = 8192; - else - vptr->rx_buf_sz = 4 * 1024; ret = velocity_init_rd_ring(vptr); if (ret < 0) --- End Message ---
[2.6.22.y] {08/17} - intel-agp-965gme-fix - series for stable kernel #2
mainline: dde4787642ee3cb85aef80bdade04b6f8ddc3df8
--
Thanks,
Oliver
--- Begin Message ---
Intel_agp: really fix 945/965GME
Fix some missing places to check with device id info, which
should probe the device gart correctly.
Signed-off-by: Wang Zhenyu <[EMAIL PROTECTED]>
Signed-off-by: Dave Airlie <[EMAIL PROTECTED]>
Acked-by: Takashi Iwai <[EMAIL PROTECTED]>
---
commit dde4787642ee3cb85aef80bdade04b6f8ddc3df8
tree e99908c8c61a08244b6bb03b87782999a5a3847d
parent a51b34593f691a0837d752a1394dcee19483c607
author Zhenyu Wang <[EMAIL PROTECTED]> Thu, 26 Jul 2007 09:18:09 +0800
committer Dave Airlie <[EMAIL PROTECTED]> Fri, 27 Jul 2007 10:48:13 +1000
drivers/char/agp/intel-agp.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
--- a/drivers/char/agp/intel-agp.c 2007-07-08 19:32:17.0 -0400
+++ b/drivers/char/agp/intel-agp.c 2007-08-27 14:01:47.0 -0400
@@ -20,7 +20,9 @@
#define PCI_DEVICE_ID_INTEL_82965G_IG 0x29A2
#define PCI_DEVICE_ID_INTEL_82965GM_HB 0x2A00
#define PCI_DEVICE_ID_INTEL_82965GM_IG 0x2A02
+#define PCI_DEVICE_ID_INTEL_82965GME_HB 0x2A10
#define PCI_DEVICE_ID_INTEL_82965GME_IG 0x2A12
+#define PCI_DEVICE_ID_INTEL_82945GME_HB 0x27AC
#define PCI_DEVICE_ID_INTEL_82945GME_IG 0x27AE
#define PCI_DEVICE_ID_INTEL_G33_HB 0x29C0
#define PCI_DEVICE_ID_INTEL_G33_IG 0x29C2
@@ -33,7 +35,8 @@
agp_bridge->dev->device == PCI_DEVICE_ID_INTEL_82965G_1_HB ||
\
agp_bridge->dev->device == PCI_DEVICE_ID_INTEL_82965Q_HB || \
agp_bridge->dev->device == PCI_DEVICE_ID_INTEL_82965G_HB || \
- agp_bridge->dev->device == PCI_DEVICE_ID_INTEL_82965GM_HB)
+ agp_bridge->dev->device == PCI_DEVICE_ID_INTEL_82965GM_HB || \
+ agp_bridge->dev->device == PCI_DEVICE_ID_INTEL_82965GME_HB)
#define IS_G33 (agp_bridge->dev->device == PCI_DEVICE_ID_INTEL_G33_HB || \
agp_bridge->dev->device == PCI_DEVICE_ID_INTEL_Q35_HB || \
@@ -527,6 +530,7 @@ static void intel_i830_init_gtt_entries(
agp_bridge->dev->device ==
PCI_DEVICE_ID_INTEL_82915GM_HB ||
agp_bridge->dev->device ==
PCI_DEVICE_ID_INTEL_82945G_HB ||
agp_bridge->dev->device ==
PCI_DEVICE_ID_INTEL_82945GM_HB ||
+ agp_bridge->dev->device ==
PCI_DEVICE_ID_INTEL_82945GME_HB ||
IS_I965 || IS_G33)
gtt_entries = MB(48) - KB(size);
else
@@ -538,6 +542,7 @@ static void intel_i830_init_gtt_entries(
agp_bridge->dev->device ==
PCI_DEVICE_ID_INTEL_82915GM_HB ||
agp_bridge->dev->device ==
PCI_DEVICE_ID_INTEL_82945G_HB ||
agp_bridge->dev->device ==
PCI_DEVICE_ID_INTEL_82945GM_HB ||
+ agp_bridge->dev->device ==
PCI_DEVICE_ID_INTEL_82945GME_HB ||
IS_I965 || IS_G33)
gtt_entries = MB(64) - KB(size);
else
@@ -1848,9 +1853,9 @@ static const struct intel_driver_descrip
NULL, _915_driver },
{ PCI_DEVICE_ID_INTEL_82945G_HB, PCI_DEVICE_ID_INTEL_82945G_IG, 0,
"945G",
NULL, _915_driver },
- { PCI_DEVICE_ID_INTEL_82945GM_HB, PCI_DEVICE_ID_INTEL_82945GM_IG, 1,
"945GM",
+ { PCI_DEVICE_ID_INTEL_82945GM_HB, PCI_DEVICE_ID_INTEL_82945GM_IG, 0,
"945GM",
NULL, _915_driver },
- { PCI_DEVICE_ID_INTEL_82945GM_HB, PCI_DEVICE_ID_INTEL_82945GME_IG, 0,
"945GME",
+ { PCI_DEVICE_ID_INTEL_82945GME_HB, PCI_DEVICE_ID_INTEL_82945GME_IG, 0,
"945GME",
NULL, _915_driver },
{ PCI_DEVICE_ID_INTEL_82946GZ_HB, PCI_DEVICE_ID_INTEL_82946GZ_IG, 0,
"946GZ",
NULL, _i965_driver },
@@ -1860,9 +1865,9 @@ static const struct intel_driver_descrip
NULL, _i965_driver },
{ PCI_DEVICE_ID_INTEL_82965G_HB, PCI_DEVICE_ID_INTEL_82965G_IG, 0,
"965G",
NULL, _i965_driver },
- { PCI_DEVICE_ID_INTEL_82965GM_HB, PCI_DEVICE_ID_INTEL_82965GM_IG, 1,
"965GM",
+ { PCI_DEVICE_ID_INTEL_82965GM_HB, PCI_DEVICE_ID_INTEL_82965GM_IG, 0,
"965GM",
NULL, _i965_driver },
- { PCI_DEVICE_ID_INTEL_82965GM_HB, PCI_DEVICE_ID_INTEL_82965GME_IG, 0,
"965GME/GLE",
+ { PCI_DEVICE_ID_INTEL_82965GME_HB, PCI_DEVICE_ID_INTEL_82965GME_IG, 0,
"965GME/GLE",
NULL, _i965_driver },
{ PCI_DEVICE_ID_INTEL_7505_0, 0, 0, "E7505", _7505_driver, NULL },
{ PCI_DEVICE_ID_INTEL_7205_0, 0, 0, "E7205", _7505_driver, NULL },
@@ -2051,11 +2056,13 @@ static struct pci_device_id agp_intel_pc
ID(PCI_DEVICE_ID_INTEL_82915GM_HB),
ID(PCI_DEVICE_ID_INTEL_82945G_HB),
ID(PCI_DEVICE_ID_INTEL_82945GM_HB),
+
[2.6.22.y] {09/17} - sony-laptop-call-sonypi_compat_init-earlier - series for stable kernel #2
mainline: 015a916fbbf105bb15f4bbfd80c3b9b2f2e0d7db
--
Thanks,
Oliver
--- Begin Message ---
sony-laptop: call sonypi_compat_init earlier
sonypi_compat uses a kfifo that needs to be present before _SRS is
called to be able to cope with the IRQs triggered when setting
resources.
Signed-off-by: Mattia Dongili <[EMAIL PROTECTED]>
Signed-off-by: Len Brown <[EMAIL PROTECTED]>
Acked-by: Jeff Mahoney <[EMAIL PROTECTED]>
---
drivers/misc/sony-laptop.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
--- a/drivers/misc/sony-laptop.c2007-11-28 10:52:13.0 -0500
+++ b/drivers/misc/sony-laptop.c2008-01-02 15:17:42.0 -0500
@@ -2068,8 +2068,6 @@ static int sony_pic_remove(struct acpi_d
struct sony_pic_ioport *io, *tmp_io;
struct sony_pic_irq *irq, *tmp_irq;
- sonypi_compat_exit();
-
if (sony_pic_disable(device)) {
printk(KERN_ERR DRV_PFX "Couldn't disable device.\n");
return -ENXIO;
@@ -2079,6 +2077,8 @@ static int sony_pic_remove(struct acpi_d
release_region(spic_dev.cur_ioport->io.minimum,
spic_dev.cur_ioport->io.address_length);
+ sonypi_compat_exit();
+
sony_laptop_remove_input();
/* pf attrs */
@@ -2144,6 +2144,9 @@ static int sony_pic_add(struct acpi_devi
goto err_free_resources;
}
+ if (sonypi_compat_init())
+ goto err_remove_input;
+
/* request io port */
list_for_each_entry(io, _dev.ioports, list) {
if (request_region(io->io.minimum, io->io.address_length,
@@ -2158,7 +2161,7 @@ static int sony_pic_add(struct acpi_devi
if (!spic_dev.cur_ioport) {
printk(KERN_ERR DRV_PFX "Failed to request_region.\n");
result = -ENODEV;
- goto err_remove_input;
+ goto err_remove_compat;
}
/* request IRQ */
@@ -2198,9 +2201,6 @@ static int sony_pic_add(struct acpi_devi
if (result)
goto err_remove_pf;
- if (sonypi_compat_init())
- goto err_remove_pf;
-
return 0;
err_remove_pf:
@@ -2216,6 +2216,9 @@ err_release_region:
release_region(spic_dev.cur_ioport->io.minimum,
spic_dev.cur_ioport->io.address_length);
+err_remove_compat:
+ sonypi_compat_exit();
+
err_remove_input:
sony_laptop_remove_input();
--- End Message ---
[2.6.22.y] {07/17} - i386-fixup-TRACE_IRQ-breakage - series for stable kernel #2
mainline: a10d9a71bafd3a283da240d2868e71346d2aef6f -- Thanks, Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6.22.y] {06/17} - handle-bogus-%cs-selector-in-single-step-instruction-decoding - series for stable kernel #2
mainline: 29eb51101c02df517ca64ec472d7501127ad1da8
--
Thanks,
Oliver
--- Begin Message ---
Handle bogus %cs selector in single-step instruction decoding
The code for LDT segment selectors was not robust in the face of a bogus
selector set in %cs via ptrace before the single-step was done.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
Acked-by: Jeff Mahoney <[EMAIL PROTECTED]>
---
arch/i386/kernel/ptrace.c | 22 +++---
arch/x86_64/kernel/ptrace.c | 23 ---
2 files changed, 31 insertions(+), 14 deletions(-)
diff --git a/arch/i386/kernel/ptrace.c b/arch/i386/kernel/ptrace.c
index 1c075f5..0c8f00e 100644
--- a/arch/i386/kernel/ptrace.c
+++ b/arch/i386/kernel/ptrace.c
@@ -164,14 +164,22 @@ static unsigned long convert_eip_to_linear(struct
task_struct *child, struct pt_
u32 *desc;
unsigned long base;
- down(>mm->context.sem);
- desc = child->mm->context.ldt + (seg & ~7);
- base = (desc[0] >> 16) | ((desc[1] & 0xff) << 16) | (desc[1] &
0xff00);
+ seg &= ~7UL;
- /* 16-bit code segment? */
- if (!((desc[1] >> 22) & 1))
- addr &= 0x;
- addr += base;
+ down(>mm->context.sem);
+ if (unlikely((seg >> 3) >= child->mm->context.size))
+ addr = -1L; /* bogus selector, access would fault */
+ else {
+ desc = child->mm->context.ldt + seg;
+ base = ((desc[0] >> 16) |
+ ((desc[1] & 0xff) << 16) |
+ (desc[1] & 0xff00));
+
+ /* 16-bit code segment? */
+ if (!((desc[1] >> 22) & 1))
+ addr &= 0x;
+ addr += base;
+ }
up(>mm->context.sem);
}
return addr;
diff --git a/arch/x86_64/kernel/ptrace.c b/arch/x86_64/kernel/ptrace.c
index fa6775e..e83cc67 100644
--- a/arch/x86_64/kernel/ptrace.c
+++ b/arch/x86_64/kernel/ptrace.c
@@ -102,16 +102,25 @@ unsigned long convert_rip_to_linear(struct task_struct
*child, struct pt_regs *r
u32 *desc;
unsigned long base;
- down(>mm->context.sem);
- desc = child->mm->context.ldt + (seg & ~7);
- base = (desc[0] >> 16) | ((desc[1] & 0xff) << 16) | (desc[1] &
0xff00);
+ seg &= ~7UL;
- /* 16-bit code segment? */
- if (!((desc[1] >> 22) & 1))
- addr &= 0x;
- addr += base;
+ down(>mm->context.sem);
+ if (unlikely((seg >> 3) >= child->mm->context.size))
+ addr = -1L; /* bogus selector, access would fault */
+ else {
+ desc = child->mm->context.ldt + seg;
+ base = ((desc[0] >> 16) |
+ ((desc[1] & 0xff) << 16) |
+ (desc[1] & 0xff00));
+
+ /* 16-bit code segment? */
+ if (!((desc[1] >> 22) & 1))
+ addr &= 0x;
+ addr += base;
+ }
up(>mm->context.sem);
}
+
return addr;
}
--- End Message ---
[2.6.22.y] {05/17} - cciss-fix_memory_leak - series for stable kernel #2
mainline: f2912a1223c0917a7b4e054f18086209137891ea -- Thanks, Oliver cciss-fix_memory_leak Description: application/mbox
[2.6.22.y] {04/17} - cciss-panic-in-blk_rq_map_sg - series for stable kernel #2
mainline: a683d652d334a546be9175b894f42dbd8e399536 -- Thanks, Oliver cciss-panic-in-blk_rq_map_sg Description: application/mbox
[2.6.22.y] {02/17} - invalid-semicolon - series for stable kernel #2
mainline: 2b02d13996fe28478e45605de9bd8bdca25718de -- Thanks, Oliver --- Begin Message --- A similar fix to netfilter from Eric Dumazet inspired me to look around a bit by using some grep/sed stuff as looking for this kind of bugs seemed easy to automate. This is one of them I found where it looks like this semicolon is not valid. Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]> Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]> --- arch/powerpc/mm/hash_utils_64.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/powerpc/mm/hash_utils_64.c 2007-07-08 19:32:17.0 -0400 +++ b/arch/powerpc/mm/hash_utils_64.c 2007-08-27 14:01:20.0 -0400 @@ -795,7 +795,7 @@ void hash_preload(struct mm_struct *mm, #ifdef CONFIG_PPC_MM_SLICES /* We only prefault standard pages for now */ - if (unlikely(get_slice_psize(mm, ea) != mm->context.user_psize)); + if (unlikely(get_slice_psize(mm, ea) != mm->context.user_psize)) return; #endif --- End Message ---
[2.6.22.y] {03/17} - pci-fix-unterminated-pci_device_id-lists - series for stable kernel #2
mainline: 248bdd5efca5a113cbf443a993c69e53d370236b -- Thanks, Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6.22.y] {01**/17} - do_anonymous_page-race - series for stable kernel
NOT IN MAINLINE Linus it's go or drop it? -- Thanks, Oliver --- Begin Message --- Additional Comment #103 From Andrea Arcangeli 2004-10-15 19:41 the last patch I attached is the safest I believe. I'm not sure if a lock_unlock or lock_unlock is always guaranteed to happen after the I/O, and this makes sure no race can happen anymore. --- fs/bio.c |9 + 1 file changed, 9 insertions(+) --- a/fs/bio.c 2007-07-08 19:32:17.0 -0400 +++ b/fs/bio.c 2007-08-27 14:01:21.0 -0400 @@ -1028,6 +1028,15 @@ void bio_endio(struct bio *bio, unsigned bio->bi_size -= bytes_done; bio->bi_sector += (bytes_done >> 9); + if (bio_data_dir(bio) == READ) + /* +* If the current cpu has written to the page by hand +* without dma, we must enforce ordering to be sure +* this written data will be visible before we expose +* the page contents to other cpus (for example with +* a set_pte). +*/ + smp_wmb(); if (bio->bi_end_io) bio->bi_end_io(bio, bytes_done, error); } --- End Message ---
[2.6.22.y] {00/17} series for stable kernel #2
01/17** do_anonymous_page-race 02/17 invalid-semicolon 03/17 pci-fix-unterminated-pci_device_id-lists 04/17 cciss-panic-in-blk_rq_map_sg 05/17 cciss-fix_memory_leak 06/17 handle-bogus-%cs-selector-in-single-step-instruction-decoding 07/17 i386-fixup-TRACE_IRQ-breakage 08/17 intel-agp-965gme-fix 09/17 sony-laptop-call-sonypi_compat_init-earlier 10/17 via-velocity-dont-oops-on-mtu-change-1 11/17 via-velocity-dont-oops-on-mtu-change-2 12/17 nfsacl-retval.diff 13/17 nfs-fix-nfs-reval-fsid 14/17 nfs-name-len-limit 15/17 nfs-unmount-leak.patch 16/17 nfsv4-MAXNAME-fix.diff 17/17** nopage-range-fix.patch Patch 1 and 17 not included is mainline -- Thanks, Oliver -- 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 22/27] quicklist: Set tlb->need_flush if pages are remaining in quicklist 0
On Fri, 1 Feb 2008, Justin M. Forbes wrote: > > On Fri, 2008-02-01 at 16:39 -0800, Christoph Lameter wrote: > > NO! Wrong fix. Was dropped from mainline. > > What is the right fix for the OOM issues with 2.6.22? Perhaps > http://marc.info/?l=linux-mm=119973653803451=2 should be added to > the queue in its place? The OOM issue in 2.6.22 is real, and should be > addressed. Indeed that is the right fix. -- 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: Feature Removals for 2.6.25
On Thu, Jan 31, 2008 at 05:38:42PM -0800, Harvey Harrison wrote: > --- > Ping? > What: vm_ops.nopage > When: Soon, provided in-kernel callers have been converted > Why: This interface is replaced by vm_ops.fault, but it has been around > forever, is used by a lot of drivers, and doesn't cost much to > maintain. > Who: Nick Piggin <[EMAIL PROTECTED]> Well the in-kernel callers have not all been converted yet. I have actually done the work, but it needs testing and merging by maintainers. Getting it done during this merge window would be nice, I'm going to try to make that happen after I get back from LCA. Otherwise probably 2.6.26. -- 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] PCI patches for 2.6.24
On Fri, 1 Feb 2008 16:49:16 -0800 Greg KH <[EMAIL PROTECTED]> wrote: > > --- a/drivers/pci/pcie/Kconfig~fix-gregkh-pci-pci-pcie-aspm-support > > +++ a/drivers/pci/pcie/Kconfig > > @@ -32,7 +32,7 @@ source "drivers/pci/pcie/aer/Kconfig" > > # > > config PCIEASPM > > bool "PCI Express ASPM support(Experimental)" > > - depends on PCI && EXPERIMENTAL > > + depends on PCI && EXPERIMENTAL && PCIEPORTBUS > > default y > > help > > This enables PCI Express ASPM (Active State Power Management) and > > _ > > Oops, sorry, I'll add that to my queue for the next round. Was "default y" 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/
Re: [PATCH] correct inconsistent ntp interval/tick_length usage
On Thu, 2008-01-31 at 06:02 +0100, Roman Zippel wrote: > Hi, > > On Wed, 30 Jan 2008, john stultz wrote: > > > My concern is we state the accumulation interval is X ns long. Then > > current_tick_length() is to return (X + ntp_adjustment), so each > > accumulation interval we can keep track of the error and adjust our > > interval length. > > > > So if ntp_update_frequency() sets tick_length_base to be: > > > > u64 second_length = (u64)(tick_usec * NSEC_PER_USEC * USER_HZ) > > << TICK_LENGTH_SHIFT; > > second_length += (s64)CLOCK_TICK_ADJUST << TICK_LENGTH_SHIFT; > > second_length += (s64)time_freq > > << (TICK_LENGTH_SHIFT - SHIFT_NSEC); > > > > tick_length_base = second_length; > > do_div(tick_length_base, NTP_INTERVAL_FREQ); > > > > > > The above is basically (X + part of ntp_adjustment) > > CLOCK_TICK_ADJUST is based on LATCH and HZ, if the update frequency isn't > based on HZ, there is no point in using it! Hey Roman, Again, I'm sorry I don't seem to be following your objections. If you want to suggest a different patch to fix the issue, it might help. The big issue for me, is that we have to initialize the clocksource cycle interval so it matches the base tick_length that NTP uses. To be clear, the issue I'm trying to address is only this: Assuming there is no NTP adjustment yet to be made, if we initialize the clocksource interval to X, then compare it with Y when we accumulate, we introduce error if X and Y are not the same. It really doesn't matter how long the length is, if we're including CLOCK_TICK_ADJUST, or if it really matches the actual HZ tick length or not. The issue is that we have to be consistent. If we're not, then we introduce error that ntpd has to additionally correct for. Now, once we're consistent, then CLOCK_TICK_ADJUST can be zero or not and it won't really matter, other then making sure we accumulate at exact tick length units. You can set it either way with my patch and things will still work out to be correct. My apologies for being so thick headed if I'm just missing something. I do appreciate the feedback. -john -- 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] as_merged_requests(): possible recursive locking detected
On Friday 01 February 2008 21:31, Jens Axboe wrote:
> On Fri, Feb 01 2008, Jens Axboe wrote:
> > I think the right solution is to remove swap_io_context() and fix the io
> > context referencing in as-iosched.c instead.
>
> IOW, the below. I don't know why Nick originally wanted to swap io
> contexts for a rq <-> rq merge, there seems little (if any) benefit to
> doing so.
Yeah, I guess this patch is fine. Simpler is better.
>
> diff --git a/block/as-iosched.c b/block/as-iosched.c
> index 9603684..852803e 100644
> --- a/block/as-iosched.c
> +++ b/block/as-iosched.c
> @@ -1266,22 +1266,8 @@ static void as_merged_requests(struct request_queue
> *q, struct request *req, */
> if (!list_empty(>queuelist) && !list_empty(>queuelist)) {
> if (time_before(rq_fifo_time(next), rq_fifo_time(req))) {
> - struct io_context *rioc = RQ_IOC(req);
> - struct io_context *nioc = RQ_IOC(next);
> -
> list_move(>queuelist, >queuelist);
> rq_set_fifo_time(req, rq_fifo_time(next));
> - /*
> - * Don't copy here but swap, because when anext is
> - * removed below, it must contain the unused context
> - */
> - if (rioc != nioc) {
> - double_spin_lock(>lock, >lock,
> - rioc < nioc);
> - swap_io_context(, );
> - double_spin_unlock(>lock, >lock,
> - rioc < nioc);
> - }
> }
> }
>
> diff --git a/block/blk-ioc.c b/block/blk-ioc.c
> index 6d16755..80245dc 100644
> --- a/block/blk-ioc.c
> +++ b/block/blk-ioc.c
> @@ -176,15 +176,6 @@ void copy_io_context(struct io_context **pdst, struct
> io_context **psrc) }
> EXPORT_SYMBOL(copy_io_context);
>
> -void swap_io_context(struct io_context **ioc1, struct io_context **ioc2)
> -{
> - struct io_context *temp;
> - temp = *ioc1;
> - *ioc1 = *ioc2;
> - *ioc2 = temp;
> -}
> -EXPORT_SYMBOL(swap_io_context);
> -
> int __init blk_ioc_init(void)
> {
> iocontext_cachep = kmem_cache_create("blkdev_ioc",
> diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
> index baba233..bbe3cf4 100644
> --- a/include/linux/blkdev.h
> +++ b/include/linux/blkdev.h
> @@ -39,7 +39,6 @@ void exit_io_context(void);
> struct io_context *get_io_context(gfp_t gfp_flags, int node);
> struct io_context *alloc_io_context(gfp_t gfp_flags, int node);
> void copy_io_context(struct io_context **pdst, struct io_context **psrc);
> -void swap_io_context(struct io_context **ioc1, struct io_context **ioc2);
>
> struct request;
> typedef void (rq_end_io_fn)(struct request *, int);
--
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.22.y] {00/17} series for stable kernel
hi! then i searched the git id's and resnd the patches On 2/2/08, Greg KH <[EMAIL PROTECTED]> wrote: > On Tue, Jan 29, 2008 at 12:13:13AM +0100, Oliver Pinter (Pint?r Oliv?r) > wrote: > > do_anonymous_page-race NOT PART OF mainline - or I not find - openSUSE patch > > invalid-semicolon 2b02d13996fe28478e45605de9bd8bdca25718de > > pci-fix-unterminated-pci_device_id-lists 248bdd5efca5a113cbf443a993c69e53d370236b > > cciss-panic-in-blk_rq_map_sg a683d652d334a546be9175b894f42dbd8e399536 > > cciss-fix_memory_leak f2912a1223c0917a7b4e054f18086209137891ea > > handle-bogus-%cs-selector-in-single-step-instruction-decoding > > 29eb51101c02df517ca64ec472d7501127ad1da8 > > i386-fixup-TRACE_IRQ-breakage a10d9a71bafd3a283da240d2868e71346d2aef6f > > intel-agp-965gme-fix dde4787642ee3cb85aef80bdade04b6f8ddc3df8 > > sony-laptop-call-sonypi_compat_init-earlier 015a916fbbf105bb15f4bbfd80c3b9b2f2e0d7db > > via-velocity-dont-oops-on-mtu-change-1 bd7b3f34198071d8bec05180530c362f1800ba46 > > via-velocity-dont-oops-on-mtu-change-2 48f6b053613b62fed7a2fe3255e5568260a8d615 > > nfsacl-retval.diff ac8587dcb58e40dd336d99d60f852041e06cc3dd > > nfs-fix-nfs-reval-fsid a0356862bcbeb20acf64bc1a82d28a4c5bb957a7 > > nfs-name-len-limit 54af3bb543c071769141387a42deaaab5074da55 > > nfs-unmount-leak.patch 13ef7b69b54aa8ae4ed264d0bf41339737f8543a - in mainline from comment: ...skipping... ?! > > nfsv4-MAXNAME-fix.diff a16e92edcd0a2846455a30823e1bac964e743baa > > nopage-range-fix.patch NOT PART OF the mainline - or I not find - original openSUSE patch > > > > this patches is from suse 10.3 kernel, the most is applyied in > > mainline, but 2 not. > > But which 2 are not? We can't add them to the -stable tree unless they > are. > > Can you resend the ones that are already upstream, with the git commit > ids? You did that with some, but not all, and more than 2, so I really > have no idea what to apply here. > > So I guess I'll drop all of these, as I really don't want to go digging > to figure it out :( > > thanks, > > greg k-h > -- Thanks, Oliver -- 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 22/27] quicklist: Set tlb->need_flush if pages are remaining in quicklist 0
On Fri, Feb 01, 2008 at 04:39:08PM -0800, Christoph Lameter wrote: > NO! Wrong fix. Was dropped from mainline. Thanks for letting us know, now dropped. 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: 2.6.24 regression: pan hanging unkilleable and un-straceable
On Friday 01 February 2008 09:45, Frederik Himpe wrote: > On ma, 2008-01-28 at 12:46 +1100, Nick Piggin wrote: > > On Sunday 27 January 2008 00:29, Frederik Himpe wrote: > > > On di, 2008-01-22 at 16:25 +1100, Nick Piggin wrote: > > > > > > On Tuesday 22 January 2008 07:58, Frederik Himpe wrote: > > > > > > > With Linux 2.6.24-rc8 I often have the problem that the pan > > > > > > > usenet reader starts using 100% of CPU time after some time. > > > > > > > When this happens, kill -9 does not work, and strace just hangs > > > > > > > when trying to attach to the process. The same with gdb. ps > > > > > > > shows the process as being in the R state. > > > > Well after trying a lot of writev combinations, I've reproduced a hang > > *hangs head*. > > > > Does this help? > > Just to confirm: in four days of testing, I haven't seen the problem > anymore, so it looks like this was indeed the right fix. Thanks very much for reporting and testing. This patch needs to go into 2.6.24.stable and upstream. -- 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] PCI patches for 2.6.24
On Fri, Feb 01, 2008 at 04:42:06PM -0800, Andrew Morton wrote:
> On Fri, 1 Feb 2008 15:11:47 -0800
> Greg KH <[EMAIL PROTECTED]> wrote:
>
> > PCI: PCIE ASPM support
>
> drivers/built-in.o: In function `pci_scan_slot':
> drivers/pci/probe.c:1016: undefined reference to `pcie_aspm_init_link_state'
> drivers/built-in.o: In function `pci_stop_dev':
> drivers/pci/remove.c:36: undefined reference to `pcie_aspm_exit_link_state'
> drivers/built-in.o: In function `pci_set_power_state':
> drivers/pci/pci.c:524: undefined reference to `pcie_aspm_pm_state_change'
> make: *** [.tmp_vmlinux1] Error 1
>
> http://userweb.kernel.org/~akpm/config-vmm.txt
>
>
> Needs this, I guess:
>
>
> --- a/drivers/pci/pcie/Kconfig~fix-gregkh-pci-pci-pcie-aspm-support
> +++ a/drivers/pci/pcie/Kconfig
> @@ -32,7 +32,7 @@ source "drivers/pci/pcie/aer/Kconfig"
> #
> config PCIEASPM
> bool "PCI Express ASPM support(Experimental)"
> - depends on PCI && EXPERIMENTAL
> + depends on PCI && EXPERIMENTAL && PCIEPORTBUS
> default y
> help
> This enables PCI Express ASPM (Active State Power Management) and
> _
Oops, sorry, I'll add that to my queue for the next round.
>
> Also, that ASPM patch unnecessarily adds a pile of macros:
>
> +#ifdef CONFIG_PCIEASPM
> +extern void pcie_aspm_init_link_state(struct pci_dev *pdev);
> +extern void pcie_aspm_exit_link_state(struct pci_dev *pdev);
> +extern void pcie_aspm_pm_state_change(struct pci_dev *pdev);
> +extern void pci_disable_link_state(struct pci_dev *pdev, int state);
> +#else
> +#define pcie_aspm_init_link_state(pdev)do {} while (0)
> +#define pcie_aspm_exit_link_state(pdev)do {} while (0)
> +#define pcie_aspm_pm_state_change(pdev)do {} while (0)
> +#define pci_disable_link_state(pdev, state)do {} while (0)
> +#endif
>
> Please don't do this.
>
> A static inline function is cleaner and provides typechecking. It also
> provides an access to the caller's argument and can avoid unused-varaiable
> warnings.
>
> The only reason to use a macro in this situation is if the caller's
> argument is for some reason not defined if !CONFIG_PCIEASPM.
>
> Greg, please check for this in your reviewing - reject macros *by default*.
> They are inferior.
Ick, missed that, again, my appologies. In cleaning up pci.h I saw a
few places like this, I'll fix that next go-around also.
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: [PATCH] Add iSCSI iBFT support (v0.4.6)
On Fri, 01 Feb 2008 18:18:09 -0600 James Bottomley <[EMAIL PROTECTED]> wrote: > Also, move the reserve_bootmem into the ibft_find routines and ensure > they're only called once on boot. And note that the reserve_bootmem() interface is about to change. http://userweb.kernel.org/~akpm/mmotm/broken-out/introduce-flags-for-reserve_bootmem.patch -- 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: kernel panic on 2.6.24/iTCO_wdt not rebooting machine
I check, watchdog still doesn't work with acpi=off, nor with pnpacpi=off I will try to check technical documents about chipset, to find any reference to watchdog registers, maybe i can see there something useful. On Fri, 1 Feb 2008 15:39:08 -0500, Len Brown wrote > On Friday 01 February 2008 14:15, Denys Fedoryshchenko wrote: > > > > On Fri, 1 Feb 2008 12:11:41 -0500, Len Brown wrote > > > > > > What do you see if you build with CONFIG_HIGH_RES_TIMERS=n > > > > > > Does it work better if you boot with "acpi=off"? > > > if yes, how about with just pnpacpi=off? > > > > > > thanks, > > > -Len > > > > It is not very easy to test. About bug - most probably it is related to third > > party ESFQ patch, i will drop it and then test more properly when i will be > > able to make watchdog work fine. But more important i notice - that iTCO_wdt > > is not working at all. I think hrtimers doesn't change anything on that. > > About testing, i cannot take even small risk now(and near 3-5 days) by > > changing kernel options, i set now maximum available set of watchdogs, cause > > there is noone to maintain server, area is unreachable because of snow and > > bad weather. > > > > Do you think reasonable to try acpi / pnpacpi with iTCO_wdt to make it work? > > Maybe just registers addresses or way how TCO watchdog activated changed on > > this chipset? > > yes, i'm wondering if the changes in IO resource reservations > in the PNPACPI layer are interfering with the native driver. > > unfortunately, if you boot with acpi=off or pnpacpi=off, you may > run into other, unrelated, issues (or not). > > one way to isolate the problem is if you revert these two lines > from their 2.6.24 values to their 2.6.23 values by applying this patch: > --- > diff --git a/include/linux/pnp.h b/include/linux/pnp.h > index 2a6d62c..16b46aa 100644 > --- a/include/linux/pnp.h > +++ b/include/linux/pnp.h > @@ -13,8 +13,8 @@ > #include > #include > > -#define PNP_MAX_PORT 40 > -#define PNP_MAX_MEM 12 > +#define PNP_MAX_PORT 8 > +#define PNP_MAX_MEM 4 > #define PNP_MAX_IRQ 2 > #define PNP_MAX_DMA 2 > #define PNP_NAME_LEN 50 -- Denys Fedoryshchenko Technical Manager Virtual ISP S.A.L. -- 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: sparse errors from string_32.h
On Fri, 2008-02-01 at 10:06 -0800, H. Peter Anvin wrote: > Ingo Molnar wrote: > > * Harvey Harrison <[EMAIL PROTECTED]> wrote: > > > >>case 1: > >> - *(unsigned char *)s = pattern; > >> + *(unsigned char *)s = pattern & 0xff; > > > > i've applied your fix - but wouldnt it be cleaner to just cast the > > pattern variable to unsigned char instead? > > > > Even better, since we're talking about fixed bytes, I suggest writing it as: > > *(u8 *)s = (u8)pattern; > > Much more compact and the intent is a little bit more obvious. > While I agree that is cleaner, that will still produce sparse warnings about a cast truncating bits from a constant value. I think that explicit & is necessary (unless the cure is worse than the disease). Harvey -- 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] PCI patches for 2.6.24
On Fri, 1 Feb 2008 15:11:47 -0800
Greg KH <[EMAIL PROTECTED]> wrote:
> PCI: PCIE ASPM support
drivers/built-in.o: In function `pci_scan_slot':
drivers/pci/probe.c:1016: undefined reference to `pcie_aspm_init_link_state'
drivers/built-in.o: In function `pci_stop_dev':
drivers/pci/remove.c:36: undefined reference to `pcie_aspm_exit_link_state'
drivers/built-in.o: In function `pci_set_power_state':
drivers/pci/pci.c:524: undefined reference to `pcie_aspm_pm_state_change'
make: *** [.tmp_vmlinux1] Error 1
http://userweb.kernel.org/~akpm/config-vmm.txt
Needs this, I guess:
--- a/drivers/pci/pcie/Kconfig~fix-gregkh-pci-pci-pcie-aspm-support
+++ a/drivers/pci/pcie/Kconfig
@@ -32,7 +32,7 @@ source "drivers/pci/pcie/aer/Kconfig"
#
config PCIEASPM
bool "PCI Express ASPM support(Experimental)"
- depends on PCI && EXPERIMENTAL
+ depends on PCI && EXPERIMENTAL && PCIEPORTBUS
default y
help
This enables PCI Express ASPM (Active State Power Management) and
_
Also, that ASPM patch unnecessarily adds a pile of macros:
+#ifdef CONFIG_PCIEASPM
+extern void pcie_aspm_init_link_state(struct pci_dev *pdev);
+extern void pcie_aspm_exit_link_state(struct pci_dev *pdev);
+extern void pcie_aspm_pm_state_change(struct pci_dev *pdev);
+extern void pci_disable_link_state(struct pci_dev *pdev, int state);
+#else
+#define pcie_aspm_init_link_state(pdev)do {} while (0)
+#define pcie_aspm_exit_link_state(pdev)do {} while (0)
+#define pcie_aspm_pm_state_change(pdev)do {} while (0)
+#define pci_disable_link_state(pdev, state)do {} while (0)
+#endif
Please don't do this.
A static inline function is cleaner and provides typechecking. It also
provides an access to the caller's argument and can avoid unused-varaiable
warnings.
The only reason to use a macro in this situation is if the caller's
argument is for some reason not defined if !CONFIG_PCIEASPM.
Greg, please check for this in your reviewing - reject macros *by default*.
They are inferior.
--
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 22/27] quicklist: Set tlb->need_flush if pages are remaining in quicklist 0
NO! Wrong fix. Was dropped from mainline. -- 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/5] ide: add ide_read_error() inline helper
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ide/ide-cd.c |2 +-
drivers/ide/ide-floppy.c |2 +-
drivers/ide/ide-io.c |4 ++--
drivers/ide/ide-iops.c |4 +++-
drivers/ide/ide-lib.c |2 +-
drivers/ide/ide-tape.c |2 +-
drivers/ide/ide-taskfile.c |5 ++---
include/linux/ide.h|7 +++
8 files changed, 18 insertions(+), 10 deletions(-)
Index: b/drivers/ide/ide-cd.c
===
--- a/drivers/ide/ide-cd.c
+++ b/drivers/ide/ide-cd.c
@@ -304,7 +304,7 @@ static int cdrom_decode_status(ide_drive
return 0;
/* Get the IDE error register. */
- err = HWIF(drive)->INB(IDE_ERROR_REG);
+ err = ide_read_error(drive);
sense_key = err >> 4;
if (rq == NULL) {
Index: b/drivers/ide/ide-floppy.c
===
--- a/drivers/ide/ide-floppy.c
+++ b/drivers/ide/ide-floppy.c
@@ -465,7 +465,7 @@ static void idefloppy_retry_pc(ide_drive
idefloppy_pc_t *pc;
struct request *rq;
- (void)drive->hwif->INB(IDE_ERROR_REG);
+ (void)ide_read_error(drive);
pc = idefloppy_next_pc_storage(drive);
rq = idefloppy_next_rq_storage(drive);
idefloppy_create_request_sense_cmd(pc);
Index: b/drivers/ide/ide-io.c
===
--- a/drivers/ide/ide-io.c
+++ b/drivers/ide/ide-io.c
@@ -821,8 +821,8 @@ static ide_startstop_t execute_drive_cmd
#ifdef DEBUG
printk("%s: DRIVE_CMD (null)\n", drive->name);
#endif
- ide_end_drive_cmd(drive, ide_read_status(drive),
- hwif->INB(IDE_ERROR_REG));
+ ide_end_drive_cmd(drive, ide_read_status(drive), ide_read_error(drive));
+
return ide_stopped;
}
Index: b/drivers/ide/ide-iops.c
===
--- a/drivers/ide/ide-iops.c
+++ b/drivers/ide/ide-iops.c
@@ -918,7 +918,9 @@ static ide_startstop_t reset_pollfunc (i
drive->failures++;
} else {
printk("%s: reset: ", hwif->name);
- if ((tmp = hwif->INB(IDE_ERROR_REG)) == 1) {
+ tmp = ide_read_error(drive);
+
+ if (tmp == 1) {
printk("success\n");
drive->failures = 0;
} else {
Index: b/drivers/ide/ide-lib.c
===
--- a/drivers/ide/ide-lib.c
+++ b/drivers/ide/ide-lib.c
@@ -578,7 +578,7 @@ u8 ide_dump_status(ide_drive_t *drive, c
}
printk("}\n");
if ((stat & (BUSY_STAT|ERR_STAT)) == ERR_STAT) {
- err = drive->hwif->INB(IDE_ERROR_REG);
+ err = ide_read_error(drive);
printk("%s: %s: error=0x%02x ", drive->name, msg, err);
if (drive->media == ide_disk)
ide_dump_ata_error(drive, err);
Index: b/drivers/ide/ide-tape.c
===
--- a/drivers/ide/ide-tape.c
+++ b/drivers/ide/ide-tape.c
@@ -1125,7 +1125,7 @@ static ide_startstop_t idetape_retry_pc
idetape_pc_t *pc;
struct request *rq;
- (void)drive->hwif->INB(IDE_ERROR_REG);
+ (void)ide_read_error(drive);
pc = idetape_next_pc_storage(drive);
rq = idetape_next_rq_storage(drive);
idetape_create_request_sense_cmd(pc);
Index: b/drivers/ide/ide-taskfile.c
===
--- a/drivers/ide/ide-taskfile.c
+++ b/drivers/ide/ide-taskfile.c
@@ -241,7 +241,6 @@ static ide_startstop_t recal_intr(ide_dr
static ide_startstop_t task_no_data_intr(ide_drive_t *drive)
{
ide_task_t *args= HWGROUP(drive)->rq->special;
- ide_hwif_t *hwif= HWIF(drive);
u8 stat;
local_irq_enable_in_hardirq();
@@ -252,7 +251,7 @@ static ide_startstop_t task_no_data_intr
/* calls ide_end_drive_cmd */
if (args)
- ide_end_drive_cmd(drive, stat, hwif->INB(IDE_ERROR_REG));
+ ide_end_drive_cmd(drive, stat, ide_read_error(drive));
return ide_stopped;
}
@@ -408,7 +407,7 @@ static ide_startstop_t task_error(ide_dr
void task_end_request(ide_drive_t *drive, struct request *rq, u8 stat)
{
if (rq->cmd_type == REQ_TYPE_ATA_TASKFILE) {
- u8 err = drive->hwif->INB(IDE_ERROR_REG);
+ u8 err = ide_read_error(drive);
ide_end_drive_cmd(drive, stat, err);
return;
Index: b/include/linux/ide.h
===
--- a/include/linux/ide.h
+++ b/include/linux/ide.h
@@ -1325,4 +1325,11 @@ static inline u8 ide_read_altstatus(ide_
return hwif->INB(hwif->io_ports[IDE_CONTROL_OFFSET]);
}
+static inline u8
Re: [patch 2/4] mmu_notifier: Callbacks to invalidate address ranges
On Fri, Feb 01, 2008 at 06:21:45PM -0600, Robin Holt wrote: > On Fri, Feb 01, 2008 at 04:05:08PM -0800, Christoph Lameter wrote: > > Are you saying that you get the callback when transitioning from a read > > only to a read write pte on the *same* page? > > I believe that is what we saw. We have not put in any more debug > information yet. I will try to squeze it in this weekend. Otherwise, > I will probably have to wait until early Monday. I hate it when I am confused. I misunderstood what Dean had been saying. After I looked at his test case and remembering his screen at the time we were discussing, I am nearly positive that both the parent and child were still running (no exec, no exit). We would therefore have two refs on the page and, yes, be changing the pte which would warrant the callout. Now I really need to think this through more. Sounds like a good thing for Monday. Thanks, Robin -- 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 4/5] ide: add ide_read_[alt]status() inline helpers
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ide/arm/icside.c |2 -
drivers/ide/ide-cd.c |7 +++---
drivers/ide/ide-dma.c |3 +-
drivers/ide/ide-floppy.c |4 +--
drivers/ide/ide-io.c | 12 +--
drivers/ide/ide-iops.c | 39 +++--
drivers/ide/ide-probe.c| 47 +++--
drivers/ide/ide-tape.c |7 +++---
drivers/ide/ide-taskfile.c | 30 ++--
drivers/scsi/ide-scsi.c|4 +--
include/linux/ide.h| 14 +
11 files changed, 100 insertions(+), 69 deletions(-)
Index: b/drivers/ide/arm/icside.c
===
--- a/drivers/ide/arm/icside.c
+++ b/drivers/ide/arm/icside.c
@@ -365,7 +365,7 @@ static void icside_dma_timeout(ide_drive
if (icside_dma_test_irq(drive))
return;
- ide_dump_status(drive, "DMA timeout", HWIF(drive)->INB(IDE_STATUS_REG));
+ ide_dump_status(drive, "DMA timeout", ide_read_status(drive));
icside_dma_end(drive);
}
Index: b/drivers/ide/ide-cd.c
===
--- a/drivers/ide/ide-cd.c
+++ b/drivers/ide/ide-cd.c
@@ -295,7 +295,8 @@ static int cdrom_decode_status(ide_drive
int stat, err, sense_key;
/* Check for errors. */
- stat = HWIF(drive)->INB(IDE_STATUS_REG);
+ stat = ide_read_status(drive);
+
if (stat_ret)
*stat_ret = stat;
@@ -692,7 +693,7 @@ int ide_cd_check_ireason(ide_drive_t *dr
/* Some drives (ASUS) seem to tell us that status
* info is available. just get it and ignore.
*/
- (void) HWIF(drive)->INB(IDE_STATUS_REG);
+ (void)ide_read_status(drive);
return 0;
} else {
/* Drive wants a command packet, or invalid ireason... */
@@ -1326,7 +1327,7 @@ ide_do_rw_cdrom (ide_drive_t *drive, str
if (blk_fs_request(rq)) {
if (info->cd_flags & IDE_CD_FLAG_SEEKING) {
unsigned long elapsed = jiffies - info->start_seek;
- int stat = HWIF(drive)->INB(IDE_STATUS_REG);
+ int stat = ide_read_status(drive);
if ((stat & SEEK_STAT) != SEEK_STAT) {
if (elapsed < IDECD_SEEK_TIMEOUT) {
Index: b/drivers/ide/ide-dma.c
===
--- a/drivers/ide/ide-dma.c
+++ b/drivers/ide/ide-dma.c
@@ -147,7 +147,8 @@ ide_startstop_t ide_dma_intr (ide_drive_
u8 stat = 0, dma_stat = 0;
dma_stat = HWIF(drive)->ide_dma_end(drive);
- stat = HWIF(drive)->INB(IDE_STATUS_REG);/* get drive status */
+ stat = ide_read_status(drive);
+
if (OK_STAT(stat,DRIVE_READY,drive->bad_wstat|DRQ_STAT)) {
if (!dma_stat) {
struct request *rq = HWGROUP(drive)->rq;
Index: b/drivers/ide/ide-floppy.c
===
--- a/drivers/ide/ide-floppy.c
+++ b/drivers/ide/ide-floppy.c
@@ -503,7 +503,7 @@ static ide_startstop_t idefloppy_pc_intr
}
/* Clear the interrupt */
- stat = drive->hwif->INB(IDE_STATUS_REG);
+ stat = ide_read_status(drive);
/* No more interrupts */
if ((stat & DRQ_STAT) == 0) {
@@ -1247,7 +1247,7 @@ static int idefloppy_get_format_progress
u8 stat;
local_irq_save(flags);
- stat = drive->hwif->INB(IDE_STATUS_REG);
+ stat = ide_read_status(drive);
local_irq_restore(flags);
progress_indication = ((stat & SEEK_STAT) == 0) ? 0 : 0x1;
Index: b/drivers/ide/ide-io.c
===
--- a/drivers/ide/ide-io.c
+++ b/drivers/ide/ide-io.c
@@ -466,7 +466,7 @@ static ide_startstop_t ide_ata_error(ide
return ide_stopped;
}
- if (hwif->INB(IDE_STATUS_REG) & (BUSY_STAT|DRQ_STAT))
+ if (ide_read_status(drive) & (BUSY_STAT | DRQ_STAT))
rq->errors |= ERROR_RESET;
if ((rq->errors & ERROR_RESET) == ERROR_RESET) {
@@ -493,7 +493,7 @@ static ide_startstop_t ide_atapi_error(i
/* add decoding error stuff */
}
- if (hwif->INB(IDE_STATUS_REG) & (BUSY_STAT|DRQ_STAT))
+ if (ide_read_status(drive) & (BUSY_STAT | DRQ_STAT))
/* force an abort */
hwif->OUTB(WIN_IDLEIMMEDIATE, IDE_COMMAND_REG);
@@ -821,8 +821,7 @@ static ide_startstop_t execute_drive_cmd
#ifdef DEBUG
printk("%s: DRIVE_CMD (null)\n", drive->name);
#endif
- ide_end_drive_cmd(drive,
- hwif->INB(IDE_STATUS_REG),
+ ide_end_drive_cmd(drive, ide_read_status(drive),
[PATCH 3/5] ide: remove ide_setup_ports()
ide-cris.c:
* Add cris_setup_ports() helper and use it instead of ide_setup_ports()
(fixes random value being set in ->io_ports[IDE_IRQ_OFFSET]).
buddha.c:
* Add buddha_setup_ports() helper and use it instead of ide_setup_ports().
falconide.c:
* Add falconide_setup_ports() helper and use it instead of ide_setup_ports(),
also fix return value of falconide_init() while at it.
gayle.c:
* Add gayle_setup_ports() helper and use it instead of ide_setup_ports().
macide.c:
* Add macide_setup_ports() helper and use it instead of ide_setup_ports()
(fixes incorrect value being set in ->io_ports[IDE_IRQ_OFFSET]).
q40ide.c:
* Fix q40_ide_setup_ports() comments.
ide.c:
* Remove no longer needed ide_setup_ports().
Cc: Mikael Starvik <[EMAIL PROTECTED]>
Cc: Geert Uytterhoeven <[EMAIL PROTECTED]>
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ide/cris/ide-cris.c| 33 --
drivers/ide/ide.c | 54 --
drivers/ide/legacy/buddha.c| 72 +
drivers/ide/legacy/falconide.c | 42 +++
drivers/ide/legacy/gayle.c | 39 +++---
drivers/ide/legacy/macide.c| 57 +---
drivers/ide/legacy/q40ide.c|9 -
include/linux/ide.h| 11 --
8 files changed, 133 insertions(+), 184 deletions(-)
Index: b/drivers/ide/cris/ide-cris.c
===
--- a/drivers/ide/cris/ide-cris.c
+++ b/drivers/ide/cris/ide-cris.c
@@ -753,6 +753,25 @@ static void cris_set_dma_mode(ide_drive_
cris_ide_set_speed(TYPE_DMA, 0, strobe, hold);
}
+static void __init cris_setup_ports(hw_regs_t *hw, unsigned long base)
+{
+ int i;
+
+ memset(hw, 0, sizeof(*hw));
+
+ for (i = 0; i <= 7; i++)
+ hw->io_ports[i] = base + cris_ide_reg_addr(i, 0, 1);
+
+ /*
+* the IDE control register is at ATA address 6,
+* with CS1 active instead of CS0
+*/
+ hw->io_ports[IDE_CONTROL_OFFSET] = base + cris_ide_reg_addr(6, 1, 0);
+
+ hw->irq = ide_default_irq(0);
+ hw->ack_intr = cris_ide_ack_intr;
+}
+
static const struct ide_port_info cris_port_info __initdata = {
.chipset= ide_etrax100,
.host_flags = IDE_HFLAG_NO_ATAPI_DMA |
@@ -765,24 +784,16 @@ static const struct ide_port_info cris_p
static int __init init_e100_ide(void)
{
hw_regs_t hw;
- int ide_offsets[IDE_NR_PORTS], h, i;
+ int h;
u8 idx[4] = { 0xff, 0xff, 0xff, 0xff };
printk("ide: ETRAX FS built-in ATA DMA controller\n");
- for (i = IDE_DATA_OFFSET; i <= IDE_STATUS_OFFSET; i++)
- ide_offsets[i] = cris_ide_reg_addr(i, 0, 1);
-
- /* the IDE control register is at ATA address 6, with CS1 active
instead of CS0 */
- ide_offsets[IDE_CONTROL_OFFSET] = cris_ide_reg_addr(6, 1, 0);
-
for (h = 0; h < 4; h++) {
ide_hwif_t *hwif = NULL;
- ide_setup_ports(, cris_ide_base_address(h),
- ide_offsets,
- 0, 0, cris_ide_ack_intr,
- ide_default_irq(0));
+ cris_setup_ports(, cris_ide_base_address(h));
+
hwif = ide_find_port(hw.io_ports[IDE_DATA_OFFSET]);
if (hwif == NULL)
continue;
Index: b/drivers/ide/ide.c
===
--- a/drivers/ide/ide.c
+++ b/drivers/ide/ide.c
@@ -618,60 +618,6 @@ abort:
EXPORT_SYMBOL(ide_unregister);
-
-/**
- * ide_setup_ports - set up IDE interface ports
- * @hw: register descriptions
- * @base: base register
- * @offsets: table of register offsets
- * @ctrl: control register
- * @ack_irq: IRQ ack
- * @irq: interrupt lie
- *
- * Setup hw_regs_t structure described by parameters. You
- * may set up the hw structure yourself OR use this routine to
- * do it for you. This is basically a helper
- *
- */
-
-void ide_setup_ports ( hw_regs_t *hw,
- unsigned long base, int *offsets,
- unsigned long ctrl, unsigned long intr,
- ide_ack_intr_t *ack_intr,
-/*
- * ide_io_ops_t *iops,
- */
- int irq)
-{
- int i;
-
- memset(hw, 0, sizeof(hw_regs_t));
- for (i = 0; i < IDE_NR_PORTS; i++) {
- if (offsets[i] == -1) {
- switch(i) {
- case IDE_CONTROL_OFFSET:
- hw->io_ports[i] = ctrl;
- break;
-#if defined(CONFIG_AMIGA) || defined(CONFIG_MAC)
- case IDE_IRQ_OFFSET:
- hw->io_ports[i] = intr;
-
[PATCH 2/5] ide: remove redundant BUG_ON() from [atapi_]reset_pollfunc()
Same BUG_ON() is present inside ide_set_handler().
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ide/ide-iops.c |2 --
1 file changed, 2 deletions(-)
Index: b/drivers/ide/ide-iops.c
===
--- a/drivers/ide/ide-iops.c
+++ b/drivers/ide/ide-iops.c
@@ -860,7 +860,6 @@ static ide_startstop_t atapi_reset_pollf
printk("%s: ATAPI reset complete\n", drive->name);
} else {
if (time_before(jiffies, hwgroup->poll_timeout)) {
- BUG_ON(HWGROUP(drive)->handler != NULL);
ide_set_handler(drive, _reset_pollfunc, HZ/20,
NULL);
/* continue polling */
return ide_started;
@@ -900,7 +899,6 @@ static ide_startstop_t reset_pollfunc (i
if (!OK_STAT(tmp = hwif->INB(IDE_STATUS_REG), 0, BUSY_STAT)) {
if (time_before(jiffies, hwgroup->poll_timeout)) {
- BUG_ON(HWGROUP(drive)->handler != NULL);
ide_set_handler(drive, _pollfunc, HZ/20, NULL);
/* continue polling */
return ide_started;
--
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/5] ide: remove write-only ->sata_misc[] from ide_hwif_t
* Remove write-only ->sata_misc[] from ide_hwif_t.
* Remove no longer used SATA_{MISC,PHY,IEN}_OFFSET defines.
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ide/pci/siimage.c |3 ---
include/linux/ide.h |5 -
2 files changed, 8 deletions(-)
Index: b/drivers/ide/pci/siimage.c
===
--- a/drivers/ide/pci/siimage.c
+++ b/drivers/ide/pci/siimage.c
@@ -704,9 +704,6 @@ static void __devinit init_mmio_iops_sii
hwif->sata_scr[SATA_STATUS_OFFSET] = base + 0x104;
hwif->sata_scr[SATA_ERROR_OFFSET] = base + 0x108;
hwif->sata_scr[SATA_CONTROL_OFFSET] = base + 0x100;
- hwif->sata_misc[SATA_MISC_OFFSET] = base + 0x140;
- hwif->sata_misc[SATA_PHY_OFFSET]= base + 0x144;
- hwif->sata_misc[SATA_IEN_OFFSET]= base + 0x148;
}
memcpy(hwif->io_ports, hw.io_ports, sizeof(hwif->io_ports));
Index: b/include/linux/ide.h
===
--- a/include/linux/ide.h
+++ b/include/linux/ide.h
@@ -115,10 +115,6 @@ typedef unsigned char byte; /* used ever
#define SATA_ERROR_OFFSET (1)
#define SATA_CONTROL_OFFSET(2)
-#define SATA_MISC_OFFSET (0)
-#define SATA_PHY_OFFSET(1)
-#define SATA_IEN_OFFSET(2)
-
/*
* Our Physical Region Descriptor (PRD) table should be large enough
* to handle the biggest I/O request we are likely to see. Since requests
@@ -473,7 +469,6 @@ typedef struct hwif_s {
/* task file registers for pata and sata */
unsigned long io_ports[IDE_NR_PORTS];
unsigned long sata_scr[SATA_NR_PORTS];
- unsigned long sata_misc[SATA_NR_PORTS];
ide_drive_t drives[MAX_DRIVES]; /* drive info */
--
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/
x86/.../trampoline_64.S racy?
Hi!
I'm trying to reuse trampoline_64.S for wakeup from ACPI s3... but I'm
getting some badness: If I insert delay loops into trampoline_64.S,
machine fails to boot; but I already increased cpu bootup delay to 200
seconds...
Is it possible that bootup is subtly racy somewhere?
diff --git a/arch/x86/kernel/smpboot_64.c b/arch/x86/kernel/smpboot_64.c
index aaf4e12..3961bcb 100644
--- a/arch/x86/kernel/smpboot_64.c
+++ b/arch/x86/kernel/smpboot_64.c
@@ -188,7 +188,7 @@ void __cpuinit smp_callin(void)
/*
* Waiting 2s total for startup (udelay is not yet working)
*/
- timeout = jiffies + 2*HZ;
+ timeout = jiffies + 200*HZ;
while (time_before(jiffies, timeout)) {
/*
* Has the boot CPU finished it's STARTUP sequence?
diff --git a/arch/x86/kernel/trampoline_64.S b/arch/x86/kernel/trampoline_64.S
index 4aedd0b..34fe9a7 100644
--- a/arch/x86/kernel/trampoline_64.S
+++ b/arch/x86/kernel/trampoline_64.S
@@ -24,12 +24,48 @@
* entries.
*/
+
#include
#include
#include
#include
#include
+
+#define BEEP \
+ inb $97, %al; \
+ outb%al, $0x80; \
+ movb$3, %al;\
+ outb%al, $97; \
+ outb%al, $0x80; \
+ movb$-74, %al; \
+ outb%al, $67; \
+ outb%al, $0x80; \
+ movb$-119, %al; \
+ outb%al, $66; \
+ outb%al, $0x80; \
+ movb$15, %al; \
+ outb%al, $66;
+
+#define DISPLAY(x) \
+ pushl %eax; \
+ movb$x, %al;\
+ outb%al, $0x80; \
+ popl%eax
+
+#define DISPLAY_UNSAFE(x) \
+ movb$x, %al;\
+ outb%al, $0x80; \
+
+#define DELAY_OK \
+ movl$0x3000,%ecx; \
+9: loopl 9b ;
+
+#define DELAY \
+ movl$1,%ecx ; \
+9: loopl 9b ;
+
+
/* We can free up trampoline after bootup if cpu hotplug is not supported. */
#ifndef CONFIG_HOTPLUG_CPU
.section .init.data, "aw", @progbits
@@ -55,6 +91,9 @@ r_base = .
# Setup stack
movw$(trampoline_stack_end - r_base), %sp
+ DISPLAY(0x70)
+ DELAY
+
callverify_cpu # Verify the cpu supports long mode
testl %eax, %eax # Check for return code
jnz no_longmode
@@ -78,6 +117,9 @@ r_base = .
lidtl tidt - r_base # load idt with 0, 0
lgdtl tgdt - r_base # load gdt with whatever is appropriate
+ DISPLAY(0x71)
+ DELAY
+
xor %ax, %ax
inc %ax # protected mode (PE) bit
lmsw%ax # into protected mode
@@ -91,6 +133,9 @@ startup_32:
movl$__KERNEL_DS, %eax # Initialize the %ds segment register
movl%eax, %ds
+ DISPLAY_UNSAFE(0x72)
+ DELAY
+
xorl%eax, %eax
btsl$5, %eax# Enable PAE mode
movl%eax, %cr4
@@ -109,6 +154,9 @@ startup_32:
btsl$0, %eax# Enable protected mode
movl%eax, %cr0
+ DISPLAY_UNSAFE(0x73)
+ DELAY
+
/*
* At this point we're in long mode but in 32bit compatibility mode
* with EFER.LME = 1, CS.L = 0, CS.D = 1 (and in turn
@@ -120,6 +168,9 @@ startup_32:
.code64
.balign 4
startup_64:
+ DISPLAY_UNSAFE(0x74)
+ DELAY
+
# Now jump into the kernel using virtual addresses
movq$secondary_startup_64, %rax
jmp *%rax
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 27/27] ACPI: apply quirk_ich6_lpc_acpi to more ICH8 and ICH9
2.6.22-stable review patch. If anyone has any objections, please let us know. -- From: Zhao Yakui <[EMAIL PROTECTED]> patch d1ec7298fcefd7e4d1ca612da402ce9e5d5e2c13 in mainline. It is important that these resources be reserved to avoid conflicts with well known ACPI registers. Signed-off-by: Zhao Yakui <[EMAIL PROTECTED]> Signed-off-by: Len Brown <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- drivers/pci/quirks.c|6 ++ include/linux/pci_ids.h |2 ++ 2 files changed, 8 insertions(+) --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -465,6 +465,12 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_I DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH8_0, quirk_ich6_lpc_acpi ); DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH8_2, quirk_ich6_lpc_acpi ); DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH8_3, quirk_ich6_lpc_acpi ); +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH8_1, quirk_ich6_lpc_acpi ); +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH8_4, quirk_ich6_lpc_acpi ); +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH9_2, quirk_ich6_lpc_acpi ); +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH9_4, quirk_ich6_lpc_acpi ); +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH9_7, quirk_ich6_lpc_acpi ); +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH9_8, quirk_ich6_lpc_acpi ); /* * VIA ACPI: One IO region pointed to by longword at --- a/include/linux/pci_ids.h +++ b/include/linux/pci_ids.h @@ -2285,6 +2285,8 @@ #define PCI_DEVICE_ID_INTEL_ICH9_4 0x2914 #define PCI_DEVICE_ID_INTEL_ICH9_5 0x2919 #define PCI_DEVICE_ID_INTEL_ICH9_6 0x2930 +#define PCI_DEVICE_ID_INTEL_ICH9_7 0x2916 +#define PCI_DEVICE_ID_INTEL_ICH9_8 0x2918 #define PCI_DEVICE_ID_INTEL_82855PM_HB 0x3340 #define PCI_DEVICE_ID_INTEL_82830_HB 0x3575 #define PCI_DEVICE_ID_INTEL_82830_CGC 0x3577 -- -- 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 26/27] POWERPC: Fix invalid semicolon after if statement
2.6.22-stable review patch. If anyone has any objections, please let us know. -- From: Ilpo Jrvinen <[EMAIL PROTECTED]> Patch 2b02d13996fe28478e45605de9bd8bdca25718de in mainline [POWERPC] Fix invalid semicolon after if statement A similar fix to netfilter from Eric Dumazet inspired me to look around a bit by using some grep/sed stuff as looking for this kind of bugs seemed easy to automate. This is one of them I found where it looks like this semicolon is not valid. Signed-off-by: Ilpo Jrvinen <[EMAIL PROTECTED]> Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- arch/powerpc/mm/hash_utils_64.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/powerpc/mm/hash_utils_64.c +++ b/arch/powerpc/mm/hash_utils_64.c @@ -795,7 +795,7 @@ void hash_preload(struct mm_struct *mm, #ifdef CONFIG_PPC_MM_SLICES /* We only prefault standard pages for now */ - if (unlikely(get_slice_psize(mm, ea) != mm->context.user_psize)); + if (unlikely(get_slice_psize(mm, ea) != mm->context.user_psize)) return; #endif -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 25/27] chelsio: Fix skb->dev setting
2.6.22-stable review patch. If anyone has any objections, please let us
know.
--
From: Divy Le Ray <[EMAIL PROTECTED]>
patch 7de6af0f23b25df8da9719ecae1916b669d0b03d in mainline.
eth_type_trans() now sets skb->dev.
Access skb->def after it gets set.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/net/chelsio/sge.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/chelsio/sge.c
+++ b/drivers/net/chelsio/sge.c
@@ -1378,10 +1378,10 @@ static void sge_rx(struct sge *sge, stru
}
__skb_pull(skb, sizeof(*p));
- skb->dev->last_rx = jiffies;
st = per_cpu_ptr(sge->port_stats[p->iff], smp_processor_id());
skb->protocol = eth_type_trans(skb, adapter->port[p->iff].dev);
+ skb->dev->last_rx = jiffies;
if ((adapter->flags & RX_CSUM_ENABLED) && p->csum == 0x &&
skb->protocol == htons(ETH_P_IP) &&
(skb->data[9] == IPPROTO_TCP || skb->data[9] == IPPROTO_UDP)) {
--
--
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 24/27] cxgb: fix stats
2.6.22-stable review patch. If anyone has any objections, please let us
know.
--
From: Divy Le Ray <[EMAIL PROTECTED]>
patch e0348b9ae5374f9a24424ae680bcd80724415f60 in mainline.
Fix MAC stats accounting.
Fix get_stats.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/net/chelsio/cxgb2.c | 67 +++--
drivers/net/chelsio/pm3393.c | 112 +--
drivers/net/chelsio/sge.c|4 -
drivers/net/chelsio/sge.h|2
4 files changed, 96 insertions(+), 89 deletions(-)
--- a/drivers/net/chelsio/cxgb2.c
+++ b/drivers/net/chelsio/cxgb2.c
@@ -370,7 +370,9 @@ static char stats_strings[][ETH_GSTRING_
"TxInternalMACXmitError",
"TxFramesWithExcessiveDeferral",
"TxFCSErrors",
-
+ "TxJumboFramesOk",
+ "TxJumboOctetsOk",
+
"RxOctetsOK",
"RxOctetsBad",
"RxUnicastFramesOK",
@@ -388,11 +390,11 @@ static char stats_strings[][ETH_GSTRING_
"RxInRangeLengthErrors",
"RxOutOfRangeLengthField",
"RxFrameTooLongErrors",
+ "RxJumboFramesOk",
+ "RxJumboOctetsOk",
/* Port stats */
- "RxPackets",
"RxCsumGood",
- "TxPackets",
"TxCsumOffload",
"TxTso",
"RxVlan",
@@ -455,23 +457,56 @@ static void get_stats(struct net_device
const struct cmac_statistics *s;
const struct sge_intr_counts *t;
struct sge_port_stats ss;
- unsigned int len;
s = mac->ops->statistics_update(mac, MAC_STATS_UPDATE_FULL);
-
- len = sizeof(u64)*(>TxFCSErrors + 1 - >TxOctetsOK);
- memcpy(data, >TxOctetsOK, len);
- data += len;
-
- len = sizeof(u64)*(>RxFrameTooLongErrors + 1 - >RxOctetsOK);
- memcpy(data, >RxOctetsOK, len);
- data += len;
-
+ t = t1_sge_get_intr_counts(adapter->sge);
t1_sge_get_port_stats(adapter->sge, dev->if_port, );
- memcpy(data, , sizeof(ss));
- data += sizeof(ss);
- t = t1_sge_get_intr_counts(adapter->sge);
+ *data++ = s->TxOctetsOK;
+ *data++ = s->TxOctetsBad;
+ *data++ = s->TxUnicastFramesOK;
+ *data++ = s->TxMulticastFramesOK;
+ *data++ = s->TxBroadcastFramesOK;
+ *data++ = s->TxPauseFrames;
+ *data++ = s->TxFramesWithDeferredXmissions;
+ *data++ = s->TxLateCollisions;
+ *data++ = s->TxTotalCollisions;
+ *data++ = s->TxFramesAbortedDueToXSCollisions;
+ *data++ = s->TxUnderrun;
+ *data++ = s->TxLengthErrors;
+ *data++ = s->TxInternalMACXmitError;
+ *data++ = s->TxFramesWithExcessiveDeferral;
+ *data++ = s->TxFCSErrors;
+ *data++ = s->TxJumboFramesOK;
+ *data++ = s->TxJumboOctetsOK;
+
+ *data++ = s->RxOctetsOK;
+ *data++ = s->RxOctetsBad;
+ *data++ = s->RxUnicastFramesOK;
+ *data++ = s->RxMulticastFramesOK;
+ *data++ = s->RxBroadcastFramesOK;
+ *data++ = s->RxPauseFrames;
+ *data++ = s->RxFCSErrors;
+ *data++ = s->RxAlignErrors;
+ *data++ = s->RxSymbolErrors;
+ *data++ = s->RxDataErrors;
+ *data++ = s->RxSequenceErrors;
+ *data++ = s->RxRuntErrors;
+ *data++ = s->RxJabberErrors;
+ *data++ = s->RxInternalMACRcvError;
+ *data++ = s->RxInRangeLengthErrors;
+ *data++ = s->RxOutOfRangeLengthField;
+ *data++ = s->RxFrameTooLongErrors;
+ *data++ = s->RxJumboFramesOK;
+ *data++ = s->RxJumboOctetsOK;
+
+ *data++ = ss.rx_cso_good;
+ *data++ = ss.tx_cso;
+ *data++ = ss.tx_tso;
+ *data++ = ss.vlan_xtract;
+ *data++ = ss.vlan_insert;
+ *data++ = ss.tx_need_hdrroom;
+
*data++ = t->rx_drops;
*data++ = t->pure_rsps;
*data++ = t->unhandled_irqs;
--- a/drivers/net/chelsio/pm3393.c
+++ b/drivers/net/chelsio/pm3393.c
@@ -45,7 +45,7 @@
#include
-#define OFFSET(REG_ADDR)(REG_ADDR << 2)
+#define OFFSET(REG_ADDR)((REG_ADDR) << 2)
/* Max frame size PM3393 can handle. Includes Ethernet header and CRC. */
#define MAX_FRAME_SIZE 9600
@@ -428,69 +428,26 @@ static int pm3393_set_speed_duplex_fc(st
return 0;
}
-static void pm3393_rmon_update(struct adapter *adapter, u32 offs, u64 *val,
- int over)
-{
- u32 val0, val1, val2;
-
- t1_tpi_read(adapter, offs, );
- t1_tpi_read(adapter, offs + 4, );
- t1_tpi_read(adapter, offs + 8, );
-
- *val &= ~0ull << 40;
- *val |= val0 & 0x;
- *val |= (val1 & 0x) << 16;
- *val |= (u64)(val2 & 0xff) << 32;
-
- if (over)
- *val += 1ull << 40;
+#define RMON_UPDATE(mac, name, stat_name) \
+{ \
+ t1_tpi_read((mac)->adapter, OFFSET(name), ); \
+ t1_tpi_read((mac)->adapter, OFFSET((name)+1), ); \
+ t1_tpi_read((mac)->adapter, OFFSET((name)+2), ); \
+
[patch 23/27] cxgb: fix T2 GSO
2.6.22-stable review patch. If anyone has any objections, please let us
know.
--
From: Divy Le Ray <[EMAIL PROTECTED]>
patch 7832ee034b6ef78aab020c9ec1348544cd65ccbd in mainline.
The patch ensures that a GSO skb has enough headroom
to push an encapsulating cpl_tx_pkt_lso header.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/net/chelsio/cxgb2.c |3 ++-
drivers/net/chelsio/sge.c | 34 +++---
drivers/net/chelsio/sge.h |1 +
3 files changed, 18 insertions(+), 20 deletions(-)
--- a/drivers/net/chelsio/cxgb2.c
+++ b/drivers/net/chelsio/cxgb2.c
@@ -397,7 +397,8 @@ static char stats_strings[][ETH_GSTRING_
"TxTso",
"RxVlan",
"TxVlan",
-
+ "TxNeedHeadroom",
+
/* Interrupt stats */
"rx drops",
"pure_rsps",
--- a/drivers/net/chelsio/sge.c
+++ b/drivers/net/chelsio/sge.c
@@ -991,6 +991,7 @@ void t1_sge_get_port_stats(const struct
ss->tx_packets += st->tx_packets;
ss->tx_cso += st->tx_cso;
ss->tx_tso += st->tx_tso;
+ ss->tx_need_hdrroom += st->tx_need_hdrroom;
ss->vlan_xtract += st->vlan_xtract;
ss->vlan_insert += st->vlan_insert;
}
@@ -1851,7 +1852,8 @@ int t1_start_xmit(struct sk_buff *skb, s
{
struct adapter *adapter = dev->priv;
struct sge *sge = adapter->sge;
- struct sge_port_stats *st = per_cpu_ptr(sge->port_stats[dev->if_port],
smp_processor_id());
+ struct sge_port_stats *st = per_cpu_ptr(sge->port_stats[dev->if_port],
+ smp_processor_id());
struct cpl_tx_pkt *cpl;
struct sk_buff *orig_skb = skb;
int ret;
@@ -1859,6 +1861,18 @@ int t1_start_xmit(struct sk_buff *skb, s
if (skb->protocol == htons(ETH_P_CPL5))
goto send;
+ /*
+* We are using a non-standard hard_header_len.
+* Allocate more header room in the rare cases it is not big enough.
+*/
+ if (unlikely(skb_headroom(skb) < dev->hard_header_len - ETH_HLEN)) {
+ skb = skb_realloc_headroom(skb, sizeof(struct cpl_tx_pkt_lso));
+ ++st->tx_need_hdrroom;
+ dev_kfree_skb_any(orig_skb);
+ if (!skb)
+ return NETDEV_TX_OK;
+ }
+
if (skb_shinfo(skb)->gso_size) {
int eth_type;
struct cpl_tx_pkt_lso *hdr;
@@ -1892,24 +1906,6 @@ int t1_start_xmit(struct sk_buff *skb, s
return NETDEV_TX_OK;
}
- /*
-* We are using a non-standard hard_header_len and some kernel
-* components, such as pktgen, do not handle it right.
-* Complain when this happens but try to fix things up.
-*/
- if (unlikely(skb_headroom(skb) < dev->hard_header_len -
ETH_HLEN)) {
- pr_debug("%s: headroom %d header_len %d\n", dev->name,
-skb_headroom(skb), dev->hard_header_len);
-
- if (net_ratelimit())
- printk(KERN_ERR "%s: inadequate headroom in "
- "Tx packet\n", dev->name);
- skb = skb_realloc_headroom(skb, sizeof(*cpl));
- dev_kfree_skb_any(orig_skb);
- if (!skb)
- return NETDEV_TX_OK;
- }
-
if (!(adapter->flags & UDP_CSUM_CAPABLE) &&
skb->ip_summed == CHECKSUM_PARTIAL &&
ip_hdr(skb)->protocol == IPPROTO_UDP) {
--- a/drivers/net/chelsio/sge.h
+++ b/drivers/net/chelsio/sge.h
@@ -64,6 +64,7 @@ struct sge_port_stats {
u64 tx_tso; /* # of TSO requests */
u64 vlan_xtract; /* # of VLAN tag extractions */
u64 vlan_insert; /* # of VLAN tag insertions */
+ u64 tx_need_hdrroom; /* # of TX skbs in need of more header room */
};
struct sk_buff;
--
--
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 22/27] quicklist: Set tlb->need_flush if pages are remaining in quicklist 0
2.6.22-stable review patch. If anyone has any objections, please let us
know.
--
From: Christoph Lameter <[EMAIL PROTECTED]>
patch 421d99193537a6522aac2148286f08792167d5fd in mainline.
This ensures that the quicklists are drained. Otherwise draining may only
occur when the processor reaches an idle state.
Fixes fatal leakage of pgd_t's on 2.6.22 and later.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
Reported-by: Dhaval Giani <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
include/asm-generic/tlb.h |4
1 file changed, 4 insertions(+)
--- a/include/asm-generic/tlb.h
+++ b/include/asm-generic/tlb.h
@@ -14,6 +14,7 @@
#define _ASM_GENERIC__TLB_H
#include
+#include
#include
#include
@@ -85,6 +86,9 @@ tlb_flush_mmu(struct mmu_gather *tlb, un
static inline void
tlb_finish_mmu(struct mmu_gather *tlb, unsigned long start, unsigned long end)
{
+#ifdef CONFIG_QUICKLIST
+ tlb->need_flush += &__get_cpu_var(quicklist)[0].nr_pages != 0;
+#endif
tlb_flush_mmu(tlb, start, end);
/* keep the page table cache within bounds */
--
--
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 20/27] ACPICA: fix acpi-cpufreq boot crash due to _PSD return-by-reference
2.6.22-stable review patch. If anyone has any objections, please let us
know.
--
From: Bob Moore <[EMAIL PROTECTED]>
patch 152c300d007c70c4a1847dad39ecdaba22e7d457 in mainline.
Changed resolution of named references in packages
Fixed a problem with the Package operator where all named
references were created as object references and left otherwise
unresolved. According to the ACPI specification, a Package can
only contain Data Objects or references to control methods. The
implication is that named references to Data Objects (Integer,
Buffer, String, Package, BufferField, Field) should be resolved
immediately upon package creation. This is the approach taken
with this change. References to all other named objects (Methods,
Devices, Scopes, etc.) are all now properly created as reference objects.
http://bugzilla.kernel.org/show_bug.cgi?id=5328
http://bugzilla.kernel.org/show_bug.cgi?id=9429
Signed-off-by: Bob Moore <[EMAIL PROTECTED]>
Signed-off-by: Len Brown <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/acpi/dispatcher/dsobject.c | 91 ++---
1 file changed, 85 insertions(+), 6 deletions(-)
--- a/drivers/acpi/dispatcher/dsobject.c
+++ b/drivers/acpi/dispatcher/dsobject.c
@@ -137,6 +137,71 @@ acpi_ds_build_internal_object(struct acp
return_ACPI_STATUS(status);
}
}
+
+ /* Special object resolution for elements of a package */
+
+ if ((op->common.parent->common.aml_opcode == AML_PACKAGE_OP) ||
+ (op->common.parent->common.aml_opcode ==
+AML_VAR_PACKAGE_OP)) {
+ /*
+* Attempt to resolve the node to a value before we
insert it into
+* the package. If this is a reference to a common data
type,
+* resolve it immediately. According to the ACPI spec,
package
+* elements can only be "data objects" or method
references.
+* Attempt to resolve to an Integer, Buffer, String or
Package.
+* If cannot, return the named reference (for things
like Devices,
+* Methods, etc.) Buffer Fields and Fields will resolve
to simple
+* objects (int/buf/str/pkg).
+*
+* NOTE: References to things like Devices, Methods,
Mutexes, etc.
+* will remain as named references. This behavior is
not described
+* in the ACPI spec, but it appears to be an oversight.
+*/
+ obj_desc = (union acpi_operand_object *)op->common.node;
+
+ status =
+ acpi_ex_resolve_node_to_value(ACPI_CAST_INDIRECT_PTR
+ (struct
+ acpi_namespace_node,
+ _desc),
+ walk_state);
+ if (ACPI_FAILURE(status)) {
+ return_ACPI_STATUS(status);
+ }
+
+ switch (op->common.node->type) {
+ /*
+* For these types, we need the actual node,
not the subobject.
+* However, the subobject got an extra
reference count above.
+*/
+ case ACPI_TYPE_MUTEX:
+ case ACPI_TYPE_METHOD:
+ case ACPI_TYPE_POWER:
+ case ACPI_TYPE_PROCESSOR:
+ case ACPI_TYPE_EVENT:
+ case ACPI_TYPE_REGION:
+ case ACPI_TYPE_DEVICE:
+ case ACPI_TYPE_THERMAL:
+
+ obj_desc =
+ (union acpi_operand_object *)op->common.
+ node;
+ break;
+
+ default:
+ break;
+ }
+
+ /*
+* If above resolved to an operand object, we are done.
Otherwise,
+* we have a NS node, we must create the package entry
as a named
+* reference.
+*/
+ if (ACPI_GET_DESCRIPTOR_TYPE(obj_desc) !=
+ ACPI_DESC_TYPE_NAMED) {
+ goto exit;
+ }
+ }
}
/* Create and init a new internal ACPI object */
@@ -156,6 +221,7 @@ acpi_ds_build_internal_object(struct acp
[patch 21/27] vfs: coredumping fix (CVE-2007-6206)
2.6.22-stable review patch. If anyone has any objections, please let us know. -- From: Ingo Molnar <[EMAIL PROTECTED]> vfs: coredumping fix patch c46f739dd39db3b07ab5deb4e3ec81e1c04a91af in mainline fix: http://bugzilla.kernel.org/show_bug.cgi?id=3043 only allow coredumping to the same uid that the coredumping task runs under. Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]> Acked-by: Alan Cox <[EMAIL PROTECTED]> Acked-by: Christoph Hellwig <[EMAIL PROTECTED]> Acked-by: Al Viro <[EMAIL PROTECTED]> Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> Cc: maximilian attems <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- fs/exec.c |6 ++ 1 file changed, 6 insertions(+) --- a/fs/exec.c +++ b/fs/exec.c @@ -1561,6 +1561,12 @@ int do_coredump(long signr, int exit_cod but keep the previous behaviour for now. */ if (!ispipe && !S_ISREG(inode->i_mode)) goto close_fail; + /* +* Dont allow local users get cute and trick others to coredump +* into their pre-created files: +*/ + if (inode->i_uid != current->fsuid) + goto close_fail; if (!file->f_op) goto close_fail; if (!file->f_op->write) -- -- 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 19/27] CASSINI: Set skb->truesize properly on receive packets.
2.6.22-stable review patch. If anyone has any objections, please let us know. -- From: David Miller <[EMAIL PROTECTED]> [ Upstream commit: d011a231675b240157a3c335dd53e9b849d7d30d ] skb->truesize was not being incremented at all to reflect the page based data added to RX SKBs. Signed-off-by: David S. Miller <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- drivers/net/cassini.c |1 + 1 file changed, 1 insertion(+) --- a/drivers/net/cassini.c +++ b/drivers/net/cassini.c @@ -2037,6 +2037,7 @@ static int cas_rx_process_pkt(struct cas skb_shinfo(skb)->nr_frags++; skb->data_len += hlen - swivel; + skb->truesize += hlen - swivel; skb->len += hlen - swivel; get_page(page->buffer); -- -- 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 18/27] CASSINI: Revert dont touch page_count.
2.6.22-stable review patch. If anyone has any objections, please let us
know.
--
From: David Miller <[EMAIL PROTECTED]>
[ Upstream commit: 9de4dfb4c7176e5bb232a21cdd8df78da2b15cac ]
This reverts changeset fa4f0774d7c6cccb4d1fda76b91dd8eddcb2dd6a
([CASSINI]: dont touch page_count) because it breaks the driver.
The local page counting added by this changeset did not account
for the asynchronous page count changes done by kfree_skb()
and friends.
The change adds extra atomics and on top of it all appears to be
totally unnecessary as well.
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
Acked-by: Nick Piggin <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/net/cassini.c | 36
1 file changed, 4 insertions(+), 32 deletions(-)
--- a/drivers/net/cassini.c
+++ b/drivers/net/cassini.c
@@ -336,30 +336,6 @@ static inline void cas_mask_intr(struct
cas_disable_irq(cp, i);
}
-static inline void cas_buffer_init(cas_page_t *cp)
-{
- struct page *page = cp->buffer;
- atomic_set((atomic_t *)>lru.next, 1);
-}
-
-static inline int cas_buffer_count(cas_page_t *cp)
-{
- struct page *page = cp->buffer;
- return atomic_read((atomic_t *)>lru.next);
-}
-
-static inline void cas_buffer_inc(cas_page_t *cp)
-{
- struct page *page = cp->buffer;
- atomic_inc((atomic_t *)>lru.next);
-}
-
-static inline void cas_buffer_dec(cas_page_t *cp)
-{
- struct page *page = cp->buffer;
- atomic_dec((atomic_t *)>lru.next);
-}
-
static void cas_enable_irq(struct cas *cp, const int ring)
{
if (ring == 0) { /* all but TX_DONE */
@@ -497,7 +473,6 @@ static int cas_page_free(struct cas *cp,
{
pci_unmap_page(cp->pdev, page->dma_addr, cp->page_size,
PCI_DMA_FROMDEVICE);
- cas_buffer_dec(page);
__free_pages(page->buffer, cp->page_order);
kfree(page);
return 0;
@@ -527,7 +502,6 @@ static cas_page_t *cas_page_alloc(struct
page->buffer = alloc_pages(flags, cp->page_order);
if (!page->buffer)
goto page_err;
- cas_buffer_init(page);
page->dma_addr = pci_map_page(cp->pdev, page->buffer, 0,
cp->page_size, PCI_DMA_FROMDEVICE);
return page;
@@ -606,7 +580,7 @@ static void cas_spare_recover(struct cas
list_for_each_safe(elem, tmp, ) {
cas_page_t *page = list_entry(elem, cas_page_t, list);
- if (cas_buffer_count(page) > 1)
+ if (page_count(page->buffer) > 1)
continue;
list_del(elem);
@@ -1374,7 +1348,7 @@ static inline cas_page_t *cas_page_spare
cas_page_t *page = cp->rx_pages[1][index];
cas_page_t *new;
- if (cas_buffer_count(page) == 1)
+ if (page_count(page->buffer) == 1)
return page;
new = cas_page_dequeue(cp);
@@ -1394,7 +1368,7 @@ static cas_page_t *cas_page_swap(struct
cas_page_t **page1 = cp->rx_pages[1];
/* swap if buffer is in use */
- if (cas_buffer_count(page0[index]) > 1) {
+ if (page_count(page0[index]->buffer) > 1) {
cas_page_t *new = cas_page_spare(cp, index);
if (new) {
page1[index] = page0[index];
@@ -2066,7 +2040,6 @@ static int cas_rx_process_pkt(struct cas
skb->len += hlen - swivel;
get_page(page->buffer);
- cas_buffer_inc(page);
frag->page = page->buffer;
frag->page_offset = off;
frag->size = hlen - swivel;
@@ -2091,7 +2064,6 @@ static int cas_rx_process_pkt(struct cas
frag++;
get_page(page->buffer);
- cas_buffer_inc(page);
frag->page = page->buffer;
frag->page_offset = 0;
frag->size = hlen;
@@ -2255,7 +2227,7 @@ static int cas_post_rxds_ringN(struct ca
released = 0;
while (entry != last) {
/* make a new buffer if it's still in use */
- if (cas_buffer_count(page[entry]) > 1) {
+ if (page_count(page[entry]->buffer) > 1) {
cas_page_t *new = cas_page_dequeue(cp);
if (!new) {
/* let the timer know that we need to
--
--
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 16/27] ATM: Check IP header validity in mpc_send_packet
2.6.22-stable review patch. If anyone has any objections, please let us
know.
--
From: Herbert Xu <[EMAIL PROTECTED]>
[ATM]: Check IP header validity in mpc_send_packet
[ Upstream commit: 1c9b7aa1eb40ab708ef3242f74b9a61487623168 ]
Al went through the ip_fast_csum callers and found this piece of code
that did not validate the IP header. While root crashing the machine
by sending bogus packets through raw or AF_PACKET sockets isn't that
serious, it is still nice to react gracefully.
This patch ensures that the skb has enough data for an IP header and
that the header length field is valid.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
net/atm/mpc.c |7 +++
1 file changed, 7 insertions(+)
--- a/net/atm/mpc.c
+++ b/net/atm/mpc.c
@@ -542,6 +542,13 @@ static int mpc_send_packet(struct sk_buf
if (eth->h_proto != htons(ETH_P_IP))
goto non_ip; /* Multi-Protocol Over ATM :-) */
+ /* Weed out funny packets (e.g., AF_PACKET or raw). */
+ if (skb->len < ETH_HLEN + sizeof(struct iphdr))
+ goto non_ip;
+ skb_set_network_header(skb, ETH_HLEN);
+ if (skb->len < ETH_HLEN + ip_hdr(skb)->ihl * 4 || ip_hdr(skb)->ihl < 5)
+ goto non_ip;
+
while (i < mpc->number_of_mps_macs) {
if (!compare_ether_addr(eth->h_dest, (mpc->mps_macs +
i*ETH_ALEN)))
if ( send_via_shortcut(skb, mpc) == 0 ) /*
try shortcut */
--
--
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 15/27] ATM: delay irq setup until card is configured
2.6.22-stable review patch. If anyone has any objections, please let us
know.
--
From: Chas Williams <[EMAIL PROTECTED]>
[ATM]: [nicstar] delay irq setup until card is configured
[ Upstream commit: 52961955aa180959158faeb9fd6b4f8a591450f5 ]
Signed-off-by: Chas Williams <[EMAIL PROTECTED]>
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/atm/nicstar.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
--- a/drivers/atm/nicstar.c
+++ b/drivers/atm/nicstar.c
@@ -625,14 +625,6 @@ static int __devinit ns_init_card(int i,
if (mac[i] == NULL)
nicstar_init_eprom(card->membase);
- if (request_irq(pcidev->irq, _irq_handler, IRQF_DISABLED | IRQF_SHARED,
"nicstar", card) != 0)
- {
- printk("nicstar%d: can't allocate IRQ %d.\n", i, pcidev->irq);
- error = 9;
- ns_init_card_error(card, error);
- return error;
- }
-
/* Set the VPI/VCI MSb mask to zero so we can receive OAM cells */
writel(0x, card->membase + VPM);
@@ -858,8 +850,6 @@ static int __devinit ns_init_card(int i,
card->iovpool.count++;
}
- card->intcnt = 0;
-
/* Configure NICStAR */
if (card->rct_size == 4096)
ns_cfg_rctsize = NS_CFG_RCTSIZE_4096_ENTRIES;
@@ -868,6 +858,15 @@ static int __devinit ns_init_card(int i,
card->efbie = 1;
+ card->intcnt = 0;
+ if (request_irq(pcidev->irq, _irq_handler, IRQF_DISABLED | IRQF_SHARED,
"nicstar", card) != 0)
+ {
+ printk("nicstar%d: can't allocate IRQ %d.\n", i, pcidev->irq);
+ error = 9;
+ ns_init_card_error(card, error);
+ return error;
+ }
+
/* Register device */
card->atmdev = atm_dev_register("nicstar", _ops, -1, NULL);
if (card->atmdev == NULL)
--
--
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 17/27] CASSINI: Fix endianness bug.
2.6.22-stable review patch. If anyone has any objections, please let us
know.
--
From: Al Viro <[EMAIL PROTECTED]>
[ Upstream commit: e5e025401f6e926c1d9dc3f3f2813cf98a2d8708 ]
Here's proposed fix for RX checksum handling in cassini; it affects
little-endian working with half-duplex gigabit, but obviously needs
testing on big-endian too.
The problem is, we need to convert checksum to fixed-endian *before*
correcting for (unstripped) FCS. On big-endian it won't matter
(conversion is no-op), on little-endian it will, but only if FCS is
not stripped by hardware; i.e. in half-duplex gigabit mode when
->crc_size is set.
cassini.c part is that fix, cassini.h one consists of trivial
endianness annotations. With that applied the sucker is endian-clean,
according to sparse.
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/net/cassini.c |8 +---
drivers/net/cassini.h | 18 +-
2 files changed, 14 insertions(+), 12 deletions(-)
--- a/drivers/net/cassini.c
+++ b/drivers/net/cassini.c
@@ -1979,6 +1979,7 @@ static int cas_rx_process_pkt(struct cas
struct cas_page *page;
struct sk_buff *skb;
void *addr, *crcaddr;
+ __sum16 csum;
char *p;
hlen = CAS_VAL(RX_COMP2_HDR_SIZE, words[1]);
@@ -2158,14 +2159,15 @@ end_copy_pkt:
skb_put(skb, alloclen);
}
- i = CAS_VAL(RX_COMP4_TCP_CSUM, words[3]);
+ csum = (__force __sum16)htons(CAS_VAL(RX_COMP4_TCP_CSUM, words[3]));
if (cp->crc_size) {
/* checksum includes FCS. strip it out. */
- i = csum_fold(csum_partial(crcaddr, cp->crc_size, i));
+ csum = csum_fold(csum_partial(crcaddr, cp->crc_size,
+ csum_unfold(csum)));
if (addr)
cas_page_unmap(addr);
}
- skb->csum = ntohs(i ^ 0x);
+ skb->csum = csum_unfold(~csum);
skb->ip_summed = CHECKSUM_COMPLETE;
skb->protocol = eth_type_trans(skb, cp->dev);
return len;
--- a/drivers/net/cassini.h
+++ b/drivers/net/cassini.h
@@ -4122,8 +4122,8 @@ cas_saturn_patch_t cas_saturn_patch[] =
inserted into
outgoing frame. */
struct cas_tx_desc {
- u64 control;
- u64 buffer;
+ __le64 control;
+ __le64 buffer;
};
/* descriptor ring for free buffers contains page-sized buffers. the index
@@ -4131,8 +4131,8 @@ struct cas_tx_desc {
* the completion ring.
*/
struct cas_rx_desc {
- u64 index;
- u64 buffer;
+ __le64 index;
+ __le64 buffer;
};
/* received packets are put on the completion ring. */
@@ -4210,10 +4210,10 @@ struct cas_rx_desc {
#define RX_INDEX_RELEASE 0x2000ULL
struct cas_rx_comp {
- u64 word1;
- u64 word2;
- u64 word3;
- u64 word4;
+ __le64 word1;
+ __le64 word2;
+ __le64 word3;
+ __le64 word4;
};
enum link_state {
@@ -4252,7 +4252,7 @@ struct cas_init_block {
struct cas_rx_comp rxcs[N_RX_COMP_RINGS][INIT_BLOCK_RX_COMP];
struct cas_rx_desc rxds[N_RX_DESC_RINGS][INIT_BLOCK_RX_DESC];
struct cas_tx_desc txds[N_TX_RINGS][INIT_BLOCK_TX];
- u64 tx_compwb;
+ __le64 tx_compwb;
};
/* tiny buffers to deal with target abort issue. we allocate a bit
--
--
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 14/27] CONNECTOR: Dont touch queue dev after decrement of ref count.
2.6.22-stable review patch. If anyone has any objections, please let us
know.
--
From: Li Zefan <[EMAIL PROTECTED]>
[CONNECTOR]: Don't touch queue dev after decrement of ref count.
[ Upstream commit: cf585ae8ae9ac7287a6d078425ea32f22bf7f1f7 ]
cn_queue_free_callback() will touch 'dev'(i.e. cbq->pdev), so it
should be called before atomic_dec(>refcnt).
Signed-off-by: Li Zefan <[EMAIL PROTECTED]>
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/connector/cn_queue.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/connector/cn_queue.c
+++ b/drivers/connector/cn_queue.c
@@ -99,8 +99,8 @@ int cn_queue_add_callback(struct cn_queu
spin_unlock_bh(>queue_lock);
if (found) {
- atomic_dec(>refcnt);
cn_queue_free_callback(cbq);
+ atomic_dec(>refcnt);
return -EINVAL;
}
--
--
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 12/27] INET: Fix netdev renaming and inet address labels
2.6.22-stable review patch. If anyone has any objections, please let us
know.
--
From: Mark McLoughlin <[EMAIL PROTECTED]>
[INET]: Fix netdev renaming and inet address labels
[ Upstream commit: 44344b2a85f03326c7047a8c861b0c625c674839 ]
When re-naming an interface, the previous secondary address
labels get lost e.g.
$> brctl addbr foo
$> ip addr add 192.168.0.1 dev foo
$> ip addr add 192.168.0.2 dev foo label foo:00
$> ip addr show dev foo | grep inet
inet 192.168.0.1/32 scope global foo
inet 192.168.0.2/32 scope global foo:00
$> ip link set foo name bar
$> ip addr show dev bar | grep inet
inet 192.168.0.1/32 scope global bar
inet 192.168.0.2/32 scope global bar:2
Turns out to be a simple thinko in inetdev_changename() - clearly we
want to look at the address label, rather than the device name, for
a suffix to retain.
Signed-off-by: Mark McLoughlin <[EMAIL PROTECTED]>
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
net/ipv4/devinet.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -1030,7 +1030,7 @@ static void inetdev_changename(struct ne
memcpy(ifa->ifa_label, dev->name, IFNAMSIZ);
if (named++ == 0)
continue;
- dot = strchr(ifa->ifa_label, ':');
+ dot = strchr(old, ':');
if (dot == NULL) {
sprintf(old, ":%d", named);
dot = old;
--
--
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 13/27] : Fix sparc64 cpu cross call hangs.
2.6.22-stable review patch. If anyone has any objections, please let us
know.
--
From: "David S. Miller" <[EMAIL PROTECTED]>
[SPARC64]: Fix endless loop in cheetah_xcall_deliver().
[ Upsteam commit: 0de56d1ab83323d604d95ca193dcbd28388dbabb ]
We need to mask out the proper bits when testing the dispatch status
register else we can see unrelated NACK bits from previous cross call
sends.
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
---
arch/sparc64/kernel/smp.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
--- a/arch/sparc64/kernel/smp.c
+++ b/arch/sparc64/kernel/smp.c
@@ -403,7 +403,7 @@ static __inline__ void spitfire_xcall_de
*/
static void cheetah_xcall_deliver(u64 data0, u64 data1, u64 data2, cpumask_t
mask)
{
- u64 pstate, ver;
+ u64 pstate, ver, busy_mask;
int nack_busy_id, is_jbus, need_more;
if (cpus_empty(mask))
@@ -435,14 +435,20 @@ retry:
"i" (ASI_INTR_W));
nack_busy_id = 0;
+ busy_mask = 0;
{
int i;
for_each_cpu_mask(i, mask) {
u64 target = (i << 14) | 0x70;
- if (!is_jbus)
+ if (is_jbus) {
+ busy_mask |= (0x1UL << (i * 2));
+ } else {
target |= (nack_busy_id << 24);
+ busy_mask |= (0x1UL <<
+ (nack_busy_id * 2));
+ }
__asm__ __volatile__(
"stxa %%g0, [%0] %1\n\t"
"membar #Sync\n\t"
@@ -458,15 +464,16 @@ retry:
/* Now, poll for completion. */
{
- u64 dispatch_stat;
+ u64 dispatch_stat, nack_mask;
long stuck;
stuck = 10 * nack_busy_id;
+ nack_mask = busy_mask << 1;
do {
__asm__ __volatile__("ldxa [%%g0] %1, %0"
: "=r" (dispatch_stat)
: "i" (ASI_INTR_DISPATCH_STAT));
- if (dispatch_stat == 0UL) {
+ if (!(dispatch_stat & (busy_mask | nack_mask))) {
__asm__ __volatile__("wrpr %0, 0x0, %%pstate"
: : "r" (pstate));
if (unlikely(need_more)) {
@@ -483,12 +490,12 @@ retry:
}
if (!--stuck)
break;
- } while (dispatch_stat & 0xUL);
+ } while (dispatch_stat & busy_mask);
__asm__ __volatile__("wrpr %0, 0x0, %%pstate"
: : "r" (pstate));
- if ((dispatch_stat & ~(0xUL)) == 0) {
+ if (dispatch_stat & busy_mask) {
/* Busy bits will not clear, continue instead
* of freezing up on this cpu.
*/
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
