HCX-9: "df" dumps core w/ "Illegal instruction"

[Bob Turner]

In article <23515 at uflorida.cis.ufl.EDU> dkf at helios.iec.ufl.edu (Dan FitzPatrick) writes:
>
>FPP POC
>dsk(4,0,0,0)/fppoc
>? CP FPP POC error 0004
>
>So, I guess this kinda pinpoints some problems with either the FS
>or FM boards of the FPP hardware because they not passing the
>power-on-confidence checks.  However, the Console Processor Reference
>manual states that when this test fails, the CP assumes the FPP
>hardware does not exist (implies that the FPP hardware is disabled).
>This might also imply that the only way to detect FPP hardware problems,
>other that running diagnostics, is by noting the above message on 
>full boots or by sensing that the system was running a bit sluggish.
>

Congratulations, you are the proud owner of a dead FPP. We have had a
HCX-9 for about the last 3 years and cooked about 4 FPP's. We are
real happy with it otherwise though. 

>
>There being logical conflicts, proceed a bit further to step number...
>
>	1)  Is only physically removing the FPP hardware all that is 
>required?  i.e., the installation manual indicates no additional steps
>for the installation of these optional products, so removal should
>be just as easy, correct?  I am assuming here that on a cold boot,
>the system actually tests for the presence of the hardware and enables
>it through the completion of a successful test.
>
Yep. Thats all folks.

We have the process down to a drill for the most part. The only
intresting thing is we remove the floating point emulation routines
from the kernel for normal operation. (option FPE) Why do I do that?
I like small kernels that don't chew up core. But its awfully hard
to do floating point without either the FPP or the emulation routines. 
So I have to cut in the backup kernel that has the routines in it.

I keep two unixes in the root partition so if the FPP craps out. We
pull the FPP cards, call the FE, boot and select the FPE kernel and
reboot. 

>	2)  If the FPP hardware is not suspect, then what would be 
>causing the diagnostics to indicate that it was?  I would (like to)
>assume that the standalone diagnostics tests that must be passed 
>prior to those that test the FPP hardware would rule anything else 
>like this out.
>

It is a known bug that the FPP is responsible for dying. If you can,
get your FE to install the boards with Plastic carriers. Believe
it or not, there was a heat conduction problem with the ceramic chips.
(I would guessed the other way around)

If you need more info call me......

						Bob

 



-- 
====================================================================
Bob Turner                    Network Manager, School of Engineering
513-229-3171                           turner at udecc.engr.udayton.edu
Univ. of Dayton, Engineering Computing Center-KL211, Dayton OH 45469