- 04 Dec, 2009 3 commits
-
-
Greg Kroah-Hartman authored
-
David Miller authored
As noticed by Oliver Hartkopp, the backport of the 'net: Partially allow skb destructors to be used on receive path' (2.6.30.y commit: 172570a2, upstream commit: d55d87fd ) was buggy. It should have added an skb_orphan() call to both skb_set_owner_w() and skb_set_owner_r(). Instead it added two calls to skb_set_owner_r(). This fixes it up. Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
David Ford authored
commit bbf31bf1 upstream. ipv4 ip_frag_reasm(), fully replace 'dev_net(dev)' with 'net', defined previously patched into 2.6.29. Between 2.6.28.10 and 2.6.29, net/ipv4/ip_fragment.c was patched, changing from dev_net(dev) to container_of(...). Unfortunately the goto section (out_fail) on oversized packets inside ip_frag_reasm() didn't get touched up as well. Oversized IP packets cause a NULL pointer dereference and immediate hang. I discovered this running openvasd and my previous email on this is titled: NULL pointer dereference at 2.6.32-rc8:net/ipv4/ip_fragment.c:566 Signed-off-by:
David Ford <david@blue-labs.org> Signed-off-by:
-
- 05 Oct, 2009 34 commits
-
-
Greg Kroah-Hartman authored
-
Lee Schermerhorn authored
commit 252c5f94 upstream. We noticed very erratic behavior [throughput] with the AIM7 shared workload running on recent distro [SLES11] and mainline kernels on an 8-socket, 32-core, 256GB x86_64 platform. On the SLES11 kernel [2.6.27.19+] with Barcelona processors, as we increased the load [10s of thousands of tasks], the throughput would vary between two "plateaus"--one at ~65K jobs per minute and one at ~130K jpm. The simple patch below causes the results to smooth out at the ~130k plateau. But wait, there's more: We do not see this behavior on smaller platforms--e.g., 4 socket/8 core. This could be the result of the larger number of cpus on the larger platform--a scalability issue--or it could be the result of the larger number of interconnect "hops" between some nodes in this platform and how the tasks for a given load end up distributed over the nodes' cpus and memories--a stochastic NUMA effect. The variability in the results are less pronounced [on the same platform] with Shanghai processors and with mainline kernels. With 31-rc6 on Shanghai processors and 288 file systems on 288 fibre attached storage volumes, the curves [jpm vs load] are both quite flat with the patched kernel consistently producing ~3.9% better throughput [~80K jpm vs ~77K jpm] than the unpatched kernel. Profiling indicated that the "slow" runs were incurring high[er] contention on an anon_vma lock in vma_adjust(), apparently called from the sbrk() system call. The patch: A comment in mm/mmap.c:vma_adjust() suggests that we don't really need the anon_vma lock when we're only adjusting the end of a vma, as is the case for brk(). The comment questions whether it's worth while to optimize for this case. Apparently, on the newer, larger x86_64 platforms, with interesting NUMA topologies, it is worth while--especially considering that the patch [if correct!] is quite simple. We can detect this condition--no overlap with next vma--by noting a NULL "importer". The anon_vma pointer will also be NULL in this case, so simply avoid loading vma->anon_vma to avoid the lock. However, we DO need to take the anon_vma lock when we're inserting a vma ['insert' non-NULL] even when we have no overlap [NULL "importer"], so we need to check for 'insert', as well. And Hugh points out that we should also take it when adjusting vm_start (so that rmap.c can rely upon vma_address() while it holds the anon_vma lock). akpm: Zhang Yanmin reprts a 150% throughput improvement with aim7, so it might be -stable material even though thiss isn't a regression: "this issue is not clear on dual socket Nehalem machine (2*4*2 cpu), but is severe on large machine (4*8*2 cpu)" [hugh.dickins@tiscali.co.uk: test vma start too] Signed-off-by:
Lee Schermerhorn <lee.schermerhorn@hp.com> Signed-off-by:
Hugh Dickins <hugh.dickins@tiscali.co.uk> Cc: Nick Piggin <npiggin@suse.de> Cc: Eric Whitney <eric.whitney@hp.com> Tested-by:
"Zhang, Yanmin" <yanmin_zhang@linux.intel.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Hugh Dickins authored
commit 1ac0cb5d upstream. do_anonymous_page() has been wrong to dirty the pte regardless. If it's not going to mark the pte writable, then it won't help to mark it dirty here, and clogs up memory with pages which will need swap instead of being thrown away. Especially wrong if no overcommit is chosen, and this vma is not yet VM_ACCOUNTed - we could exceed the limit and OOM despite no overcommit. Signed-off-by:
Rik van Riel <riel@redhat.com> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Cc: Nick Piggin <npiggin@suse.de> Cc: Mel Gorman <mel@csn.ul.ie> Cc: Minchan Kim <minchan.kim@gmail.com> Signed-off-by:
-
Henrique de Moraes Holschuh authored
HBRV-based default selection of backlight control strategy didn't work well, at least the X41 defines it but doesn't use it and I don't think it will stop there. Switch to a blacklist, and make sure only Radeon- based models get ECNVRAM. Symptoms of incorrect backlight mode selection are: 1. Non-working backlight control through sysfs; 2. Backlight gets reset to the lowest level at every shutdown, reboot and when thinkpad-acpi gets unloaded; This fixes a regression in 2.6.30, bugzilla #13826. This fix is already present on 2.6.31. This is a minimal patch for 2.6.30-stable, based on mainline commits: 050df107, 7d95a3d5, 59fe4fe3, 6da25bf5 Signed-off-by:
Henrique de Moraes Holschuh <hmh@hmh.eng.br> Reported-by:
Tobias Diedrich <ranma+kernel@tdiedrich.de> Reported-by:
Robert de Rooy <robert.de.rooy@gmail.com> Signed-off-by:
-
Rafael J. Wysocki authored
commit 0c570cde upstream. Since 2.6.29 the PCI PM core have been restoring the standard configuration registers of PCI devices in the early phase of resume. In particular, PCI devices without drivers have been handled this way since commit 355a72d7 (PCI: Rework default handling of suspend and resume). Unfortunately, this leads to post-resume problems with CardBus devices which cannot be accessed in the early phase of resume, because the sockets they are on have not been woken up yet at that point. To solve this problem, move the yenta socket resume to the early phase of resume and, analogously, move the suspend of it to the late phase of suspend. Additionally, remove some unnecessary PCI code from the yenta socket's resume routine. Fixes http://bugzilla.kernel.org/show_bug.cgi?id=13092 , which is a post-2.6.28 regression. Signed-off-by:
Rafael J. Wysocki <rjw@sisk.pl> Reported-by:
Florian <fs-kernelbugzilla@spline.de> Signed-off-by:
-
Rafael J. Wysocki authored
commit 827b4649 upstream. pcmcia_socket_dev_suspend() doesn't use its second argument, so it may be dropped safely. This change is necessary for the subsequent yenta suspend/resume fix. Signed-off-by:
-
KAMEZAWA Hiroyuki authored
Not upstream due to other fixes in .32 Works around a BUG() which is triggered when the kernel accesses holes in vmalloc regions. BUG: unable to handle kernel paging request at fa54c000 IP: [<c04f687a>] read_kcore+0x260/0x31a *pde = 3540b067 *pte = 00000000 Oops: 0000 [#1] SMP last sysfs file: /sys/devices/pci0000:00/0000:00:1c.2/0000:03:00.0/ieee80211/phy0/rfkill0/state Modules linked in: fuse sco bridge stp llc bnep l2cap bluetooth sunrpc nf_conntrack_ftp ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 cpufreq_ondemand acpi_cpufreq dm_multipath uinput usb_storage arc4 ecb snd_hda_codec_realtek snd_hda_intel ath5k snd_hda_codec snd_hwdep iTCO_wdt snd_pcm iTCO_vendor_support pcspkr i2c_i801 mac80211 joydev snd_timer serio_raw r8169 snd soundcore mii snd_page_alloc ath cfg80211 ata_generic i915 drm i2c_algo_bit i2c_core video output [last unloaded: scsi_wait_scan] Sep 4 12:45:16 tuxedu kernel: Pid: 2266, comm: cat Not tainted (2.6.31-rc8 #2) Joybook Lite U101 EIP: 0060:[<c04f687a>] EFLAGS: 00010286 CPU: 0 EIP is at read_kcore+0x260/0x31a EAX: f5e5ea00 EBX: fa54d000 ECX: 00000400 EDX: 00001000 ESI: fa54c000 EDI: f44ad000 EBP: e4533f4c ESP: e4533f24 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Process cat (pid: 2266, ti=e4532000 task=f09d19a0 task.ti=e4532000) Stack: 00005000 00000000 f44ad000 09d9c000 00003000 fa54c000 00001000 f6d16f60 e4520b80 fffffffb e4533f70 c04ef8eb e4533f98 00008000 09d97000 c04f661a e4520b80 09d97000 c04ef88c e4533f8c c04ba531 e4533f98 c04c0930 e4520b80 Call Trace: [<c04ef8eb>] ? proc_reg_read+0x5f/0x73 [<c04f661a>] ? read_kcore+0x0/0x31a [<c04ef88c>] ? proc_reg_read+0x0/0x73 [<c04ba531>] ? vfs_read+0x82/0xe1 [<c04c0930>] ? path_put+0x1a/0x1d [<c04ba62e>] ? sys_read+0x40/0x62 [<c0403298>] ? sysenter_do_call+0x12/0x2d Code: 39 f3 89 ca 0f 43 f3 89 fb 29 f2 29 f3 39 cf 0f 46 d3 29 55 dc 8d 1c 32 f6 40 0c 01 75 18 89 d1 89 f7 c1 e9 02 2b 7d ec 03 7d e0 <f3> a5 89 d1 83 e1 03 74 02 f3 a4 8b 00 83 7d dc 00 74 04 85 c0 EIP: [<c04f687a>] read_kcore+0x260/0x31a SS:ESP 0068:e4533f24 CR2: 00000000fa54c000 To access vmalloc area which may have memory holes, copy_from_user is useful. So this: # cat /proc/kcore > /dev/null will not panic. This is a minimal fix, suitable for 2.6.30.x and 2.6.31. More extensive /proc/kcore changes are planned for 2.6.32. Signed-off-by:
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Tested-by:
Nick Craig-Wood <nick@craig-wood.com> Cc: Pekka Enberg <penberg@cs.helsinki.fi> Reported-by: <kbowa@tuxedu.org> Signed-off-by:
-
Weirich, Bernhard authored
[I'm going to fix upstream differently, by having all CPU types actually support _PAGE_SPECIAL, but I prefer the simple and obvious fix for -stable. -- Ben] The test that decides whether to define __HAVE_ARCH_PTE_SPECIAL on powerpc is bogus and will end up always defining it, even when _PAGE_SPECIAL is not supported (in which case it's 0) such as on 8xx or 40x processors. Signed-off-by:
Bernhard Weirich <bernhard.weirich@riedel.net> Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Rex Feany authored
commit e0908085 upstream. After upgrading to the latest kernel on my mpc875 userspace started running incredibly slow (hours to get to a shell, even!). I tracked it down to commit 8d30c14c , that patch removed a work-around for the 8xx. Adding it back makes my problem go away. Signed-off-by:
Rex Feany <rfeany@mrv.com> Signed-off-by:
-
Lee Schermerhorn authored
Not upstream as it is fixed differently in .32 I noticed that alloc_bootmem_huge_page() will only advance to the next node on failure to allocate a huge page. I asked about this on linux-mm and linux-numa, cc'ing the usual huge page suspects. Mel Gorman responded: I strongly suspect that the same node being used until allocation failure instead of round-robin is an oversight and not deliberate at all. It appears to be a side-effect of a fix made way back in commit 63b4613c ["hugetlb: fix hugepage allocation with memoryless nodes"]. Prior to that patch it looked like allocations would always round-robin even when allocation was successful. Andy Whitcroft countered that the existing behavior looked like Andi Kleen's original implementation and suggested that we ask him. We did and Andy replied that his intention was to interleave the allocations. So, ... This patch moves the advance of the hstate next node from which to allocate up before the test for success of the attempted allocation. This will unconditionally advance the next node from which to alloc, interleaving successful allocations over the nodes with sufficient contiguous memory, and skipping over nodes that fail the huge page allocation attempt. Note that alloc_bootmem_huge_page() will only be called for huge pages of order > MAX_ORDER. Signed-off-by:
Andi Kleen <ak@linux.intel.com> Cc: Mel Gorman <mel@csn.ul.ie> Cc: David Rientjes <rientjes@google.com> Cc: Adam Litke <agl@us.ibm.com> Cc: Andy Whitcroft <apw@canonical.com> Cc: Eric Whitney <eric.whitney@hp.com> Signed-off-by:
-
Michael Abbott authored
commit 96830a57 upstream. Git commit 79741dd3 changes idle cputime accounting, but unfortunately the /proc/uptime file hasn't caught up. Here the idle time calculation from /proc/stat is copied over. Signed-off-by:
Michael Abbott <michael.abbott@diamond.ac.uk> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Patrick McHardy authored
netfilter: nf_nat: fix inverted logic for persistent NAT mappings Upstream commit cce5a5c3: Kernel 2.6.30 introduced a patch [1] for the persistent option in the netfilter SNAT target. This is exactly what we need here so I had a quick look at the code and noticed that the patch is wrong. The logic is simply inverted. The patch below fixes this. Also note that because of this the default behavior of the SNAT target has changed since kernel 2.6.30 as it now ignores the destination IP in choosing the source IP for nating (which should only be the case if the persistent option is set). [1] http://git.eu.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=98d500d66cb7940747b424b245fc6a51ecfbf005 Signed-off-by:
Maximilian Engelhardt <maxi@daemonizer.de> Signed-off-by:
Patrick McHardy <kaber@trash.net> Signed-off-by:
-
Patrick McHardy authored
netfilter: ebt_ulog: fix checkentry return value Upstream commit 8a56df0a: Commit 19eda879 (netfilter: change return types of check functions for Ebtables extensions) broke the ebtables ulog module by missing a return value conversion. Signed-off-by:
-
Patrick McHardy authored
netfilter: bridge: refcount fix Upstream commit f3abc9b9: commit f216f082 ([NETFILTER]: bridge netfilter: deal with martians correctly) added a refcount leak on in_dev. Instead of using in_dev_get(), we can use __in_dev_get_rcu(), as netfilter hooks are running under rcu_read_lock(), as pointed by Patrick. Signed-off-by:
Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by:
-
Kurt Roeckx authored
commit f0adb134 upstream. Fixes bugzilla #13780 From: Kurt Roeckx <kurt@roeckx.be> Signed-off-by:
Dave Jones <davej@redhat.com> Signed-off-by:
-
Arjan van de Ven authored
fixed upstream in commit b7058842 in a different way The length of the to-copy data structure is currently stored in a signed integer. However many comparisons are done with sizeof(..) which is unsigned. It's more suitable for this variable to be unsigned to make these comparisons more naturally right. Signed-off-by:
Arjan van de Ven <arjan@linux.intel.com> Cc: David S. Miller <davem@davemloft.net> Cc: Ingo Molnar <mingo@elte.hu> Cc: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Arjan van de Ven authored
fixed upstream in commit b7058842 in a different way The ax25 code tried to use if (optlen < sizeof(int)) return -EINVAL; as a security check against optlen being negative (or zero) in the set socket option. Unfortunately, "sizeof(int)" is an unsigned property, with the result that the whole comparison is done in unsigned, letting negative values slip through. This patch changes this to if (optlen < (int)sizeof(int)) return -EINVAL; so that the comparison is done as signed, and negative values get properly caught. Signed-off-by:
-
Tejun Heo authored
commit 31b239ad upstream. Commit a5bfc471 dropped explicit pci_intx() manipulation from ahci because it seemed unnecessary and ahci doesn't seem to be the right place to be tweaking it if it were. This was largely okay but there are exceptions. There was one on an embedded platform which was fixed via firmware and now bko#14124 reports it on a HP DL320. http://bugzilla.kernel.org/show_bug.cgi?id=14124 I still think this isn't something libata drivers should be caring about (the only ones which are calling pci_intx() explicitly are libata ones and one other driver) but for now reverting the change seems to be the right thing to do. Signed-off-by:
Tejun Heo <tj@kernel.org> Reported-by:
Thomas Jarosch <thomas.jarosch@intra2net.com> Signed-off-by:
Jeff Garzik <jgarzik@redhat.com> Signed-off-by:
-
Marcelo Tosatti authored
(cherry picked from commit dc7e795e ) This reverts commit 6c20e1442bb1c62914bb85b7f4a38973d2a423ba. To my understanding, it became obsolete with the advent of the more robust check in mmu_alloc_roots (89da4ff17f). Moreover, it prevents the conceptually safe pattern 1. set sregs 2. register mem-slots 3. run vcpu by setting a sticky triple fault during step 1. Signed-off-by:
Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by:
Avi Kivity <avi@redhat.com> Signed-off-by:
-
Mark McLoughlin authored
(cherry picked from commit cb007648 ) If we run out of cpuid entries for extended request types we should return -E2BIG, just like we do for the standard request types. Signed-off-by:
Mark McLoughlin <markmc@redhat.com> Signed-off-by:
-
Glauber Costa authored
(cherry picked from commit a20316d2 ) The use of __pa() to calculate the address of a C-visible symbol is wrong, and can lead to unpredictable results. See arch/x86/include/asm/page.h for details. It should be replaced with __pa_symbol(), that does the correct math here, by taking relocations into account. This ensures the correct wallclock data structure physical address is passed to the hypervisor. Signed-off-by:
Glauber Costa <glommer@redhat.com> Signed-off-by:
-
Marcelo Tosatti authored
(cherry picked from commit 1444885a ) Otherwise its possible to starve the host by programming lapic timer with a very high frequency. Signed-off-by:
Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by:
-
Marcelo Tosatti authored
(cherry picked from commit b90c062c ) Remove the bogus n_free_mmu_pages assignment from alloc_mmu_pages. It breaks accounting of mmu pages, since n_free_mmu_pages is modified but the real number of pages remains the same. Signed-off-by:
-
Marcelo Tosatti authored
(cherry picked from commit 6a1ac771 ) n_requested_mmu_pages/n_free_mmu_pages are used by kvm_mmu_change_mmu_pages to calculate the number of pages to zap. alloc_mmu_pages, called from the vcpu initialization path, modifies this variables without proper locking, which can result in a negative value in kvm_mmu_change_mmu_pages (say, with cpu hotplug). Signed-off-by:
-
Jan Kiszka authored
(cherry picked from commit 07708c4a ) So far unprivileged guest callers running in ring 3 can issue, e.g., MMU hypercalls. Normally, such callers cannot provide any hand-crafted MMU command structure as it has to be passed by its physical address, but they can still crash the guest kernel by passing random addresses. To close the hole, this patch considers hypercalls valid only if issued from guest ring 0. This may still be relaxed on a per-hypercall base in the future once required. Signed-off-by:
-
Izik Eidus authored
(cherry picked from commit 3b80fffe ) First check if the list is empty before attempting to look at list entries. Signed-off-by:
Izik Eidus <ieidus@redhat.com> Signed-off-by:
-
Gleb Natapov authored
(cherry picked from commit 5fff7d27 ) Don't call adjust_vmx_controls() two times for the same control. It restores options that were dropped earlier. This loses us the cr8 exit control, which causes a massive performance regression Windows x64. Signed-off-by:
Gleb Natapov <gleb@redhat.com> Signed-off-by:
-
Avi Kivity authored
(cherry picked from commit 0a79b009 ) Debug registers may only be accessed from cpl 0. Unfortunately, vmx will code to emulate the instruction even though it was issued from guest userspace, possibly leading to an unexpected trap later. Signed-off-by:
-
Chuck Ebbert authored
commit 20d1752f upstream. commit ac683924 ("[CIFS] Allow raw ntlmssp code to be enabled with sec=ntlmssp") added a new bit to the allowed security flags mask but seems to have inadvertently removed Lanman security from the allowed flags. Add it back. Signed-off-by:
Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
Steve French <sfrench@us.ibm.com> Signed-off-by:
-
Christian Lamparter authored
commit f7f71173 upstream. This patch adds a new usbid for Zcomax XG-705A to the device table. Reported-by:
Jari Jaakola <jari.jaakola@gmail.com> Signed-off-by:
Christian Lamparter <chunkeey@googlemail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Ryusuke Konishi authored
commit 1f28fcd9 upstream. This will fix file system corruption which infrequently happens after mount. The problem was reported from users with the title "[NILFS users] Fail to mount NILFS." (Message-ID: <200908211918.34720.yuri@itinteg.net>), and so forth. I've also experienced the corruption multiple times on kernel 2.6.30 and 2.6.31. The problem turned out to be caused due to discordance between mapping->nrpages of a btree node cache and the actual number of pages hung on the cache; if the mapping->nrpages becomes zero even as it has pages, truncate_inode_pages() returns without doing anything. Usually this is harmless except it may cause page leak, but garbage collection fairly infrequently sees a stale page remained in the btree node cache of DAT (i.e. disk address translation file of nilfs), and induces the corruption. I identified a missing initialization in btree node caches was the root cause. This corrects the bug. I've tested this for kernel 2.6.30 and 2.6.31. Reported-by:
Yuri Chislov <yuri@itinteg.net> Signed-off-by:
Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp> Signed-off-by:
-
Paul Mundt authored
commit a9ece53c upstream. Commit b478b782 "kallsyms, tracing: output more proper symbol name" introduces a "bugfix" that introduces a segfault in kallsyms in my configurations. The cause is the introduction of prefix_underscores_count() which attempts to count underscores, even in symbols that do not have them. As a result, it just uselessly runs past the end of the buffer until it crashes: CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 KSYM .tmp_kallsyms1.S /bin/sh: line 1: 16934 Done sh-linux-gnu-nm -n .tmp_vmlinux1 16935 Segmentation fault | scripts/kallsyms > .tmp_kallsyms1.S make: *** [.tmp_kallsyms1.S] Error 139 This simplifies the logic and just does a straightforward count. Signed-off-by:
Paul Mundt <lethal@linux-sh.org> Reviewed-by:
Li Zefan <lizf@cn.fujitsu.com> Cc: Lai Jiangshan <laijs@cn.fujitsu.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Paulo Marques <pmarques@grupopie.com> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Jan Kara authored
commit 580be083 upstream. In theory it could happen that on one CPU we initialize a new inode but clearing of I_NEW | I_LOCK gets reordered before some of the initialization. Thus on another CPU we return not fully uptodate inode from iget_locked(). This seems to fix a corruption issue on ext3 mounted over NFS. [akpm@linux-foundation.org: add some commentary] Signed-off-by:
Jan Kara <jack@suse.cz> Cc: Christoph Hellwig <hch@infradead.org> Signed-off-by:
-
Alex Chiang authored
commit 7e24bc1c upstream. Similar to commit b6adc195 (PCI hotplug: acpiphp wants a 64-bit _SUN), pci_slot.ko reads and creates sysfs directories based on the _SUN method. Certain HP platforms return 64 bits in _SUN. This change to pci_slot.ko allows us to see the correct sysfs directories. Reported-by:
Chad Smith <chad.smith@hp.com> Signed-off-by:
Alex Chiang <achiang@hp.com> Signed-off-by:
Len Brown <len.brown@intel.com> Signed-off-by:
-
- 24 Sep, 2009 3 commits
-
-
Greg Kroah-Hartman authored
-
Brian King authored
commit 46db2f86 upstream. The SLB can change sizes across a live migration, which was not being handled, resulting in possible machine crashes during migration if migrating to a machine which has a smaller max SLB size than the source machine. Fix this by first reducing the SLB size to the minimum possible value, which is 32, prior to migration. Then during the device tree update which occurs after migration, we make the call to ensure the SLB gets updated. Also add the slb_size to the lparcfg output so that the migration tools can check to make sure the kernel has this capability before allowing migration in scenarios where the SLB size will change. BenH: Fixed #include <asm/mmu-hash64.h> -> <asm/mmu.h> to avoid breaking ppc32 build Signed-off-by:
Brian King <brking@linux.vnet.ibm.com> Signed-off-by:
-
Jean Delvare authored
commit 6b5096e4 upstream. One more form factor for Compaq Evo D510, which needs the same quirk as the other form factors. Apparently there's no hardware monitoring chip on that one, but SPD EEPROMs, so it's still worth unhiding the SMBus. Signed-off-by:
Jean Delvare <khali@linux-fr.org> Tested-by:
Nuzhna Pomoshch <nuzhna_pomoshch@yahoo.com> Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
