Re: [Wine] Wine + serial port basically hangs system
Hallo, this is a thread from wine-users. I think further discussion of this issue is better done on wine-devel. In short, Dan Armbrust notices some application (heavy weather.exe) accessing the serial port causing a high system load. As the application uses WaitCommEvent, I fear that my implementation of WaitCommEvent is inappropriate. In my last posting, I ask Dan to count the calls to WaitcommEvent by counting the number of lines containing WaitCommEvent in a relay log. His results are:
"Dan" == Dan Armbrust <daniel.armbrust.list(a)gmail.com> writes:
Dan> I let the app run for about 2 minutes, at the standard priority - Dan> basically until the system was about ready to take a dive :) Dan> Data was coming in to the program and being displayed before I Dan> killed it. Dan> The count on WaitCommEvent was 15051 - so I guess we would have Dan> 7526 calls to WaitCommEvent in < 2 minutes. It probably took the Dan> first 30 seconds just to get the app up and running, so that was Dan> maybe 90 seconds of actually accessing the serial port. As Dan's machine is not a "big iron one", I guess these about 7500 thread creation/termination in about 90 seconds could explain the high system load. In the moment, my implementation of WaitCommEvent creates a thread in the context of the running program for every call. Any ideas how to do it better? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
As Dan's machine is not a "big iron one", I guess these about 7500 thread creation/termination in about 90 seconds could explain the high system load.
In the moment, my implementation of WaitCommEvent creates a thread in the context of the running program for every call. Any ideas how to do it better?
I'd think that creating that thread once per opened port (delayed until WaitCommEvent is called) would be better. The thread can be suspended and thus out of the way when it's not needed. Cheers, Kuba
Uwe Bonnes wrote:
Hallo,
this is a thread from wine-users. I think further discussion of this issue is better done on wine-devel.
In short, Dan Armbrust notices some application (heavy weather.exe) accessing the serial port causing a high system load. As the application uses WaitCommEvent, I fear that my implementation of WaitCommEvent is inappropriate. In my last posting, I ask Dan to count the calls to WaitcommEvent by counting the number of lines containing WaitCommEvent in a relay log. His results are:
the preferred way is of course to do the wait operation in the server (or at least the trigger in the server, and the handling of the trigger can be done on client side) A+ -- Eric Pouech
"Eric" == Eric Pouech <eric.pouech(a)wanadoo.fr> writes:
Eric> Uwe Bonnes wrote: >> Hallo, >> >> this is a thread from wine-users. I think further discussion of this >> issue is better done on wine-devel. >> >> In short, Dan Armbrust notices some application (heavy weather.exe) >> accessing the serial port causing a high system load. As the >> application uses WaitCommEvent, I fear that my implementation of >> WaitCommEvent is inappropriate. In my last posting, I ask Dan to >> count the calls to WaitcommEvent by counting the number of lines >> containing WaitCommEvent in a relay log. His results are: Eric> the preferred way is of course to do the wait operation in the Eric> server (or at least the trigger in the server, and the handling of Eric> the trigger can be done on client side) A+ But the server is always at the limit of capabilities. I don't feel like I am to implement that capabilities.. -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
On Tue, 2006-05-09 at 21:17 +0200, Eric Pouech wrote:
Uwe Bonnes wrote:
Hallo,
this is a thread from wine-users. I think further discussion of this issue is better done on wine-devel.
In short, Dan Armbrust notices some application (heavy weather.exe) accessing the serial port causing a high system load. As the application uses WaitCommEvent, I fear that my implementation of WaitCommEvent is inappropriate. In my last posting, I ask Dan to count the calls to WaitcommEvent by counting the number of lines containing WaitCommEvent in a relay log. His results are:
the preferred way is of course to do the wait operation in the server (or at least the trigger in the server, and the handling of the trigger can be done on client side) A+
This bug crept into between May 7 01:04 and May 11 00:48. It seems to happens when the program http://appdb.winehq.org/appview.php?appId=1957 attempts to initialize the serial port. I'll get more details later, and file a bug report if required. This is just a heads up. Thanks, Ron ALSA lib timer_hw.c:269:(snd_timer_hw_open) extended read is not supported (SNDRV_TIMER_IOCTL_TREAD) fixme:win:EnumDisplayDevicesW ((null),0,0x7fc3f7f0,0x00000000), stub! fixme:dciman:DCICreatePrimary 0x300 0x7e0c11fc fixme:comm:set_queue_size insize 1048 outsize 128 unimplemented stub wine: Unhandled page fault on write access to 0x00000000 at address 0x7bed0e84 (thread 0042), starting debugger... WineDbg starting on pid 0x41 Unhandled exception: page fault on write access to 0x00000000 in 32-bit code (0x7bed0e84). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:7bed0e84 ESP:7fc3e37c EBP:7fc3e594 EFLAGS:00010246( - 00 -RIZP1) EAX:00000000 EBX:7bef5244 ECX:00000000 EDX:00000000 ESI:0000001b EDI:00000000 Stack dump: 0x7fc3e37c: 7fc3e4d4 00000004 00000016 7fc3e3a0 0x7fc3e38c: b7eef8a9 00000000 7bed24dd 00000016 0x7fc3e39c: 7bef5244 7fc3e5c0 7bed072c 00000094 0x7fc3e3ac: 00000016 7fc3e5b0 00000000 7fc3e540 0x7fc3e3bc: 7fc3e4d0 00000016 7bef5244 7fc3e5e8 0x7fc3e3cc: 7bed072c 00000000 00000000 00000016 Backtrace: =>1 0x7bed0e84 COMM_DeviceIoControl+0x894(hDevice=0x94, hEvent=0x0, UserApcRoutine=0x0, UserApcContext=0x0, piosb=0x7fc3e698, dwIoControlCode=0x1b0020, lpInBuffer=0x0, nInBufferSize=0x0, lpOutBuffer=0x7fc3e6f4, nOutBufferSize=0x14) [/home/rjensen/src/wine/dlls/ntdll/serial.c:379] in ntdll (0x7bed0e84) 2 0x7beae217 NtDeviceIoControlFile+0x247(handle=0x94, event=0x0, apc=0x0, apc_context=0x0, io=0x7fc3e698, code=0x1b0020, in_buffer=0x0, in_size=0x0, out_buffer=0x7fc3e6f4, out_size=0x14) [/home/rjensen/src/wine/dlls/ntdll/file.c:886] in ntdll (0x7beae217) 3 0x7fce0fa6 DeviceIoControl+0x326(hDevice=0x94, dwIoControlCode=0x1b0020, lpvInBuffer=0x0, cbInBuffer=0x0, lpvOutBuffer=0x7fc3e6f4, cbOutBuffer=0x14, lpcbBytesReturned=0x0, lpOverlapped=0x0) [/home/rjensen/src/wine/dlls/kernel/vxd.c:384] in kernel32 (0x7fce0fa6) 4 0x7fc7c7fa GetCommTimeouts+0x6a(hComm=0x94, lptimeouts=0x7fc3e728) [/home/rjensen/src/wine/dlls/kernel/comm.c:1117] in kernel32 (0x7fc7c7fa) 5 0x10023f93 in hrmcom (+0x23f93) (0x10023f93) 0x7bed0e84 COMM_DeviceIoControl+0x894 [/home/rjensen/src/wine/dlls/ntdll/serial.c:379] in ntdll: movl % edi,0x0(%edx) 379 st->ReadIntervalTimeout = reply->readinterval; Modules: Module Address Debug info Name (90 modules) PE 0x00400000-00808000 Deferred polar 32 PE 0x10000000-10062000 Export hrmcom PE 0x20000000-20021000 Deferred dzip32 PE 0x30000000-3001c000 Deferred dunzip32 PE 0x70d00000-70e91000 Deferred gdiplus ELF 0x73712000-7371b000 Deferred libxrender.so.1 ELF 0x7be7e000-7bf00000 Stabs ntdll<elf> \-PE 0x7be90000-7bf00000 \ ntdll ELF 0x7bf00000-7bf03000 Deferred <wine-loader> ELF 0x7dcc6000-7dcda000 Deferred dciman32<elf> \-PE 0x7dcd0000-7dcda000 \ dciman32 ELF 0x7eabb000-7ead0000 Deferred midimap<elf> \-PE 0x7eac0000-7ead0000 \ midimap ELF 0x7ec08000-7ecbb000 Deferred libasound.so.2 ELF 0x7ecbb000-7ece4000 Deferred winealsa<elf> \-PE 0x7ecc0000-7ece4000 \ winealsa ELF 0x7ece4000-7ecf7000 Deferred libresolv.so.2 ELF 0x7ecf7000-7ecfd000 Deferred libnss_dns.so.2 ELF 0x7ed01000-7ed19000 Deferred msacm32<elf> \-PE 0x7ed10000-7ed19000 \ msacm32 ELF 0x7ed19000-7edfe000 Deferred libdb-4.3.so ELF 0x7edfe000-7ee4c000 Deferred libgcrypt.so.11 ELF 0x7ee4c000-7eeb4000 Deferred libgnutls.so.12 ELF 0x7eeb4000-7eed0000 Deferred libcups.so.2 ELF 0x7ef10000-7ef20000 Deferred libtasn1.so.2 ELF 0x7ef29000-7ef5b000 Deferred uxtheme<elf> \-PE 0x7ef30000-7ef5b000 \ uxtheme ELF 0x7ef5b000-7ef78000 Deferred ximcp.so.2 ELF 0x7ef78000-7f199000 Deferred r200_dri.so ELF 0x7f199000-7f1fc000 Deferred libgl.so.1 ELF 0x7f1fc000-7f2c7000 Deferred libx11.so.6 ELF 0x7f2c7000-7f2d5000 Deferred libxext.so.6 ELF 0x7f2d5000-7f2ed000 Deferred libice.so.6 ELF 0x7f2ed000-7f2f6000 Deferred libsm.so.6 ELF 0x7f2f6000-7f312000 Deferred imm32<elf> \-PE 0x7f300000-7f312000 \ imm32 ELF 0x7f312000-7f394000 Deferred winex11<elf> \-PE 0x7f320000-7f394000 \ winex11 ELF 0x7f394000-7f3b4000 Deferred libexpat.so.1 ELF 0x7f3b4000-7f3e3000 Deferred libfontconfig.so.1 ELF 0x7f3e3000-7f450000 Deferred libfreetype.so.6 PE 0x7f450000-7f470000 Deferred polarhrm ELF 0x7f478000-7f47d000 Deferred libnss_db.so.2 ELF 0x7f47d000-7f4a8000 Deferred ws2_32<elf> \-PE 0x7f490000-7f4a8000 \ ws2_32 ELF 0x7f4a8000-7f4c2000 Deferred wsock32<elf> \-PE 0x7f4b0000-7f4c2000 \ wsock32 ELF 0x7f4c2000-7f54b000 Deferred winmm<elf> \-PE 0x7f4d0000-7f54b000 \ winmm ELF 0x7f54b000-7f57a000 Deferred winspool<elf> \-PE 0x7f550000-7f57a000 \ winspool ELF 0x7f57a000-7f599000 Deferred iphlpapi<elf> \-PE 0x7f580000-7f599000 \ iphlpapi ELF 0x7f599000-7f5e7000 Deferred rpcrt4<elf> \-PE 0x7f5b0000-7f5e7000 \ rpcrt4 ELF 0x7f5e7000-7f680000 Deferred ole32<elf> \-PE 0x7f600000-7f680000 \ ole32 ELF 0x7f680000-7f6de000 Deferred shlwapi<elf> \-PE 0x7f690000-7f6de000 \ shlwapi ELF 0x7f6de000-7f7bf000 Deferred shell32<elf> \-PE 0x7f6f0000-7f7bf000 \ shell32 ELF 0x7f7bf000-7f861000 Deferred comdlg32<elf> \-PE 0x7f7d0000-7f861000 \ comdlg32 ELF 0x7f861000-7f8a4000 Deferred advapi32<elf> \-PE 0x7f870000-7f8a4000 \ advapi32 ELF 0x7f8a4000-7f936000 Deferred gdi32<elf> \-PE 0x7f8c0000-7f936000 \ gdi32 ELF 0x7f936000-7fa6a000 Deferred user32<elf> \-PE 0x7f950000-7fa6a000 \ user32 ELF 0x7fa6a000-7fb30000 Deferred comctl32<elf> \-PE 0x7fa70000-7fb30000 \ comctl32 ELF 0x7fc49000-7fd50000 Stabs kernel32<elf> \-PE 0x7fc60000-7fd50000 \ kernel32 ELF 0x7fe60000-7fe64000 Deferred libgpg-error.so.0 ELF 0x7fe64000-7fe6d000 Deferred libxcursor.so.1 ELF 0x7fe6d000-7fe79000 Deferred libnss_files.so.2 ELF 0x7fe79000-7fe83000 Deferred libnss_nis.so.2 ELF 0x7fe83000-7fe8c000 Deferred libnss_compat.so.2 ELF 0x7fe8c000-7fea0000 Deferred libz.so.1 ELF 0x7fea8000-7fece000 Deferred libm.so.6 ELF 0x7fed0000-7fee6000 Deferred libnsl.so.1 ELF 0x7feea000-7ffe0000 Deferred libwine_unicode.so.1 ELF 0xb7da9000-b7dad000 Deferred libdl.so.2 ELF 0xb7dad000-b7ee5000 Deferred libc.so.6 ELF 0xb7ee5000-b7ef8000 Deferred libpthread.so.0 ELF 0xb7ef8000-b7efb000 Deferred xlcdef.so.2 ELF 0xb7efb000-b7f00000 Deferred libxxf86vm.so.1 ELF 0xb7f10000-b7f14000 Deferred libxrandr.so.2 ELF 0xb7f14000-b7f2e000 Deferred libwine.so.1 ELF 0xb7f30000-b7f47000 Deferred ld-linux.so.2 Threads: process tid prio (all id:s are in hex) 00000041 (D) C:\Program Files\Polar\Polar 32.exe 00000043 0 00000042 0 <== 0000000a 0000000b 0 00000008 0000000c -2 00000009 0
This bug crept into between May 7 01:04 and May 11 00:48. It seems to happens when the program http://appdb.winehq.org/appview.php?appId=1957 attempts to initialize the serial port. I'll get more details later, and file a bug report if required. This is just a heads up.
just sent a fix for this one A+ -- Eric Pouech
On Fri, 2006-05-12 at 22:07 +0200, Eric Pouech wrote:
This bug crept into between May 7 01:04 and May 11 00:48. It seems to happens when the program http://appdb.winehq.org/appview.php?appId=1957 attempts to initialize the serial port. I'll get more details later, and file a bug report if required. This is just a heads up.
just sent a fix for this one
Thanks, that worked for me. The clipboard can be a dangerous tool if mis-used :) Ron
participants (4)
-
Eric Pouech -
Kuba Ober -
Ron Jensen -
Uwe Bonnes