I'm trying to use Wine to run a program called heavy weather - its a windows only program that interfaces with a weather station that I have through a serial port. I was able to get the program up and running with wine. Then, I couldn't get it to connect at all to the weather station. After much too long, I finally realized that the problem was that my permissions on /dev/ttyS0 were too restrictive - I change them, and now the program connects up, and pulls in data. The next problem, however, is that as soon as I start the program, the system load starts to skyrocket. 5, 6, 7... and climbing. Soon, the mouse starts to become jerky, and its hard to change windows. Within about 2 minutes, the mouse doesn't work at all, and remote terminals stop responding. The system load is up in the 40s. As soon as I unplug the serial cable, everything goes back to normal. Here is some information that is being kicked out to the command line: fixme:comm:SetupComm insize 1298 outsize 1298 unimplemented stub err:ntdll:RtlpWaitForCriticalSection section 0x5204ac84 "loader.c: loader_section" wait timed out in thread 0025, blocked by 0024, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x685f8f58 "?" wait timed out in thread 000a, blocked by 0009, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x685f8f58 "?" wait timed out in thread 000a, blocked by 0009, retrying (60 sec) And that error continues until I unplug the serial port. Any suggestions? Why is this serial port traffic bringing the entire system down? Its not a very fast computer, but, this it shouldn't take much processing power for this... Thanks, Dan
In article <mailman.94.1146347414.7241.wine-users@winehq.org> you wrote:> The next problem, however, is that as soon as I start the program, the > system load starts to skyrocket. 5, 6, 7... and climbing. Soon, the > mouse starts to become jerky, and its hard to change windows. Within > about 2 minutes, the mouse doesn't work at all, and remote terminals > stop responding. The system load is up in the 40s.Could you check in what part of the system the processing power is mostly spent? I.e. user/system/waiting...> fixme:comm:SetupComm insize 1298 outsize 1298 unimplemented stub > err:ntdll:RtlpWaitForCriticalSection section 0x5204ac84 "loader.c: > loader_section" wait timed out in thread 0025, blocked by 0024, > retrying (60 sec) > err:ntdll:RtlpWaitForCriticalSection section 0x685f8f58 "?" wait timed > out in thread 000a, blocked by 0009, retrying (60 sec) > err:ntdll:RtlpWaitForCriticalSection section 0x685f8f58 "?" wait timed > out in thread 000a, blocked by 0009, retrying (60 sec)Those RtlpWaitForCriticalection are signs of a race condition, usually caused by the fact that wine sometimes has to go about things in a rather roundabout way. It could for example be that your program uses one thread to read the serial port and another for the main program. Now if those two threads are competing for a lock/semaphore/whatever the result could be what you are seeing. Another possibility is that some other program is trying to read from ttyS0 as well. Daniel> > > And that error continues until I unplug the serial port. > > Any suggestions? Why is this serial port traffic bringing the entire > system down? Its not a very fast computer, but, this it shouldn't > take much processing power for this... > > Thanks, > > Dan >
>>>>> "Dan" == Dan Armbrust <daniel.armbrust.list@gmail.com> writes:Dan> I'm trying to use Wine to run a program called heavy weather - its Dan> a windows only program that interfaces with a weather station that Dan> I have through a serial port. Dan> I was able to get the program up and running with wine. Then, I Dan> couldn't get it to connect at all to the weather station. Dan> After much too long, I finally realized that the problem was that Dan> my permissions on /dev/ttyS0 were too restrictive - I change them, Dan> and now the program connects up, and pulls in data. Dan> The next problem, however, is that as soon as I start the program, Dan> the system load starts to skyrocket. 5, 6, 7... and climbing. Dan> Soon, the mouse starts to become jerky, and its hard to change Dan> windows. Within about 2 minutes, the mouse doesn't work at all, Dan> and remote terminals stop responding. The system load is up in the Dan> 40s. Dan> As soon as I unplug the serial cable, everything goes back to Dan> normal. Dan> Here is some information that is being kicked out to the command Dan> line: Are you using a recent wine version? There was a leak in my patches, causing a flood of processes. -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
> > Are you using a recent wine version? There was a leak in my patches, causing > a flood of processes.I just installed 0.9.2 from RPM. Do I need to be newer than RPM? Thanks, Dan -- **************************** Daniel Armbrust Biomedical Informatics Mayo Clinic Rochester daniel.armbrust(at)mayo.edu http://informatics.mayo.edu/
Dan Armbrust <daniel.armbrust.list@gmail.com> wrote:> fixme:comm:SetupComm insize 1298 outsize 1298 unimplemented stubMaybe this stub (function exists, but does nothing) is causing you problems.> So, it looks like after it calls getModemStatus, its getting back a > status that it doesn't like: > trace:comm:Comm_CheckEvents OUTQUEUE 0, Transmitter not emptyThis is not necessarily a bad thing, could just be a status report.> Any ideas on where this is coming from? I did have this thing > connected at one point last week (which gave me the error that I > started this thead for) but now I can't even get back to that point.Did you use wine-0.9.12 last week, too? Daniel
Dan Armbrust <daniel.armbrust.list@gmail.com> wrote:> Restarted the machine, ran my app, and boom - it connects up, and pulls in data. > > Now, I'm back on-topic for this thread - the machine load still > spirals out of control when it runs. > > Here is the last capture from top that I was able to get (this is > after the program had been running for a couple of minutes) > > top - 18:28:57 up 12 min, 2 users, load average: 27.42, 14.38, 6.40 > Tasks: 98 total, 14 running, 84 sleeping, 0 stopped, 0 zombie > Cpu(s): 27.8% us, 72.2% sy, 0.0% ni, 0.0% id, 0.0% wa, 0.0% hi, 0.0% si > Mem: 256064k total, 253268k used, 2796k free, 16544k buffers > Swap: 522104k total, 0k used, 522104k free, 113640k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 5916 vortex 16 0 1573m 13m 7448 S 55.4 5.5 2:05.46 heavy weather.e > 5919 vortex 15 0 25248 21m 748 R 46.4 8.5 1:31.39 wineserver > 4687 root 18 0 9340 5192 1896 R 0.2 2.0 0:01.78 perl > 4683 root 16 0 9712 4640 1828 S 0.1 1.8 0:01.17 perlOk, I guess that you only pasted the first lines. What is a little confusing is your high load. Not only do wineserver and Heavy Weather eat up all of the CPU, there also are some 20 other apps competing for it. Either the first two are hogging the CPU so much that everything else has to wait, or wine spawned a lot of children; my guess is on the first option. What is the output of 'setserial -a /dev/ttyS0'?> And here is the output that I got from the launch of the app: > > wine heavy\ weather.exe > fixme:win:EnumDisplayDevicesW ((null),0,0x7bbbf7f4,0x00000000), stub! > fixme:win:EnumDisplayDevicesW ((null),1,0x7bbbf7f4,0x00000000), stub! > fixme:win:EnumDisplayDevicesW ((null),0,0x7bbbf7f4,0x00000000), stub! > fixme:win:EnumDisplayDevicesW ((null),1,0x7bbbf7f4,0x00000000), stub! > fixme:comm:SetupComm insize 1298 outsize 1298 unimplemented stub > fixme:comm:SetupComm insize 1298 outsize 1298 unimplemented stub > err:ntdll:RtlpWaitForCriticalSection section 0x685f8f58 "?" wait timed > out in thread 0059, blocked by 0009, retrying (60 sec) > err:ntdll:RtlpWaitForCriticalSection section 0x685f8f58 "?" wait timed > out in thread 000c, blocked by 0009, retrying (60 sec) > err:ntdll:RtlpWaitForCriticalSection section 0x685f8f58 "?" wait timed > out in thread 000c, blocked by 0009, retrying (60 sec) > err:ntdll:RtlpWaitForCriticalSection section 0x685f8f58 "?" wait timed > out in thread 000c, blocked by 0009, retrying (60 sec)Not surprising given the above top listing. Daniel
Dan Armbrust <daniel.armbrust.list@gmail.com> wrote: ...> Its very possible that this app could just be very poorly written... I > haven't been real impressed with it. But if there is anything else I > can do to make it run better, that would be great.It can also be that my WaitCommEvent Implementation in kernel/comm.c is poorly written. For every WaitCommEvent call of the application, a thread is created if the condition is no met immediate. Can you run a relay log and count how many WaitCommEvent calls the application does? Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de> wrote:> It can also be that my WaitCommEvent Implementation in kernel/comm.c is > poorly written. For every WaitCommEvent call of the application, a thread > is created if the condition is no met immediate. Can you run a relay log andA thread for every call? That would be a very good explanation for the extremly high load. Daniel
If u have Gnome System Monitor installed, u can display a %cpu column, and list processes in descending order of cpu usage by clicking the %cpu column heading. It will show u the process name, PID, cpu time, children, and arguments of each process. Jonathan
Daniel Skorka <skorka@gmx.net> wrote:> Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de> wrote: > > It can also be that my WaitCommEvent Implementation in kernel/comm.c is > > poorly written. For every WaitCommEvent call of the application, a thread > > is created if the condition is no met immediate. Can you run a relay log and> A thread for every call? That would be a very good explanation for the > extremly high load.Any better idea to implement the task? -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------