Very Computer

I just tried sys-suspend on a Blade 100 with either Solaris 9 9/05
or Solaris 10 3/05 installed. With both OS versions, the resume boot
fails with:

  cprboot: can't open /.CPR
  please reboot
  Program terminated

I know that there were problems in the past (Solaris 7/8?) with
resuming after sys-suspend when / is a logging filesystem, but
I thought those had been fixed, esp. as logging is now default
for all filesystems.

Is this still a general problem (bugid 4491494 from Apr/2005 seems
to suggest this), or is it a local problem ?

mp.
--
Systems Administrator | Institute of Scientific Computing | Univ. of Vienna

Martin Paul schrieb:

Quote:> I just tried sys-suspend on a Blade 100 with either Solaris 9 9/05
> or Solaris 10 3/05 installed. With both OS versions, the resume boot
> fails with:

>   cprboot: can't open /.CPR
>   please reboot
>   Program terminated

> I know that there were problems in the past (Solaris 7/8?) with
> resuming after sys-suspend when / is a logging filesystem, but
> I thought those had been fixed, esp. as logging is now default
> for all filesystems.

> Is this still a general problem (bugid 4491494 from Apr/2005 seems
> to suggest this), or is it a local problem ?

> mp.

I had the same problem on a Blade 1000 and a different one with
a crash that is under investigation on a Blade 2500. Concerning the
"can't open /.CPR" error I asked if this is a known problem and
received a negative answert. But I did not ask any further as
I don't need suspend/resume on this machine.

Tom

Strange. For me the behaviour is consistent both with Solaris 9
and 10 - resume fails with the above mentioned error when / is
logging, and works without a problem when root is nologging.

As logging is default now, everybody should see the problem when
using sys-suspend. I can only guess that no one is actually using
it, and therefore the problem hasn't been mentioned here more often.

mp.
--
Systems Administrator | Institute of Scientific Computing | Univ. of Vienna

Martin Paul schrieb:

That is, what I guessed, too. But the person handling my case
said, he does suspend/resume on a regular basis without a
problem. Maybe his filesystem isn't logging. I will ask him...

Tom

Thomas Maier-Komor schrieb:

sorry to reply to my own post.

I looked on sunsolve. It is a known problem. Bugid 4163575.
Work around is: disable logging.

HTH,
Tom

On Tue, 18 Oct 2005 16:21:08 +0200, Thomas Maier-Komor  

that one was fixed in Solaris 9.

---
frankB

Perhaps he should check the status of write caching on the
disks.....

Casper

I use it on my home sparcs (not my home x86 machine, unfortunately).

It seems to be hit and miss. I had the same problem on and off
throughout S10 beta. For the last few months it's worked fine
without a hitch - and that is with / mounted with logging.

(One thing I was suspicious about was that once I had got it to work
once, it tended to work thereafter. If you re-enable logging, does its
stop working again?)

--
-Peter Tribble
L.I.S., University of Hertfordshire - http://www.herts.ac.uk/
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/

Casper H.S. Dik schrieb:

on the blade 1000, where I had this error write caching is disabled,
isn't it?

scsi> p8

Page 0x8:
default:     88 12 90 00 ff ff 00 00 00 76 ff ff 80 02 00 00
              00 00 00 00
current:     88 12 90 00 ff ff 00 00 00 76 ff ff 80 02 00 00
              00 00 00 00
saved:       88 12 90 00 ff ff 00 00 00 76 ff ff 80 02 00 00
              00 00 00 00
changeable:  88 12 b5 00 00 00 ff ff ff ff 00 00 a0 ff 00 00
              00 00 00 00

Tom

Frank Batschulat schrieb:

the one that was fixed in Solaris 9 is 4163575, you are right.
But there is another one from Apr 27, 2005: 4491494.
The newer one refers to the older one as "Related Change Request".

So I posted the wrong one...

Tom

So what about 4491494, which describes the same problem, and whose
state is just "6-Fix Understood" ?

mp.
--
Systems Administrator | Institute of Scientific Computing | Univ. of Vienna

Quote:> Perhaps he should check the status of write caching on the
> disks.....

My machine is Blade 100 with an ST320011A ATA disk. 'format -e'
doesn't show the cache status, but from old google posts it seems
that the write cache on Suns ATA disks is on by default. Would
that be a problem with sys-suspend and UFS logging ?

mp.
--
Systems Administrator | Institute of Scientific Computing | Univ. of Vienna

Great hint - I re-enabled logging, init 6, sys-suspend, and now the
resume worked.

Suspicious, indeed. Maybe it makes a difference that after the first
successfull sys-suspend the /.CPR file already exists, and is reused
on following suspends ?

Let's test that. After a successfull resume and with logging /, I
removed /.CPR and /.cpr_default. Ran sys-suspend, and the next
resume failed. Boot the machine with "boot". The .CPR/.cpr_default
files exist now, so run sys-suspend again - and indeed, the next
resume works.

The net result of my (limited, of course) test:

If the / filesystem is nologging, sys-suspend and resume always work.

If the / filesystem is logging, the resume will fail if /.CPR hasn't
existed before running sys-suspend.

mp.
--
Systems Administrator | Institute of Scientific Computing | Univ. of Vienna

this is an interesting question of course, the ATA driver
has code to flush the write cache, this in turn seems
to happen during reset, e.g. a reboot - I'd assume when
the system is suspended this will be done as well,
but I'll x-check this with our ATA driver group.

---
frankB

Quote:> Suspicious, indeed. Maybe it makes a difference that after the first
> successfull sys-suspend the /.CPR file already exists, and is reused
> on following suspends ?

> Let's test that. After a successfull resume and with logging /, I
> removed /.CPR and /.cpr_default. Ran sys-suspend, and the next
> resume failed. Boot the machine with "boot". The .CPR/.cpr_default
> files exist now, so run sys-suspend again - and indeed, the next
> resume works.

> The net result of my (limited, of course) test:

> If the / filesystem is nologging, sys-suspend and resume always work.

> If the / filesystem is logging, the resume will fail if /.CPR hasn't
> existed before running sys-suspend.

did you ever saw a error messages from CPR that claims
it failed to disable logging ?

thanks

---
frankB