This content has been marked as final. Show 37 replies
use the Find function, with a Type: Hex Bytes, to search for 7F FF FE 2E. There is only one instance of it in the SunPCI 3.2.2 sunpcbinary. Then replace those characters with those that Sun-Worshiper recommended. It only works for v3.2.2. I'm still trying to figure out how to alter the binary for 3.1.
Using SweetScape to edit the binary, I see 00000001 at offset 4CF8 without even being started making changes. This is the data when read from left to right ie. from 4CF8h to 4CFBh. Please guide me if Iam looking at right location.
I am running OS, if matters any:
5.8 Generic_108528-13 sun4u sparc SUNW,Sun-Blade-100
# pkginfo -l SUNWspci3
NAME: SunPCi III
VENDOR: Sun Microsystems, Inc.
DESC: This package contains the SunPCi III software for Solaris 7, 8, and 9, Sparc PCI Platforms
INSTDATE: Apr 19 2005 08:56
Ok, interestingly there is no such string found in my sunpcbinary.
I did implement the following patch to SunPCI 3.2.2 original package. I'm not sure if it altered the sunpcbinary or not: 118591-03.
tmarucci71 wrote:The process I used was:
Sun-Worshiper. I was able to fix SunPCI 3.2.2 binary. I'm in the process of using a hexeditor to find the validate_system_time call in the SunPCI 3.1 binary. Being new to this I was wondering if you might be able to educate me on how you figured out the offset where the call was made.
Any help you can give would be greatly appreciated.
1) Run sunpci under truss and guessed that calls to the system function time() were being used to check the system time.
2) Tried to use dtrace to dynamically (without modifying the binary file) change the return value from time (known to dtrace as syscall::gtime) to a fixed value in a year before 2010. Gave up as couldn't find out how to do that, a limitation of dtrace is that it doesn't appear able to change the return value from a function.
(although dtrace is able to modify an input parameter - see [http://forums.sun.com/thread.jspa?threadID=5398609&messageID=10772016#10772016] for an example of using dtrace to work-around another SunPCI 3.2.2 annoyance)
3) Used /usr/ccs/bin/dis to disassemble sunpcibinary and searched for where validate_system_file was called from. It was only called from a single place in main:
The disassembly showed that 7f ff fe 2e was the hex value which was then searched for in the /usr/bin/ghex2 hex editor (the GHOME hex editor which was installed on my Solaris 10 11/06 s10s_u3wos_10 SPARC systerm).
main+0x1a4: 94 10 00 1b mov %i3, %o2 main+0x1a8: 7f ff fe 2e call validate_system_time main+0x1ac: 29 00 00 52 sethi %hi(0x14800), %l4
The call uses relative addressing, so it will be a different hex string to search for in a different binary (if the hex string for the call appears more than one in the binary expand the search for check for adjacent instructions).
4) The hex string 01000000 for the NOP used to replace the call validate_system_time is the same for any binary.
Hope that helps.
Hilarious - Y2K + hex A
Same here - something told me this was not normal :)
Also my Sun Update Connection is crapping out. Got certificate issues. Don't even know yet. I'll bet everyone is busy.
Thanks so much for the explanation. I tried it with SunPCI 3.1. I found one location where validate_system_time was called. It was not in main. I modified the hex value for the call, but did not have any luck. I'm going to re-attack tomorrow when i'm fresh.
Thanks for the schooling. At least now I know a little more about working with binaries.
Thanks so much for your findings and your explanation, Sun-worshiper.
I just discovered the Y2K+0xA problem on my own machine. Thanks to your posts, I was able to get SunPCI running in less than five minutes! (I used ghex2 as you described to patch my 3.2.2 installation of the SunPCI software.)
Well Sun Update Connection is working now without intervention. Something bad obviously happened on 1/1 :) I'll wait for the SunPCI update from Sun.
BTW I'm glad to see there are other fools like me still using SunPCI cards. I'm running SuSE 11.1 on an external USB drive on mine - it boots when the machine boots and I access it with Xming and putty as if a standalone machine.
Thanks you for the great information. I made the edit and got the system back up and running quickly.
C. Jeffery Small
It's too bad that we have to go the "patch-the-binary" road. Unless Sun has already decided that they will no longer support their product, it seems like they like to take their time to provide a fix.
I'm not sure if anyone on this forum ever had issues with the "/net/ltfu/files1/sunpci/...." embedded in the binary. The 3.2.2 sunpci software would sit for about 10 minutes before the automounter would give up trying to access that network drive. In any case, that was yet another occasion when I had to patch the binary to get it to work and never saw a patch from Sun.
It's too bad that we have to go the "patch-the-binary" road. Unless Sun has already decided that they will no longer support their product, it seems like they like to take their time to provide a fix.This sounds familiar to me. It's like the isssue with RSC 2.2.3 GUI on Windows. I visited the [download page|http://www.sun.com/servers/rsc.html] today, still there is no updated/fixed release.
Update: Someone told me that patch 118591-04 for the SunPCi3 has been submited for release and will be soon available on Sunsolve.
Edited by: MAAL on 12.01.2010 01:19
Here is an update on the case that we opened with Sun on this issue.
They provided Tpatch T118591-04. They stated the patch is the almost final fix for CR6913785. When patch 118591-04 actually is released on sunsolve.sun.com (very soon now), you'll have to backout T118591-04 before installing the released patch 118591-04.
Shame on Sun for causing this issue. Y2K in 2010? Who want's to go through several patches? Perhaps time to get off the PCI cards forever.