PowerBook 540c Restoration Project

[croissantking]

Yeah, I did, I had to back off on the overclock.

 

[LaPorta]

Yes, that is totally normal afterdark behavior on a PowerBook. Always has been. One wonders why you need a screensaver on an LCD to begin with

 

[croissantking]

They're fun to look at.

 

[jmacz]

Haha yeah. Just for fun.

 

[jmacz]

Got bit by the drive spin down issue again.

Realized when I changed OS's, I knocked out the power setting to never allow the hard drive to spin down. Disabled the spin down again and left it running for a while. No lock ups.

If this holds after a while, I guess I'll try overclocking the CPU again.

 

[jmacz]

So my lock up issue, been playing around some more with the "spin down hard disk" setting set to 1 minute. Once the drive spins down, accessing anything on disk that has not been recently accessed causes the "lock up". But it's not a permanent lock up. I wasn't patient enough before. I decided to see what happens if I leave it and eventually it does come back. I timed it and it looks like it comes back after about a little over 3 minutes of being stuck.

When I get a chance I will take a look at the ZuluSCSI code and see how it handles spin downs / spin ups, but looks like something's either wrong with my machine or wrong in the interaction with the ZuluSCSI but it hangs on spin up for 3+ minutes.

If I disable the hard drive spin down setting, I am not seeing lock ups anymore.

 

[jmacz]

Oh, and this reminds me, when I played with this last year, with a normal spinning disk installed, I did not get lock ups on spin down / spin up.

 

[jmacz]

Some more notes after debugging.

Looks like the Powerbook cuts the power (both +5V and +12V) to the hard drive when it spins down. Figured this out when I saw that the issue doesn't occur if I have a USB cable (for serial debugging) plugged into the ZuluSCSI (since that cable continues to power the board). After power is provided back to the board, the system is stuck for exactly 3 minutes (180 seconds) before it unfreezes. During this time, I saw that the ZuluSCSI is not getting any SCSI commands from the Powerbook until exactly 180 seconds later.

I was looking at the System 7 source code that ZigZagJoe sent me a link to, and it's the system software cutting the power so this isn't a PowerBook specific thing.

Not sure if it's just my machine or others have it as well, but again, after coming out of spin down and power is restored, looks like the Powerbook or System isn't sending any SCSI commands for some time. Need to understand why.

I tried a few other settings that folks on IRC mentioned (EnableUnitAttention and InitPreDelay and InitPostDelay) but those didn't help.

I did confirm with the ZuluSCSI creator that the firmware for the ZuluSCSI hasn't implemented the Power Conditions handling or the Vital Product Data values (which include some values for spin up recovery time). I'm curious whether that might be causing System 7 to wait some default 180 seconds for proper spin up before continuing. If I can't figure it out, might have to try playing with the ZuluSCSI firmware code.

 

[jmacz]

The issue isn't with the power conditions handling or the vital product data, as none of the operations surrounding those are sent by the PowerBook/System 7.

The debugger shows that the PowerBook/System 7 is stuck waiting on a read operation to SCSI.

The debug logs from the ZuluSCSI shows that it's just sitting there waiting for commands from the PowerBook/System 7.

Looks like the cause is that upon power restoration, the PowerBook/System 7 within a short amount of time is sending the read request. But doesn't look like the ZuluSCSI is ready for it. Logs show that after power up, the earliest that the ZuluSCSI can take a SCSI command is around 1800ms. The read request from the PowerBook/System 7 must be coming in before that.

But once this read is missed, both sides (PowerBook and ZuluSCSI) are just sitting there waiting. There seems to be some watchdog timer in System 7 that triggers after 3 minutes after which everything works. Still need to fully prove all this but that's what it looks like right now.

Given the read request is missed, I can't obviously recreate it. But trying to see if there's a way to trigger a resend. But beyond that there's probably another issue which is detecting the case. Since the ZuluSCSI lost power, it will think it's a fresh power up. It has no way of knowing it missed any requests.

One known workaround - disable power down of the HD, which is what I have been doing.

But other workarounds: 1.) Write a system extension that knows the HD was powered down and upon power up, forces a delay of 2-3 seconds. 2.) Modify the ZuluSCSI firmware to somehow trigger a resend. I don't know enough about the SCSI specification - would need to read up on this. I have been modifying the firmware code and testing it out but need to understand the firmware code some more.

 

[croissantking]

Quite interesting. Nice sleuthing!

 

[finkmac]

oh yeah i remember having this issue with the 2.5" scsi2sds. i got it fixed by messing with the timing settings iirc but i can't remember which ones exactly.
maybe i should dump the config from the card in question....

 

[jmacz]

Yeah, I think someone mentioned to try the EnableUnitAttention setting and the InitPreDelay and InitPostDelay - to set those over 5-10 seconds - which helped or worked on the SCSI2SD but I tried and although they did take effect, it didn't help in my case.

I determined the block #s for the file I'm trying to access (post HD suspension) and then compared the instructions coming from the System when power is cut off to the ZuluSCSI as well as when the ZuluSCSI is powered using external USB power, and what I see is that once System 7 restores power to the ZuluSCSI, the READ request for those block #s is coming in within 500ms after power is restored.

But the ZuluSCSI is still coming up during that time period.. in fact the first polling I see from the ZuluSCSI and scsi state machine activity (busy, free, the various scsi phases, etc) is around 1800ms after power restoration. So the ZuluSCSI has entirely missed the read request and is just sitting there thinking that the scsi bus has no activity. At the same time, dropping into MacsBug on the PowerBook, System 7 is stuck on the read call. I haven't figured out yet which watchdog timer is firing but it's on the PowerBook/System 7 side, not on the ZuluSCSI. So after 180 seconds (3 minutes), I see a fresh new read request come in from the PowerBook/System 7 and things start working again.

I injected a scsi bus reset from the ZuluSCSI side while in this "stuck" state (drove the RST pin appropriately for 250ms which should be plenty) and that still didn't trigger any type of response from System 7, it remained stuck.

If you do remember and have more insight into how you resolved it, let me know.

Otherwise, I'm not sure anything can be done from the ZuluSCSI side.. if the observations I have made are true and also the PowerBook/System 7 won't respond to a bus reset, then I don't think any fix can be done on the ZuluSCSI side -- or maybe there's a better way to deal with a lost request in the specification?

I'm now thinking of making a patch on the System 7 side instead.

Of course, I can just leave the spin down turned off in the PowerBook control panel but somehow every so often that setting is reset and hit this issue again (on PRAM zap for example).

 

[jmacz]

Tried installing AfterDark (versions 2, 3, and 4). On my desktop machines, the animation from the screen savers (like Flying Toasters or Warp) is smooth and stays smooth indefinitely.

On my PowerBook 540c, the animation is smooth for around 15 seconds and after that it starts stuttering, some times gets stuck for long pauses before resuming. It's not just the animation but the sound effects too, they stop at the same time as the animation. If I break out of the screen saver and then go back in, it's fine again for about 15 seconds before stuttering. If I leave the screen saver on long enough (like 15+ minutes) in its stuttering state, when I break out of the screen saver, it redraws the Finder, and then is stuck there (mouse movement but nothing else) for a while and then eventually it seems to "catch up" with the events and all the mouse clicks/etc I had done while stuck fire off and then it resumes normal operation -- it's as if an event queue was stuck and events were piling up behind it.

All my 68k PowerBooks do this. I want to say it's something like processor cycling, but I'm not sure that's what it is because I think I have this disabled. It does seem like a feature though, or a side effect of a feature that might be to do with energy saving.

Yes, that is totally normal afterdark behavior on a PowerBook. Always has been. One wonders why you need a screensaver on an LCD to begin with

Yeah, so confirmed this is a "feature" on PowerBooks. The Power Manager has a notion of an "idle" state which is activated after 15 seconds of inactivity (matching my observation). The Power Manager via wait states drives the effective clock speed down to 1MHz when in the idle state reducing power consumption. This explains why I was seeing the screen saver slow down after 15 seconds.

 

[croissantking]

Yeah, so confirmed this is a "feature" on PowerBooks. The Power Manager has a notion of an "idle" state which is activated after 15 seconds of inactivity (matching my observation). The Power Manager via wait states drives the effective clock speed down to 1MHz when in the idle state reducing power consumption. This explains why I was seeing the screen saver slow down after 15 seconds.

Can it be turned off? Is it really necessary with the power adapter plugged in?

 

[jmacz]

Yeah, it does look like there are traps to turn it off. Working on something to add a wait on the spin up of the HD after power restoration so will take a look to see if it can also disable this thing if the power adapter is plugged in.

 

[jmacz]

Ok had some fun this weekend putting together an INIT to add a 2 second delay after the drive is powered back on. And it works.

Took a little longer than I expected as it was the first time I was patching an OS trap (as opposed to a Toolbox trap) and it didn't like the A4 setup and thus I had to code the patch in assembly in order to allow the A4 magic to work. I think it would have been easier in Symantec/Think C with inlined assembly as opposed to being limited to full assembly functions in CodeWarrior. Also took time to figure out what the Power Manager was doing and intercept the specific HD power on call. And then of course, had to add an icon and get it to show during boot up (which actually wasn't trivial). The other thing that was annoying was finding all the renamed constants (switched to CodeWarrior Pro 4 and various things were renamed).

Not well tested yet but it is working. The assembly is in 68K and I have only tested on my PB540c with the ZuluSCSI. Also tested on my Quadra 800 (to ensure it does not patch on that machine and shows an X'd icon on boot).



Might look into working on a Control Panel for turning off the idle mode on these PowerBooks (configurable). The logic would be simple as there's a trap specifically for it, but I haven't coded a CDEV in 30 years so need to page that all back in.

 

[croissantking]

Well done! This is a huge achievement - I’m very impressed.

 

[3lectr1cPPC]

This is awesome!!!! Send me a copy and I’ll test it on my PowerBook 170 which has this same issue.

 

[jmacz]

Attached v0.1.0... again, it's super early so might have some issues but I haven't encountered any so far on my PowerBook. Only works on 68K under Sys7 or newer (although only tested up to 7.5).

README included inside.

 

[3lectr1cPPC]

Didn't work on my PowerBook 170, still locks up. Running System 7.1. Are you able to test on a 68030?