Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!sun-barr!lll-winken!ncis.tis.llnl.gov!blackbird!udecc!turner From: turner@udecc.engr.udayton.edu (Bob Turner) Newsgroups: comp.sys.tahoe Subject: Re: HCX-9: "df" dumps core w/ "Illegal instruction" Message-ID: <1990Jun12.214332.4697@udecc.engr.udayton.edu> Date: 12 Jun 90 21:43:32 GMT References: <23515@uflorida.cis.ufl.EDU> Reply-To: turner@udecc.engr.udayton.edu (Bob Turner) Organization: Univ. of Dayton, School of Engineering Lines: 68 In article <23515@uflorida.cis.ufl.EDU> dkf@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@udecc.engr.udayton.edu Univ. of Dayton, Engineering Computing Center-KL211, Dayton OH 45469