Only Mike Salehi <firstname.lastname@example.org> responded. Thank you,
Sun recommended we update the kernel patch to the current rev,
105181-23 and that we try again. This did not help. The next
step was to upgrade the OBP. This failed with a "vpp range
error." If you look at SunSolve, this problem's workaround is
a motherboard replacement, which, unfortunately for some
licenses, also requires not keeping the old nvram. Sun
replaced the motherboard promptly last night. The system is
back up and running fine, as far as we can tell. Maybe the
problem was hardware all along. We really don't know with any
>We have a dual 296MHz processor e450 with Solaris 2.6, 105181-17.
>Once before it behaved this way, but it stopped just as
>mysteriously as it started. Now it is doing it again. What is
>that, you ask?
>When one runs a sleep command, the sleep takes a significantly
>longer time than requested and not always the same multiple or
>same increased amount. Also, if one uses time (1) on the sleep
>command, it shows the same amount of real time as requested,
>even though date commands bracketing the sleep show the real
># date; time sleep 5; date
>Thu Dec 21 14:39:55 MST 2000
>Thu Dec 21 14:40:07 MST 2000
>Also, if xntpd is running, the clock will slow down by about
>the same amount as sleep runs slow. I say "about" because it is
>hard to be certain that it is exactly the same amount, but it
>sure looks the same.
>Anyone seen this or have ideas about it?
>Brooke King direct: +1.415.901.2207 fax: +1.501.423.9037
>114 Sansome Street, Ninth Floor, San Francisco, CA 94104 USA
>sunmanagers mailing list
Brooke King direct: +1.415.901.2207 fax: +1.501.423.9037 email@example.com Yipes Communications 114 Sansome Street, Ninth Floor, San Francisco, CA 94104 USA
_______________________________________________ sunmanagers mailing list firstname.lastname@example.org http://www.sunmanagers.org/mailman/listinfo/sunmanagers
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:14:25 CDT