| 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 <2014> 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 <2014> 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | RE: Streamdevice 2.6 autoconnection failure using drvAsynSerialPort |
| From: | Mazanec Tomáš <[email protected]> |
| To: | Mark Rivers <[email protected]>, "[email protected]" <[email protected]> |
| Date: | Tue, 8 Apr 2014 14:19:48 +0000 |
|
Hi Mark Thanks for a quick response. The IOC runs on Scientific Linux 6.5 x86-64 and its default kernel. Yes, I have upgraded it (from 6.4 to 6.5) prior to SynApps upgrade. Linux udev system is configured in a way that my usb-serial device gets always the same device name (/dev/ttyUSBPIC) no matter what other devices are present (major, minor device numbers can change). I've double-checked Asyn 4.21 re-connection ability using asynRecord (.CNCT, .PCNCT). It works fine, so the issue might be a glitch in the new StreamDevice. Nevertheless, I've kept SynApps-5-6 installed and compared re-connection behavior to 5.7. The older version is fine -- If my usb-serial device is physically disconnected, IOC with SynApps-5-6 reports: 2014/04/07 16:55:20.994 PORT EEE:volts: connection closed in write 2014/04/07 16:55:25.994 PORT EEE:volts: pasynCommon->connect() failed: /dev/ttyUSBPIC Can't open No such device 2014/04/07 16:55:25.994 PORT EEE:volts: Protocol aborted and when the usb-serial device is connected back, R/W operations continue as usual. Whereas with the new version (5.7), IOC shell is kind of silent unless I try to reload StreamDevice protocol : epics> streamReload EEE:volts 2014/04/08 11:46:52.567355 _main_ StreamCore::finishProtocol(EEE:volts): Still waiting for writeSuccess() 2014/04/08 11:46:52.567398 _main_ EEE:volts: Protocol aborted or unless I try to use StreamDevice's connect command (through the EEE:CONNECT PV): epics> dbpf EEE:CONNECT 1 DBR_STRING: "ON" epics> 2014/04/07 17:10:06.446437 timerQueue EEE:CONNECT: Connect failed 2014/04/07 17:10:06.446482 timerQueue EEE:CONNECT: Protocol aborted ?2014/04/07 17:10:07.536724 timerQueue EEE:CONNECT: Connect failed ?2014/04/07 17:10:07.536747 timerQueue EEE:CONNECT: Protocol aborted but the connection is not re-established anyway. Furthermore, protocol reload makes IOC shell stuck. There is an older post about different connection issue, but also with StreamDevice & Asyn. So, with the new version (5.7), I've checked whether the timerQueue thread is OK and checked for any locked mutexes. The thread is OK. There is a mutex reported as locked once the usb-serial device is diconnected, however it remains locked when the device is connected back. epics> epicsMutexShowAll 1 ellCount(&mutexList) 112 ellCount(&freeList) 0 epicsMutexId 0x1d5bfd0 source ../../asyn/asynDriver/asynManager.c line 1868 No mutexes remain locked after the usb-device re-connection with the older version (5.6). But this could be just a result of the issue. Tomas Od: Mark Rivers [[email protected]]
Odesláno: 7. dubna 2014 18:36 Komu: Mazanec Tomáš; [email protected] Předmět: RE: Streamdevice 2.6 autoconnection failure using drvAsynSerialPort Hi Tomas,
There were no substantive changes in the drvAsynSerialPort code between asyn 4.18 and asyn 4.21. SVN tag 1917 is asyn 4.18 and tag 2203 is asyn 4.21.
Here are the differences:
corvette:asyn/asyn/drvAsynSerial>svn diff -r1917:2203 drvAsynSerialPort* Index: drvAsynSerialPort.c =================================================================== --- drvAsynSerialPort.c (revision 1917) +++ drvAsynSerialPort.c (revision 2203) @@ -103,12 +103,12 @@ if ((ioctl(tty->fd, FIOBAUDRATE, tty->baud) < 0) && (ioctl(tty->fd, SIO_BAUD_SET, tty->baud) < 0)) { epicsSnprintf(pasynUser->errorMessage, pasynUser->errorMessageSize, - "SIO_BAUD_SET failed: %s\n", strerror(errno)); + "SIO_BAUD_SET failed: %s", strerror(errno)); return asynError; } if (ioctl(tty->fd, SIO_HW_OPTS_SET, tty->termios.c_cflag) < 0) { epicsSnprintf(pasynUser->errorMessage, pasynUser->errorMessageSize, - "SIO_HW_OPTS_SET failed: %s\n", strerror(errno)); + "SIO_HW_OPTS_SET failed: %s", strerror(errno)); return asynError; } #else @@ -116,7 +116,7 @@ tty->termios.c_cflag |= CREAD; if (tcsetattr(tty->fd, TCSANOW, &tty->termios) < 0) { epicsSnprintf(pasynUser->errorMessage, pasynUser->errorMessageSize, - "tcsetattr failed: %s\n", strerror(errno)); + "tcsetattr failed: %s", strerror(errno)); return asynError; } #endif @@ -253,12 +253,12 @@ } if(cfsetispeed(&tty->termios,baudCode) < 0 ) { epicsSnprintf(pasynUser->errorMessage,pasynUser->errorMessageSize, - "cfsetispeed returned %s\n",strerror(errno)); + "cfsetispeed returned %s",strerror(errno)); return asynError; } if(cfsetospeed(&tty->termios,baudCode) < 0 ) { epicsSnprintf(pasynUser->errorMessage,pasynUser->errorMessageSize, - "cfsetospeed returned %s\n",strerror(errno)); + "cfsetospeed returned %s",strerror(errno)); return asynError; } } @@ -452,7 +452,7 @@ tcflush(tty->fd, TCOFLUSH); #endif #ifdef vxWorks - ioctl(tty->fd, FIOCANCEL, NULL); + ioctl(tty->fd, FIOCANCEL, 0); /* * Since it is possible, though unlikely, that we got here before the * slow system call actually started, we arrange to poke the thread @@ -509,14 +509,14 @@ */ if ((tty->fd = open(tty->serialDeviceName, O_RDWR|O_NOCTTY|O_NONBLOCK, 0)) < 0) { epicsSnprintf(pasynUser->errorMessage,pasynUser->errorMessageSize, - "%s Can't open %s\n", + "%s Can't open %s", tty->serialDeviceName, strerror(errno)); return asynError; } #if defined(FD_CLOEXEC) && !defined(vxWorks) if (fcntl(tty->fd, F_SETFD, FD_CLOEXEC) < 0) { epicsSnprintf(pasynUser->errorMessage,pasynUser->errorMessageSize, - "Can't set %s close-on-exec flag: %s\n", + "Can't set %s close-on-exec flag: %s", tty->serialDeviceName, strerror(errno)); close(tty->fd); tty->fd = -1; @@ -578,7 +578,7 @@ asynPrint(pasynUser, ASYN_TRACE_FLOW, "%s write.\n", tty->serialDeviceName); asynPrintIO(pasynUser, ASYN_TRACEIO_DRIVER, data, numchars, - "%s write %d\n", tty->serialDeviceName, numchars); + "%s write %lu\n", tty->serialDeviceName, (unsigned long)numchars); if (tty->fd < 0) { epicsSnprintf(pasynUser->errorMessage,pasynUser->errorMessageSize, "%s disconnected:", tty->serialDeviceName); @@ -672,7 +672,7 @@ } if (maxchars <= 0) { epicsSnprintf(pasynUser->errorMessage,pasynUser->errorMessageSize, - "%s maxchars %d Why <=0?\n",tty->serialDeviceName,(int)maxchars); + "%s maxchars %d Why <=0?",tty->serialDeviceName,(int)maxchars); return asynError; } if (tty->readTimeout != pasynUser->timeout) { @@ -775,8 +775,8 @@ data[nRead] = 0; else if (gotEom) *gotEom = ASYN_EOM_CNT; - asynPrint(pasynUser, ASYN_TRACE_FLOW, "%s read %d, return %d\n", - tty->serialDeviceName, *nbytesTransfered, status); + asynPrint(pasynUser, ASYN_TRACE_FLOW, "%s read %lu, return %d\n", + tty->serialDeviceName, (unsigned long)*nbytesTransfered, status); return status; }
So the changes are removing “\n” from the end of epicsSNprintf formats, and some other minor changes to avoid compiler warnings.
Is this on Linux?
Have you upgraded the OS?
I think any change in behavior is likely due either to a change in StreamDevice or a change in the OS, and not due to any change in asyn.
Mark
From: [email protected] [mailto:[email protected]]
On Behalf Of Mazanec Tomáš
|