OnRxTimer called - any meaning?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

OnRxTimer called - any meaning?

Bill Schwab-2
Hi Blair,

A troublesome app went from being flaky to being _really_ unreliable: I'm
happily making the most of it.  Actually, this is the same app that lead to
the "dead timer thread" discussion.  It's back with a really bothersome
machine lockup.  The change has been a considerable expansion of its
mission; the serial I/O cable trunk that comes off of the machine is known
as "the octopus" if that helps :)

I'm on the second of two multi-port serial I/O cards from different vendors.
With the new card, the lockups have become less severe and more frequent.
Now I get a chance to interact with the machine after a disaster; before it
just froze and nothing would run.  I can still completely fry the machine by
killing the app after it locks; but, other apps can run up to that point,
including the SysInternals debug monitor.

One of the things that I've captured is a bunch of lines that read

           OnRxTimerCalled

Does that mean anything in/to Dolphin?  I'll put the same question to the
card vendor.

IIRC, you originally recommended that I move from Delay to another method of
passing time.  You fixed the VM bug so fast that I never needed to make that
change; this might be a good time to do it because I'd really like to get
this working.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: OnRxTimer called - any meaning?

Bill Schwab-2
Hi Blair,

It's interesting what one sees when opening a .vxd file.  One of the drivers
shipped with the board includes the string "OnRxTimer called".  I'll ask
them what it means, but, any suggestions you might have will still be much
appreciated.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: OnRxTimer called - any meaning?

Bill Schwab-2
In reply to this post by Bill Schwab-2
Blair,

> IIRC, you originally recommended that I move from Delay to another method
of
> passing time.  You fixed the VM bug so fast that I never needed to make
that
> change; this might be a good time to do it because I'd really like to get
> this working.

The "OnRxTimer called" messages (which appear to have been coming from the
device driver for the card - unless you tell me otherwise) got me thinking
abouit MM timers.  The last time we had troubles with this app, I didn't
want to change away from Delay in part to avoid masking the problem we were
trying to fix; this time, it seemed harmless to try KernalLibrary>>sleep:.
There were only a few app-specific uses of Delay (but they executed MANY
times), so it was easy to make the change.

Doing that gave me an app that crashed - quickly!  It also left behind dumps
:)   The dump looked the same each time, complaining about a particular
connection which wasn't actually hooked up to its monitor.  It wasn't as
simple as an empty/nil problem though.  The code was reboiled from a while
ago, and it contained a Processor yield; it appears that the #yield was
clobbering it.  It's fairly obvious that it was causing the super-fast
crashes, because it's been up for >20 minutes now, which would be
unprecedented an hour ago.  Now we wait to see if the thing holds up for
hours/days/weeks.  Today, I'll gladly settle for hours.

The #yield in this case was no longer needed, if it ever was necessary.
However, I'm somewhat surprised to see the unpleasant reaction to it.  Could
there be something about overlapped calls (which are now the basis of the
time delays) that doesn't agree with #yield?

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: OnRxTimer called - any meaning?

Blair McGlashan
Bill

You wrote in message news:8ttttq$7gea$[hidden email]...

[Re: overlapped KernelLibrary>>sleep:]

> Doing that gave me an app that crashed - quickly!  It also left behind
dumps

> :)   The dump looked the same each time, complaining about a particular
> connection which wasn't actually hooked up to its monitor.  It wasn't as
> simple as an empty/nil problem though.  The code was reboiled from a while
> ago, and it contained a Processor yield; it appears that the #yield was
> clobbering it.  It's fairly obvious that it was causing the super-fast
> crashes, because it's been up for >20 minutes now, which would be
> unprecedented an hour ago.  Now we wait to see if the thing holds up for
> hours/days/weeks.  Today, I'll gladly settle for hours.
>
> The #yield in this case was no longer needed, if it ever was necessary.
> However, I'm somewhat surprised to see the unpleasant reaction to it.
Could
> there be something about overlapped calls (which are now the basis of the
> time delays) that doesn't agree with #yield?

I don't think so, but of course it is always possible there is a bug. One
thing to be aware of is that one mustn't issue overlapped calls from the
idle process (or do anything that blocks the idle process), because that
will cause an "idle panic" interrupt from the VM when it finds it has no
processes to run, the response to which is to start a new idle AND main
process. This can rapidly degenerate if one inserts KernelLibrary>>sleep:
calls into the idle loop, which is why Delay doesn't use sleep, even though
it would simplify Delay's implementation considerably.

Regards

Blair