Date: Tue, 17 Feb 1998 00:42:48 +0100 From: Tor Egge <Tor.Egge@idi.ntnu.no> To: mike@smith.net.au Cc: toor@dyson.iquest.net, hackers@FreeBSD.ORG Subject: Re: VM messed: vm_page_free panic problem Message-ID: <199802162342.AAA16968@pat.idi.ntnu.no> In-Reply-To: Your message of "Mon, 16 Feb 1998 13:27:37 -0800" References: <199802162127.NAA07811@dingo.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> In the case in question, this is to be expected. The MFS is supposed > to be in the kernel image, but because the 4MB page covering the kernel > is not correctly set up an early MFS operation causes a fatal fault. > > Your fix is probably correct in the general case, but it's not relevant > here. It is relevant. I probably gave too little information in my previous mail. The kernel backtrace shown was for a slightly modified (DDB was added) 3.0-SNAP install kernel. The program to be started was "/stand/sysinstall". Without a mfs_getpages, I got the crash. With a mfs_getpages, the kernel booted fine, and I got the normal sysinstall menu. I did not regenerate the MFS image, thus exactly the same MFS image was used in both cases. DISABLE_PSE was not specified in the kernel config file for any of these (modified) 3.0-SNAP install kernels. It should not be needed to use this option at all. The main difference between running 3.0-CURRENT from hard disk and and installing a 3.0-SNAP from a floppy is how the MFS file system is used. Reading/writing files does not cause a VOP_GETPAGES() call, but a VOP_STRATEGY() call, which is supported by MFS. The actual layout of files on the MFS image in the kernel would very much affect whether this bug was to be triggered or not. The MFS image I've tested has a blocksize/fragment size of 4K/512 bytes. A short fsdb session (using a slightly modified fsdb) shows the following: ikke:/export/akg6/chroot/CURRENT/usr/obj/usr/src/release$ fsdb -r ./fs-image.std ./fs-image.std is not a character device CONTINUE? yes ** ./fs-image.std (NO WRITE) Examining file system `./fs-image.std' Last Mounted on /tmp/mnt_xx inode 2 is at fsblk 56 (dblk 56, inum 0..32) current inode: directory I=2 MODE=40755 SIZE=512 MTIME=Feb 16 20:00:31 1998 [0 nsec] CTIME=Feb 16 20:00:31 1998 [0 nsec] ATIME=Feb 16 20:00:30 1998 [0 nsec] OWNER=root GRP=wheel LINKCNT=6 FLAGS=0 BLKCNT=1 GEN=56788a10 direct blocks:120,0,0,0,0,0,0,0,0,0,0,0 indirect blocks:0,0,0 fsdb (inum: 2)> cd stand component `stand': inode 161 is at fsblk 96 (dblk 96, inum 160..192) current inode: directory I=161 MODE=40755 SIZE=512 MTIME=Feb 16 20:01:46 1998 [0 nsec] CTIME=Feb 16 20:01:46 1998 [0 nsec] ATIME=Feb 16 20:00:26 1998 [0 nsec] OWNER=root GRP=wheel LINKCNT=4 FLAGS=0 BLKCNT=1 GEN=43bbe041 direct blocks:121,0,0,0,0,0,0,0,0,0,0,0 indirect blocks:0,0,0 fsdb (inum: 161)> ls slot 0 ino 161 reclen 12: directory, `.' slot 1 ino 2 reclen 12: directory, `..' slot 2 ino 162 reclen 16: directory, `help' slot 3 ino 186 reclen 20: regular, `boot.help' slot 4 ino 187 reclen 20: regular, `boot_crunch' slot 5 ino 187 reclen 12: regular, `sh' slot 6 ino 187 reclen 16: regular, `find' slot 7 ino 187 reclen 12: regular, `pwd' slot 8 ino 187 reclen 12: regular, `ft' slot 9 ino 187 reclen 12: regular, `ppp' slot 10 ino 187 reclen 20: regular, `sysinstall' slot 11 ino 187 reclen 16: regular, `newfs' slot 12 ino 187 reclen 16: regular, `gzip' slot 13 ino 187 reclen 16: regular, `cpio' slot 14 ino 187 reclen 16: regular, `bad144' slot 15 ino 187 reclen 16: regular, `fsck' slot 16 ino 187 reclen 20: regular, `ifconfig' slot 17 ino 187 reclen 16: regular, `route' slot 18 ino 187 reclen 20: regular, `slattach' slot 19 ino 187 reclen 20: regular, `mount_nfs' slot 20 ino 187 reclen 16: regular, `gunzip' slot 21 ino 187 reclen 16: regular, `zcat' slot 22 ino 187 reclen 12: regular, `-sh' slot 23 ino 188 reclen 12: directory, `etc' slot 24 ino 192 reclen 136: regular, `symbols' fsdb (inum: 161)> inode 187 current inode: regular file I=187 MODE=100555 SIZE=1175552 MTIME=Feb 16 03:27:10 1998 [0 nsec] CTIME=Feb 16 20:00:31 1998 [0 nsec] ATIME=Feb 16 03:27:10 1998 [0 nsec] OWNER=root GRP=bin LINKCNT=19 FLAGS=0 BLKCNT=900 GEN=70972d4f direct blocks:272,280,288,296,304,312,320,328,336,344,352,360 indirect blocks:368,0,0 fsdb (inum: 187)> The first 12 pages in "/stand/sysinstall" are available via the direct blocks. The first indirect block (that describes where the rest of the file is located) is located after the first 12 pages, thus only the first 12 pages of the file are located sequentially, and ffs_getpages frees the last 4 pages (pindex 12 to pindex 15) passed to it before trying to call VOP_GETPAGES on the mfs vnode. This also explains why the reports has 12 as the page index right before the panic: vm_page_free: pindex(12), busy(0), PG_BUSY(0), hold(0) ^^ > Just for general reference though, with DISABLE_PSE in GENERIC the > -current install disk image works again. With a mfs_getpages, the -current install images should work again, regardless of DISABLE_PSE being used as an option or not. With VM_INITIAL_PAGEIN defined to 12 (instead of 16), the -current install image would probably work again, although that is not the correct fix. It is not obvious to me how using the DISABLE_PSE option fixes this problem. The problem probably started occuring with revision 1.76 of kern_exec.c, dated `1998/02/05 03:32:04', which changed the pagein behavior when starting new processes. - Tor Egge To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802162342.AAA16968>