No RAM errors after 9 cycles.

Post #309,596 by Another Scott 6/12/09 8:43:32 AM Reply	No RAM errors after 9 cycles. That makes sense, because even when the program hangs (the GUI becomes unresponsive - I don't know if it continues working) the system as a whole continues to run Ok. I'll look around and see if there's a SpeedStep utility or the like that lets me slow the CPU down. Perhaps just running the clock slower will help... (I've tried a couple of "Compatibility" settings in XP, but they didn't have any effect.) Cheers, Scott.
Post #309,606 by folkert 6/12/09 11:10:09 AM Reply	Re: No RAM errors after 9 cycles. Unplug the machine and run it on battery power for a bit to see if it fails or what have you. Yes, I know it'll be slower... but that is the point. And, if you want, you might be able to get it to run under Wine on your T61. And GFREQlet seems to be able to slow down my laptop whenever I want it to. Of course mine is only Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz (actually 2201MHz)
Post #309,629 by Another Scott 6/12/09 6:52:15 PM Reply	Thanks again. It would be nice if Wine ran on Winders, but I guess it's not there yet. ;-) This T61 has a 2.5 GHz T9300. Memtest86 said it was running at 2.7 GHz, but I don't believe that. I'll mess around with it some more this weekend. If I have anything meaningful to report, I'll follow-up. Cheers, Scott.
Post #309,632 by Another Scott 6/13/09 12:26:36 AM Reply	Seems to be a video and/or motherboard issue. The BC++ smoothing program will hang instantly on my T61 if it ever loses the focus. Even a popup help message thingy over it will cause it to hang. That seems to me to be an indication of a graphics driver problem. I just did a full ThinkVantage System Update (close to 1 GB of stuff including a new BIOS). It didn't help with the smoothing program - it still hangs the same way. I tried running it on the battery with maximum power saving settings turned on - it still hangs the same way. I tried turning off the video acceleration settings in winders - the same hang. I tried running the desktop at 800x600 rather than 1680x1050 - the same thing (but it didn't stay in 800x600 on rebooting). This T61 (6459CTO) has the nVidia Quadro NVS 140M and 4 GB of RAM is installed. It doesn't exactly match this situation, but it is worrying: http://www-307.ibm.c...ndocid=MIGR-69684 "Planar" is IBM-ese for "motherboard"... As I said earlier, I'll find a work-around - installing Win2k in a virtual machine if necessary. I may eventually ship it off to be worked on if it does actually have the problem mentioned in the link, with the hope that they don't make it worse... Cheers, Scott.
Post #309,633 by Another Scott 6/13/09 12:53:35 AM Reply	Maybe not... While the GUI stops being updated for my BC++ program, it does continue to run. When the calculation is done, the GUI updates properly. It's probably due to a stupid way that I release the GUI thread (yield) occasionally during the calculations (rather than learning how to do the calculation in a separate thread). On slower machines, it works fine. Here, something happens after the program loses focus that causes updates to stop. What matters is the calculations continue. I can live with that. So, there's probably not a hardware or driver issue with the T61, but a programming issue. Cheers, Scott. (Who hopes the simulation -> gnuplot program issue can be solved as easily.)
Post #309,639 by folkert 6/13/09 10:55:36 AM Reply	Hmmm... Sounds familiar... Programmers blaming hardware... hardware guys blaming the software devs for sloppy work... Same conundrum as has been forever.
Post #309,642 by Another Scott 6/13/09 11:26:20 AM Reply	"It always worked before, therefore it's not my fault." "Nothing bad has happened yet, therefore I'm Ok." http://xkcd.com/582/ :-) Cheers, Scott. (Who thinks that some programmers may have a lot of work upcoming - fixing old code to run on superfast CPUs.)
Post #310,233 by Another Scott 6/27/09 10:46:30 PM Reply	Application->ProcessMessages() http://www.borlandta...n+processmessages discusses a reasonable work-around without using threads. Cheers, Scott.
Post #310,237 by folkert 6/28/09 9:46:11 AM Reply	Re: Application->ProcessMessages() it looks like a matter of slowing it down a touch.
Post #310,238 by Another Scott 6/28/09 9:56:16 AM Reply	Sorta. It's a matter of letting go of the GUI message queue (or whatever the proper term is) so that the interface messages continue to flow in the OS properly. It's much less granular to do it this way than to add "sleep" messages which do nothing more than slow it down. As I understand it, anyway. :-) Cheers, Scott.

Welcome to IWETHEY!