*This message was transferred with a trial version of CommuniGate(tm) Pro*
First of all excuse me for my bad English and if the content of my=20
first post=A0:

I=92m trying to convert an old PowerMac 7600/120 in a Fax Server. I =
chose=20
to use NetBSD and Hylafax=85

Reading carefully many post I install NetBSD 2.0 on the machine without=20=

many trouble=85
I was working to install Hylafax and to tray to configure it.

But my actual problems was to be sure auto restart after a power failure

I=92m not certain, but on my machine the configuration on the=20
auto-restart function is not do in the PRAM (Zapping it don=92t change=20=

the configuration=A0!)
I read about about the penny solution=A0:

> hold down the power button on the keyboard, and then jam some pennies=20=

> and dimes in there to keep it held down after you walk away.  This is=20=

> tested and works reliably on a m68k Quadra, so hopefully other ADB=20
> machines will also work.=94

It=92s should works, and it=92s a good workaround but may be the will be =
a=20
more technical solution =85 I make many google search without success on=20=

the *bsd side, but i found some interesting things on the apple and=20
linux side=A0:

=95 an Apple technical Note TN1079: Power Management & Servers=A0: Auto=20=

Restart =46rom Power Failure=A0:=20
http://developer.apple.com/technotes/tn/tn1079.html

=95 Somme's links about =94 PmacPow=94 from Takashi Oe who send and Hex=20=

string to the Cuda ships to make him to automatically restart=20
http://ppc.linux.or.jp/~toe/#pmacpow (and many others)

=95 An interesting post of the YDL list=A0:
> Here's what I do on my home router:
> 1.  I created the 3-byte file /etc/powerup-boot containing exactly the=20=

> following hex sequence (no terminating null or newline):
> 0x011301
> The first 0x01 indicates this is a CUDA_PACKET (see <asm/adb.h>) since=20=

> the CUDA chip is responsible for power management among other things. =20=

> The 0x13 indicates the specific CUDA parameter being accessed or=20
> modified, and isn't even documented in <asm/cuda.h>, but by digging=20
> around in MOL, I figured out that  it was the CUDA_FILE_SERVER_FLAG=20
> parameter.  The second 0x01 indicates that this system is a file=20
> server (really any machine that has to stay up all the time), and so=20=

> if there is a power failure, when the power is restored, the CUDA chip=20=

> allows the power to be passed through to the main processor initiating=20=

> the boot sequence.
>
> I also created the 3-byte file /etc/powerup-off containing the hex=20
> sequence:
> 0x011300
> This file can be used to restore the system to the default powerup=20
> behavior following a power failure, namely to not automatically boot=20=

> up, requiring the user to turn on the power to the main processor to=20=

> initiate the boot process (this is the way I leave my primary home=20
> system set up since I'd rather not have it possibly damaged by=20
> multiple power fluctuations that might occur during a severe lightning=20=

> storm for example - better to just leave it off).
>
> 2.  At the end of my /etc/rc.d/rc.local file, I added the following=20
> line:
> cat /etc/powerup-boot >> /dev/adb
> The ADB device is used to access and control the CUDA chip. This=20
> command may actually only have to be done once rather than during=20
> every boot, but I haven't tested that, and it seemed safer to just=20
> redo it every boot.  I believe the power management settings are kept=20=

> in the PRAM so they should in theory be saved across reboots.
>
> 3.  I set the Open Firmware variable boot-command to:
> begin ['] boot catch 1000 ms cr again
> This allows the disk time to spin up, and retries the boot command=20
> after a second (I got this tidbit from one of the installation=20
> manuals).
>
> I figured out a lot of this by looking at Takashi Oe's pmacpow-tool=20
> source, which allows you to set the powerup time on a PowerMac (I was=20=

> too lazy to modify his source to add an option to set/clear the=20
> CUDA_FILE_SERVER_FLAG parameter, but it should be relatively easy to=20=

> do).
>
> To test this you have to be relatively brave and simulate a power=20
> failure by for example pulling the power cord (after doing a few sync=20=

> commands of course to flush the disk cache in memory out to the actual=20=

> disk).  After doing a graceful shutdown, the user still has to=20
> explicitly reapply power to the main processor by pressing the power=20=

> key.  I am using this on my home router (a 7500) and have also tested=20=

> it on my primary home system (a 6500) and it works fine on both these=20=

> systems.
>
> Some of this may be processor or model dependent, so YMMV.  And of=20
> course I assume absolutely no responsibility whatsoever for any=20
> negative impact on your system, so use this advice with appropriate=20
> caution (for example make sure to have a recent, validated system=20
> backup if concerned about data integrity before performing the power=20=

> failure test).
> 	-HTH
> 	-Bill Fink
> P.S.  The Power Saving Control Panel should also work fine I think=20
> since it should effectively be doing the same thing by setting the=20
> CUDA_FILE_SERVER_FLAG parameter in the PRAM.

=95 and finally a nice program for linux to configure all (auto-restart,=20=

start-up time =85) =94 cudamgr=94 from Michel Lanners
http://lists.debian.org/debian-powerpc/2002/09/msg00047.html
who seam=92s to do exactly what I (and many others) need.

But the problems is that I can=92t adapt it for the NetBSD platform=85 =
can=20
may be a NetBSD Geeks adapt it or may be have all ready do some think=20
in these way=A0?

Tanks

Gerard Grazzini