On Wed, 14 Mar 2007, Bjorn Helgaas wrote:
On Wednesday 14 March 2007 12:59, Mel Gorman wrote:
Virtual mem_map starts at 0xa0007fffc720
Zone PFN ranges:
Total aside, a message should have been printed out here with
"sizeof(struct page) = ??" when loglevel was set to 8. I wanted it so I
On Wednesday 14 March 2007 12:59, Mel Gorman wrote:
> >
> > Virtual mem_map starts at 0xa0007fffc720
> > Zone PFN ranges:
>
> Total aside, a message should have been printed out here with
> "sizeof(struct page) = ??" when loglevel was set to 8. I wanted it so I
> could work out PFNs from
On Wed, 14 Mar 2007, Bjorn Helgaas wrote:
On Wednesday 14 March 2007 11:21, Mel Gorman wrote:
Can you tell me if the faulting line was at the check for PageBuddy?
I don't know, sorry.
No problem, the fact the patch booted lets me know that calling
PageBuddy() on an invalid page had the
On Wednesday 14 March 2007 11:21, Mel Gorman wrote:
> Can you tell me if the faulting line was at the check for PageBuddy?
I don't know, sorry.
> Can you
> also apply the following patch and boot with loglevel=8 please? The
> patch moves the check for pfn_valid() before PageBuddy() is called.
On (14/03/07 10:52), Bjorn Helgaas didst pronounce:
> On Wednesday 14 March 2007 10:13, Mel Gorman wrote:
> > Ok. This looks like another case of HOLES_IN_ZONE hilarity with page_zone().
> > As I take a new look at the BUG_ON check in move_freepages(), it isn't even
> > necessary as
On Wednesday 14 March 2007 10:13, Mel Gorman wrote:
> Ok. This looks like another case of HOLES_IN_ZONE hilarity with page_zone().
> As I take a new look at the BUG_ON check in move_freepages(), it isn't even
> necessary as move_freepages_block() already checks the zone boundaries. At a
> later
On (14/03/07 09:11), Bjorn Helgaas didst pronounce:
> On Wednesday 14 March 2007 03:44, Mel Gorman wrote:
> > Please try the following patch from Yasunori Goto.
> > ...
> > --- current_test.orig/mm/page_alloc.c 2007-03-08 15:44:10.0
> > +0900
> > +++ current_test/mm/page_alloc.c
On Wednesday 14 March 2007 03:44, Mel Gorman wrote:
> Please try the following patch from Yasunori Goto.
> ...
> --- current_test.orig/mm/page_alloc.c 2007-03-08 15:44:10.0 +0900
> +++ current_test/mm/page_alloc.c 2007-03-08 16:17:29.0 +0900
> @@ -707,7 +707,7 @@ int
On (13/03/07 21:52), Bjorn Helgaas didst pronounce:
> FYI, I'm seeing the following oops with 2.6.21-rc3-mm1 (and -mm2)
> on the HP rx2600 and an Intel Tiger (both ia64 boxes).
>
> I haven't investigated this other than to determine that it
> does not occur with 2.6.21-rc3 or 2.6.20-rc3-mm1, and
On (13/03/07 21:52), Bjorn Helgaas didst pronounce:
FYI, I'm seeing the following oops with 2.6.21-rc3-mm1 (and -mm2)
on the HP rx2600 and an Intel Tiger (both ia64 boxes).
I haven't investigated this other than to determine that it
does not occur with 2.6.21-rc3 or 2.6.20-rc3-mm1, and the
On Wednesday 14 March 2007 03:44, Mel Gorman wrote:
Please try the following patch from Yasunori Goto.
...
--- current_test.orig/mm/page_alloc.c 2007-03-08 15:44:10.0 +0900
+++ current_test/mm/page_alloc.c 2007-03-08 16:17:29.0 +0900
@@ -707,7 +707,7 @@ int
On (14/03/07 09:11), Bjorn Helgaas didst pronounce:
On Wednesday 14 March 2007 03:44, Mel Gorman wrote:
Please try the following patch from Yasunori Goto.
...
--- current_test.orig/mm/page_alloc.c 2007-03-08 15:44:10.0
+0900
+++ current_test/mm/page_alloc.c2007-03-08
On Wednesday 14 March 2007 10:13, Mel Gorman wrote:
Ok. This looks like another case of HOLES_IN_ZONE hilarity with page_zone().
As I take a new look at the BUG_ON check in move_freepages(), it isn't even
necessary as move_freepages_block() already checks the zone boundaries. At a
later date
On (14/03/07 10:52), Bjorn Helgaas didst pronounce:
On Wednesday 14 March 2007 10:13, Mel Gorman wrote:
Ok. This looks like another case of HOLES_IN_ZONE hilarity with page_zone().
As I take a new look at the BUG_ON check in move_freepages(), it isn't even
necessary as
On Wednesday 14 March 2007 11:21, Mel Gorman wrote:
Can you tell me if the faulting line was at the check for PageBuddy?
I don't know, sorry.
Can you
also apply the following patch and boot with loglevel=8 please? The
patch moves the check for pfn_valid() before PageBuddy() is called.
On Wed, 14 Mar 2007, Bjorn Helgaas wrote:
On Wednesday 14 March 2007 11:21, Mel Gorman wrote:
Can you tell me if the faulting line was at the check for PageBuddy?
I don't know, sorry.
No problem, the fact the patch booted lets me know that calling
PageBuddy() on an invalid page had the
On Wednesday 14 March 2007 12:59, Mel Gorman wrote:
SNIP
Virtual mem_map starts at 0xa0007fffc720
Zone PFN ranges:
Total aside, a message should have been printed out here with
sizeof(struct page) = ?? when loglevel was set to 8. I wanted it so I
could work out PFNs from the
On Wed, 14 Mar 2007, Bjorn Helgaas wrote:
On Wednesday 14 March 2007 12:59, Mel Gorman wrote:
SNIP
Virtual mem_map starts at 0xa0007fffc720
Zone PFN ranges:
Total aside, a message should have been printed out here with
sizeof(struct page) = ?? when loglevel was set to 8. I wanted it so I
FYI, I'm seeing the following oops with 2.6.21-rc3-mm1 (and -mm2)
on the HP rx2600 and an Intel Tiger (both ia64 boxes).
I haven't investigated this other than to determine that it
does not occur with 2.6.21-rc3 or 2.6.20-rc3-mm1, and the
instruction at move_freepages+0x10 is a load of the value
FYI, I'm seeing the following oops with 2.6.21-rc3-mm1 (and -mm2)
on the HP rx2600 and an Intel Tiger (both ia64 boxes).
I haven't investigated this other than to determine that it
does not occur with 2.6.21-rc3 or 2.6.20-rc3-mm1, and the
instruction at move_freepages+0x10 is a load of the value
20 matches
Mail list logo
