[Bug 29188] New: Serial Port Comm Failure for USB2Serial Converters?
http://bugs.winehq.org/show_bug.cgi?id=29188 Bug #: 29188 Summary: Serial Port Comm Failure for USB2Serial Converters? Product: Wine Version: 1.3.32 Platform: All OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll AssignedTo: wine-bugs(a)winehq.org ReportedBy: rogerx.oss(a)gmail.com Classification: Unclassified Created attachment 37657 --> http://bugs.winehq.org/attachment.cgi?id=37657 wine-serialfailure.log I have an application trying to communicate to a serial port provided by a USB to Serial Converter device (/dev/ttyUSB0). The application fails to communicate and I think the following is where it fails: trace:comm:io_control 0x78 IOCTL_SERIAL_WAIT_ON_MASK (nil) 0 0x90e9f0 4 0x90e9bc trace:comm:get_irq_info TIOCSERGETLSR err Invalid argument The application states it fails to communicate even though I have blinking lights on the device and can use picocom or screen to login. ie. $ picocom -b 115200 /dev/ttyUSB0 Or $ screen /dev/ttyUSB0 115200 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29188 Roger <rogerx.oss(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rogerx.oss(a)gmail.com -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29188 Dmitry Timoshkov <dmitry(a)baikal.ru> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|rogerx.oss(a)gmail.com | Component|ntdll |-unknown Platform|All |Other -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29188 --- Comment #1 from Roger <rogerx.oss(a)gmail.com> 2011-11-27 19:11:41 CST --- grepping through the Wine GIT, I'm only finding ifdef's for TIOCSERGETLSR and I cannot find the place where it's defined. How can I see if TIOCSERGETLSR is even getting defined? (Also noticing some commented-out ifdef TIOCSERGETLSR statements which might be interesting to see what happens if they're uncommented.) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29188 --- Comment #2 from Roger <rogerx.oss(a)gmail.com> 2011-11-27 19:25:23 CST --- Never mind. Found it's defined within the system's /usr/include "termios.h|ioctls.h|ioctl-types.h" files. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29188 --- Comment #3 from Roger <rogerx.oss(a)gmail.com> 2011-11-27 20:17:36 CST --- OK. I think TIOCSERGETLSR is technically undefined on my Gentoo distro because I see no files within /usr/include containing this except for: /usr/include/asm-generic/ioctls.h:#define TIOCSERGETLSR 0x5459 /* Get line status register */ Wine does pull in: checking linux/ioctl.h usability... yes checking linux/ioctl.h presence... yes checking for linux/ioctl.h... yes checking sys/ioctl.h usability... yes checking sys/ioctl.h presence... yes checking for sys/ioctl.h... yes ... none of which contain or define TIOCSERGETLSR. As such, USB2Serial adapters won't work. (Am I correct on this? If so, this points to autoconf/automake.) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29188 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |hardware --- Comment #4 from Austin English <austinenglish(a)gmail.com> 2013-12-05 20:24:57 CST --- Dmitry did some work recently on serial devices, could you please retest this in current (1.7.7 or newer) wine? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29188 --- Comment #5 from Roger <rogerx.oss(a)gmail.com> 2013-12-05 22:32:36 CST --- OK. Will need to setup the environment again sometime soon. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29188 --- Comment #6 from Bruno Jesus <00cpxxx(a)gmail.com> --- (In reply to Roger from comment #5)
OK. Will need to setup the environment again sometime soon.
If possible share a test project that reproduces the issue, I have a PL2303 and a CP2101 to test. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29188 --- Comment #7 from Roger <rogerx.oss(a)gmail.com> --- This bug is still present when using a usbserial (usb to serial) MCT U232 or a U232-P9 device. The following error is still persistent: fixme:comm:set_queue_size insize 4096 outsize 4096 unimplemented stub err:comm:stop_waiting failed to clear waiting state: 0xc0000008 To reproduce, attach a USB to serial (ie. DB9 pinout) device to your USB port. Plug the other end into a serial or DB9 device and try to utilize a win32 binary to communicate with the device. Upon changing the COM Port speeds within the win32 binary and repeatidly trying to communicate with the COM port, an exception now occurs with the following snipped backtrace: Unhandled exception: page fault on write access to 0x00a0e9b0 in 32-bit code (0x7bc7b20b). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:7bc7b20b ESP:00b0e8f0 EBP:00b0e988 EFLAGS:00010246( R- -- I Z- -P- ) EAX:00a0e9b0 EBX:7bcc7000 ECX:f7569000 EDX:00b0e8cc ESI:00164140 EDI:c0000008 Stack dump: 0x00b0e8f0: 00000000 00b0e948 00000000 000000a0 0x00b0e900: 00000000 00000000 00176c50 00110000 0x00b0e910: 00b0e930 7bcc7000 00b0e988 00164160 0x00b0e920: 00b0e948 00b0e93c 00a0e9b0 00b0e950 0x00b0e930: 00110060 0000000b 00000000 00000000 0x00b0e940: 000001a0 00000001 ffffd8f0 ffffffff 000c: sel=0067 base=00000000 limit=00000000 32-bit r-x Backtrace: =>0 0x7bc7b20b in ntdll (+0x6b20b) (0x00b0e988) 1 0x7bc8b1b0 in ntdll (+0x7b1af) (0x00b0e9f8) 2 0x7bc7f350 call_thread_func_wrapper+0xb() in ntdll (0x00b0ea18) 3 0x7bc8218d call_thread_func+0x7c() in ntdll (0x00b0eae8) 4 0x7bc7f32e RtlRaiseException+0x21() in ntdll (0x00b0eb08) 5 0x7bc88818 in ntdll (+0x78817) (0x00b0f358) 6 0xf7557005 in libpthread.so.0 (+0x8004) (0x00b0f428) 7 0xf74996fe __clone+0x5d() in libc.so.6 (0x00000000) 8 0xf74996fe __clone+0x5d() in libc.so.6 (0x00000000) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29188 --- Comment #8 from Roger <rogerx.oss(a)gmail.com> --- I should also note with this usbserial adapter, this MCT serial adapter has blinking red & green lights denoting RX/TX. If I'm not mistaken, I get four series of green (LINK) and red (RX) lights in what looks like an attempt to communicate with the DB9/COM linked device. Green is always lit until the red TX/RX lights light, so I see a green light, then a red RX light and then green link light blink. This occurs four times, until the above noted error occurs, and likely a timeout error. (The COM/DB9 device is probably being probed with an incorrect request. Wine might be only configured to communicate with other computers running a full terminal, already transmitting data?) The lights being green (LINK), red (TX), red (RX). I don't think I see the TX light lighting up, as this might be the light for when the DB9/COM connected device transfers data downward. I'm guessing, WINE is yet to be configured to deal with common RX/TX requests as noted above. The only other DB9/COM device I have is a GPS hockey puck antenna, for which I do not currently have a desktop 12VDC power supply yet and I know this device constantly outputs GPS data not likely requiring any request packet to initiate the data from being sent out. I do have another computer to run a terminal (ie. mintty), but hasn't been setup configured in this method for quite sometime. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29188 --- Comment #9 from Roger <rogerx.oss(a)gmail.com> --- A quick snip of "WINEDEBUG=+relay,+snoop wine .my.exe &>/tmp/debug_pipe" 0023:CALL Location.(a)TLocationObject@Set$q17System(a)AnsiString(00632038,00000000) ret=00451dd4 0023:RET Location.(a)TLocationObject@Set$q17System(a)AnsiString() retval=0033f83c ret=00451dd4 0023:CALL borlndmm.(a)Borlndmm@SysGetMem$qqri() ret=0048e673 0023:RET borlndmm.(a)Borlndmm@SysGetMem$qqri() retval=006338bc ret=0048e673 0023:CALL cc3260mt._memset(006338c0,00000000,00000001) ret=0040ac9f 0023:RET cc3260mt._memset() retval=006338c0 ret=0040ac9f 0023:CALL borlndmm.(a)Borlndmm@SysGetMem$qqri() ret=0048e673 0023:RET borlndmm.(a)Borlndmm@SysGetMem$qqri() retval=006338f0 ret=0048e673 0023:CALL cc3260mt._memset(006338f4,00000000,00000001) ret=0040ac9f 0023:RET cc3260mt._memset() retval=006338f4 ret=0040ac9f 0023:CALL borlndmm.(a)Borlndmm@SysFreeMem$qqrpv() ret=0048e693 0023:RET borlndmm.(a)Borlndmm@SysFreeMem$qqrpv() retval=00000000 ret=0048e693 0023:Call KERNEL32.CreateFileA(00626544 "COM4",c0000000,00000000,00000000,00000003,40000080,00000000) ret=0045edf6 0023:Ret KERNEL32.CreateFileA() retval=00000090 ret=0045edf6 0023:Call KERNEL32.SetupComm(00000090,00001000,00001000) ret=0045ee28 fixme:comm:set_queue_size insize 4096 outsize 4096 unimplemented stub 0023:Ret KERNEL32.SetupComm() retval=00000001 ret=0045ee28 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29188 --- Comment #10 from Roger <rogerx.oss(a)gmail.com> --- Grepping some of the debug output, I think the following is very likely relevant here! trace:comm:get_irq_info TIOCSERGETLSR err Inappropriate ioctl for device trace:comm:get_modem_status 0146 -> MS_RLSD_ON MS_DSR_ON The above TIOCSERGETLSR was previously also reported, and likely suspected as the root cause. For those referencing this bug, please see "http://wine-wiki.org/index.php/Debugging_Wine_Examples#Com_Ports" The above error was easily found using 'WINEDEBUG="+comm,+file" wine my.exe', and doesn't look like Wine was able to even open a COM port because of the TIOCSERGETLSR error. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29188 Alex Henrie <alexhenrie24(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |alexhenrie24(a)gmail.com --- Comment #11 from Alex Henrie <alexhenrie24(a)gmail.com> --- I just tested this and had no problems communicating between PuTTY on Wine on a USB serial port and minicom on another USB serial port connected by a null modem. Without an example program to demonstrate the problem, this bug report will eventually be closed as irreproducible. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29188 --- Comment #12 from Roger <rogerx.oss(a)gmail.com> --- Understood. I have been using a VirtualBox Windows XP session for providing serial communications for some proprietary radio hardware and software. (Too much to do, so little time available for bug tracing!) With the advent of rtl-sdr devices, native linux applications are more likely, however a few developers are still developing "Windows only" applications for even rtl-sdr devices. The idea of using command line only tools and reducing CPU usage is largely catching on, due to smaller platforms. As soon as I have my radio serial device available for testing, I'll give the latest Wine a try. FreeScan is the application I've recently been using, instead of the proprietary Uniden software. This bug was evident with both applications, using a serial to USB converter. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29188 --- Comment #13 from Roger <rogerx.oss(a)gmail.com> --- I'm able to read through the serial to USB convertor using the mct_u232 driver. While reading, wine spawned the following error: fixme:comm:set_queue_size insize 4096 outsize 4096 unimplemented stub After apparently stopping the assigned task, wine spawned the following error: err:comm:stop_waiting failed to clear waiting state: 0xc0000008 Unknown if the two errors caused any problems with the data transfer, but guessing the first error was probably treated as a notice or there's a fall back for the device. The second error would have to check the data transferred for any problems. Apparently, the device treated both as notices and the application apparently functioned as it would have under MS Windows. (Bugs and all. Could be those errors were spawned by the original MS Windows application binary for all I know.) I have not tried writing to the device through the serial USB converter, due to migrating to another application for maintaining the device. If you can write through the serial USB converter, probably a safe bet to close this bug. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29188 winetest(a)luukku.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |winetest(a)luukku.com --- Comment #14 from winetest(a)luukku.com --- I make no promises for this, but this bug might have been improved in wine-git version. Since bug 11811 got fixed. The fix will be in next wine 2.8 and wine-staging 2.8 release. And can be used with git if you are familiar building your own wine. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29188 Bruno Jesus <00cpxxx(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |WORKSFORME Status|UNCONFIRMED |RESOLVED --- Comment #15 from Bruno Jesus <00cpxxx(a)gmail.com> --- After reading the bug again I think it is safe to close as worksforme. There was no easy way to test the bug in the same way as original reporter, it requires specific software and hardware. Serial port loop in usb serial converter and null modem between 2 serial ports work (comment 11). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29188 --- Comment #16 from Roger <rogerx.oss(a)gmail.com> --- The MS Windows based software initially utilized was (I think) Uniden's software. So I'm guessing the software was very likely using some really basic MS Windows communication functions/protocols/routines. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29188 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #17 from Austin English <austinenglish(a)gmail.com> --- Closing. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
wine-bugs＠winehq.org