Messages in this thread | | | From | "Art Haas" <> | Date | Thu, 29 Apr 2004 21:05:25 -0500 | Subject | Problem with recent changes to fs/dcache.c |
| |
Hi.
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.
Art Haas -- Man once surrendering his reason, has no remaining guard against absurdities the most monstrous, and like a ship without rudder, is the sport of every wind.
-Thomas Jefferson to James Smith, 1822 - 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/
| |