Date: Thu, 23 Feb 1995 07:27:24 -0500 From: starkhome!gene@sbstark.cs.sunysb.edu (Gene Stark) To: Charlie Root <mother.cdrom.com!root@sbstark.cs.sunysb.edu> Cc: bugs@FreeBSD.org Subject: panic while accessing tape drive.. Message-ID: <199502231227.HAA03815@starkhome.cs.sunysb.edu> In-Reply-To: Charlie Root's message of Wed, 22 Feb 1995 16:53:00 GMT
next in thread | raw e-mail | index | archive | help
At the risk of telling you what you already know... >From the fault virtual address I would say that an attempt was made to dereference a NULL structure pointer (e.g. p->field, where p is NULL). The IOPL indicates that the fault occurred in the top half of the driver. If you use GDB, even without debugging symbols, you can locate the position of the instruction causing the fault, from which it should at least be easy to see what statement in the driver is dereferencing the null pointer. Well, that doesn't tell you *why* the pointer is null, but presumably this has to do with the fact that some variable is not properly initialized in case of the error condition noticed on the drive. At this point, a crash dump and debugging symbols would be handy. - Gene >Do a tar tvf /dev/rst1 and you get: > >st1: bad request, must be between 0 and 0 >st1(bt0:6:0): > >Fatal trap 12: page fault while in kernel mode >fault virtual address = 0xc00 >fault code = supervisor read, page not present >instruction pointer = 0x8:0xf011263f >code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 >processor eflags = interrupt enabled, resume, IOPL = 0 >current process = Idle >interrupt mask = bio >panic: page fault
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199502231227.HAA03815>