Messages in this thread | | | Date | Fri, 30 Apr 2004 14:41:19 -0700 | From | Andrew Morton <> | Subject | Re: Problem with recent changes to fs/dcache.c |
| |
"Art Haas" <ahaas@airmail.net> wrote: > > I'm still trying to debug this, so I've cloned a 2.6.5 tree and added > some printk() bits to see what it reported. Here's the top of the > 'dmesg' output. Notice the 'num_phspages' is 45829, so the value I was > getting in the 2.6.6-rc3 bootup of 46073 is very similar, which suggests > that the problem _might_ be with the nr_free_pages() call - which leads > down in the the mmzone code. Here's the dmesg output: > > ....... > Boot time fixup v1.6. 4/Mar/98 Jakub Jelinek (jj@ultra.linux.cz). > Patching kerne l for srmmu[TI Viking/MXCC]/iommu > 319MB HIGHMEM available. > On node 0 totalpages: 130409 > DMA zone: 48666 pages, LIFO batch:11 > Normal zone: 0 pages, LIFO batch:1 > HighMem zone: 81743 pages, LIFO batch:16
130409 pages.
> Power off control detected. > Built 1 zonelists > Kernel command line: root=/dev/sda1 > PID hash table entries: 2048 (order 11: 16384 bytes) > Console: colour dummy device 80x25 > calling mem_init() > Memory: 509676k available (1352k kernel code, 312k data, 116k init, > 326972k high mem) [f0000000,1ff4f000] > num_physpages: 45829
That's wrong.
I do think that num_physpages is ripe for removal - we have a number of ways of calculating much the same thing in generic code, and probably all users could be changed to use something else anyway.
But short-term we're stuck with it, and there's a bug somewhere in arch/sparc/'s calculation of this number.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |