Hello, I'm looking for comments on the following patch that exposes _SUN on processor objects in /proc/acpi/processor/<...>/info. This didn't get many comments on the linux-acpi list, so I'm sending to a wider distribution. I notice that acpiphp exposes _SUN for (hotpluggable) PCI slots in /sys/bus/pci/slots/N/, where N is the value of _SUN. I'm not so sure we want to go *exactly* in the same direction for CPUs, because: - x86 systems might not implement _SUN for processors - ia...

This patch adds a proper prototype for show_interrupts() in include/linux/interrupt.h Signed-off-by: Adrian Bunk <bunk@kernel.org> --- arch/h8300/kernel/irq.c | 1 + fs/proc/proc_misc.c | 2 +- include/linux/interrupt.h | 2 ++ 3 files changed, 4 insertions(+), 1 deletion(-) 3884100dff673abe8667f2e53586ecd705e7af24 diff --git a/arch/h8300/kernel/irq.c b/arch/h8300/kernel/irq.c index 8dec4dd..5a1b4cf 100644 --- a/arch/h8300/kernel/irq.c +++ b/arch/h8300/kernel/ir...

Acked-by: David Rientjes <rientjes@google.com> -

As you can see from the patch there is already a case to catch this type of problem. This BUG_ON() adds a resursive OOPS , since BUG() causes an OOPS and the OOPS just calls do_exit() , and do_exit() just causes another OOPS with this BUG_ON().. If we call panic() here then it's clear what the problem was, instead of causing an endless recursive crash. Signed-off-by: Daniel Walker <dwalker@mvista.com> --- kernel/exit.c | 1 - 1 file changed, 1 deletion(-) Index: linux-2.6.23.1/kern...

I wonder if Ingo had his reasons for keeping it.. They're may have been a benefit to doing a BUG_ON at one point .. I don't know .. Daniel -

Dear Linux PCI, Kernel Version(s): 2.6.22 (Ubuntu 7.10) and 2.6.21 (Fedora Core 7) I am trying to use fakephp to rescan the PCI bus when I reload my PCI Interface FPGA. When I reload the FPGA, lspci shows "[disabled]" for the original Base Address Regions. My hope is that a rescan will re-enumerate the bus and fill in the PCI Settings on the FPGA interface. In fact, I can use setpci to re-enable the board after loading FPGA, but only if I have not changed any of the core parameters. I would hope th...

Commit 80c5606c3b45e0176c32d3108ade1e1cb0b954f3 from Linus moved the VM_MAYEXEC code further down, but in the process broke the mmap_23_1 test from the LTP suite. Moving it down means that the test for FMODE_READ ends up above the test for f_op->mmap. If the write side of the pipe is called for mmap(), we end up returning -EACCES rather than -ENODEV. Was this an intended change of behavior? Unless there's a global error precedence in SuS that I missed, I think both error codes could be ...

Jeff, will you (at least) notify the LTP project of this issue and need for a patch? --- ~Randy -

Hi, If this is really off-topic here, I apologize first. But I cannot think a better place to ask this particular question. I understand that the current PCI subsystem or linux kernel (x86) supports only one message when MSI is enabled even for devices having multiple MSI messages. But why? Is this a limitation solely due to the OS or due to the x86 APIC? I know the current linux kernel (2.6.23) changed MSI message data format a little bit to support other architectures. But some older versio...

> > If this is really off-topic here, I apologize first. But I cannot > > think a better place to ask this particular question. > > I understand that the current PCI subsystem or linux kernel (x86) > > supports only one message when MSI is enabled even for devices having > > multiple MSI messages. But why? Is this a limitation solely due to the > > OS or due to the x86 APIC? > > I know the current linux kernel (2.6.23) changed MSI message data > &g...

On Mon, 29 Oct 2007 22:41:30 +0100 (CET) ditto. -

From: "Olivér_Pintér" <oliver.pntr@gmail.com> I'll take care of this, thanks for the report. -

Hi, This patch fixes a panic on shrinking DM device, due to reference outside of the DM table. The problem occurs only if there is outstanding I/O to the removed part of the device. The bug is in that __clone_and_map() assumes dm_table_find_target() always returns a valid pointer. It may fail if a BIO is sent from the block layer but its target sector is already not in the DM table. This patch tidies up dm_table_find_target() to return NULL instead of bogus pointer for failure case. Then ...

I am sorry, my patch broke this and Kristov Provost also noticed this. See http://lkml.org/lkml/2007/10/30/355 -

Please check if this patch helps. Regards, Alex.

The only change to drivers/acpi/ac.c after .23 was d5b4a3d0efa36de31b86d5677dad6c36cb8735d7. Don't see how it could lead to less messages from AC. Regards, Alex. -

I'm seeing these in the latest git: kernel/marker.c: In function `marker_probe_unregister': kernel/marker.c:355: warning: `probe_module' might be used uninitialized in this function kernel/marker.c: In function `marker_probe_unregister_private_data': kernel/marker.c:389: warning: `probe_module' might be used uninitialized in this function kernel/marker.c:392: warning: `entry' might be used uninitialized in this function It's due to gcc not detecting that the need_update condition is actually cons...

This series of 4 proposed patches (take 3) changes fs/ioctl.c and Unionfs as follows. This series is against v2.6.24-rc1-423-g97855b4. Patch 1: just applies coding standards to fs/ioctl.c (while I'm at it, I figured it's worth cleaning VFS files one at a time). Patch 2: does two things: (a) Renames the old vfs_ioctl to do_ioctl, because the comment above it clearly indicates that it is an internal function not to be exported to modules; therefore it should have a more traditional do_...

Signed-off-by: Erez Zadok <ezk@cs.sunysb.edu> --- fs/ioctl.c | 129 +++++++++++++++++++++++++++++++++++------------------------- 1 files changed, 75 insertions(+), 54 deletions(-) diff --git a/fs/ioctl.c b/fs/ioctl.c index 1ab7b7d..cd8c1a3 100644 --- a/fs/ioctl.c +++ b/fs/ioctl.c @@ -53,32 +53,34 @@ long vfs_ioctl(struct file *filp, unsigned int cmd, } EXPORT_SYMBOL_GPL(vfs_ioctl); +static int ioctl_fibmap(struct file *filp, int __user *p) +{ + struct address_space *mapping = fil...

Signed-off-by: Erez Zadok <ezk@cs.sunysb.edu> --- fs/ioctl.c | 164 +++++++++++++++++++++++++++++++----------------------------- 1 files changed, 84 insertions(+), 80 deletions(-) diff --git a/fs/ioctl.c b/fs/ioctl.c index c2a773e..652cacf 100644 --- a/fs/ioctl.c +++ b/fs/ioctl.c @@ -12,8 +12,8 @@ #include <linux/fs.h> #include <linux/security.h> #include <linux/module.h> +#include <linux/uaccess.h> -#include <asm/uaccess.h> #include <asm/ioctl...

Add the primitives cmpxchg_local, cmpxchg64 and cmpxchg64_local to ia64. They use cmpxchg_acq as underlying macro, just like the already existing ia64 cmpxchg(). Changelog: ia64 cmpxchg_local coding style fix Quoting Keith Owens: As a matter of coding style, I prefer #define cmpxchg_local cmpxchg #define cmpxchg64_local cmpxchg64 Which makes it absolutely clear that they are the same code. With your patch, humans have to do a string compare of two defines to see if they are the same....

It is or at least it should be. The GPEs are supposed to be fully functional Is the "[2.6.24-rc1 regression] AC adapter state does not change after resume" message a follow-up to this one? Rafael -

Hmmm, i've looked back a couple of releases and this seems to get reported correctly. Removing this space is then silent. ERROR: no space after that '*' (ctx:BxW) #4: FILE: Z31.c:1: + crc = __be32_to_cpu(* ((__be32 *) ((void *) firmware + calc_size))); What version is checkpatch reported as? Also can I have the entire diff hunk this is from in case its being caused by the context, though that seems unlikely. Thanks. -apw -

[Empty message]

Use the new generic cmpxchg_local (disables interrupt). Also use the generic cmpxchg as fallback if SMP is not set. Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> CC: clameter@sgi.com CC: gerg@uclinux.org --- include/asm-m68knommu/system.h | 28 +++++++++++----------------- 1 file changed, 11 insertions(+), 17 deletions(-) Index: linux-2.6-lttng/include/asm-m68knommu/system.h =================================================================== --- linux-2.6-lttng.orig/...