linux/drivers/base/memory.c, branch v3.5

Merge tag 'v3.3-rc7' into x86/mce

2012-03-14T06:44:11Z

Merge reason: Update from an ancient -rc1 base to an almost-final stable kernel. Signed-off-by: Ingo Molnar

drivers/base/memory.c: fix memory_dev_init() long delay

2012-02-02T23:50:05Z

One system with 2048g ram, reported soft lockup on recent kernel. [ 34.426749] cpu_dev_init done [ 61.166399] BUG: soft lockup - CPU#0 stuck for 22s! [swapper/0:1] [ 61.166733] Modules linked in: [ 61.166904] irq event stamp: 1935610 [ 61.178431] hardirqs last enabled at (1935609): [] mutex_lock_nested+0x299/0x2b4 [ 61.178923] hardirqs last disabled at (1935610): [] apic_timer_interrupt+0x6b/0x80 [ 61.198767] softirqs last enabled at (1935476): [] __do_softirq+0x195/0x1ab [ 61.218604] softirqs last disabled at (1935471): [] call_softirq+0x1c/0x30 [ 61.238408] CPU 0 [ 61.238549] Modules linked in: [ 61.238744] [ 61.238825] Pid: 1, comm: swapper/0 Not tainted 3.3.0-rc1-tip-yh-02076-g962f689-dirty #171 [ 61.278212] RIP: 0010:[] [] lock_release+0x90/0x9c [ 61.278627] RSP: 0018:ffff883f64dbfd70 EFLAGS: 00000246 [ 61.298287] RAX: ffff883f64dc0000 RBX: 0000000000000000 RCX: 000000000000008b [ 61.298690] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 61.318383] RBP: ffff883f64dbfda0 R08: 0000000000000001 R09: 000000000000008b [ 61.338215] R10: 0000000000000000 R11: 0000000000000000 R12: ffff883f64dbfd10 [ 61.338610] R13: ffff883f64dc0708 R14: ffff883f64dc0708 R15: ffffffff81095657 [ 61.358299] FS: 0000000000000000(0000) GS:ffff883f7d600000(0000) knlGS:0000000000000000 [ 61.378118] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 61.378450] CR2: 0000000000000000 CR3: 00000000024af000 CR4: 00000000000007f0 [ 61.398144] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 61.417918] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 61.418260] Process swapper/0 (pid: 1, threadinfo ffff883f64dbe000, task ffff883f64dc0000) [ 61.445358] Stack: [ 61.445511] 0000000000000002 ffff897f649ba168 ffff883f64dbfe10 ffff88ff64bb57a8 [ 61.458040] 0000000000000000 0000000000000000 ffff883f64dbfdc0 ffffffff81ceb1b4 [ 61.458491] 000000000011608c ffff88ff64bb58a8 ffff883f64dbfdf0 ffffffff81c57638 [ 61.478215] Call Trace: [ 61.478367] [] _raw_spin_unlock+0x21/0x2e [ 61.497994] [] klist_next+0x9e/0xbc [ 61.498264] [] next_device+0xe/0x1e [ 61.517867] [] subsys_find_device_by_id+0xb7/0xd6 [ 61.518197] [] find_memory_block_hinted+0x3d/0x66 [ 61.537927] [] find_memory_block+0x10/0x12 [ 61.538193] [] add_memory_section+0x35/0x9e [ 61.557932] [] memory_dev_init+0x68/0xda [ 61.558227] [] driver_init+0x97/0xa7 [ 61.577853] [] kernel_init+0xf6/0x1c0 [ 61.578140] [] kernel_thread_helper+0x4/0x10 [ 61.597850] [] ? retint_restore_args+0xe/0xe [ 61.598144] [] ? start_kernel+0x3ab/0x3ab [ 61.617826] [] ? gs_change+0xb/0xb [ 61.618060] Code: 10 48 83 3b 00 eb e8 4c 89 f2 44 89 fe 4c 89 ef e8 e1 fe ff ff 65 48 8b 04 25 40 bc 00 00 c7 80 cc 06 00 00 00 00 00 00 41 54 9d <5e> 5b 41 5c 41 5d 41 5e 41 5f 5d c3 55 48 89 e5 41 57 41 89 cf [ 89.285380] memory_dev_init done Finally it takes about 55s to create 16400 memory entries. Root cause: for x86_64, 2048g (with 2g hole at [2g,4g), and TOP2 will be 2050g), will have 16400 memory block. find_memory_block/subsys_find_device_by_id will be expensive with that many entries. Actually, we don't need to find that memory block for BOOT path. Skip that finding make it get back to normal. [ 34.466696] cpu_dev_init done [ 35.290080] memory_dev_init done Also solved the delay with topology_init when sections_per_block is not 1. Signed-off-by: Yinghai Lu Cc: Kay Sievers Cc: Nathan Fontenot Cc: Robin Holt Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman

Merge tag 'mce-recovery-for-tip' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras into x86/mce

2012-01-26T10:40:13Z

Implement MCE recovery for the data load error path and assorted cleanups. Signed-off-by: Ingo Molnar

kdump: add udev events for memory online/offline

2012-01-13T04:13:11Z

Currently no udev events for memory hotplug "online" and "offline" are generated: # udevadm monitor # echo offline > /sys/devices/system/memory/memory4/state ==> No event When kdump is loaded, kexec detects the current memory configuration and stores it in the pre-allocated ELF core header. Therefore, for kdump it is necessary to reload the kdump kernel with kexec when the memory configuration changes (e.g. for online/offline hotplug memory). In order to do this automatically, udev rules should be used. This kernel patch adds udev events for "online" and "offline". Together with this kernel patch, the following udev rules for online/offline have to be added to "/etc/udev/rules.d/98-kexec.rules": SUBSYSTEM=="memory", ACTION=="online", PROGRAM="/etc/init.d/kdump restart" SUBSYSTEM=="memory", ACTION=="offline", PROGRAM="/etc/init.d/kdump restart" [sfr@canb.auug.org.au: fixups for class to subsystem conversion] Signed-off-by: Michael Holzheu Cc: Heiko Carstens Cc: Vivek Goyal Cc: "Eric W. Biederman" Cc: Kay Sievers Cc: Dave Hansen Cc: Martin Schwidefsky Cc: Greg KH Signed-off-by: Stephen Rothwell Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

HWPOISON: Clean up memory_failure() vs. __memory_failure()

2012-01-03T20:06:32Z

There is only one caller of memory_failure(), all other users call __memory_failure() and pass in the flags argument explicitly. The lone user of memory_failure() will soon need to pass flags too. Add flags argument to the callsite in mce.c. Delete the old memory_failure() function, and then rename __memory_failure() without the leading "__". Provide clearer message when action optional memory errors are ignored. Acked-by: Borislav Petkov Signed-off-by: Tony Luck

convert 'memory' sysdev_class to a regular subsystem

2011-12-21T22:48:43Z

This moves the 'memory sysdev_class' over to a regular 'memory' subsystem and converts the devices to regular devices. The sysdev drivers are implemented as subsystem interfaces now. After all sysdev classes are ported to regular driver core entities, the sysdev implementation will be entirely removed from the kernel. Signed-off-by: Kay Sievers Signed-off-by: Greg Kroah-Hartman

mm: memory hotplug: Check if pages are correctly reserved on a per-section basis

2011-10-18T21:01:24Z

(Resending as I am not seeing it in -next so maybe it got lost) mm: memory hotplug: Check if pages are correctly reserved on a per-section basis It is expected that memory being brought online is PageReserved similar to what happens when the page allocator is being brought up. Memory is onlined in "memory blocks" which consist of one or more sections. Unfortunately, the code that verifies PageReserved is currently assuming that the memmap backing all these pages is virtually contiguous which is only the case when CONFIG_SPARSEMEM_VMEMMAP is set. As a result, memory hot-add is failing on those configurations with the message; kernel: section number XXX page number 256 not reserved, was it already online? This patch updates the PageReserved check to lookup struct page once per section to guarantee the correct struct page is being checked. [Check pages within sections properly: rientjes@google.com] [original patch by: nfont@linux.vnet.ibm.com] Signed-off-by: Mel Gorman Acked-by: KAMEZAWA Hiroyuki Tested-by: Nathan Fontenot Signed-off-by: Greg Kroah-Hartman

Revert "memory hotplug: Correct page reservation checking"

2011-10-18T21:00:57Z

This reverts commit 54f23eb7ba7619de85d8edca6e5336bc33072dbd. Turns out this patch is wrong, another correct one will follow it. Signed-off-by: Greg Kroah-Hartman

memory hotplug: Correct page reservation checking

2011-09-26T23:21:14Z

The check to ensure that pages of recently added memory sections are correctly marked as reserved before trying to online the memory is broken. The request to online the memory fails with the following: kernel: section number XXX page number 256 not reserved, was it already online? This updates the page reservation checking to check the pages of each memory section of the memory block being onlined individually. Signed-off-by: Nathan Fontenot Signed-off-by: Greg Kroah-Hartman

memory hotplug: Refuse to add unaligned memory regions

2011-09-26T23:21:14Z

The sysfs memory probe interface allows unaligned regions to be added: # echo 0xffffff > /sys/devices/system/memory/probe # cat /proc/iomem 00ffffff-01fffffe : System RAM 01ffffff-02fffffe : System RAM 02ffffff-03fffffe : System RAM 03ffffff-04fffffe : System RAM 04ffffff-05fffffe : System RAM Return -EINVAL instead of creating these bad regions. Signed-off-by: Anton Blanchard Signed-off-by: Greg Kroah-Hartman