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] |
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] |
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] |
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. > 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 |
Free forum by Nabble | Edit this page |