Messages in this thread | | | Date | Thu, 29 Apr 2004 20:39:01 -0700 | From | Andrew Morton <> | Subject | Re: Problem with recent changes to fs/dcache.c |
| |
"Art Haas" <ahaas@airmail.net> wrote: > > I run linux on a SparcStation SS20 in addition to a PC, and found that > none of the 2.6.6-rc kernels would boot. After trying the latest -rc3 > kernel and seeing it fail also, my debugging quest began. Adding a few > printk() statements pointed the problem to be in fs/dcache.c in the > vfs_caches_init() function. The 1.69->1.70 changes to this file added in > a call to nr_free_pages() and used that result to adjust the global > mempages variable. This change caused the boot failures. > > The printk() statements I'd added showed that vfs_caches_init() was > being called with 'mempages' set to 46073. The nr_free_pages() call > returned 127661, and this value being subtracted from mempages went > negative, but the value is unsigned, so mempages became enormous. Things > ended up getting stuck in the inode_init() call down a bit, having > seeming survived the dcache_init() call only because of values > wrapping around. > > I commented out the 'mempages -= reserve;' line in the file, and the > boot continued along. Unfortunately I encounter a kernel trap when > mounting the hard drives, so there are other problems still needing to > be looked at. > > The possiblity of nr_free_pages() being larger than mempages looks like > a silent bug that was tripped. If not, then another bug in the Sparc > port may be responsible for values being used in these functions. The > memory-management gurus can take a peek and see what they find.
Yes, something's bust in the sparc port's calculation of num_physpages. Clearly it should be larger than nr_free_pages(). - 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/
| |