Date: Sun, 6 Sep 2009 08:44:54 -0700 From: David Wolfskill <david@catwhisker.org> To: stable@freebsd.org Subject: panic: vm_phys_paddr_to_vm_page: paddr 0xf8000 is not in any segment Message-ID: <20090906154454.GN23018@albert.catwhisker.org>
next in thread | raw e-mail | index | archive | help
--KCXyoJ//PRyfzsc9 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable First got this on my laptop (but not my headless build machine) -- each of which is i386 -- yesterday, at r196858; after reverting to r196827 (from Thursday), then rebuilding stable/7 at r196886, it recurred. It appears to be happening when xdm(1) gets started., which is pretty late in the transition to multi-user mode. One oddity of which to be aware: all ports (save for misc/compat6x) are built and installed while running stable/6. (I track stable/6, stable/7, and head, as well as track ports, daily, on both the build machine and the laptop. As I try to have some time to actually use the laptop, rather than merely building stuff on it, I don't try to update the ports collection daily for each of the 3 versions of the OS I run. And as the laptop is "user-facing," it tends to have a lot (863, at last count) of ports installed.) misc/compat6x was installed and is updated under stable/7; it is presently at compat6x-i386-6.4.604000.200810_3 -- updated Sep 4 06:03:18 2009. For the past couple of weeks (until yesterday), I noticed that during the attempt to start xdm(1), the laptop (when running stable/7) would sometimes lock up (i.e., keyboard apparently non-functional;; mouse non-functional; only thing I could find to make any progress was a power cycle, then booting single-user & issuing "fsck -p && exit"). Since I wasn't able to get any information, I didn't mention it here previously, but now aat least I have an apparently consistennt panic -- but only when running stable/7. I have no problems runnning xdm(1) under stable/6 (not that that's a surprise), but I also have no problems runing xdm(1) under head. I've copied the crashinfo(8) information to a file visible to my Web server; it may be viewed at <http://www.catwhisker.org/~david/FreeBSD/core.txt.6>. I'll paste the uname info & backtrace here, but for more details, please see that page. (Of course, if the details you seek aren't in the crashinfo(8) output, please just let me know what you seek....) FreeBSD localhost 7.2-STABLE FreeBSD 7.2-STABLE #935 r196886: Sun Sep 6 05= :35:04 PDT 2009 root@g1-69.catwhisker.org:/common/S3/obj/usr/src/sys/CA= NARY i386 #0 doadump () at pcpu.h:196 196 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:196 #1 0xc049a979 in db_fncall (dummy1=3D1, dummy2=3D0, dummy3=3D-1060239008,= =20 dummy4=3D0xc3b6986c "\200@=E2=C3") at /usr/src/sys/ddb/db_command.c:516 #2 0xc049aefc in db_command (last_cmdp=3D0xc0c95694, cmd_table=3D0x0, dopa= ger=3D1) at /usr/src/sys/ddb/db_command.c:413 #3 0xc049b00a in db_command_loop () at /usr/src/sys/ddb/db_command.c:466 #4 0xc049cabd in db_trap (type=3D3, code=3D0) at /usr/src/sys/ddb/db_main.= c:228 #5 0xc0812406 in kdb_trap (type=3D3, code=3D0, tf=3D0xc3b69a14) at /usr/src/sys/kern/subr_kdb.c:524 #6 0xc0af205b in trap (frame=3D0xc3b69a14) at /usr/src/sys/i386/i386/trap.= c:692 #7 0xc0ad5d4b in calltrap () at /usr/src/sys/i386/i386/exception.s:166 #8 0xc081258a in kdb_enter_why (why=3D0xc0b93e11 "panic",=20 msg=3D0xc0b93e11 "panic") at cpufunc.h:60 #9 0xc07e55b6 in panic ( fmt=3D0xc0bb024d "vm_phys_paddr_to_vm_page: paddr %#jx is not in any se= gment") at /usr/src/sys/kern/kern_shutdown.c:557 #10 0xc0a504bd in vm_phys_paddr_to_vm_page (pa=3D1015808) at /usr/src/sys/vm/vm_phys.c:385 #11 0xc0a2ec21 in dev_pager_getpages (object=3D0xc4d29000, m=3D0xc3b69c04,= =20 count=3D1, reqpage=3D0) at /usr/src/sys/vm/device_pager.c:240 #12 0xc0a3ae90 in vm_fault (map=3D0xc4d0d000, vaddr=3D676900864,=20 fault_type=3D1 '\001', fault_flags=3DVariable "fault_flags" is not avai= lable. ) at vm_pager.h:130 #13 0xc0af13bb in trap_pfault (frame=3D0xc3b69d38, usermode=3D1, eva=3D6769= 04576) at /usr/src/sys/i386/i386/trap.c:833 #14 0xc0af1d27 in trap (frame=3D0xc3b69d38) at /usr/src/sys/i386/i386/trap.= c:399 #15 0xc0ad5d4b in calltrap () at /usr/src/sys/i386/i386/exception.s:166 #16 0x285599c1 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb)=20 Given that last ("Previous frame inner to this frame (corrupt stack?)"), I'm not at all certain that the backtraace (or the dump) will be all that useful. And because of my odd configuration, this may not be of sufficient interest to merit much expenditure of anyone else's time. I'm quite willing to experiment, try patches, or whatnot. I have local mirrors of the CVVS & SVN repositories handy. I'm not much of a kernel hacker per se, but I am fairly comfortable hacking sources in general. I welcome clues. Thanks. Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --KCXyoJ//PRyfzsc9 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkqj2PUACgkQmprOCmdXAD3SVACeNQr/0ryxOk5IPeMy/rvyrCl6 tCQAniDxz45Hn0PfnJfBC+2Qh+h4Qbsc =/nHQ -----END PGP SIGNATURE----- --KCXyoJ//PRyfzsc9--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090906154454.GN23018>