Debian on VirtualBox. Easy-peasy.

Post #309,566 by Another Scott 6/11/09 12:46:49 AM Reply	Debian on VirtualBox. Easy-peasy. I've got a little Win32 simulation program that spawns a gnuplot session for plotting. For some reason, it won't run on my 2.5 GHz dual-core T61 laptop running XP. It throws an error on startup saying it can't communicate with the gnuplot session. :-/ It runs fine on Kubuntu on WINE on my P7120D, and runs fine on my 2.2 GHz dual core Opteron system running Win2k, so maybe it's related to the speed of this system, or something. After trying to debug it for a while, I decided to install Sun's VirtualBox and install Debian 5.01 on it. It was easy. I'm posting with it now. Recommended. :-) Now, I just have to figure out how to access the NTFS partition and I'll be good to go (probably after installing WINE). Cheers, Scott.
Post #309,568 by folkert 6/11/09 9:21:30 AM Reply	Re: Debian on VirtualBox. Easy-peasy. hmmm FUSE and other stuff for NTFS works wonders nowaday, especially with Lenny.
Post #309,589 by Another Scott 6/11/09 11:07:25 PM Reply	Thanks. Is that needed in addition to the "net use ..." stuff that's mentioned in the Shared Folder settings of VirtualBox? I'm beginning to think my T61 has a hardware problem. I've got a Borland C++ program that does heavy number crunching for hours (smoothing lots of data) and it's hanging on the T61 while it runs fine on all my other machines that I've tested it on. It shouldn't care about how fast the processor is (other than faster being better), so I don't understand why it is having issues... :-( I'll run Memtest86 overnight on it and see if it finds anything. Cheers, Scott.
Post #309,590 by folkert 6/12/09 12:26:35 AM Reply	Re: Thanks. If anything is going to make a 'puter puke its a compiler. Also, how new is it? Reason I ask... some compilers do not recognize or mis-recognize the processors and sometimes don't use the right optimizations for the compiler. Case in point, Oracle is known for having issues with NEWNEW* processors that weren't in the pipeline when the Java installer and runtimes where put together. I've also seen issues with other C++ and C compilers that don't quite understand the machines past "i686". You might want to get an update on the compiler (binary patchset typically) and get the stuff updated. If you can re-compile that is. If not... it might just be the wrong optimizations (or workarounds for bad Intel Chips still active on good processors)... Bleah, please remember, a great test is to compile a current Linux Kernel with GCC and load a "known config" from /boot/config-something... if it fails there, then you might have a bad piece of hardware Too bad Borland is basically no more. Great company gone south ...
Post #309,591 by Another Scott 6/12/09 12:42:03 AM Reply	It's a binary made with Borland C++ Builder 5. I'll have to check, but I don't think it's doing anything more than 386 optimizations. The other program that has trouble communicating with gnuplot I only have as a binary, and I think a MS compiler was used for it. It was built around 2004. I have a copy of Builder 6, but it is different enough in compiling our code that it was decided not to do the upgrade. The errors and warnings thrown up compiling the code with 6 may be indicative of real issues, but since it works fine on almost all of our machines, well... So far Memtest86 hasn't found any errors with the Standard memory tests on the T61. It throws up errors if I tell it to test All the RAM, rather than only that IDed by the BIOS. Dunno if that's meaningful though... Oh well, I'll probably just live with it and slowly migrate the BC++ code to Python, and use the problematic binaries on machines that don't have trouble with it. It does give me pause to think about a new fast laptop, though... Thanks. Cheers, Scott.
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!