yeah. i completely forgot about those bits. But lets make sure the forcedeth.c fix gets into .25 - it's obvious and it fixes a nasty bug. Without that fix netconsole is unusable on forcedeth. Ingo --

We need more info, namely full 'dmesg', 'lspci -v', and your kernel config. Also, make /sure/ you are not running closed-source modules known to crash the system, like ndiswrapper or nvidia graphics driver. Jeff --

Sanitized locking for ->mnt_expiry, race fixes for shrink_submounts(), some stack footprint reduction on using struct path instead of struct nameidata in several places in namespace.c (more will be possible once we sanitize prototypes of several LSM hooks, but that's post-25). Please, pull from git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6.git/ for-linus Shortlog: Al Viro (5): reduce stack footprint in namespace.c count ghost references to vfsmounts sanitize l...

New driver to read energy, power, and temperature meters in various IBM System X hardware. Signed-off-by: Darrick J. Wong <djwong@us.ibm.com> --- Documentation/hwmon/ibmaem | 37 + drivers/hwmon/Kconfig | 14 + drivers/hwmon/Makefile | 1 drivers/hwmon/ibmaem.c | 1151 ++++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 1203 insertions(+), 0 deletions(-) diff --git a/Documentation/hwmon/ibmaem b/Documentation/hwmon/ibmaem new file mode 100644 index 0000...

This patch deletes a couple of superfluous word occurrences in the document Documentation/unaligned-memory-access.txt. Thanks to Sebastien Dugue for the remark about English usage. --- Documentation/unaligned-memory-access.txt | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/unaligned-memory-access.txt b/Documentation/unaligned-memory-access.txt index 6223eac..b0472ac 100644 --- a/Documentation/unaligned-memory-access.txt +++ b/Documentation/unaligned-me...

Rename defines to be in RIO* namespace to not to collide with other defines in tree. This broke (as akpm correctly pointed out) some allmodconfig builds, e.g. on ppc: In file included from drivers/char/rio/rio_linux.c:81: drivers/char/rio/cirrus.h:202:1: warning: "COMPLETE" redefined In file included from include/net/netns/ipv4.h:8, from include/net/net_namespace.h:13, from include/linux/seq_file.h:7, from include/asm/machdep.h:12, ...

Add some locks and unlocks to some code paths. Signed-off-by: Jiri Slaby <jirislaby@gmail.com> --- drivers/char/rio/riotable.c | 4 +++- drivers/char/rio/riotty.c | 4 ++++ 2 files changed, 7 insertions(+), 1 deletions(-) diff --git a/drivers/char/rio/riotable.c b/drivers/char/rio/riotable.c index dfce405..2b24488 100644 --- a/drivers/char/rio/riotable.c +++ b/drivers/char/rio/riotable.c @@ -424,8 +424,10 @@ int RIOApel(struct rio_info *p) MapP = &p->RIOConnectTabl...

While reviewing some CAN driver I stumbled on iounmap which has following prototype on x86: extern void iounmap(volatile void __iomem *addr); I argued that the driver should not use volatile but then I cannot explain why the argument to iounmap takes a volatile. The same goes for many other functions in the io*.h headers. Grepping the other archs they mostly follow same pattern. Can anyone explain the rational for volatile in this case. Thanks, Sam --

Yes. The use of volatile in a function prototype like this means that it is valid to pass a volatile pointer to that function -- in other words, we're telling gcc that we're not going to do anything with the pointer that is invalid for a volatile pointer. A lot of the "volatile considered harmful" stuff that has been bandied about is explicitly about marking *data* items volatile (it does have its uses, but it's easy to get wrong); Linus has explicitly made the distinction between volatile...

Yes, it does. -hpa --

This is crashing at boot my lowmem reserved RAM patch. This is causing GFP_DMA allocations at boot for no good reason. It crashes in my case because there's no ram below 16M available to linux. Are you sure this is needed at all, for sure if there's any bug this isn't the right fix. Please reverse, thanks! changeset: 87150:1f7afb388483 user: Yang Shi <yang.shi@windriver.com> date: Tue Mar 04 11:20:51 2008 +0100 summary: Fix DMA access of block device in 64-bit kernel on...

Is kmem_cache_free safe to call while holding a spinlock (can kmem_cache_free ever block or recurse into a file system)? I see it trying to grab just another spinlock which is probably fine (but was worried whether any of the worker functions called a sem) ... my assumption is that it would be safe, but the man page doesn't mention when it can be used safely. -- Thanks, Steve --

hm, this looks a bit weird - why are all the preempt-disable/enable calls needed? Ingo --

could you post the stacktraces of the warnings as they occured? All those codepaths should be running with preemption disabled in some natural way. Ingo --

Add UV macros for converting between cpu numbers, blade numbers and node numbers. Note that these are used ONLY within x86_64 UV modules, and are not for general kernel use. Based on: git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git Signed-off-by: Jack Steiner <steiner@sgi.com> --- include/asm-x86/uv/uv_hub.h | 74 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 74 insertions(+) Index: linux/include/asm-x86/uv/uv_hub.h ==================...

Definitions of UV MMRs. Note: this file is auto-generated by hardware design tools. Signed-off-by: Jack Steiner <steiner@sgi.com> --- include/asm-x86/uv/uv_mmrs.h | 373 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 373 insertions(+) Index: linux/include/asm-x86/uv/uv_mmrs.h =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ linux/include/asm-x86/uv/uv_mmrs.h 2008-03-27 12:47:36.000000000 -0500 @@ ...

Increase the number of bits in an apicid from 8 to 32. By default, MP_processor_info() gets the APICID from the mpc_config_processor structure. However, this structure limits the size of APICID to 8 bits. This patch allows the caller of MP_processor_info() to optionally pass a larger APICID that will be used instead of the one in the mpc_config_processor struct. Based on: git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git Signed-off-by: Jack Steiner <steiner@sgi...

Introduce a function to read the local APIC_ID. This change is in preparation for additional changes to the APICID functions that will come in a later patch. Based on: git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git Signed-off-by: Jack Steiner <steiner@sgi.com> --- arch/x86/kernel/apic_32.c | 4 ++-- arch/x86/kernel/apic_64.c | 10 +++++----- arch/x86/kernel/genapic_flat_64.c | 2 +- arch/x86/kernel/io_apic_3...

thanks Jack, applied. Ingo --

The oopses (at least some of them) seem to be a use-after-free where we seem to do a list_add() on an already-released list head (or we didn't remove the previous/next entry from a list before we free'd it, and then The problem with kerneloops is that it seems to be really hard to figure out the *source* of the oops. I can find the oopses (and it's really good with the whole search-and-clump-together-by-version thing), but then when some oops like this is found, it's hard to see where yo...

I just implemented this; below are two examples of this: http://www.kerneloops.org/searchweek.php?search=tcp_mark_head_lost http://www.kerneloops.org/search.php?search=input_release_device The ratio of automatic versus mailinglist/bugzilla mails is quite high in favor of the automatic ones so there's not all THAT many of these at this point, especially in the "searchweek" version, which only shows the last 7 days of reports. --

Hmm. Definitely not from the kernel mailing list. I'm intrigued, where did that oops #5814 come from (picked a recent one at random)? The thing is recent, and oopses on "mutex_lock(dev->mutex)" in input_release_device. In particular, the path *seems* to be this one: evdev_release -> evdev_ungrab -> input_release_device -> mutex_lock -> mutex_lock_nested -> __mutex_lock_common -> list_add_tail(&waiter.list,...

That I've seen before, analysed a bit and posted: http://permalink.gmane.org/gmane.linux.kernel.input/4281 johannes

I tend to think it's actually a regression, I've done exactly what I described there dozens of times before on older kernels and it doesn't seem to be a race condition, X always locks the input device and I never I have to admit to not understanding the depths of the input code, I just took a quick look when I posted that. Mind you, that was 5 weeks I don't. I think Dmitry just said in the other mail that he did, but I haven't seen that yet. johannes

... and if bisecting the whole tree isn't the way for you to go right now, maybe restricting to drivers/input/ and drivers/base/ (as I think this might be some broken driver core refcounting) and possibly drivers/hid/ (if you are using any HID input device) might also be sufficient. -- Jiri Kosina SUSE Labs --