Hello kby,

The good news : disabling the firewire extensions solves the "quit Finder" problem. I've made many tests, with my favorite Finder unfriendly apps (stuffit-TFI and Acorbat Reader) and I could not reproduce the problem. Even force quitting those apps (cmd-alt-esc) works better than ever, with no visible side effect.

I too have a firewire card. It's an USB-FW combo card, with no brand name printed on the box. It came with a Formac sheet and CD inside. Manufacturer code is "104C".

This solution solves the problem in the two configurations I'm testing : my work system (patched all-by-hand), and a test system (patched through copy/paste "System 9.2.2 US OW resc 9.2a4" ressources).

I've also tried to replace the 2.8.5 firewire extensions ("Activation firewire" [firewire activation?] and "Gestion Firewire" [firewire manager?]) with the 2.4 version that came with the Formac CD, and the problem comes back, the same.

About the Apus 3000, I also red somewhere (6400 zone ?) that its motherboard was a redisign of the Tanzania. But it always behave like a 6400, with the same flaws. Here's what the "Information sytème Apple" application reports about it (the app from Apple - System Configuration ?):

Informations matérielles
Code de modèle : 58
Modèle : Power Macintosh séries 6360/6400
Type de clavier : clavier étendu Apple (ISO)
Processeur : PowerPC 603ev
Vitesse : 200 MHz
Version nanokernel : 2.27
Extensions nanokernel : 0
CPU prévues nanokernel :1

Informations de production
Révision de ROM : $77D.29F1

Now, the big question ;-) Is there a way to recover the FW capabilities ?....

Thanks for the info. That's unfortunately what I've experienced (I also tried older FW extensions and such). From a programming standpoint, it looks like the crash is caused by a stack-out-of-phase error, in that what happens is there is a return to an a value on the stack that isn't an address. Not that I know what to do about that at the moment but I mention it for anyone else who might. As far as FW goes, I think the issue isn't firewire per se but that it influences things. After reading RogueB's post and realizing that what he mentioned earlier was an alternate description of what I was seeing, I tried without VM on. And it does seem better but as he recently mentioned not necessarily "fixed." I have noted that using ConflictCatcher and stopping loading soon after carbon lib loads also makes things work "better" but not necessarily perfectly. That prevents background apps from starting up, though, so it makes the symptom more difficult to see (that is usually when I might see it hit the Finder). Changing the order of CarbonLib's loading also doesn't help for me (at least trying very early or very late). Gut feeling is it's a memory deallocation issue that's set up when the image starts running and is timing dependent as to when it actually hits something, but I have no proof, of course. VM influencing the problem would tend to indicate that more than FireWire, but I think the FireWire stuff just twiddles the timing enough that the issue doesn't hit at least with anywhere near the same frequency. I also tried using the debugging carbonlib, and all of the applications break into macsbug with "errors" of some sort, but so do some apps that don't have the problem. It seemed to be looking for things that don't exist, but which are presumably weak-loaded (clearly the application normally "runs" with the supposed "problems"). I believe I also tried using the 9.1 gpchs rather than the 9.2a whatever gpchs and that didn't help. You might want to try that in case I am remembering wrong. I would use the system file from your last test if possible.

What your work has verified at least for me is that it's something in the code itself and not the patch method since you pretty much duplicated my results for that.

For the moment I have just worked around the problem. I save downloads and decompress them with stuffit's contextual menu item (which doesn't have the problem). Also, stuffit expander 5.5 seems to be OK and will do most things, but you probably have to delete the 6.x copy or fiddle with the way things appear in the desktop database to get Netscape or whatever to run it rather than the 6.x copy even though the name is different. I don't look at that many pdfs, but when I do I either just close down everything before exitting acrobat and deal with the crash. I might try using GSViewer at some point to look at ones, as well. This is clearly not ideal, but until I or someone else figures out more, this has been the best I could do. As I said before I think this showed up with 9.2.1, and obviously didn't get any better with 9.2.2 (but I don't think any worse, either). What is odd is that I was sure it worked OK initially upon doing 9.2.1, but since then apps have been updated and so forth in the hopes of fixing the problem (but only HexEdit seems to have actually been "fixed"--but I thought it was OK for some time as well and then didn't work and now does). I'm sorry I can't come up with anything better at this point.

Another oddity I note is that AppleSystemProfiler doesn't show the firewire ports--but there seem to be issues with both it and firewire (but not this particular one that I can tell) that are even in "vanilla" 9.2.x, as well as in the patched version, so I'm not convinced the problem is with the old code interfacing with the new per se (for our class of machines there really isn't any "patched" code--just a bunch of old code existing for which no new version exists).-kby

Edited by kby on 02/11/02 10:50 AM.

Thanks--this was helpful. I agree that using the FW things isn't the issue. Removing all the devices once seemed to help but I think it was just a fluke of the timing. It's the presence of firewire support at all that seems the issue. It appears not to be vendor specific, since the three of us have all different cards. You might want to read the other reply I just posted as it has other info. In the future I will probably reply to one or the other but only once to save space and time, if the answer is "general."-kby

Hello kby ... few more pieces of data ...

On occasion the "finder quits" would precipitate an outright freeze; When rebooted the drive which had 9.2.2 would not mount. I used SCSI probe to detect, and mount it ...
On those occasions the computer would boot from my other internal drive (I have two scsi IBM internal drives), one that actually has 9.1 installed on it.

Finaly on one such occasion after a finder quit I could not remount the drive with 9.2.2 on it at all, even with scsi probe. This forced me to abandon (for now) 9.2.2. I had to
boot from a CD and then reformat the drive wiht OS 9.2.2 ...

I also attached my firewire drive to an iMAC DV SE (1999)
running OS 9.2.2 (and OS X) and found that the drive worked perfectly. No finder quits and it worked at (predictably) higher transfer rates then the PCI mediated firewire cards.

Here I wonder whether the firewire issue may be related to the PCI slot given that no finder quits were noted when running same drive on iMAC. Admittedly I do not have the same applications on iMAC and the S900.

Did you try running firewire device with OS 9.1 firewire extensions (version 2.7) ?

Hope we'll find an answer.

Thanks for all your hard work ... it is appreciated

RogueB

I tried older FireWire versions. Last night, I checked some of the loose ends that have been mentioned in the past:

1. Tried to add back the 2 gpchs Scott proposed being removed since they were removed for the beige G3.

2. Tried to use gpch 750 and 752 from 9.1 instead of 9.2a4.

Neither of these changed. I've tried to send e-mail to kenny asking why only 750 and 752 were taken from 9.2a4 (although it may be that only these are needed on the 7300-9600 series that these were originally designed around--need to check that myself--or that they may be the only ones that were different from 9.1), and if there's any chance of a later 9.2 beta.

The best test, but one which I can't run is to find a beige G3 and put similar hardware on it. My suspect is it may fail in even those cases, or if I could get it to work there it would be possible to get it to not fail here.

Partially I'm waiting to see if 9.3 will fix it (and not be worse for other things). I feel it's quite possible (although by no means clear) that it's a 9.2.x bug that has nothing to do with the old world stuff other than the higher liklihood of certain older combinations of hardware (e.g. fw PCI add-in cards)--the beige G3 would be the key test here in eliminating that. Ideally I'd take my modified file (which shouldn't act any different for a beige G3 from the distribution) and try that.

I also have not tried keeping the software installed but removing the hardware--that's more of a pain to do and risks more irrepairable damgage--to see if it influences anything. Like I said earlier though, I think that FW and maybe VM as you mentioned exacerbates the problem but probably isn't the problem itself. The other thing I remember after my last post that I also noticed was it seems to be one of the millions of WaitNextEvent patches, of which the FW software includes one (but it doesn't seem to do much if you read the code and breakpointing didn't yield useful results--made the problem go away if you tried to single-step, etc.; hence the other feeling of a timing dependence).

I don't think this is Scott's problem as I have this but not the AppleWorks 5 issue on the same machine.

Was your disk damage bad enough that something like DiskWarrior couldn't fix it? I suspect that the fact that the damage was severe enough to 'need' reformatting was more due to timing--or, depending on how often you check your disks after crashes, cumulative bad timing of crashes and hits on the file structure. It is also possible it's a driver issue--do you use FWB and if so which version?-kby

I finally got back to OS9.2.2 on my 9600/G4-450 Powerlogix and all 4G of audio and video apps are running solid. I had to go back to PowerDomain Control 3 to get things working and leave the folder locations the way OS9.1 sets them up.

As to the finder crash (and crashes in general) many were memory related, since I'm running 1.5G of RAM, I checked out the "About This Computer" to see what was happening since I had lots of memory allocated to files/applications; low and behold (holy [censored]) my OS9.2.2 was using 1.49G of memory!!!!...nothing left for the apps. This happened randomly and often. I trashed the memory preferences, increased memory to the finder and things have been very stabile since.

It appears as stabile as OS9.1 and I'm looking forward to loading FCP 3 on it and see how it goes. FCP 3 was the only reason I went through all of this. Thanks Apple ( not really...grrr, they deserve this recent "built in obselence" lawsuit as far as I'm concerned)

My system: 9600/G4-450 Powerlogix, Adaptec 3940UW, Nexus 128 & Exclaim3D, Dual AppleVision 850's, CompUSA Firewire/USB combo card (Lucent chip), Korg 1212, Astra 1220S and Sprintscan 35Plus scanners, ext. ZIP, Yamaha 16x10x40 SCSI CD-RW, Epson Photo EX, 1270, and Apple Personal 320 Laserwriter printers. All working perfectly. The latest Firewire drivers are installed for Media 100 Cinestream 3.01 & Moto/Photo DV.

Install summary: I set up my OS9.1 system with apps in designated folder (OS9 apps folder). Then ran the OS9.2.1 update using MachWannabe (#510) using a custom install of only the core system and utilities. Finally, ran the patched OS9.2.2 installer and updated some apps, like Techtool Pro to their compatible 9.2.2 versions. For safety, I duplicated the entire volume/drive to another for back-up while it was clean using Retrospect. So far everything is rock solid after a couple of days.

Forgive the long post but I figured there were others who could benefit from knowing the total configuration.

Marshmellow

OK, I have a shot in the dark to try (well, not quite the dark). I went over the old work and in Scott's original list of gpch's needed, one that's listed is #246 (decimal). It is true this is referenced in at least gtbl 26 (and probably others--didn't check yet). And it's true it isn't in 9.2.x system files. However, it's also referenced in the beige G3 gtbl (gtbl #46), so it's in theory not needed on that machine either. I seem to recall that the code in boot 3 is resilient enough to just jump over entries that don't exist (tries to get the resource, fails, then goes on). However, we all put gpch #246 back in, so my theory is to try and pull it. Note that the correct thing from the coding point of view is to change gtbl as well as pull the resource, probably, unless it's called elsewhere (unlikely). I will try pulling it later tonight, but I may not get time to try this out as I'm fairly busy tonight, so I'm posting it here. If you want to be on the safe side, wait until I post results one way or the other in the next couple of days.-kby

Alas, this doesn't help this particular problem. I'll probably run thi way for a while though to see if there's any noticable difference.

Edited by kby on 02/12/02 06:30 PM.

Short test report

I pulled gpch #246 from my "OW resc 9.2a4" patched system and had no problem to boot (FW disabled, gtbl unchanged)).
Then I enabled the FW extensions, rebooted, and the "quit finder" symptom was back.

I looked at gpch 246 and it appears to have ties to cursor routines and power management (gestalt for 'pwrv': power manager version; GetTrapAddress calls for SetCursor and SetCCursor).-kby

Hello KBY ..

re: HD drivers- they are apple drivers; I have no other utility as far as HD is concerned. I do have
intech's CD/DVD toolkit v5.7 strictly for CD rom operations.

Disk warrior did not recognize the drive once it was "gone" from the desktop. However, when I booted from Disk Warrior
CD (v2.0) all drives mounted properly (note that DW v2.0 boots from OS 9.0.0).

I reinstalled OS 9.2.2 on one of my drives: instant quits
when operating acrobat, expander, RealBasic CARBON version.

I then used Res Edit to increase finder memory allocation, but quits continued. I then disabled VM and quits disappeared. However just before I disabled VM, I used res edit to look the "size" resource in the finder. I clicked on the "size" icon and got the resource numbers. I highlighted
the line with the two numbers and selected "resource info"
from the menu. I activated purgeable, protected, and preload
functions. I have had NO quits since then (note that VM is still off) .. this may be a fluke .. but no matter which application I run (acrobat, RealBAsic carbon or expander) I no longer get quits. Again this may be temporary ... so I'll run it as much as possible and see if the problem returns

Note, that I have FW extension enabled and so far saw no problems

Hope this helps ...

Thanks, RogueB