From owner-freebsd-current Sun Aug 13 23:23:34 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id XAA01682 for current-outgoing; Sun, 13 Aug 1995 23:23:34 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.FreeBSD.org (8.6.11/8.6.6) with SMTP id XAA01581 for ; Sun, 13 Aug 1995 23:22:22 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA18239; Mon, 14 Aug 1995 08:22:12 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id IAA08161; Mon, 14 Aug 1995 08:20:51 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id IAA11398; Mon, 14 Aug 1995 08:11:26 +0200 From: J Wunsch Message-Id: <199508140611.IAA11398@uriah.heep.sax.de> Subject: Re: procfs problems in -current? To: fn@pain.csrv.uidaho.edu (faried nawaz) Date: Mon, 14 Aug 1995 08:11:25 +0200 (MET DST) Cc: current@freebsd.org In-Reply-To: <199508130211.TAA00198@big-brother.csrv.uidaho.edu> from "faried nawaz" at Aug 12, 95 07:11:34 pm Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 5820 Sender: current-owner@freebsd.org Precedence: bulk As faried nawaz wrote: > > > fault virtual address = 0x1028 > fault code = supervisor read, page not present > instruction pointer = 0x8: 0xf0124487 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, OPL = 0 > current process = 161 (mount) > panic: page fault Just to let you know, ironically, after remaking the world and rebooting a new kernel (one with the modified [4.4Lite-2] mount structures), i'm now also suffering from this. It appears to me that all LKM file systems don't work. The machine works well with the demand-loaded fs's commented out of fstab (no cd9660, no procfs - i can temporarily live with this). I've got core dumps, so i have at least something to look into. :-/ j@uriah 41% gdb -k kernel /var/crash/vmcore.16 IdlePTD 205000 current pcb at 1d91a8 panic: because you said to! ... #8 0xf01a4c2b in trap_fatal (frame=0xefbffbfc) at ../../i386/i386/trap.c:714 #9 0xf01a47a8 in trap_pfault (frame=0xefbffbfc, usermode=0) at ../../i386/i386/trap.c:640 #10 0xf01a4423 in trap (frame={tf_es = -260374512, tf_ds = 16, tf_edi = 0, tf_esi = -260316288, tf_ebp = -272630680, tf_isp = -272630748, tf_ebx = 0, tf_edx = -260316172, tf_ecx = -260278528, tf_eax = 0, tf_trapno = 12, tf_err = -260374528, tf_eip = -260297713, tf_cs = -272695288, tf_eflags = 66118, tf_esp = -260316288, tf_ss = -260864512}) at ../../i386/i386/trap.c:299 #11 0xf019a821 in calltrap () #12 0xf07c4f4a in end () #13 0xf0127678 in lookup (ndp=0xefbffe50) at ../../kern/vfs_lookup.c:490 #14 0xf012704e in namei (ndp=0xefbffe50) at ../../kern/vfs_lookup.c:147 #15 0xf012afe6 in lstat (p=0xf07c1100, uap=0xefbfff94, retval=0xefbfff8c) at ../../kern/vfs_syscalls.c:1260 #16 0xf01a4e33 in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi = -272638582, tf_esi = 213248, tf_ebp = -272638864, tf_isp = -272629788, tf_ebx = 213320, tf_edx = -272638586, tf_ecx = 213312, tf_eax = 190, tf_trapno = 582, tf_err = 582, tf_eip = 38053, tf_cs = 31, tf_eflags = 582, tf_esp = -272638984, tf_ss = 39}) at ../../i386/i386/trap.c:858 #17 0xf019a86b in Xsyscall () #18 0x6e66 in ?? () #19 0x2337 in ?? () #20 0x22bd in ?? () #21 0x10e8 in ?? () Frames #11 and #12 both displayed bogusly as ``end ()'' in DDB. (kgdb) up 10 #10 0xf01a4423 in trap (frame={tf_es = -260374512, tf_ds = 16, tf_edi = 0, tf_esi = -260316288, tf_ebp = -272630680, tf_isp = -272630748, tf_ebx = 0, tf_edx = -260316172, tf_ecx = -260278528, tf_eax = 0, tf_trapno = 12, tf_err = -260374528, tf_eip = -260297713, tf_cs = -272695288, tf_eflags = 66118, tf_esp = -260316288, tf_ss = -260864512}) at ../../i386/i386/trap.c:299 299 (void) trap_pfault(&frame, FALSE); (kgdb) frame frame.tf_ebp frame.tf_eip #0 0xf07c2c0f in end () This should be the exact trap location. I think the ``end + ...'' means it has been executing code from the data/bss instead of the text segment. (kgdb) disas 0xf07c2c00 0xf07c2c1f Dump of assembler code from 0xf07c2c00 to 0xf07c2c1f: 0xf07c2c00 : movl 0xffffffec(%ebp),%edi 0xf07c2c03 : movl 0x11c(%edi),%edi 0xf07c2c09 : movl %edi,0xffffffe4(%ebp) 0xf07c2c0c : movl %edi,0x1c(%esi) 0xf07c2c0f : movl 0xc(%edi),%eax <<<=== 0xf07c2c12 : movl %eax,0xc(%esi) 0xf07c2c15 : incw 0x4(%eax) 0xf07c2c19 : addl $0x4,%esp 0xf07c2c1c : cmpl $0x0,0x10(%ebp) End of assembler dump. (kgdb) up #1 0xf019cee7 in boot (arghowto=-272630520) at ../../i386/i386/machdep.c:877 877 dumpsys(); (kgdb) up #2 0xf07c4f4a in end () (kgdb) up #3 0xf0127678 in lookup (ndp=0xefbffe50) at ../../kern/vfs_lookup.c:490 490 error = VFS_ROOT(dp->v_mountedhere, &tdp); (kgdb) up #4 0xf012704e in namei (ndp=0xefbffe50) at ../../kern/vfs_lookup.c:147 147 error = lookup(ndp); (kgdb) p ndp $5 = (struct nameidata *) 0xefbfdd8a (kgdb) p *ndp $6 = {ni_dirp = 0x4d524554
, ni_segflg = 1986228285, ni_startdir = 0x353274, ni_rootdir = 0x454d4f48, ni_vp = 0x6f722f3d, ni_dvp = 0x5300746f, ni_pathlen = 1280066888, ni_next = 0x73752f3d
, ni_loopcnt = 1869361010, ni_cnd = {cn_nameiop = 795631971, cn_flags = 795765090, cn_proc = 0x68736374, cn_cred = 0x474f4c00, cn_pnbuf = 0x454d414e
, cn_nameptr = 0x5500723d
, cn_namelen = 1028801875, cn_hash = 1095762034, cn_consume = 792545364}} Looks pretty bogus, eh? But now suprise, one stack frame above, it looks fine: (kgdb) up #5 0xf012afe6 in lstat (p=0xf07c1100, uap=0xefbfff94, retval=0xefbfff8c) at ../../kern/vfs_syscalls.c:1260 1260 error = namei(&nd); (kgdb) p nd $7 = {ni_dirp = 0x34140 "/cd", ni_segflg = UIO_USERSPACE, ni_startdir = 0x0, ni_rootdir = 0xf070b980, ni_vp = 0xf07bec00, ni_dvp = 0xf070b980, ni_pathlen = 1, ni_next = 0xf0709403 "", ni_loopcnt = 0, ni_cnd = { cn_nameiop = 0, cn_flags = 32780, cn_proc = 0xf07c1100, cn_cred = 0xf07bc700, cn_pnbuf = 0xf0709400 "/cd", cn_nameptr = 0xf0709401 "cd", cn_namelen = 2, cn_hash = 199, cn_consume = 0}} (kgdb) p &nd $8 = (struct nameidata *) 0xefbffe50 Obviously, the `ndp' becomes mangled inside namei(). Does this look familiar to somebody? -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-)