NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/sys/mac/system/10294

Text File | 1992-07-22 | 6.0 KB | 121 lines

Newsgroups: comp.sys.mac.system
Path: sparky!uunet!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!The-Star.honeywell.com!umn.edu!noc.msc.net!news.stolaf.edu!mari.acc.stolaf.edu!smithc
From: [e-mail] (Christopher A. Smith)
Subject: Re: Bad F-line instruction?
Message-ID: <[e-mail]>
Sender: [e-mail]
Organization: St. Olaf College, Northfield (aka Cow Country), MN   USA
References: <[e-mail]> <[e-mail]> <[e-mail]>
Distribution: na
Date: Thu, 23 Jul 1992 03:17:05 GMT
Lines: 108

In article <[e-mail]> [e-mail] (Tony Wingo) writes:
>In article <[e-mail]>,
>[e-mail] (Christopher A. Smith) wrote:
>
>> Tony, let me tell you about my experiences with this Bad F-Line
>> instruction, just in case my previous posting from about a month ago
>> has scrolled off...
>>
>> [Long description of problems with F-Line errors deleted]
>>
>>
>> How can a program become corrupted, especially more than once a day,
>> under different circumstances (different or no INITs or applications)?
>
>Without being there I can't answer this directly.  One of the weaknesses of
>the Mac OS is that memory protection is not built into it, thus allowing an
>errant piece of code to do all kinds of random things. (No flames please --
>this was a decision made almost a decade ago, and while in retrospect it
>might have been made differently, we have to live with it for a bit).
>
>While I can sympathize with your frustration, keep in mind that what you
>are seeing is not a system problem. I routinely work on four different
>machines (two IIfx, a IIx and a PB 140) running 7.0.1 and 7.1 beta.  My
>buddy in the next cube has even more machines including a Quadra 700.
>Since we do software development our machines are always a little flaky,
>and neither one of us sees many F-line problems at all.  There is something
>about your particular configuration that is causing problems.
>Unfortunately, without being there (fat chance: I grew up in DC, and I
>wouldn't go back in July or August if my life depended on it :-) ) there is
>not much else I can tell you.  Sometimes these things can only be found
>with an intense mixture of TMON and strong black coffee.
>
>However, a couple of things to look at.
>1. Are you absolutely sure that the system is installed correctly for the
>particular machine?  If you try to run a IIx system on a Classic, all bets
>are off.  If you are not sure, drag the system, finder and all the apple
>cdevs and extensions to the trash, then carefully use the installer to
>re-install the system - never do a system install by dragging the system
>files from one machine to another: Always use the installer.
>
>2. Are all of the applications and extensions you are running up to date?
>Some older versions of software had problems with some aspects of system 7.
> In addition, some older versions didn't get along with 68030's.  There are
>still a bunch that don't like 040's.
>
>3. If this is not your own machine, make sure it only has one system
>folder.  (use the Find command to make sure there isn't a second one buried
>somewhere). I once ran into a machine that had 13 distinct system folders
>on it.
>
>4. Do these problems occur primarily on one machine.  If so, what is
>different between that machine and machines that don't exhibit the problem.
>
>5. Install MacsBug or TMON.  The F-Line failure will trap into the
>Debuegger, and if A5 and A6 are not clobbered, you MAY be able to identify
>what is being corrupted.  If you are so lucky, then you can use the
>checksumming facility to catch the actual corruption.
>
>6. There is a REMOTE possibility that you have an intermittent hardware
>problem, such as a flaky SIMM.  (It would have to be real intermittent for
>it to consistently get past the startup diagnostics) The only real way to
>test for this is to copy your entire configuration over to another machine
>with the same hardware configuration and see if the problem moves with it.
>
>Sorry I couldn't be more help.
>
>-tony
>
>>>usual disclaimers apply<<


The system was correctly installed; I've been using Mazcs extensively
for four years, including for programming and such.  I've run Mac EKG,
Snooper, and some other programs to check the hardware and the hard
drive, and all reports are that the system is in good health.  The
software is all up to date, with latest versions.  If the problem is
hardware, then the problem is very, very, very intermittent and
untraceable.  Technicians have checked for hardware problems, and they
can't find anything, either.  Everything, and I mean *everything* has
been done to find the culprit.  The only thing left to do is to swap
motherboards with another mac IIci, swap SIMMs (which were pronounced
to be fine), and swap hard drives (which was pronounced to be fine;
plus if it were a hard drive problem, I'd be losing data in places
other than just the System folder)...

INIT & application juggling, Mac EKG, Snooper, Norton Utilities,
Central Point MacTools, Disk First Aid, SAM AntiVirus, system
reinstallations, hard drive reformatting (with different drivers,
too), SCSI device removals, cable replacements...  It's all been done.
Plus other folks here have said they've had the same problems -- Bad
F-line errors fixed by reinstalling softwre, which is what prompted my
reponse...  I'd posted something a month ago here and on CompuServe
and I got very little response.  The only conclusion was that the SCSI
devices might be interfering, but they're off the system.  If it's the
SCSI controller, then the motherboard has to be replaced.  But before
I go swapping motherboards, I want to make absolutely certain it's the
SCSI controller...

I've seen the same Bad F-Line errors t work, too, under different
configurations, and I've read about them on here...

Thanks,
Chris

  ==================================================================
             Christopher A. Smith
       German & Mathematics -- St. Olaf College, Northfield, MN
             Internet:  [e-mail]