linux.git/arch/powerpc, branch v2.6.28 Linux kernel source tree powerpc: Fix corruption error in rh_alloc_fixed() 2008-12-17T16:06:14+00:00 Guillaume Knispel gknispel@proformatique.com 2008-12-09T14:28:34+00:00 af4d3643864ee5fcba0c97d77a424fa0b0346f8e There is an error in rh_alloc_fixed() of the Remote Heap code: If there is at least one free block blk won't be NULL at the end of the search loop, so -ENOMEM won't be returned and the else branch of "if (bs == s || be == e)" will be taken, corrupting the management structures. Signed-off-by: Guillaume Knispel <gknispel@proformatique.com> Acked-by: Timur Tabi <timur@freescale.com> Signed-off-by: Kumar Gala <galak@kernel.crashing.org> 
There is an error in rh_alloc_fixed() of the Remote Heap code:
If there is at least one free block blk won't be NULL at the end of the
search loop, so -ENOMEM won't be returned and the else branch of
"if (bs == s || be == e)" will be taken, corrupting the management
structures.

Signed-off-by: Guillaume Knispel <gknispel@proformatique.com>
Acked-by: Timur Tabi <timur@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
powerpc/fsl-booke: Fix the miss interrupt restore 2008-12-17T16:06:13+00:00 Dave Liu daveliu@freescale.com 2008-12-17T10:24:15+00:00 28707af01b8912e701e3c5b619ff8f6dde8f2e81 The commit e5e774d8833de1a0037be2384efccadf16935675 powerpc/fsl-booke: Fix problem with _tlbil_va being interrupted introduce one issue. that casue the problem like this: Kernel BUG at c00b19fc [verbose debug info unavailable] Oops: Exception in kernel mode, sig: 5 [#1] MPC8572 DS Modules linked in: NIP: c00b19fc LR: c00b1c34 CTR: c0064e88 REGS: ef02b7b0 TRAP: 0700 Not tainted (2.6.28-rc8-00057-g1bda712) MSR: 00021000 <ME> CR: 44048028 XER: 20000000 TASK = ef02c000[1] 'init' THREAD: ef02a000 GPR00: 00000001 ef02b860 ef02c000 eec201a0 c0dec2c0 00000000 000078a1 00000400 GPR08: c00b4e40 000078a1 c048ec00 a1780000 44048028 ecd26917 00000001 ef02b948 GPR16: ffffffea 0000020c 00000000 00000000 00000003 0000000a 00000000 000078a1 GPR24: eec201a0 00000000 ed849000 00000400 ef02b95c 00000001 ef02b978 ef02b984 NIP [c00b19fc] __find_get_block+0x24/0x238 LR [c00b1c34] __getblk+0x24/0x2a0 Call Trace: [ef02b860] [c017b768] generic_make_request+0x290/0x328 (unreliable) [ef02b8b0] [c00b1c34] __getblk+0x24/0x2a0 [ef02b910] [c00b4ae4] __bread+0x14/0xf8 [ef02b920] [c00fc228] ext2_get_branch+0xf0/0x138 [ef02b940] [c00fcc88] ext2_get_block+0xb8/0x828 [ef02ba00] [c00bbdc8] do_mpage_readpage+0x188/0x808 [ef02bac0] [c00bc5b4] mpage_readpages+0xec/0x144 [ef02bb50] [c00fba38] ext2_readpages+0x24/0x34 [ef02bb60] [c006ade0] __do_page_cache_readahead+0x150/0x230 [ef02bbb0] [c0064bdc] filemap_fault+0x31c/0x3e0 [ef02bbf0] [c00728b8] __do_fault+0x60/0x5b0 [ef02bc50] [c0011e0c] do_page_fault+0x2d8/0x4c4 [ef02bd10] [c000ed90] handle_page_fault+0xc/0x80 [ef02bdd0] [c00c7adc] set_brk+0x74/0x9c [ef02bdf0] [c00c9274] load_elf_binary+0x70c/0x1180 [ef02be70] [c00945f0] search_binary_handler+0xa8/0x274 [ef02bea0] [c0095818] do_execve+0x19c/0x1d4 [ef02bed0] [c000766c] sys_execve+0x58/0x84 [ef02bef0] [c000e950] ret_from_syscall+0x0/0x3c [ef02bfb0] [c009c6fc] sys_dup+0x24/0x6c [ef02bfc0] [c0001e04] init_post+0xb0/0xf0 [ef02bfd0] [c046c1ac] kernel_init+0xcc/0xf4 [ef02bff0] [c000e6d0] kernel_thread+0x4c/0x68 Instruction dump: 4bffffa4 813f000c 4bffffac 9421ffb0 7c0802a6 7d800026 90010054 bf210034 91810030 7c0000a6 68008000 54008ffe <0f000000> 3d20c04e 3b29ffb8 38000008 The issue was the beqlr returns early but we haven't reenabled interrupts. Signed-off-by: Dave Liu <daveliu@freescale.com> Signed-off-by: Kumar Gala <galak@kernel.crashing.org> 
The commit e5e774d8833de1a0037be2384efccadf16935675
powerpc/fsl-booke: Fix problem with _tlbil_va being interrupted
introduce one issue. that casue the problem like this:

Kernel BUG at c00b19fc [verbose debug info unavailable]
Oops: Exception in kernel mode, sig: 5 [#1]
MPC8572 DS
Modules linked in:
NIP: c00b19fc LR: c00b1c34 CTR: c0064e88
REGS: ef02b7b0 TRAP: 0700   Not tainted  (2.6.28-rc8-00057-g1bda712)
MSR: 00021000 <ME>  CR: 44048028  XER: 20000000
TASK = ef02c000[1] 'init' THREAD: ef02a000
GPR00: 00000001 ef02b860 ef02c000 eec201a0 c0dec2c0 00000000 000078a1 00000400
GPR08: c00b4e40 000078a1 c048ec00 a1780000 44048028 ecd26917 00000001 ef02b948
GPR16: ffffffea 0000020c 00000000 00000000 00000003 0000000a 00000000 000078a1
GPR24: eec201a0 00000000 ed849000 00000400 ef02b95c 00000001 ef02b978 ef02b984
NIP [c00b19fc] __find_get_block+0x24/0x238
LR [c00b1c34] __getblk+0x24/0x2a0
Call Trace:
[ef02b860] [c017b768] generic_make_request+0x290/0x328 (unreliable)
[ef02b8b0] [c00b1c34] __getblk+0x24/0x2a0
[ef02b910] [c00b4ae4] __bread+0x14/0xf8
[ef02b920] [c00fc228] ext2_get_branch+0xf0/0x138
[ef02b940] [c00fcc88] ext2_get_block+0xb8/0x828
[ef02ba00] [c00bbdc8] do_mpage_readpage+0x188/0x808
[ef02bac0] [c00bc5b4] mpage_readpages+0xec/0x144
[ef02bb50] [c00fba38] ext2_readpages+0x24/0x34
[ef02bb60] [c006ade0] __do_page_cache_readahead+0x150/0x230
[ef02bbb0] [c0064bdc] filemap_fault+0x31c/0x3e0
[ef02bbf0] [c00728b8] __do_fault+0x60/0x5b0
[ef02bc50] [c0011e0c] do_page_fault+0x2d8/0x4c4
[ef02bd10] [c000ed90] handle_page_fault+0xc/0x80
[ef02bdd0] [c00c7adc] set_brk+0x74/0x9c
[ef02bdf0] [c00c9274] load_elf_binary+0x70c/0x1180
[ef02be70] [c00945f0] search_binary_handler+0xa8/0x274
[ef02bea0] [c0095818] do_execve+0x19c/0x1d4
[ef02bed0] [c000766c] sys_execve+0x58/0x84
[ef02bef0] [c000e950] ret_from_syscall+0x0/0x3c
[ef02bfb0] [c009c6fc] sys_dup+0x24/0x6c
[ef02bfc0] [c0001e04] init_post+0xb0/0xf0
[ef02bfd0] [c046c1ac] kernel_init+0xcc/0xf4
[ef02bff0] [c000e6d0] kernel_thread+0x4c/0x68
Instruction dump:
4bffffa4 813f000c 4bffffac 9421ffb0 7c0802a6 7d800026 90010054 bf210034
91810030 7c0000a6 68008000 54008ffe <0f000000> 3d20c04e 3b29ffb8 38000008

The issue was the beqlr returns early but we haven't reenabled interrupts.

Signed-off-by: Dave Liu <daveliu@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
powerpc/cell/axon-msi: Fix MSI after kexec 2008-12-16T02:48:18+00:00 Arnd Bergmann arnd@arndb.de 2008-12-12T09:19:50+00:00 23e0e8afafd9ac065d81506524adf3339584044b Commit d015fe995 'powerpc/cell/axon-msi: Retry on missing interrupt' has turned a rare failure to kexec on QS22 into a reproducible error, which we have now analysed. The problem is that after a kexec, the MSIC hardware still points into the middle of the old ring buffer. We set up the ring buffer during reboot, but not the offset into it. On older kernels, this would cause a storm of thousands of spurious interrupts after a kexec, which would most of the time get dropped silently. With the new code, we time out on each interrupt, waiting for it to become valid. If more interrupts come in that we time out on, this goes on indefinitely, which eventually leads to a hard crash. The solution in this commit is to read the current offset from the MSIC when reinitializing it. This now works correctly, as expected. Reported-by: Dirk Herrendoerfer <d.herrendoerfer@de.ibm.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Michael Ellerman <michael@ellerman.id.au> Signed-off-by: Paul Mackerras <paulus@samba.org> 
Commit d015fe995 'powerpc/cell/axon-msi: Retry on missing interrupt'
has turned a rare failure to kexec on QS22 into a reproducible
error, which we have now analysed.

The problem is that after a kexec, the MSIC hardware still points
into the middle of the old ring buffer.  We set up the ring buffer
during reboot, but not the offset into it.  On older kernels, this
would cause a storm of thousands of spurious interrupts after a
kexec, which would most of the time get dropped silently.

With the new code, we time out on each interrupt, waiting for
it to become valid.  If more interrupts come in that we time
out on, this goes on indefinitely, which eventually leads to
a hard crash.

The solution in this commit is to read the current offset from
the MSIC when reinitializing it.  This now works correctly, as
expected.

Reported-by: Dirk Herrendoerfer <d.herrendoerfer@de.ibm.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Paul Mackerras <paulus@samba.org>
powerpc: Fix bootmem reservation on uninitialized node 2008-12-16T02:48:18+00:00 Dave Hansen dave@linux.vnet.ibm.com 2008-12-11T08:36:06+00:00 a4c74ddd5ea3db53fc73d29c222b22656a7d05be careful_allocation() was calling into the bootmem allocator for nodes which had not been fully initialized and caused a previous bug: http://patchwork.ozlabs.org/patch/10528/ So, I merged a few broken out loops in do_init_bootmem() to fix it. That changed the code ordering. I think this bug is triggered by having reserved areas for a node which are spanned by another node's contents. In the mark_reserved_regions_for_nid() code, we attempt to reserve the area for a node before we have allocated the NODE_DATA() for that nid. We do this since I reordered that loop. I suck. This is causing crashes at bootup on some systems, as reported by Jon Tollefson. This may only present on some systems that have 16GB pages reserved. But, it can probably happen on any system that is trying to reserve large swaths of memory that happen to span other nodes' contents. This commit ensures that we do not touch bootmem for any node which has not been initialized, and also removes a compile warning about an unused variable. Signed-off-by: Dave Hansen <dave@linux.vnet.ibm.com> Signed-off-by: Paul Mackerras <paulus@samba.org> 
careful_allocation() was calling into the bootmem allocator for
nodes which had not been fully initialized and caused a previous
bug:  http://patchwork.ozlabs.org/patch/10528/  So, I merged a
few broken out loops in do_init_bootmem() to fix it.  That changed
the code ordering.

I think this bug is triggered by having reserved areas for a node
which are spanned by another node's contents.  In the
mark_reserved_regions_for_nid() code, we attempt to reserve the
area for a node before we have allocated the NODE_DATA() for that
nid.  We do this since I reordered that loop.  I suck.

This is causing crashes at bootup on some systems, as reported
by Jon Tollefson.

This may only present on some systems that have 16GB pages
reserved.  But, it can probably happen on any system that is
trying to reserve large swaths of memory that happen to span other
nodes' contents.

This commit ensures that we do not touch bootmem for any node which
has not been initialized, and also removes a compile warning about
an unused variable.

Signed-off-by: Dave Hansen <dave@linux.vnet.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
powerpc: Check for valid hugepage size in hugetlb_get_unmapped_area 2008-12-16T02:48:18+00:00 Brian King brking@linux.vnet.ibm.com 2008-12-04T04:07:54+00:00 48f797de550d39ea35552646c34149991362ff7f It looks like most of the hugetlb code is doing the correct thing if hugepages are not supported, but the mmap code is not. If we get into the mmap code when hugepages are not supported, such as in an LPAR which is running Active Memory Sharing, we can oops the kernel. This fixes the oops being seen in this path. oops: Kernel access of bad area, sig: 11 [#1] SMP NR_CPUS=1024 NUMA pSeries Modules linked in: nfs(N) lockd(N) nfs_acl(N) sunrpc(N) ipv6(N) fuse(N) loop(N) dm_mod(N) sg(N) ibmveth(N) sd_mod(N) crc_t10dif(N) ibmvscsic(N) scsi_transport_srp(N) scsi_tgt(N) scsi_mod(N) Supported: No NIP: c000000000038d60 LR: c00000000003945c CTR: c0000000000393f0 REGS: c000000077e7b830 TRAP: 0300 Tainted: G (2.6.27.5-bz50170-2-ppc64) MSR: 8000000000009032 <EE,ME,IR,DR> CR: 44000448 XER: 20000001 DAR: c000002000af90a8, DSISR: 0000000040000000 TASK = c00000007c1b8600[4019] 'hugemmap01' THREAD: c000000077e78000 CPU: 6 GPR00: 0000001fffffffe0 c000000077e7bab0 c0000000009a4e78 0000000000000000 GPR04: 0000000000010000 0000000000000001 00000000ffffffff 0000000000000001 GPR08: 0000000000000000 c000000000af90c8 0000000000000001 0000000000000000 GPR12: 000000000000003f c000000000a73880 0000000000000000 0000000000000000 GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000010000 GPR20: 0000000000000000 0000000000000003 0000000000010000 0000000000000001 GPR24: 0000000000000003 0000000000000000 0000000000000001 ffffffffffffffb5 GPR28: c000000077ca2e80 0000000000000000 c00000000092af78 0000000000010000 NIP [c000000000038d60] .slice_get_unmapped_area+0x6c/0x4e0 LR [c00000000003945c] .hugetlb_get_unmapped_area+0x6c/0x80 Call Trace: [c000000077e7bbc0] [c00000000003945c] .hugetlb_get_unmapped_area+0x6c/0x80 [c000000077e7bc30] [c000000000107e30] .get_unmapped_area+0x64/0xd8 [c000000077e7bcb0] [c00000000010b140] .do_mmap_pgoff+0x140/0x420 [c000000077e7bd80] [c00000000000bf5c] .sys_mmap+0xc4/0x140 [c000000077e7be30] [c0000000000086b4] syscall_exit+0x0/0x40 Instruction dump: fac1ffb0 fae1ffb8 fb01ffc0 fb21ffc8 fb41ffd0 fb61ffd8 fb81ffe0 fbc1fff0 fbe1fff8 f821fef1 f8c10158 f8e10160 <7d49002e> f9010168 e92d01b0 eb4902b0 Signed-off-by: Brian King <brking@linux.vnet.ibm.com> Signed-off-by: Paul Mackerras <paulus@samba.org> 
It looks like most of the hugetlb code is doing the correct thing if
hugepages are not supported, but the mmap code is not.  If we get into
the mmap code when hugepages are not supported, such as in an LPAR
which is running Active Memory Sharing, we can oops the kernel.  This
fixes the oops being seen in this path.

oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=1024 NUMA pSeries
Modules linked in: nfs(N) lockd(N) nfs_acl(N) sunrpc(N) ipv6(N) fuse(N) loop(N)
dm_mod(N) sg(N) ibmveth(N) sd_mod(N) crc_t10dif(N) ibmvscsic(N)
scsi_transport_srp(N) scsi_tgt(N) scsi_mod(N)
Supported: No
NIP: c000000000038d60 LR: c00000000003945c CTR: c0000000000393f0
REGS: c000000077e7b830 TRAP: 0300   Tainted: G
(2.6.27.5-bz50170-2-ppc64)
MSR: 8000000000009032 <EE,ME,IR,DR>  CR: 44000448  XER: 20000001
DAR: c000002000af90a8, DSISR: 0000000040000000
TASK = c00000007c1b8600[4019] 'hugemmap01' THREAD: c000000077e78000 CPU: 6
GPR00: 0000001fffffffe0 c000000077e7bab0 c0000000009a4e78 0000000000000000
GPR04: 0000000000010000 0000000000000001 00000000ffffffff 0000000000000001
GPR08: 0000000000000000 c000000000af90c8 0000000000000001 0000000000000000
GPR12: 000000000000003f c000000000a73880 0000000000000000 0000000000000000
GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000010000
GPR20: 0000000000000000 0000000000000003 0000000000010000 0000000000000001
GPR24: 0000000000000003 0000000000000000 0000000000000001 ffffffffffffffb5
GPR28: c000000077ca2e80 0000000000000000 c00000000092af78 0000000000010000
NIP [c000000000038d60] .slice_get_unmapped_area+0x6c/0x4e0
LR [c00000000003945c] .hugetlb_get_unmapped_area+0x6c/0x80
Call Trace:
[c000000077e7bbc0] [c00000000003945c] .hugetlb_get_unmapped_area+0x6c/0x80
[c000000077e7bc30] [c000000000107e30] .get_unmapped_area+0x64/0xd8
[c000000077e7bcb0] [c00000000010b140] .do_mmap_pgoff+0x140/0x420
[c000000077e7bd80] [c00000000000bf5c] .sys_mmap+0xc4/0x140
[c000000077e7be30] [c0000000000086b4] syscall_exit+0x0/0x40
Instruction dump:
fac1ffb0 fae1ffb8 fb01ffc0 fb21ffc8 fb41ffd0 fb61ffd8 fb81ffe0 fbc1fff0
fbe1fff8 f821fef1 f8c10158 f8e10160 <7d49002e> f9010168 e92d01b0 eb4902b0

Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Merge branch 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc 2008-12-15T00:25:19+00:00 Linus Torvalds torvalds@linux-foundation.org 2008-12-15T00:25:19+00:00 cefb3d02cad6fae49369cdde24526c4c4806b20f * 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc: powerpc/fsl-booke: Fix problem with _tlbil_va being interrupted 
* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc:
  powerpc/fsl-booke: Fix problem with _tlbil_va being interrupted
powerpc/fsl-booke: Fix problem with _tlbil_va being interrupted 2008-12-13T23:02:47+00:00 Kumar Gala galak@kernel.crashing.org 2008-12-13T23:01:37+00:00 e5e774d8833de1a0037be2384efccadf16935675 An example calling sequence which we did see: copy_user_highpage -> kmap_atomic -> flush_tlb_page -> _tlbil_va We got interrupted after setting up the MAS registers before the tlbwe and the interrupt handler that caused the interrupt also did a kmap_atomic (ide code) and thus on returning from the interrupt the MAS registers no longer contained the proper values. Since we dont save/restore MAS registers for normal interrupts we need to disable interrupts in _tlbil_va to ensure atomicity. Signed-off-by: Kumar Gala <galak@kernel.crashing.org> 
An example calling sequence which we did see:

copy_user_highpage -> kmap_atomic -> flush_tlb_page -> _tlbil_va

We got interrupted after setting up the MAS registers before the
tlbwe and the interrupt handler that caused the interrupt also did
a kmap_atomic (ide code) and thus on returning from the interrupt
the MAS registers no longer contained the proper values.

Since we dont save/restore MAS registers for normal interrupts we
need to disable interrupts in _tlbil_va to ensure atomicity.

Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
powerpc/40x: Add proper BOOTCFLAGS for cuboot-acadia 2008-12-11T12:34:22+00:00 Josh Boyer jwboyer@linux.vnet.ibm.com 2008-11-25T06:33:35+00:00 9f3eefc4f9b02404e89d624a6cd40e7b468b5fd5 The cuboot-acadia.c wrapper can cause assembler errors on some toolchains due to the lack of the proper BOOTCFLAGS. This adds the proper flags for the file. Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com> 
The cuboot-acadia.c wrapper can cause assembler errors on some
toolchains due to the lack of the proper BOOTCFLAGS.  This adds
the proper flags for the file.

Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Merge branch 'merge' of master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc into merge 2008-12-09T03:58:37+00:00 Paul Mackerras paulus@samba.org 2008-12-09T03:58:37+00:00 ab44f4627e2160cddbddbe8aa8b1d2b2e1559790 






powerpc/virtex5: Fix Virtex5 machine check handling
2008-12-05T19:34:26+00:00

Grant Likely
grant.likely@secretlab.ca

2008-12-04T05:39:55+00:00

640d17d60e83401e10e66a0ab6e9e2d6350df656

The 440x5 core in the Virtex5 uses the 440A type machine check
(ie, they have MCSRR0/MCSRR1). They thus need to call the
appropriate fixup function to hook the right variant of the
exception.

Without this, all machine checks become fatal due to loss
of context when entering the exception handler.

Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>





The 440x5 core in the Virtex5 uses the 440A type machine check
(ie, they have MCSRR0/MCSRR1). They thus need to call the
appropriate fixup function to hook the right variant of the
exception.

Without this, all machine checks become fatal due to loss
of context when entering the exception handler.

Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>