* Re: [BUG] 2.6.25-rc3-mm1 kernel panic while bootup on powerpc ()
From: Andrew Morton @ 2008-03-04 20:34 UTC (permalink / raw)
To: Christoph Lameter; +Cc: linux-mm, mel, kamalesh, linuxppc-dev, penberg, stable
In-Reply-To: <Pine.LNX.4.64.0803041205370.18277@schroedinger.engr.sgi.com>
On Tue, 4 Mar 2008 12:07:39 -0800 (PST)
Christoph Lameter <clameter@sgi.com> wrote:
> I think this is the correct fix.
>
> The NUMA fallback logic should be passing local_flags to kmem_get_pages()
> and not simply the flags.
>
> Maybe a stable candidate since we are now simply
> passing on flags to the page allocator on the fallback path.
Do we know why this is only reported in 2.6.25-rc3-mm1?
Why does this need fixing in 2.6.24.x?
Thanks.
> Signed-off-by: Christoph Lameter <clameter@sgi.com>
>
> ---
> mm/slab.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: linux-2.6.25-rc3-mm1/mm/slab.c
> ===================================================================
> --- linux-2.6.25-rc3-mm1.orig/mm/slab.c 2008-03-04 12:01:07.430911920 -0800
> +++ linux-2.6.25-rc3-mm1/mm/slab.c 2008-03-04 12:04:54.449857145 -0800
> @@ -3277,7 +3277,7 @@ retry:
> if (local_flags & __GFP_WAIT)
> local_irq_enable();
> kmem_flagcheck(cache, flags);
> - obj = kmem_getpages(cache, flags, -1);
> + obj = kmem_getpages(cache, local_flags, -1);
> if (local_flags & __GFP_WAIT)
> local_irq_disable();
> if (obj) {
^ permalink raw reply
* Re: V4L2: __ucmpdi2 undefined on ppc
From: Segher Boessenkool @ 2008-03-04 20:32 UTC (permalink / raw)
To: David Woodhouse; +Cc: paulus, henrik.sorensen, Stephane Marchesin, linuxppc-dev
In-Reply-To: <1204648648.3891.439.camel@pmac.infradead.org>
>> Every occurrence of r7 here is wrong (and some of the r6).
>
> Can you elucidate?
Sure! It should read either "7" or "cr7".
>> Is there any reason to do this in assembler code at all?
>
> Is there any particular reason not to?
1) If written in assembler, it needs to be written for every
architecture
separately, and sometimes even for every architecture variant (32 vs. 64
bit is only the tip of the iceberg).
2) As shown here as well as in the recent strncmp() patch, it is a lot
harder
to write correct assembler code than it is to write correct C code(*),
and
the C code isn't less efficient either.
Segher
(*) Well, the generic C strncmp() code in the kernel is broken too, bad
example perhaps :-)
^ permalink raw reply
* Re: [BUG] 2.6.25-rc3-mm1 kernel panic while bootup on powerpc ()
From: Pekka Enberg @ 2008-03-04 20:08 UTC (permalink / raw)
To: Christoph Lameter
Cc: linux-mm, Mel Gorman, Kamalesh Babulal, linuxppc-dev,
Andrew Morton
In-Reply-To: <Pine.LNX.4.64.0803041205370.18277@schroedinger.engr.sgi.com>
Christoph Lameter wrote:
> I think this is the correct fix.
>
> The NUMA fallback logic should be passing local_flags to kmem_get_pages()
> and not simply the flags.
>
> Maybe a stable candidate since we are now simply
> passing on flags to the page allocator on the fallback path.
>
> Signed-off-by: Christoph Lameter <clameter@sgi.com>
Indeed, good catch. I spotted the same thing just few seconds ago.
Reviewed-by: Pekka Enberg <penberg@cs.helsinki.fi>
Was it you Kamalesh that reported this? Can you please re-test?
^ permalink raw reply
* Re: [BUG] 2.6.25-rc3-mm1 kernel panic while bootup on powerpc ()
From: Christoph Lameter @ 2008-03-04 20:07 UTC (permalink / raw)
To: Pekka J Enberg
Cc: linux-mm, Mel Gorman, Kamalesh Babulal, linuxppc-dev,
Andrew Morton
In-Reply-To: <Pine.LNX.4.64.0803042200410.8545@sbz-30.cs.Helsinki.FI>
I think this is the correct fix.
The NUMA fallback logic should be passing local_flags to kmem_get_pages()
and not simply the flags.
Maybe a stable candidate since we are now simply
passing on flags to the page allocator on the fallback path.
Signed-off-by: Christoph Lameter <clameter@sgi.com>
---
mm/slab.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.25-rc3-mm1/mm/slab.c
===================================================================
--- linux-2.6.25-rc3-mm1.orig/mm/slab.c 2008-03-04 12:01:07.430911920 -0800
+++ linux-2.6.25-rc3-mm1/mm/slab.c 2008-03-04 12:04:54.449857145 -0800
@@ -3277,7 +3277,7 @@ retry:
if (local_flags & __GFP_WAIT)
local_irq_enable();
kmem_flagcheck(cache, flags);
- obj = kmem_getpages(cache, flags, -1);
+ obj = kmem_getpages(cache, local_flags, -1);
if (local_flags & __GFP_WAIT)
local_irq_disable();
if (obj) {
^ permalink raw reply
* Re: [BUG] 2.6.25-rc3-mm1 kernel panic while bootup on powerpc ()
From: Christoph Lameter @ 2008-03-04 20:02 UTC (permalink / raw)
To: Pekka J Enberg
Cc: linux-mm, Mel Gorman, Kamalesh Babulal, linuxppc-dev,
Andrew Morton
In-Reply-To: <Pine.LNX.4.64.0803042200410.8545@sbz-30.cs.Helsinki.FI>
On Tue, 4 Mar 2008, Pekka J Enberg wrote:
> On Tue, 4 Mar 2008, Christoph Lameter wrote:
> > Slab allocations should never be passed these flags since the slabs do
> > their own thing there.
> >
> > The following patch would clear these in slub:
>
> Here's the same fix for SLAB:
That is an immediate fix ok. But there must be some location where SLAB
does the masking of the gfp bits where things go wrong. Looking for that.
^ permalink raw reply
* Re: [BUG] 2.6.25-rc3-mm1 kernel panic while bootup on powerpc ()
From: Christoph Lameter @ 2008-03-04 20:01 UTC (permalink / raw)
To: Pekka Enberg
Cc: linux-mm, Mel Gorman, Kamalesh Babulal, linuxppc-dev,
Andrew Morton
In-Reply-To: <84144f020803041141x5bb55832r495d7fde92356e27@mail.gmail.com>
On Tue, 4 Mar 2008, Pekka Enberg wrote:
> > > >> [c000000009edf5f0] [c0000000000b56e4] .__alloc_pages_internal+0xf8/0x470
> > > >> [c000000009edf6e0] [c0000000000e0458] .kmem_getpages+0x8c/0x194
> > > >> [c000000009edf770] [c0000000000e1050] .fallback_alloc+0x194/0x254
> > > >> [c000000009edf820] [c0000000000e14b0] .kmem_cache_alloc+0xd8/0x144
Ahh! This is SLAB. slub does not suffer this problem since new_slab()
masks the bits correctly.
So we need to fix SLAB.
^ permalink raw reply
* Re: [BUG] 2.6.25-rc3-mm1 kernel panic while bootup on powerpc ()
From: Pekka J Enberg @ 2008-03-04 20:01 UTC (permalink / raw)
To: Christoph Lameter
Cc: linux-mm, Mel Gorman, Kamalesh Babulal, linuxppc-dev,
Andrew Morton
In-Reply-To: <Pine.LNX.4.64.0803041151360.18160@schroedinger.engr.sgi.com>
On Tue, 4 Mar 2008, Christoph Lameter wrote:
> Slab allocations should never be passed these flags since the slabs do
> their own thing there.
>
> The following patch would clear these in slub:
Here's the same fix for SLAB:
diff --git a/mm/slab.c b/mm/slab.c
index 473e6c2..c6dbf7e 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -1677,6 +1677,7 @@ static void *kmem_getpages(struct kmem_cache *cachep, gfp_t flags, int nodeid)
flags |= __GFP_COMP;
#endif
+ flags &= ~GFP_MOVABLE_MASK;
flags |= cachep->gfpflags;
if (cachep->flags & SLAB_RECLAIM_ACCOUNT)
flags |= __GFP_RECLAIMABLE;
^ permalink raw reply related
* Re: [BUG] 2.6.25-rc3-mm1 kernel bug while running libhugetlbfs
From: Andrew Morton @ 2008-03-04 19:51 UTC (permalink / raw)
To: Kamalesh Babulal; +Cc: linuxppc-dev, balbir, linux-kernel
In-Reply-To: <47CDA0F1.9030908@linux.vnet.ibm.com>
On Wed, 05 Mar 2008 00:50:17 +0530
Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
> Hi Andrew,
>
> kernel bug is triggered while running libhugetlbfs test with 2.6.25-rc3-mm1 kernel
> over the x86 and power machines.
>
> ------------[ cut here ]------------
> kernel BUG at mm/hugetlb.c:295!
> invalid opcode: 0000 [#1] SMP
> last sysfs file: /sys/devices/system/node/possible
> Modules linked in:
>
> Pid: 5484, comm: counters Not tainted (2.6.25-rc3-mm1-autokern1 #1)
> EIP: 0060:[<c10535cf>] EFLAGS: 00010202 CPU: 0
> EIP is at alloc_buddy_huge_page+0x7a/0xb0
> EAX: c13acd01 EBX: f7d3a000 ECX: 00000000 EDX: 00006363
> ESI: 00000001 EDI: 00000000 EBP: 00000000 ESP: f5539ebc
> DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
> Process counters (pid: 5484, ti=f5538000 task=f60afa20 task.ti=f5538000)
> Stack: 00000001 c1053669 fffffff4 00000001 f5539ecc f5539ecc 00000001 fffffff4
> f55d0e78 00000001 c105480c 00000001 00200000 c1054875 00000000 f54426c0
> 00200000 00000000 f54426c0 c10b0fb8 fffffff4 00200000 00000000 f55d0e78
> Call Trace:
> [<c1053669>] gather_surplus_pages+0x64/0x16d
> [<c105480c>] hugetlb_acct_memory+0x1e/0x4a
> [<c1054875>] hugetlb_reserve_pages+0x3d/0x6b
> [<c10b0fb8>] hugetlbfs_file_mmap+0x9b/0xe1
> [<c104bf9f>] mmap_region+0x1dc/0x3ae
> [<c104bd42>] do_mmap_pgoff+0x27f/0x28e
> [<c1005af2>] sys_mmap2+0x5a/0x78
> [<c10029fa>] syscall_call+0x7/0xb
> =======================
> Code: c1 e8 ed 27 1c 00 85 db 74 41 83 7b 04 00 75 10 68 c0 93 27 c1 e8 02 92 fc ff 58 e8 c1 02 fb ff f0 ff 4b 04 0f 94 c0 84 c0 74 04 <0f> 0b eb fe c7 43 38 3e 33 05 c1 8b 03 c1 e8 1c ff 04 85 60 ce
> EIP: [<c10535cf>] alloc_buddy_huge_page+0x7a/0xb0 SS:ESP 0068:f5539ebc
> ---[ end trace 5a47484f8fe93a33 ]---
>
>
Please send Adam a copy of that libhugetlbfs test ;)
hugetlb-correct-page-count-for-surplus-huge-pages.patch adds:
if (page) {
/*
* This page is now managed by the hugetlb allocator and has
* no users -- drop the buddy allocator's reference.
*/
int page_count = put_page_testzero(page);
BUG_ON(page_count != 0);
^ permalink raw reply
* Re: [BUG] 2.6.25-rc3-mm1 kernel panic while bootup on powerpc ()
From: Christoph Lameter @ 2008-03-04 19:56 UTC (permalink / raw)
To: Pekka Enberg
Cc: linux-mm, Mel Gorman, Kamalesh Babulal, linuxppc-dev,
Andrew Morton
In-Reply-To: <84144f020803041141x5bb55832r495d7fde92356e27@mail.gmail.com>
On Tue, 4 Mar 2008, Pekka Enberg wrote:
> > > I suspect the WARN_ON() is bogus although I really don't know that part
> > > of the code all too well. Mel?
> > >
> >
> > The warn-on is valid. A situation should not exist that allows both flags to
> > be set. I suspect if remove-set_migrateflags.patch was reverted from -mm
> > the warning would not trigger. Christoph, would it be reasonable to always
> > clear __GFP_MOVABLE when __GFP_RECLAIMABLE is set for SLAB_RECLAIM_ACCOUNT.
Slab allocations should never be passed these flags since the slabs do
their own thing there.
The following patch would clear these in slub:
---
mm/slub.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.25-rc3-mm1/mm/slub.c
===================================================================
--- linux-2.6.25-rc3-mm1.orig/mm/slub.c 2008-03-04 11:53:47.600342756 -0800
+++ linux-2.6.25-rc3-mm1/mm/slub.c 2008-03-04 11:55:40.153855150 -0800
@@ -1033,8 +1033,8 @@ static struct page *allocate_slab(struct
struct page *page;
int pages = 1 << s->order;
+ flags &= ~GFP_MOVABLE_MASK;
flags |= s->allocflags;
-
page = alloc_slab_page(flags | __GFP_NOWARN | __GFP_NORETRY,
node, s->order);
if (unlikely(!page)) {
^ permalink raw reply
* Re: [BUG] 2.6.25-rc3-mm1 kernel panic while bootup on powerpc ()
From: Pekka Enberg @ 2008-03-04 19:41 UTC (permalink / raw)
To: Mel Gorman
Cc: linuxppc-dev, Kamalesh Babulal, linux-mm, Andrew Morton,
Christoph Lameter
In-Reply-To: <20080304193532.GC9051@csn.ul.ie>
(adding Christoph as cc)
On Tue, Mar 4, 2008 at 9:35 PM, Mel Gorman <mel@csn.ul.ie> wrote:
> > >> [c000000009edf5f0] [c0000000000b56e4] .__alloc_pages_internal+0xf8/0x470
> > >> [c000000009edf6e0] [c0000000000e0458] .kmem_getpages+0x8c/0x194
> > >> [c000000009edf770] [c0000000000e1050] .fallback_alloc+0x194/0x254
> > >> [c000000009edf820] [c0000000000e14b0] .kmem_cache_alloc+0xd8/0x144
> > >> [c000000009edf8c0] [c0000000001fe0f8] .radix_tree_preload+0x50/0xd4
> > >> [c000000009edf960] [c0000000000ad048] .add_to_page_cache+0x38/0x12c
> > >> [c000000009edfa00] [c0000000000ad158] .add_to_page_cache_lru+0x1c/0x4c
> > >> [c000000009edfa90] [c0000000000add58] .find_or_create_page+0x60/0xa8
> > >> [c000000009edfb30] [c00000000011e478] .__getblk+0x140/0x310
> > >> [c000000009edfc00] [c0000000001b78c4]
> > >.journal_get_descriptor_buffer+0x44/0xd8
> > >> [c000000009edfca0] [c0000000001b236c]
> > >.journal_commit_transaction+0x948/0x1590
> > >> [c000000009edfe00] [c0000000001b585c] .kjournald+0xf4/0x2ac
> > >> [c000000009edff00] [c00000000007ff4c] .kthread+0x84/0xd0
> > >> [c000000009edff90] [c000000000028900] .kernel_thread+0x4c/0x68
> > >> Instruction dump:
> > >> 7dc57378 48009575 60000000 2fa30000 419e0490 56c902d8 3c000018 7dd907b4
> > >> 7ad2c7e2 7f890000 7c000026 5400fffe <0b000000> e93e8128 3b000000
> > >80090000
> > >/* Convert GFP flags to their corresponding migrate type */
> > >static inline int allocflags_to_migratetype(gfp_t gfp_flags)
> > >{
> > > WARN_ON((gfp_flags & GFP_MOVABLE_MASK) == GFP_MOVABLE_MASK);
> > >
> > >Mel, Pekka: would you have some head-scratching time for this one please?
> >
> > What we have is __getblk() -> __getblk_slow() -> grow_buffers() ->
> > grow_dev_page() doing find_or_create_page() with __GFP_MOVABLE set. That
> > path then eventually does radix_tree_preload -> kmem_cache_alloc() to a
> > cache that has SLAB_RECLAIM_ACCOUNT set which implies __GFP_RECLAIMABLE
> > (for both SLAB and SLUB). So we oops there.
> >
> > I suspect the WARN_ON() is bogus although I really don't know that part
> > of the code all too well. Mel?
> >
>
> The warn-on is valid. A situation should not exist that allows both flags to
> be set. I suspect if remove-set_migrateflags.patch was reverted from -mm
> the warning would not trigger. Christoph, would it be reasonable to always
> clear __GFP_MOVABLE when __GFP_RECLAIMABLE is set for SLAB_RECLAIM_ACCOUNT.
>
> --
> Mel Gorman
> Part-time Phd Student Linux Technology Center
> University of Limerick IBM Dublin Software Lab
>
>
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
>
^ permalink raw reply
* Re: [BUG] 2.6.25-rc3-mm1 kernel panic while bootup on powerpc ()
From: Mel Gorman @ 2008-03-04 19:35 UTC (permalink / raw)
To: Pekka Enberg; +Cc: linux-mm, linuxppc-dev, Andrew Morton, Kamalesh Babulal
In-Reply-To: <47CDA081.7070503@cs.helsinki.fi>
On (04/03/08 21:18), Pekka Enberg didst pronounce:
> Andrew Morton wrote:
> >> [c000000009edf5f0] [c0000000000b56e4] .__alloc_pages_internal+0xf8/0x470
> >> [c000000009edf6e0] [c0000000000e0458] .kmem_getpages+0x8c/0x194
> >> [c000000009edf770] [c0000000000e1050] .fallback_alloc+0x194/0x254
> >> [c000000009edf820] [c0000000000e14b0] .kmem_cache_alloc+0xd8/0x144
> >> [c000000009edf8c0] [c0000000001fe0f8] .radix_tree_preload+0x50/0xd4
> >> [c000000009edf960] [c0000000000ad048] .add_to_page_cache+0x38/0x12c
> >> [c000000009edfa00] [c0000000000ad158] .add_to_page_cache_lru+0x1c/0x4c
> >> [c000000009edfa90] [c0000000000add58] .find_or_create_page+0x60/0xa8
> >> [c000000009edfb30] [c00000000011e478] .__getblk+0x140/0x310
> >> [c000000009edfc00] [c0000000001b78c4]
> >.journal_get_descriptor_buffer+0x44/0xd8
> >> [c000000009edfca0] [c0000000001b236c]
> >.journal_commit_transaction+0x948/0x1590
> >> [c000000009edfe00] [c0000000001b585c] .kjournald+0xf4/0x2ac
> >> [c000000009edff00] [c00000000007ff4c] .kthread+0x84/0xd0
> >> [c000000009edff90] [c000000000028900] .kernel_thread+0x4c/0x68
> >> Instruction dump:
> >> 7dc57378 48009575 60000000 2fa30000 419e0490 56c902d8 3c000018 7dd907b4
> >> 7ad2c7e2 7f890000 7c000026 5400fffe <0b000000> e93e8128 3b000000
> >80090000
> >/* Convert GFP flags to their corresponding migrate type */
> >static inline int allocflags_to_migratetype(gfp_t gfp_flags)
> >{
> > WARN_ON((gfp_flags & GFP_MOVABLE_MASK) == GFP_MOVABLE_MASK);
> >
> >Mel, Pekka: would you have some head-scratching time for this one please?
>
> What we have is __getblk() -> __getblk_slow() -> grow_buffers() ->
> grow_dev_page() doing find_or_create_page() with __GFP_MOVABLE set. That
> path then eventually does radix_tree_preload -> kmem_cache_alloc() to a
> cache that has SLAB_RECLAIM_ACCOUNT set which implies __GFP_RECLAIMABLE
> (for both SLAB and SLUB). So we oops there.
>
> I suspect the WARN_ON() is bogus although I really don't know that part
> of the code all too well. Mel?
>
The warn-on is valid. A situation should not exist that allows both flags to
be set. I suspect if remove-set_migrateflags.patch was reverted from -mm
the warning would not trigger. Christoph, would it be reasonable to always
clear __GFP_MOVABLE when __GFP_RECLAIMABLE is set for SLAB_RECLAIM_ACCOUNT.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* Re: [BUG] 2.6.25-rc3-mm1 kernel panic while bootup on powerpc ()
From: Pekka Enberg @ 2008-03-04 19:18 UTC (permalink / raw)
To: Andrew Morton
Cc: linuxppc-dev, Mel Gorman, linux-kernel, Kamalesh Babulal,
linux-mm
In-Reply-To: <20080304103636.3e7b8fdd.akpm@linux-foundation.org>
Andrew Morton wrote:
> > [c000000009edf5f0] [c0000000000b56e4] .__alloc_pages_internal+0xf8/0x470
> > [c000000009edf6e0] [c0000000000e0458] .kmem_getpages+0x8c/0x194
> > [c000000009edf770] [c0000000000e1050] .fallback_alloc+0x194/0x254
> > [c000000009edf820] [c0000000000e14b0] .kmem_cache_alloc+0xd8/0x144
> > [c000000009edf8c0] [c0000000001fe0f8] .radix_tree_preload+0x50/0xd4
> > [c000000009edf960] [c0000000000ad048] .add_to_page_cache+0x38/0x12c
> > [c000000009edfa00] [c0000000000ad158] .add_to_page_cache_lru+0x1c/0x4c
> > [c000000009edfa90] [c0000000000add58] .find_or_create_page+0x60/0xa8
> > [c000000009edfb30] [c00000000011e478] .__getblk+0x140/0x310
> > [c000000009edfc00] [c0000000001b78c4] .journal_get_descriptor_buffer+0x44/0xd8
> > [c000000009edfca0] [c0000000001b236c] .journal_commit_transaction+0x948/0x1590
> > [c000000009edfe00] [c0000000001b585c] .kjournald+0xf4/0x2ac
> > [c000000009edff00] [c00000000007ff4c] .kthread+0x84/0xd0
> > [c000000009edff90] [c000000000028900] .kernel_thread+0x4c/0x68
> > Instruction dump:
> > 7dc57378 48009575 60000000 2fa30000 419e0490 56c902d8 3c000018 7dd907b4
> > 7ad2c7e2 7f890000 7c000026 5400fffe <0b000000> e93e8128 3b000000 80090000
>
> /* Convert GFP flags to their corresponding migrate type */
> static inline int allocflags_to_migratetype(gfp_t gfp_flags)
> {
> WARN_ON((gfp_flags & GFP_MOVABLE_MASK) == GFP_MOVABLE_MASK);
>
> Mel, Pekka: would you have some head-scratching time for this one please?
What we have is __getblk() -> __getblk_slow() -> grow_buffers() ->
grow_dev_page() doing find_or_create_page() with __GFP_MOVABLE set. That
path then eventually does radix_tree_preload -> kmem_cache_alloc() to a
cache that has SLAB_RECLAIM_ACCOUNT set which implies __GFP_RECLAIMABLE
(for both SLAB and SLUB). So we oops there.
I suspect the WARN_ON() is bogus although I really don't know that part
of the code all too well. Mel?
Pekka
^ permalink raw reply
* [BUG] 2.6.25-rc3-mm1 kernel bug while running libhugetlbfs
From: Kamalesh Babulal @ 2008-03-04 19:20 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, Balbir Singh, linux-kernel
In-Reply-To: <20080304011928.e8c82c0c.akpm@linux-foundation.org>
Hi Andrew,
kernel bug is triggered while running libhugetlbfs test with 2.6.25-rc3-mm1 kernel
over the x86 and power machines.
------------[ cut here ]------------
kernel BUG at mm/hugetlb.c:295!
invalid opcode: 0000 [#1] SMP
last sysfs file: /sys/devices/system/node/possible
Modules linked in:
Pid: 5484, comm: counters Not tainted (2.6.25-rc3-mm1-autokern1 #1)
EIP: 0060:[<c10535cf>] EFLAGS: 00010202 CPU: 0
EIP is at alloc_buddy_huge_page+0x7a/0xb0
EAX: c13acd01 EBX: f7d3a000 ECX: 00000000 EDX: 00006363
ESI: 00000001 EDI: 00000000 EBP: 00000000 ESP: f5539ebc
DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process counters (pid: 5484, ti=f5538000 task=f60afa20 task.ti=f5538000)
Stack: 00000001 c1053669 fffffff4 00000001 f5539ecc f5539ecc 00000001 fffffff4
f55d0e78 00000001 c105480c 00000001 00200000 c1054875 00000000 f54426c0
00200000 00000000 f54426c0 c10b0fb8 fffffff4 00200000 00000000 f55d0e78
Call Trace:
[<c1053669>] gather_surplus_pages+0x64/0x16d
[<c105480c>] hugetlb_acct_memory+0x1e/0x4a
[<c1054875>] hugetlb_reserve_pages+0x3d/0x6b
[<c10b0fb8>] hugetlbfs_file_mmap+0x9b/0xe1
[<c104bf9f>] mmap_region+0x1dc/0x3ae
[<c104bd42>] do_mmap_pgoff+0x27f/0x28e
[<c1005af2>] sys_mmap2+0x5a/0x78
[<c10029fa>] syscall_call+0x7/0xb
=======================
Code: c1 e8 ed 27 1c 00 85 db 74 41 83 7b 04 00 75 10 68 c0 93 27 c1 e8 02 92 fc ff 58 e8 c1 02 fb ff f0 ff 4b 04 0f 94 c0 84 c0 74 04 <0f> 0b eb fe c7 43 38 3e 33 05 c1 8b 03 c1 e8 1c ff 04 85 60 ce
EIP: [<c10535cf>] alloc_buddy_huge_page+0x7a/0xb0 SS:ESP 0068:f5539ebc
---[ end trace 5a47484f8fe93a33 ]---
------------[ cut here ]------------
cpu 0x3: Vector: 700 (Program Check) at [c0000000fb277740]
pc: c0000000000c6f54: .alloc_buddy_huge_page+0x120/0x1dc
lr: c0000000000c6f20: .alloc_buddy_huge_page+0xec/0x1dc
sp: c0000000fb2779c0
msr: 8000000000029032
current = 0xc0000000fc4cae90
paca = 0xc0000000004fae80
pid = 6828, comm = counters
kernel BUG at mm/hugetlb.c:295!
enter ? for help
[c0000000fb277a50] c0000000000c70e8 .hugetlb_acct_memory+0xd8/0x374
[c0000000fb277b10] c0000000000c769c .hugetlb_reserve_pages+0x184/0x2b0
[c0000000fb277bc0] c00000000018c950 .hugetlbfs_file_mmap+0xec/0x160
[c0000000fb277c70] c0000000000bc280 .mmap_region+0x254/0x4d4
[c0000000fb277d80] c00000000000b1b8 .sys_mmap+0xa4/0x104
[c0000000fb277e30] c00000000000872c syscall_exit+0x0/0x40
--- Exception: c01 (System Call) at 000004000019e528
SP (fffffcd4eb0) is in userspace
3:mon>
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* Re: dtc: Make some functions local to parser
From: Scott Wood @ 2008-03-04 19:18 UTC (permalink / raw)
To: Jon Loeliger, linuxppc-dev
In-Reply-To: <20080304043700.GB2757@localhost.localdomain>
On Tue, Mar 04, 2008 at 03:37:00PM +1100, David Gibson wrote:
> * The Bison documentation explicitly permits yyerror() to be a
> variadic function, so fold yyerror() and yyerrorf() into a single
> printf-style function.
Then the bison documentation is not consistent with the bison
implementation when verbose error messages are enabled. How can it possibly
know whether to put % or %% in the string when an unexpected % is
encountered?
Reading bison internals makes my head hurt...
> The combined function is defined and used
> only in the parse, so make it static.
Static-izing something that is used externally in a posted patch where
you've provided no alternate to use is rather bad form...
-Scott
^ permalink raw reply
* [patch 16/16] xtensa: use generic pci_enable_resources()
From: Bjorn Helgaas @ 2008-03-04 18:57 UTC (permalink / raw)
To: linux-pci, linux-arch
Cc: Chris Zankel, Grant Grundler, linux-parisc, Matthew Wilcox,
Kyle McMartin, linuxppc-dev, Paul Mackerras, linux-arm-kernel,
Russell King
In-Reply-To: <20080304185646.864917286@ldl.fc.hp.com>
Use the generic pci_enable_resources() instead of the arch-specific code.
Unlike this arch-specific code, the generic version:
- checks PCI_NUM_RESOURCES (11), not 6, resources
- skips resources that have neither IORESOURCE_IO nor IORESOURCE_MEM set
- skips ROM resources unless IORESOURCE_ROM_ENABLE is set
- checks for resource collisions with "!r->parent"
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Index: work8/arch/xtensa/kernel/pci.c
===================================================================
--- work8.orig/arch/xtensa/kernel/pci.c 2008-03-04 10:17:29.000000000 -0700
+++ work8/arch/xtensa/kernel/pci.c 2008-03-04 10:18:07.000000000 -0700
@@ -91,37 +91,6 @@
}
}
-int
-pcibios_enable_resources(struct pci_dev *dev, int mask)
-{
- u16 cmd, old_cmd;
- int idx;
- struct resource *r;
-
- pci_read_config_word(dev, PCI_COMMAND, &cmd);
- old_cmd = cmd;
- for(idx=0; idx<6; idx++) {
- r = &dev->resource[idx];
- if (!r->start && r->end) {
- printk (KERN_ERR "PCI: Device %s not available because "
- "of resource collisions\n", pci_name(dev));
- return -EINVAL;
- }
- if (r->flags & IORESOURCE_IO)
- cmd |= PCI_COMMAND_IO;
- if (r->flags & IORESOURCE_MEM)
- cmd |= PCI_COMMAND_MEMORY;
- }
- if (dev->resource[PCI_ROM_RESOURCE].start)
- cmd |= PCI_COMMAND_MEMORY;
- if (cmd != old_cmd) {
- printk("PCI: Enabling device %s (%04x -> %04x)\n",
- pci_name(dev), old_cmd, cmd);
- pci_write_config_word(dev, PCI_COMMAND, cmd);
- }
- return 0;
-}
-
struct pci_controller * __init pcibios_alloc_controller(void)
{
struct pci_controller *pci_ctrl;
@@ -238,31 +207,7 @@
int pcibios_enable_device(struct pci_dev *dev, int mask)
{
- u16 cmd, old_cmd;
- int idx;
- struct resource *r;
-
- pci_read_config_word(dev, PCI_COMMAND, &cmd);
- old_cmd = cmd;
- for (idx=0; idx<6; idx++) {
- r = &dev->resource[idx];
- if (!r->start && r->end) {
- printk(KERN_ERR "PCI: Device %s not available because "
- "of resource collisions\n", pci_name(dev));
- return -EINVAL;
- }
- if (r->flags & IORESOURCE_IO)
- cmd |= PCI_COMMAND_IO;
- if (r->flags & IORESOURCE_MEM)
- cmd |= PCI_COMMAND_MEMORY;
- }
- if (cmd != old_cmd) {
- printk("PCI: Enabling device %s (%04x -> %04x)\n",
- pci_name(dev), old_cmd, cmd);
- pci_write_config_word(dev, PCI_COMMAND, cmd);
- }
-
- return 0;
+ return pci_enable_resources(dev, mask);
}
#ifdef CONFIG_PROC_FS
--
^ permalink raw reply
* [patch 14/16] v850: use generic pci_enable_resources()
From: Bjorn Helgaas @ 2008-03-04 18:57 UTC (permalink / raw)
To: linux-pci, linux-arch
Cc: Chris Zankel, Grant Grundler, linux-parisc, Matthew Wilcox,
Kyle McMartin, linuxppc-dev, Paul Mackerras, linux-arm-kernel,
Russell King
In-Reply-To: <20080304185646.864917286@ldl.fc.hp.com>
Use the generic pci_enable_resources() instead of the arch-specific code.
Unlike this arch-specific code, the generic version:
- checks PCI_NUM_RESOURCES (11), not 6, resources
- skips resources that have neither IORESOURCE_IO nor IORESOURCE_MEM set
- skips ROM resources unless IORESOURCE_ROM_ENABLE is set
- checks for resource collisions with "!r->parent"
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Index: work8/arch/v850/kernel/rte_mb_a_pci.c
===================================================================
--- work8.orig/arch/v850/kernel/rte_mb_a_pci.c 2008-03-04 10:12:04.000000000 -0700
+++ work8/arch/v850/kernel/rte_mb_a_pci.c 2008-03-04 10:12:26.000000000 -0700
@@ -219,30 +219,7 @@
\f
int __nomods_init pcibios_enable_device (struct pci_dev *dev, int mask)
{
- u16 cmd, old_cmd;
- int idx;
- struct resource *r;
-
- pci_read_config_word(dev, PCI_COMMAND, &cmd);
- old_cmd = cmd;
- for (idx = 0; idx < 6; idx++) {
- r = &dev->resource[idx];
- if (!r->start && r->end) {
- printk(KERN_ERR "PCI: Device %s not available because "
- "of resource collisions\n", pci_name(dev));
- return -EINVAL;
- }
- if (r->flags & IORESOURCE_IO)
- cmd |= PCI_COMMAND_IO;
- if (r->flags & IORESOURCE_MEM)
- cmd |= PCI_COMMAND_MEMORY;
- }
- if (cmd != old_cmd) {
- printk("PCI: Enabling device %s (%04x -> %04x)\n",
- pci_name(dev), old_cmd, cmd);
- pci_write_config_word(dev, PCI_COMMAND, cmd);
- }
- return 0;
+ return pci_enable_resources(dev, mask);
}
\f
--
^ permalink raw reply
* [patch 15/16] x86: use generic pci_enable_resources()
From: Bjorn Helgaas @ 2008-03-04 18:57 UTC (permalink / raw)
To: linux-pci, linux-arch
Cc: Chris Zankel, Grant Grundler, linux-parisc, Matthew Wilcox,
Kyle McMartin, linuxppc-dev, Paul Mackerras, linux-arm-kernel,
Russell King
In-Reply-To: <20080304185646.864917286@ldl.fc.hp.com>
Use the generic pci_enable_resources() instead of the arch-specific code.
Unlike this arch-specific code, the generic version:
- checks for resource collisions with "!r->parent"
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Index: work8/arch/x86/pci/common.c
===================================================================
--- work8.orig/arch/x86/pci/common.c 2008-03-04 10:12:42.000000000 -0700
+++ work8/arch/x86/pci/common.c 2008-03-04 10:12:51.000000000 -0700
@@ -527,7 +527,7 @@
{
int err;
- if ((err = pcibios_enable_resources(dev, mask)) < 0)
+ if ((err = pci_enable_resources(dev, mask)) < 0)
return err;
if (!dev->msi_enabled)
Index: work8/arch/x86/pci/i386.c
===================================================================
--- work8.orig/arch/x86/pci/i386.c 2008-03-04 10:12:56.000000000 -0700
+++ work8/arch/x86/pci/i386.c 2008-03-04 10:13:03.000000000 -0700
@@ -238,44 +238,6 @@
*/
fs_initcall(pcibios_assign_resources);
-int pcibios_enable_resources(struct pci_dev *dev, int mask)
-{
- u16 cmd, old_cmd;
- int idx;
- struct resource *r;
-
- pci_read_config_word(dev, PCI_COMMAND, &cmd);
- old_cmd = cmd;
- for (idx = 0; idx < PCI_NUM_RESOURCES; idx++) {
- /* Only set up the requested stuff */
- if (!(mask & (1 << idx)))
- continue;
-
- r = &dev->resource[idx];
- if (!(r->flags & (IORESOURCE_IO | IORESOURCE_MEM)))
- continue;
- if ((idx == PCI_ROM_RESOURCE) &&
- (!(r->flags & IORESOURCE_ROM_ENABLE)))
- continue;
- if (!r->start && r->end) {
- printk(KERN_ERR "PCI: Device %s not available "
- "because of resource %d collisions\n",
- pci_name(dev), idx);
- return -EINVAL;
- }
- if (r->flags & IORESOURCE_IO)
- cmd |= PCI_COMMAND_IO;
- if (r->flags & IORESOURCE_MEM)
- cmd |= PCI_COMMAND_MEMORY;
- }
- if (cmd != old_cmd) {
- printk("PCI: Enabling device %s (%04x -> %04x)\n",
- pci_name(dev), old_cmd, cmd);
- pci_write_config_word(dev, PCI_COMMAND, cmd);
- }
- return 0;
-}
-
/*
* If we set up a device for bus mastering, we need to check the latency
* timer as certain crappy BIOSes forget to set it properly.
Index: work8/arch/x86/pci/pci.h
===================================================================
--- work8.orig/arch/x86/pci/pci.h 2008-03-04 10:13:08.000000000 -0700
+++ work8/arch/x86/pci/pci.h 2008-03-04 10:13:12.000000000 -0700
@@ -44,7 +44,6 @@
extern unsigned int pcibios_max_latency;
void pcibios_resource_survey(void);
-int pcibios_enable_resources(struct pci_dev *, int);
/* pci-pc.c */
--
^ permalink raw reply
* [patch 13/16] sparc64: use generic pci_enable_resources()
From: Bjorn Helgaas @ 2008-03-04 18:56 UTC (permalink / raw)
To: linux-pci, linux-arch
Cc: Chris Zankel, Grant Grundler, linux-parisc, Matthew Wilcox,
Kyle McMartin, linuxppc-dev, Paul Mackerras, linux-arm-kernel,
Russell King
In-Reply-To: <20080304185646.864917286@ldl.fc.hp.com>
Use the generic pci_enable_resources() instead of the arch-specific code.
Unlike this arch-specific code, the generic version:
- skips resources that have neither IORESOURCE_IO nor IORESOURCE_MEM set
- skips ROM resources unless IORESOURCE_ROM_ENABLE is set
- checks for resource collisions with "!r->parent"
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Index: work8/arch/sparc64/kernel/pci.c
===================================================================
--- work8.orig/arch/sparc64/kernel/pci.c 2008-03-04 10:11:25.000000000 -0700
+++ work8/arch/sparc64/kernel/pci.c 2008-03-04 10:11:45.000000000 -0700
@@ -927,32 +927,7 @@
int pcibios_enable_device(struct pci_dev *dev, int mask)
{
- u16 cmd, oldcmd;
- int i;
-
- pci_read_config_word(dev, PCI_COMMAND, &cmd);
- oldcmd = cmd;
-
- for (i = 0; i < PCI_NUM_RESOURCES; i++) {
- struct resource *res = &dev->resource[i];
-
- /* Only set up the requested stuff */
- if (!(mask & (1<<i)))
- continue;
-
- if (res->flags & IORESOURCE_IO)
- cmd |= PCI_COMMAND_IO;
- if (res->flags & IORESOURCE_MEM)
- cmd |= PCI_COMMAND_MEMORY;
- }
-
- if (cmd != oldcmd) {
- printk(KERN_DEBUG "PCI: Enabling device: (%s), cmd %x\n",
- pci_name(dev), cmd);
- /* Enable the appropriate bits in the PCI command register. */
- pci_write_config_word(dev, PCI_COMMAND, cmd);
- }
- return 0;
+ return pci_enable_resources(dev, mask);
}
void pcibios_resource_to_bus(struct pci_dev *pdev, struct pci_bus_region *region,
--
^ permalink raw reply
* [patch 12/16] sh: use generic pci_enable_resources()
From: Bjorn Helgaas @ 2008-03-04 18:56 UTC (permalink / raw)
To: linux-pci, linux-arch
Cc: Chris Zankel, Grant Grundler, linux-parisc, Matthew Wilcox,
Kyle McMartin, linuxppc-dev, Paul Mackerras, linux-arm-kernel,
Russell King
In-Reply-To: <20080304185646.864917286@ldl.fc.hp.com>
Use the generic pci_enable_resources() instead of the arch-specific code.
Unlike this arch-specific code, the generic version:
- checks PCI_NUM_RESOURCES (11), not 6, resources
- skips resources that have neither IORESOURCE_IO nor IORESOURCE_MEM set
- skips ROM resources unless IORESOURCE_ROM_ENABLE is set
- checks for resource collisions with "!r->parent"
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Index: work8/arch/sh/drivers/pci/pci.c
===================================================================
--- work8.orig/arch/sh/drivers/pci/pci.c 2008-03-04 10:10:44.000000000 -0700
+++ work8/arch/sh/drivers/pci/pci.c 2008-03-04 10:11:04.000000000 -0700
@@ -133,34 +133,7 @@
int pcibios_enable_device(struct pci_dev *dev, int mask)
{
- u16 cmd, old_cmd;
- int idx;
- struct resource *r;
-
- pci_read_config_word(dev, PCI_COMMAND, &cmd);
- old_cmd = cmd;
- for(idx=0; idx<6; idx++) {
- if (!(mask & (1 << idx)))
- continue;
- r = &dev->resource[idx];
- if (!r->start && r->end) {
- printk(KERN_ERR "PCI: Device %s not available because "
- "of resource collisions\n", pci_name(dev));
- return -EINVAL;
- }
- if (r->flags & IORESOURCE_IO)
- cmd |= PCI_COMMAND_IO;
- if (r->flags & IORESOURCE_MEM)
- cmd |= PCI_COMMAND_MEMORY;
- }
- if (dev->resource[PCI_ROM_RESOURCE].start)
- cmd |= PCI_COMMAND_MEMORY;
- if (cmd != old_cmd) {
- printk(KERN_INFO "PCI: Enabling device %s (%04x -> %04x)\n",
- pci_name(dev), old_cmd, cmd);
- pci_write_config_word(dev, PCI_COMMAND, cmd);
- }
- return 0;
+ return pci_enable_resources(dev, mask);
}
/*
--
^ permalink raw reply
* [patch 11/16] ppc: use generic pci_enable_resources()
From: Bjorn Helgaas @ 2008-03-04 18:56 UTC (permalink / raw)
To: linux-pci, linux-arch
Cc: Chris Zankel, Grant Grundler, linux-parisc, Matthew Wilcox,
Kyle McMartin, linuxppc-dev, Paul Mackerras, linux-arm-kernel,
Russell King
In-Reply-To: <20080304185646.864917286@ldl.fc.hp.com>
Use the generic pci_enable_resources() instead of the arch-specific code.
Unlike this arch-specific code, the generic version:
- checks PCI_NUM_RESOURCES (11), not 6, resources
- skips resources that have neither IORESOURCE_IO nor IORESOURCE_MEM set
- skips ROM resources unless IORESOURCE_ROM_ENABLE is set
- checks for resource collisions with "!r->parent", not IORESOURCE_UNSET
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Index: work8/arch/ppc/kernel/pci.c
===================================================================
--- work8.orig/arch/ppc/kernel/pci.c 2008-03-04 10:09:13.000000000 -0700
+++ work8/arch/ppc/kernel/pci.c 2008-03-04 10:10:18.000000000 -0700
@@ -578,39 +578,6 @@
}
-int
-pcibios_enable_resources(struct pci_dev *dev, int mask)
-{
- u16 cmd, old_cmd;
- int idx;
- struct resource *r;
-
- pci_read_config_word(dev, PCI_COMMAND, &cmd);
- old_cmd = cmd;
- for (idx=0; idx<6; idx++) {
- /* Only set up the requested stuff */
- if (!(mask & (1<<idx)))
- continue;
-
- r = &dev->resource[idx];
- if (r->flags & IORESOURCE_UNSET) {
- printk(KERN_ERR "PCI: Device %s not available because of resource collisions\n", pci_name(dev));
- return -EINVAL;
- }
- if (r->flags & IORESOURCE_IO)
- cmd |= PCI_COMMAND_IO;
- if (r->flags & IORESOURCE_MEM)
- cmd |= PCI_COMMAND_MEMORY;
- }
- if (dev->resource[PCI_ROM_RESOURCE].start)
- cmd |= PCI_COMMAND_MEMORY;
- if (cmd != old_cmd) {
- printk("PCI: Enabling device %s (%04x -> %04x)\n", pci_name(dev), old_cmd, cmd);
- pci_write_config_word(dev, PCI_COMMAND, cmd);
- }
- return 0;
-}
-
static int next_controller_index;
struct pci_controller * __init
@@ -785,33 +752,11 @@
int pcibios_enable_device(struct pci_dev *dev, int mask)
{
- u16 cmd, old_cmd;
- int idx;
- struct resource *r;
-
if (ppc_md.pcibios_enable_device_hook)
if (ppc_md.pcibios_enable_device_hook(dev, 0))
return -EINVAL;
-
- pci_read_config_word(dev, PCI_COMMAND, &cmd);
- old_cmd = cmd;
- for (idx=0; idx<6; idx++) {
- r = &dev->resource[idx];
- if (r->flags & IORESOURCE_UNSET) {
- printk(KERN_ERR "PCI: Device %s not available because of resource collisions\n", pci_name(dev));
- return -EINVAL;
- }
- if (r->flags & IORESOURCE_IO)
- cmd |= PCI_COMMAND_IO;
- if (r->flags & IORESOURCE_MEM)
- cmd |= PCI_COMMAND_MEMORY;
- }
- if (cmd != old_cmd) {
- printk("PCI: Enabling device %s (%04x -> %04x)\n",
- pci_name(dev), old_cmd, cmd);
- pci_write_config_word(dev, PCI_COMMAND, cmd);
- }
- return 0;
+
+ return pci_enable_resources(dev, mask);
}
struct pci_controller*
--
^ permalink raw reply
* [patch 05/16] frv: use generic pci_enable_resources()
From: Bjorn Helgaas @ 2008-03-04 18:56 UTC (permalink / raw)
To: linux-pci, linux-arch
Cc: Chris Zankel, Grant Grundler, linux-parisc, Matthew Wilcox,
Kyle McMartin, linuxppc-dev, Paul Mackerras, linux-arm-kernel,
Russell King
In-Reply-To: <20080304185646.864917286@ldl.fc.hp.com>
Use the generic pci_enable_resources() instead of the arch-specific code.
Unlike this arch-specific code, the generic version:
- checks PCI_NUM_RESOURCES (11), not 6, resources
- skips resources that have neither IORESOURCE_IO nor IORESOURCE_MEM set
- skips ROM resources unless IORESOURCE_ROM_ENABLE is set
- checks for resource collisions with "!r->parent"
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Index: work8/arch/frv/mb93090-mb00/pci-frv.c
===================================================================
--- work8.orig/arch/frv/mb93090-mb00/pci-frv.c 2008-03-04 10:03:11.000000000 -0700
+++ work8/arch/frv/mb93090-mb00/pci-frv.c 2008-03-04 10:03:25.000000000 -0700
@@ -231,38 +231,6 @@
pcibios_assign_resources();
}
-int pcibios_enable_resources(struct pci_dev *dev, int mask)
-{
- u16 cmd, old_cmd;
- int idx;
- struct resource *r;
-
- pci_read_config_word(dev, PCI_COMMAND, &cmd);
- old_cmd = cmd;
- for(idx=0; idx<6; idx++) {
- /* Only set up the requested stuff */
- if (!(mask & (1<<idx)))
- continue;
-
- r = &dev->resource[idx];
- if (!r->start && r->end) {
- printk(KERN_ERR "PCI: Device %s not available because of resource collisions\n", pci_name(dev));
- return -EINVAL;
- }
- if (r->flags & IORESOURCE_IO)
- cmd |= PCI_COMMAND_IO;
- if (r->flags & IORESOURCE_MEM)
- cmd |= PCI_COMMAND_MEMORY;
- }
- if (dev->resource[PCI_ROM_RESOURCE].start)
- cmd |= PCI_COMMAND_MEMORY;
- if (cmd != old_cmd) {
- printk("PCI: Enabling device %s (%04x -> %04x)\n", pci_name(dev), old_cmd, cmd);
- pci_write_config_word(dev, PCI_COMMAND, cmd);
- }
- return 0;
-}
-
/*
* If we set up a device for bus mastering, we need to check the latency
* timer as certain crappy BIOSes forget to set it properly.
Index: work8/arch/frv/mb93090-mb00/pci-frv.h
===================================================================
--- work8.orig/arch/frv/mb93090-mb00/pci-frv.h 2008-03-04 10:03:29.000000000 -0700
+++ work8/arch/frv/mb93090-mb00/pci-frv.h 2008-03-04 10:03:33.000000000 -0700
@@ -31,7 +31,6 @@
extern unsigned int pcibios_max_latency;
void pcibios_resource_survey(void);
-int pcibios_enable_resources(struct pci_dev *, int);
/* pci-vdk.c */
Index: work8/arch/frv/mb93090-mb00/pci-vdk.c
===================================================================
--- work8.orig/arch/frv/mb93090-mb00/pci-vdk.c 2008-03-04 10:03:37.000000000 -0700
+++ work8/arch/frv/mb93090-mb00/pci-vdk.c 2008-03-04 10:03:45.000000000 -0700
@@ -465,7 +465,7 @@
{
int err;
- if ((err = pcibios_enable_resources(dev, mask)) < 0)
+ if ((err = pci_enable_resources(dev, mask)) < 0)
return err;
if (!dev->msi_enabled)
pcibios_enable_irq(dev);
--
^ permalink raw reply
* [patch 09/16] parisc: use generic pci_enable_resources()
From: Bjorn Helgaas @ 2008-03-04 18:56 UTC (permalink / raw)
To: linux-pci, linux-arch
Cc: Chris Zankel, Grant Grundler, linux-parisc, Matthew Wilcox,
Kyle McMartin, linuxppc-dev, Paul Mackerras, linux-arm-kernel,
Russell King
In-Reply-To: <20080304185646.864917286@ldl.fc.hp.com>
Use the generic pci_enable_resources() instead of the arch-specific code.
Unlike this arch-specific code, the generic version:
- checks PCI_NUM_RESOURCES (11), not DEVICE_COUNT_RESOURCE (12), resources
- skips resources that have neither IORESOURCE_IO nor IORESOURCE_MEM set
- skips ROM resources unless IORESOURCE_ROM_ENABLE is set
- checks for resource collisions with "!r->parent"
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Index: work8/arch/parisc/kernel/pci.c
===================================================================
--- work8.orig/arch/parisc/kernel/pci.c 2008-03-04 10:06:11.000000000 -0700
+++ work8/arch/parisc/kernel/pci.c 2008-03-04 10:07:54.000000000 -0700
@@ -287,23 +287,15 @@
*/
int pcibios_enable_device(struct pci_dev *dev, int mask)
{
- u16 cmd;
- int idx;
+ int err;
+ u16 cmd, old_cmd;
- pci_read_config_word(dev, PCI_COMMAND, &cmd);
-
- for (idx = 0; idx < DEVICE_COUNT_RESOURCE; idx++) {
- struct resource *r = &dev->resource[idx];
+ err = pci_enable_resources(dev, mask);
+ if (err < 0)
+ return err;
- /* only setup requested resources */
- if (!(mask & (1<<idx)))
- continue;
-
- if (r->flags & IORESOURCE_IO)
- cmd |= PCI_COMMAND_IO;
- if (r->flags & IORESOURCE_MEM)
- cmd |= PCI_COMMAND_MEMORY;
- }
+ pci_read_config_word(dev, PCI_COMMAND, &cmd);
+ old_cmd = cmd;
cmd |= (PCI_COMMAND_SERR | PCI_COMMAND_PARITY);
@@ -312,8 +304,12 @@
if (dev->bus->bridge_ctl & PCI_BRIDGE_CTL_FAST_BACK)
cmd |= PCI_COMMAND_FAST_BACK;
#endif
- DBGC("PCIBIOS: Enabling device %s cmd 0x%04x\n", pci_name(dev), cmd);
- pci_write_config_word(dev, PCI_COMMAND, cmd);
+
+ if (cmd != old_cmd) {
+ dev_info(&dev->dev, "enabling SERR and PARITY (%04x -> %04x)\n",
+ old_cmd, cmd);
+ pci_write_config_word(dev, PCI_COMMAND, cmd);
+ }
return 0;
}
--
^ permalink raw reply
* [patch 10/16] powerpc: use generic pci_enable_resources()
From: Bjorn Helgaas @ 2008-03-04 18:56 UTC (permalink / raw)
To: linux-pci, linux-arch
Cc: Chris Zankel, Grant Grundler, linux-parisc, Matthew Wilcox,
Kyle McMartin, linuxppc-dev, Paul Mackerras, linux-arm-kernel,
Russell King
In-Reply-To: <20080304185646.864917286@ldl.fc.hp.com>
Use the generic pci_enable_resources() instead of the arch-specific code.
The generic version is functionally equivalent, but uses dev_printk.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Index: work8/arch/powerpc/kernel/pci-common.c
===================================================================
--- work8.orig/arch/powerpc/kernel/pci-common.c 2008-03-04 10:08:18.000000000 -0700
+++ work8/arch/powerpc/kernel/pci-common.c 2008-03-04 10:08:54.000000000 -0700
@@ -1155,41 +1155,9 @@
int pcibios_enable_device(struct pci_dev *dev, int mask)
{
- u16 cmd, old_cmd;
- int idx;
- struct resource *r;
-
if (ppc_md.pcibios_enable_device_hook)
if (ppc_md.pcibios_enable_device_hook(dev))
return -EINVAL;
- pci_read_config_word(dev, PCI_COMMAND, &cmd);
- old_cmd = cmd;
- for (idx = 0; idx < PCI_NUM_RESOURCES; idx++) {
- /* Only set up the requested stuff */
- if (!(mask & (1 << idx)))
- continue;
- r = &dev->resource[idx];
- if (!(r->flags & (IORESOURCE_IO | IORESOURCE_MEM)))
- continue;
- if ((idx == PCI_ROM_RESOURCE) &&
- (!(r->flags & IORESOURCE_ROM_ENABLE)))
- continue;
- if (r->parent == NULL) {
- printk(KERN_ERR "PCI: Device %s not available because"
- " of resource collisions\n", pci_name(dev));
- return -EINVAL;
- }
- if (r->flags & IORESOURCE_IO)
- cmd |= PCI_COMMAND_IO;
- if (r->flags & IORESOURCE_MEM)
- cmd |= PCI_COMMAND_MEMORY;
- }
- if (cmd != old_cmd) {
- printk("PCI: Enabling device %s (%04x -> %04x)\n",
- pci_name(dev), old_cmd, cmd);
- pci_write_config_word(dev, PCI_COMMAND, cmd);
- }
- return 0;
+ return pci_enable_resources(dev, mask);
}
-
--
^ permalink raw reply
* [patch 07/16] mips: use generic pci_enable_resources()
From: Bjorn Helgaas @ 2008-03-04 18:56 UTC (permalink / raw)
To: linux-pci, linux-arch
Cc: Chris Zankel, Grant Grundler, linux-parisc, Matthew Wilcox,
Kyle McMartin, linuxppc-dev, Paul Mackerras, linux-arm-kernel,
Russell King
In-Reply-To: <20080304185646.864917286@ldl.fc.hp.com>
Use the generic pci_enable_resources() instead of the arch-specific code.
Unlike this arch-specific code, the generic version:
- checks for resource collisions with "!r->parent"
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Index: work8/arch/mips/pci/pci.c
===================================================================
--- work8.orig/arch/mips/pci/pci.c 2008-03-04 10:04:51.000000000 -0700
+++ work8/arch/mips/pci/pci.c 2008-03-04 10:05:08.000000000 -0700
@@ -163,44 +163,6 @@
subsys_initcall(pcibios_init);
-static int pcibios_enable_resources(struct pci_dev *dev, int mask)
-{
- u16 cmd, old_cmd;
- int idx;
- struct resource *r;
-
- pci_read_config_word(dev, PCI_COMMAND, &cmd);
- old_cmd = cmd;
- for (idx=0; idx < PCI_NUM_RESOURCES; idx++) {
- /* Only set up the requested stuff */
- if (!(mask & (1<<idx)))
- continue;
-
- r = &dev->resource[idx];
- if (!(r->flags & (IORESOURCE_IO | IORESOURCE_MEM)))
- continue;
- if ((idx == PCI_ROM_RESOURCE) &&
- (!(r->flags & IORESOURCE_ROM_ENABLE)))
- continue;
- if (!r->start && r->end) {
- printk(KERN_ERR "PCI: Device %s not available "
- "because of resource collisions\n",
- pci_name(dev));
- return -EINVAL;
- }
- if (r->flags & IORESOURCE_IO)
- cmd |= PCI_COMMAND_IO;
- if (r->flags & IORESOURCE_MEM)
- cmd |= PCI_COMMAND_MEMORY;
- }
- if (cmd != old_cmd) {
- printk("PCI: Enabling device %s (%04x -> %04x)\n",
- pci_name(dev), old_cmd, cmd);
- pci_write_config_word(dev, PCI_COMMAND, cmd);
- }
- return 0;
-}
-
/*
* If we set up a device for bus mastering, we need to check the latency
* timer as certain crappy BIOSes forget to set it properly.
@@ -231,7 +193,7 @@
{
int err;
- if ((err = pcibios_enable_resources(dev, mask)) < 0)
+ if ((err = pci_enable_resources(dev, mask)) < 0)
return err;
return pcibios_plat_dev_init(dev);
--
^ permalink raw reply
* [patch 08/16] mn10300: use generic pci_enable_resources()
From: Bjorn Helgaas @ 2008-03-04 18:56 UTC (permalink / raw)
To: linux-pci, linux-arch
Cc: Chris Zankel, Grant Grundler, linux-parisc, Matthew Wilcox,
Kyle McMartin, linuxppc-dev, Paul Mackerras, linux-arm-kernel,
Russell King
In-Reply-To: <20080304185646.864917286@ldl.fc.hp.com>
Use the generic pci_enable_resources() instead of the arch-specific code.
Unlike this arch-specific code, the generic version:
- checks PCI_NUM_RESOURCES (11), not 6, resources
- skips resources that have neither IORESOURCE_IO nor IORESOURCE_MEM set
- skips ROM resources unless IORESOURCE_ROM_ENABLE is set
- checks for resource collisions with "!r->parent"
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Index: work8/arch/mn10300/unit-asb2305/pci-asb2305.c
===================================================================
--- work8.orig/arch/mn10300/unit-asb2305/pci-asb2305.c 2008-03-04 10:05:27.000000000 -0700
+++ work8/arch/mn10300/unit-asb2305/pci-asb2305.c 2008-03-04 10:05:36.000000000 -0700
@@ -218,45 +218,6 @@
pcibios_allocate_resources(1);
}
-int pcibios_enable_resources(struct pci_dev *dev, int mask)
-{
- u16 cmd, old_cmd;
- int idx;
- struct resource *r;
-
- pci_read_config_word(dev, PCI_COMMAND, &cmd);
- old_cmd = cmd;
-
- for (idx = 0; idx < 6; idx++) {
- /* Only set up the requested stuff */
- if (!(mask & (1 << idx)))
- continue;
-
- r = &dev->resource[idx];
-
- if (!r->start && r->end) {
- printk(KERN_ERR
- "PCI: Device %s not available because of"
- " resource collisions\n",
- pci_name(dev));
- return -EINVAL;
- }
-
- if (r->flags & IORESOURCE_IO)
- cmd |= PCI_COMMAND_IO;
- if (r->flags & IORESOURCE_MEM)
- cmd |= PCI_COMMAND_MEMORY;
- }
-
- if (dev->resource[PCI_ROM_RESOURCE].start)
- cmd |= PCI_COMMAND_MEMORY;
-
- if (cmd != old_cmd)
- pci_write_config_word(dev, PCI_COMMAND, cmd);
-
- return 0;
-}
-
/*
* If we set up a device for bus mastering, we need to check the latency
* timer as certain crappy BIOSes forget to set it properly.
Index: work8/arch/mn10300/unit-asb2305/pci-asb2305.h
===================================================================
--- work8.orig/arch/mn10300/unit-asb2305/pci-asb2305.h 2008-03-04 10:05:41.000000000 -0700
+++ work8/arch/mn10300/unit-asb2305/pci-asb2305.h 2008-03-04 10:05:45.000000000 -0700
@@ -36,7 +36,6 @@
extern unsigned int pcibios_max_latency;
extern void pcibios_resource_survey(void);
-extern int pcibios_enable_resources(struct pci_dev *dev, int mask);
/* pci.c */
Index: work8/arch/mn10300/unit-asb2305/pci.c
===================================================================
--- work8.orig/arch/mn10300/unit-asb2305/pci.c 2008-03-04 10:05:49.000000000 -0700
+++ work8/arch/mn10300/unit-asb2305/pci.c 2008-03-04 10:05:54.000000000 -0700
@@ -440,7 +440,7 @@
{
int err;
- err = pcibios_enable_resources(dev, mask);
+ err = pci_enable_resources(dev, mask);
if (err == 0)
pcibios_enable_irq(dev);
return err;
--
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox