HP-UX Error: 14: Bad address

[Mitra Bhanu Rath_1]

Hi Unix Guru`s,I am getting this error message and the oracle is going down.I have checked all the disks on which oracle is doing the work,but found no errors on that.The complete erroe details is pasted below.....
KCF: write/open error block=0x3d2a online=1
file=159 /oradata/u005/ACCDW/ACCDW_gcldm_idx_04.dbf
error=27072 txt: 'HP-UX Error: 14: Bad address
Additional information: 15658'
Fri Apr 8 14:21:13 2005
Errors in file /oracle/admin/ACCDW/bdump/dbw0_8850_accdw.trc:
ORA-01242: data file suffered media failure: database in NOARCHIVELOG mode
ORA-01114: IO error writing block to file 159 (block # 15658)
ORA-01110: data file 159: '/oradata/u005/ACCDW/ACCDW_gcldm_idx_04.dbf'
ORA-27072: skgfdisp: I/O error
HP-UX Error: 14: Bad address
Additional information: 15658
DBW0: terminating instance due to error 1242

Now Oracle says it is OS related..but i don`t find any errors in OS logs.Pls suggest..

[Jannik]

could be a fiber or scsi error... Does you dmesg give you any information?
And you tried the fsck and the dd on the system without any failurs?

fsck on the unmounted volume.
dd if= of=/dev/null

[Mitra Bhanu Rath_1]

Hi Jannik,

I don`t have any errors in dmesg except the below given errors..
WARNING: modpath: DLKM is not initialized
WARNING: ioctl: DLKM is not initialized
WARNING: ioctl: DLKM is not initialized
WARNING: ioctl: DLKM is not initialized

And yes i have checked the disks with dd command and there was no errors found.

[RAC_1]

The DLKM error indicates that your last kernel tuning dod not go quite well. To check it further you can as follows.

echo "mod_initialized/D" | adb -k /stand/vmunix /dev/kmem.
If it reports 0, then you need to tune your kernel.

About oracle error, check the disk in STM. does it report any error??

[rick jones]

Errno 14 is EFAULT (grep 14 /usr/include/sys/errno.h can be your friend). It suggests that an address passed-in on a system call may have been bad. The Oracle output line you provide suggests that either the write(2) or open(2) calls were involved. The manpages for each of those should have an entry for EFAULT in them that will suggest what may have happened.

You can I suppose confirm the system calls by taking a tusc trace of the process - of course that can have a bit of overhead... and you have to know which process to trace.