Date: Mon, 14 Aug 1995 08:11:25 +0200 (MET DST) From: J Wunsch <j@uriah.heep.sax.de> To: fn@pain.csrv.uidaho.edu (faried nawaz) Cc: current@freebsd.org Subject: Re: procfs problems in -current? Message-ID: <199508140611.IAA11398@uriah.heep.sax.de> In-Reply-To: <199508130211.TAA00198@big-brother.csrv.uidaho.edu> from "faried nawaz" at Aug 12, 95 07:11:34 pm
next in thread | previous in thread | raw e-mail | index | archive | help
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 <end+6129852>: movl 0xffffffec(%ebp),%edi
0xf07c2c03 <end+6129855>: movl 0x11c(%edi),%edi
0xf07c2c09 <end+6129861>: movl %edi,0xffffffe4(%ebp)
0xf07c2c0c <end+6129864>: movl %edi,0x1c(%esi)
0xf07c2c0f <end+6129867>: movl 0xc(%edi),%eax <<<===
0xf07c2c12 <end+6129870>: movl %eax,0xc(%esi)
0xf07c2c15 <end+6129873>: incw 0x4(%eax)
0xf07c2c19 <end+6129877>: addl $0x4,%esp
0xf07c2c1c <end+6129880>: 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 <Address 0x4d524554 out of bounds>,
ni_segflg = 1986228285, ni_startdir = 0x353274, ni_rootdir = 0x454d4f48,
ni_vp = 0x6f722f3d, ni_dvp = 0x5300746f, ni_pathlen = 1280066888,
ni_next = 0x73752f3d <Address 0x73752f3d out of bounds>,
ni_loopcnt = 1869361010, ni_cnd = {cn_nameiop = 795631971,
cn_flags = 795765090, cn_proc = 0x68736374, cn_cred = 0x474f4c00,
cn_pnbuf = 0x454d414e <Address 0x454d414e out of bounds>,
cn_nameptr = 0x5500723d <Address 0x5500723d out of bounds>,
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. ;-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199508140611.IAA11398>