[Orca-users] orca seg fault on SAN connected host - Update needed to RICHPse?

[Robert Stannard]

Thanks Dago

I am running orcallator.se from orca site, I think

root at unix-eval # /usr/ucb/ps -auxwww | grep orca
root     17373  0.0  0.42647225824 pts/3    S 13:14:07  0:01 /opt/RICHPse/bin/se.sparcv9 -DWATCH_OS -I/opt/orca/lib/SE/3.4 /opt/orca/lib/orcallator.se
root     17411  0.0  0.0 1352 1152 pts/3    S 13:15:40  0:00 grep orca
root at unix-eval #

Now have orca running after adding old fix to diskinfo.se from Carl Staroscik, backed by jsutch

root at unix-eval # diff /opt/RICHPse/include/diskinfo.se /opt/RICHPse/include/diskinfo.se.orig
215,220d214
<      // 09-12-2005 Carl Hack to stop segmentation faults - must be a bug in readdir -
<       if (ld > 18446744071543217903) {
<         continue;
<       }
<      // get the segmentation fault here when ld is > 18446744071543217903
<      // jsutch 20060805

Rob Stannard
Unix Consultant
020 7577 2713
robert.stannard at int.sc.mufg.jp
 
P Please consider the environment - do you really need to print this email? 
 
 


-----Original Message-----
From: Dagobert Michelsen [mailto:dam at baltic-online.de] 
Sent: 18 January 2008 12:58
To: Robert Stannard
Cc: orca-users at orcaware.com
Subject: Re: [Orca-users] orca seg fault on SAN connected host - Update needed to RICHPse?


Hi Robert,

Am 18.01.2008 um 12:40 schrieb Robert Stannard:
> Get orca seg fault on SAN connected host.
> Sun Solaris 10 08/07 on T5220 connected to EMC DMX3 disks via
> Veritas 5.0

:-)

> Running RICHPse 3.4 PSTAMP:  05 Jan 05
>
> Tried using a file from RICHPse3.4+ which looked promising
> (mentioned in previous thread by <js.tech.mailer at ...> )
>
> root at unix-eval # ls -l /var/tmp/rs/RICHPse3.4+/opt/RICHPse/
> orcallator/orcallator.se
> -rw-r--r--   1 root     other      85392 Feb 28  2007 /var/tmp/rs/ 
> RICHPse3.4+/opt/RICHPse/orcallator/orcallator.se
> root at unix-eval # ls -l /opt/RICHPse/orcallator/orcallator.se
> -rw-r--r--   1 root     other      80768 Jan  5  2005 /opt/RICHPse/ 
> orcallator/orcallator.se
> root at unix-eval #
>
> Have dowloaded latest tarball orca-snapshot-r531, compiled without
> error, but still get fault below.

Please make sure you use the orcallator from the Orca package, not the one included with RICHPse. If it still crashes, you can run se with the debug-option '-d'. You will most likely hit
   https://sourceforge.net/tracker/index.php? 
func=detail&aid=1698128&group_id=189279&atid=928689
on Solaris 10. Upgrading SE Toolkit to 3.4.1 solves the problem.

> 3202:   readlink("/dev/dsk/c3t5006048452A702A7d29s0", "../../ 
> devices/pci at 0/pci at 0/pci at 8/pci at 0/pci at 1/fibre-channel at 0,1/fp at 0,0/
> ssd at w5006048452a702a7,1d:a", 256) = 95
> 3202:   ioctl(4, KSTAT_IOC_CHAIN_ID, 0x00000000)        = 2020
> 3202:   ioctl(4, KSTAT_IOC_READ, "sd1,err")             = 2020
> 3202:   ioctl(4, KSTAT_IOC_CHAIN_ID, 0x00000000)        = 2020
> 3202:   ioctl(4, KSTAT_IOC_READ, "sd3,err")             = 2020
> 3202:   ioctl(4, KSTAT_IOC_CHAIN_ID, 0x00000000)        = 2020
> 3202:   ioctl(4, KSTAT_IOC_READ, "sd2,err")             = 2020
> 3202:   ioctl(4, KSTAT_IOC_CHAIN_ID, 0x00000000)        = 2020
> 3202:       Incurred fault #6, FLTBOUNDS  %pc = 0xFFFFFFFF7DE00A88
> 3202:         siginfo: SIGSEGV SEGV_MAPERR addr=0xFFFFFFFF7F506000
> 3202:       Received signal #11, SIGSEGV [default]
> 3202:         siginfo: SIGSEGV SEGV_MAPERR addr=0xFFFFFFFF7F506000
> 3204:   nanosleep(0xFFBFF740, 0xFFBFF738)               = 0
> 3204:   _exit(0)
>
> Finally worked out that I should comment out the USE_RAWDISK from /
> opt/RICHPse/orcallator/orcallator.se
>
> Update needed to RICHPse?

Yes. RICHPse 3.4.1 and latest orcallator.se from Orca package.


Best regards

   -- Dago

-- 
Dagobert Michelsen (Leiter IT)          Baltic Online Computer GmbH
Firmensitz:   Alter Markt 1-2, 24103 Kiel, Telefon: +49 431 54003-0
Geschäftsführer:        Erik Cickovskis, Amtsgericht Kiel, HRB 3756
"Of course computer servers don't need thrust, since they generally don't go anywhere."  -- Comment in TR on new HP server turbine fans





**********************************************************
Mitsubishi UFJ Securities International plc ("MUSI") is registered in England, company number 1698498, registered office at 6 Broadgate, London EC2M 2AA, and is part of the Mitsubishi UFJ Financial Group.  MUSI is authorised and regulated in the UK by The Financial Services Authority Limited (FSA). The information contained herein or attached hereto has been obtained from sources we believe to be reliable but we do not represent that it is accurate or complete and is not  to be viewed as a 'personal recommendation' within the meaning of the FSA rules.  The Information is not to be construed as an offer or solicitation to buy or sell any security, instrument or investment. Any reference to past performance should not be taken as an indication of future performance.  MUSI or any affiliated company may have an interest, position, or effect transactions, in any investment mentioned herein. Any opinions or recommendations expressed herein are solely those of the author or analyst and are subject to change without notice. Neither MUSI nor any of its affiliates accept any liability whatsoever for any direct or consequential loss arising from any use of information or material contained herein.



This message is intended solely for the individual addressee named above.  The information contained in this e-mail is confidential and may be legally privileged.   If you are not the intended recipient, you must not copy, distribute or take any action in reliance on it.   Messages sent via this medium may be subject to delays, non-delivery and unauthorised alteration.