On Mon, 2003-06-30 21:24:46 -0400, Tyson Whitehead <twhitehe@uwo.ca>
wrote in message <[🔎] 200306302124.47099.twhitehe@uwo.ca>:
> On June 30, 2003 12:36, Joerg Hoh wrote:
> > alpha:~# cat /proc/srm_environment/named_variables/auto_action
> > BOOT
> > alpha:~# echo "BOOT" > /proc/srm_environment/named_variables/auto_action
> >
> > the machine doesn't come back to the prompt; on the serial terminal I get
> > this:
>
> Humm. I've tried it on a few different PW500a in our lab. Some of them take
> a long time before they come back (5min). Some come back right away (1s).
Time depends on how fast SRM can physically store your variabled in
non-volatile memory.
> The only time I locked on up was when I did:
>
> cat /proc/srm_environment/named_variales/boot_dev \
> /proc/srm_environment/named_variables/bootdef_dev
>
> I assume this causes a deadlock in the module?
Hmmm. I never did that when developing that module. I'll try that.
> I noticed that if you set stuff in the SRM environment, it doesn't add in a
> newline. One of our lab machines complains if you try and set any SRM
> variables with a newline on the end (the other ones don't seem to care).
SRM stores any variables without a newline. After all, there *are*
variables which (in theory) could sensefull hold an additional \n so I
decided on presenting the values as-is, with no newline at their end.
> Maybe you should try:
>
> echo -n "BOOT" > /proc/srm_environment/named_variables/auto_action
That should do. Generally, I need to do some work on the module. During
2.5.x, it got modifies some times which broke it a bit (does still work,
but emits an error during operation and so on - that's not nice...).
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg
fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak!
ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));
Attachment:
pgpySGuUyM9NG.pgp
Description: PGP signature