Re: System crash when using mksysb
From: Nicholas Dronen (ndronen_at_io.frii.com)
Date: 06/25/03
- Next message: Nicholas Dronen: "Re: How to load kernel extension (NEWBIE)......."
- Previous message: Paul Pluzhnikov: "Re: xlc 5.0.2.0 compiler bug - request confirmation."
- In reply to: Will: "Re: System crash when using mksysb"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: 25 Jun 2003 04:06:54 GMT
Will <nerk88@yahoo.com> wrote:
W> Thanks for the chart, I've examined the devices, the two disks
W> (mirrored) and the tape drive are on the same SCSI bus (different
W> ID's), so I think thats OK.
W> I also examined the error log a bit, and from reading that and IBM's
W> "Introduction to Reading Dumps"
W> (http://www-1.ibm.com/support/docview.wss?uid=isg1hintsTips0442), it
W> appears to be a trap. The web page says a trap is "An assert statement
W> in the code caused the system to crash because it was not true." So, I
W> am thinking this is a software problem. MKSYSB is a script that uses
W> the "backup" program, is there a known problem with this or could it
W> still be a hardware problem?
The instruction tweq appears in the IAR line, so, yes, this is
an assertion. An failed assertion such as this means that some
kernel or device driver data structure is in an invalid state.
That much of it occurs in software. But a hardware problem could
still be the cause of the invalid state.
W> # crash /var/adm/ras/vmcore.5
W> Using /unix as the default namelist file.
>> trace -m
W> Skipping first MST
Below is the kernel stack trace.
W> MST STACK TRACE:
W> 0x2ff3b400 (excpt=40012f62:40000000:00030098:40012f62:00000106)
W> (intpri=11)
W> IAR: .jfs_getpcl+100 (002170bc): tweq r14,r14
The last function called was jfs_getpcl. It asserted.
W> LR: .jfs_getpcl+d0 (0021708c)
It was called recursively.
W> 2ff3b1e0: .vnop_getpcl+1c (001c37e0)
W> 2ff3b220: .spec_getpcl+50 (00224c7c)
W> 2ff3b290: .vnop_getpcl+1c (001c37e0)
W> 2ff3b2d0: .getpcl+80 (0024dc18)
W> 2ff3b350: .statpriv+17c (0024dedc)
W> 2ff3b3c0: .sys_call_ret+0 (00003a90)
The bottom function sys_call_ret is the entry point into
the kernel. When a process issues a system call, it switches
contexts into kernel mode so it can access the kernel address
space. In user mode, a process only has access to its own
virtual memory.
W> 0452-771: Cannot read return address at address 0x200216c8.
Regards,
Nicholas
-- "Why shouldn't I top-post?" http://www.aglami.com/tpfaq.html "Meanings are another story." http://www.ifas.org/wa/glossolalia.html
- Next message: Nicholas Dronen: "Re: How to load kernel extension (NEWBIE)......."
- Previous message: Paul Pluzhnikov: "Re: xlc 5.0.2.0 compiler bug - request confirmation."
- In reply to: Will: "Re: System crash when using mksysb"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
