mojo@uunet.uu.net (Joseph Moran) (07/27/89)
Our system some times fails to boot and prints out: "xy: cannot exec
first read" and returns to the monitor prompt. After this happens, typing
"b" to the monitor sometimes will reboot the system. However, other
times, this error is persistent and you continue getting the same "xy:
cannot exec first read" message from the monitor each time you try and
boot from the disk. In these cases, powering cycling the CPU doesn't
clear the error condition. The only way to recover from this condition is
to power cycle the *disks*. From this I conclude that the disks are
sometimes left in some funny state during a clean shutdown that the boot
PROM may not be able to clear during its reboot sequence.
We have a Sun-3/160 with PROM revision level 2.7 and a Xylogics 451
controller connected to 2 850 Mb CDC Saber drives. Our support people
have replaced the 451 controller, but the problem did not go away. This
seems to leave the disk, the cabling, or the boot PROM as the most likely
suspects. I would prefer not to change the disks unless I have more
evidence that this could really be the problem.
Does anyone know what types of things can cause this error message? Does
anyone with monitor sources know what is happening when the monitor prints
the "xy: cannot exec first read" diagnostic? Has anyone else out there
seen this problem?
Joseph Moran
Legato Systems, Inc.
260 Sheridan Avenue
Palo Alto, CA 94306
(415) 329-7886
mojo@Legato.COM or {sun,uunet}!legato!mojobrent@uunet.uu.net (Brent Chapman) (08/12/89)
# Our system some times fails to boot and prints out: "xy: cannot exec
# first read" and returns to the monitor prompt. After this happens, typing
# "b" to the monitor sometimes will reboot the system. However, other
# times, this error is persistent and you continue getting the same "xy:
# cannot exec first read" message from the monitor each time you try and
# boot from the disk. In these cases, powering cycling the CPU doesn't
# clear the error condition. The only way to recover from this condition is
# to power cycle the *disks*. From this I conclude that the disks are
# sometimes left in some funny state during a clean shutdown that the boot
# PROM may not be able to clear during its reboot sequence.
#
# We have a Sun-3/160 with PROM revision level 2.7 and a Xylogics 451
# controller connected to 2 850 Mb CDC Saber drives. Our support people
# have replaced the 451 controller, but the problem did not go away. This
# seems to leave the disk, the cabling, or the boot PROM as the most likely
# suspects. I would prefer not to change the disks unless I have more
# evidence that this could really be the problem.
We ran into this in late December and early January. This is indeed a bug
in the 2.7 (and 2.8, from what I'm told by Sun) PROMs. We had a 3/280
that started exhibiting the same problems after a motherboard swap during
maintenance, and we finally narrowed it down to the new PROMs. Going back
to an older boot PROM (2.6 or earlier) fixed the problem. I don't know if
it's been fixed in subsequent versions of the PROM (I've seen at least one
machine with PROM rev 2.8.3, though).
While we were tracking this down, we heard from several other people at
other sites with the same problem, and folks from Sun were working on it.
The person at Sun who we working with and who seemed to be the one
tracking the problem was Mike Persichetty <mike@sun.com>. Sorry, I don't
have a bug number (do such things exist for hardware problems?) or service
order number handy, but hopefully he'll remember it.
-Brent
--
Brent Chapman Capital Market Technology, Inc.
Computer Operations Manager 1995 University Ave., Suite 390
brent@capmkt.com Berkeley, CA 94704
{apple,lll-tis,uunet}!capmkt!brent Phone: 415/540-6400heath%sunkist.West@sun.com (Frank Heath) (08/12/89)
I encountered that problem on my first reboot following a 4.0 to 4.0.3 upgrade. Needless to say I was freaked. It can be very persistent. Alternate files do not seem to effect it. I think in has something to do with the 4.0.3 boot code. After upgrading we had multiple power failures, smashed / and /usr, so we had to go back to 4.0 temporarily. We had no xy:.. problems until we got back to 4.0.3. Our Sun rep seems to think its physical problem with the drive not being able to do the seek the first time. This has some plausibility but I think there is some 4.0.3 tie in. Frank S. Heath Rockwell SPD 4311 Jamboree Road P.O. Box C Newport Beach, CA, 92658-8902 (714) 833 6864 FAX (714) 833 6863 M/S 985-337 heath%mogwai.decnet@consort.rok.com sun!sunkist!earth!heath mogwai::heath (Decnet)
mike@ebay.sun.com (Mike Persichetty) (08/23/89)
The problem described was caused by a timing condition in the CPU
firmware. This problem was corrected by Sun in mid March 1989 with the
release of the 2.8.4 Boot PROM.
CPU boards with the following part numbers incorporate this change:
501-1206-16 or greater Sun-3/260/280
501-1100-15 or greater Sun-3/260/280
501-1274-20 or greater Sun-4/260/280
501-1491-04 or greater Sun-4/260/280
501-1522-04 or greater Sun-4/260/280
501-1164-14 or greater Sun-3/160/180
501-1208-10 or greater Sun-3/160/180
>Date: Fri, 11 Aug 89 10:34:08 PDT
>From: Brent Chapman <capmkt!brent@uunet.uu.net>
>Subject: Re: xy: cannot exec first read
>We ran into this in late December and early January. This is indeed a bug
>in the 2.7 (and 2.8, from what I'm told by Sun) PROMs. We had a 3/280
>that started exhibiting the same problems after a motherboard swap during
>maintenance, and we finally narrowed it down to the new PROMs. Going back
>to an older boot PROM (2.6 or earlier) fixed the problem. I don't know if
>it's been fixed in subsequent versions of the PROM (I've seen at least one
>machine with PROM rev 2.8.3, though).
>While we were tracking this down, we heard from several other people at
>other sites with the same problem, and folks from Sun were working on it.
>The person at Sun who we working with and who seemed to be the one
>tracking the problem was Mike Persichetty <mike@sun.com>. Sorry, I don't
>have a bug number (do such things exist for hardware problems?) or service
>order number handy, but hopefully he'll remember it.
>-Brent
>--
>Brent Chapman Capital Market Technology, Inc.
>Computer Operations Manager 1995 University Ave., Suite 390
>brent@capmkt.com Berkeley, CA 94704
>{apple,lll-tis,uunet}!capmkt!brent Phone: 415/540-6400
Mike Persichetty
Sun Microsystems, Inc.
CSD Product Support Engineering